[dm-crypt] Authenticated Encryption for dm-crypt

[dm-crypt] Authenticated Encryption for dm-crypt

[Ralf Ramsauer]

Hi,

are there any weighty reasons why there is no support for authenticated
encryption for
dm-crypt or did simply no one want to implement it up to now? :-)

Did anyone do any work on this topic up to now? I think authenticated
encryption would
be a nice feature.

Regards

-- 
Ralf Ramsauer

PGP: 0x8F10049B

Re: [dm-crypt] Authenticated Encryption for dm-crypt

[Arno Wagner]

I am not really sure what you mean. 

Per-sector authenticatipn is infeasible as it requires 
additional space. This is not communication encryption
where attaching a few bytes is possible. This is disk
encryption where 512 encrypted bytes have to fit exactly
into 512 bytes of space. 

Do you mean the header should authenticate itself to the 
user in decryption? That would only make sense if a 
malicious disk encryption system is assumed and would 
have to be done before the passphrase is given. The
attacker model would be something like disk-impersonation
gere or a cryptsetup or kernel that tries to steal the
passphrase.

Arno


On Tue, May 21, 2013 at 12:31:09AM +0200, Ralf Ramsauer wrote:
> Hi,
> 
> are there any weighty reasons why there is no support for authenticated
> encryption for
> dm-crypt or did simply no one want to implement it up to now? :-)
> 
> Did anyone do any work on this topic up to now? I think authenticated
> encryption would
> be a nice feature.
> 
> Regards
> 
> -- 
> Ralf Ramsauer
> 
> PGP: 0x8F10049B
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] Authenticated Encryption for dm-crypt

[Ralf Ramsauer]

Hi,
On 05/21/2013 01:41 AM, Arno Wagner wrote:
> I am not really sure what you mean. 
>
> Per-sector authenticatipn is infeasible as it requires 
> additional space. This is not communication encryption
> where attaching a few bytes is possible. This is disk
> encryption where 512 encrypted bytes have to fit exactly
> into 512 bytes of space. 
Well additional space is no problem in my point of view. Let's assume we
would tag a 512 sector with a "Mac" with 20 bytes length.
Then we would need ~20GiB for Tags for a disk with a size of 500GiB. We
still would have 480GiB for bulk data. In my opinion
that's a fair deal. The problem of the sector size could be solved by
tagging larger amounts of data with larger tags. I know
that's not really more secure but it solves the problem with the sector
size (e.g. tag 4KiB of data with 512 Byte Tags or sth. like that).
>
> Do you mean the header should authenticate itself to the 
> user in decryption? That would only make sense if a 
> malicious disk encryption system is assumed and would 
> have to be done before the passphrase is given. The
> attacker model would be something like disk-impersonation
> gere or a cryptsetup or kernel that tries to steal the
> passphrase.
No, i meant the point you mentioned above.

Regards
>
> Arno
>
>
> On Tue, May 21, 2013 at 12:31:09AM +0200, Ralf Ramsauer wrote:
>> Hi,
>>
>> are there any weighty reasons why there is no support for authenticated
>> encryption for
>> dm-crypt or did simply no one want to implement it up to now? :-)
>>
>> Did anyone do any work on this topic up to now? I think authenticated
>> encryption would
>> be a nice feature.
>>
>> Regards
>>
>> -- 
>> Ralf Ramsauer
>>
>> PGP: 0x8F10049B
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Ralf Ramsauer

PGP: 0x8F10049B

Re: [dm-crypt] Authenticated Encryption for dm-crypt

[Arno Wagner]

On Tue, May 21, 2013 at 01:59:01AM +0200, Ralf Ramsauer wrote:
> Hi,
> On 05/21/2013 01:41 AM, Arno Wagner wrote:
> > I am not really sure what you mean. 
> >
> > Per-sector authenticatipn is infeasible as it requires 
> > additional space. This is not communication encryption
> > where attaching a few bytes is possible. This is disk
> > encryption where 512 encrypted bytes have to fit exactly
> > into 512 bytes of space. 
> Well additional space is no problem in my point of view. 

Sorry, but it is a massive problem. This has been tried
before with massively negative impact on performance
and data integrity. 

> Let's assume we
> would tag a 512 sector with a "Mac" with 20 bytes length.
> Then we would need ~20GiB for Tags for a disk with a size of 500GiB. We
> still would have 480GiB for bulk data. In my opinion
> that's a fair deal. 

The additional space is not the problem. The problem is keeping 
data and additonal data consistent and keeping head-movements 
minimal. There is quite a bit of discussion and literature
around about these problems as this gets proposed time and again. 
If I remember correctly, some people even tried with custom disks 
that had 540 byte sectors or something like that. All efforts failed,
this idea always dies as soon as practical filesystem aspects come 
into play. 

> The problem of the sector size could be solved by
> tagging larger amounts of data with larger tags. I know
> that's not really more secure but it solves the problem with the sector
> size (e.g. tag 4KiB of data with 512 Byte Tags or sth. like that).

This fails once you have 512B writes. 

Arno



> > Do you mean the header should authenticate itself to the 
> > user in decryption? That would only make sense if a 
> > malicious disk encryption system is assumed and would 
> > have to be done before the passphrase is given. The
> > attacker model would be something like disk-impersonation
> > gere or a cryptsetup or kernel that tries to steal the
> > passphrase.
> No, i meant the point you mentioned above.
> 
> Regards
> >
> > Arno
> >
> >
> > On Tue, May 21, 2013 at 12:31:09AM +0200, Ralf Ramsauer wrote:
> >> Hi,
> >>
> >> are there any weighty reasons why there is no support for authenticated
> >> encryption for
> >> dm-crypt or did simply no one want to implement it up to now? :-)
> >>
> >> Did anyone do any work on this topic up to now? I think authenticated
> >> encryption would
> >> be a nice feature.
> >>
> >> Regards
> >>
> >> -- 
> >> Ralf Ramsauer
> >>
> >> PGP: 0x8F10049B
> >>
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> 
> 
> -- 
> Ralf Ramsauer
> 
> PGP: 0x8F10049B
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] Authenticated Encryption for dm-crypt

[octane indice]

En réponse à Arno Wagner <arno@wagner.name> :
> The additional space is not the problem. The problem is
> keeping  data and additonal data consistent and keeping
> head-movements  minimal. There is quite a bit of discussion
> and literature around about these problems as this gets
> proposed time and again. 
> If I remember correctly, some people even tried with custom
> disks  that had 540 byte sectors or something like that. All
> efforts failed, this idea always dies as soon as practical
> filesystem aspects come  into play. 
> 
Maybe it's off topic, but why we don't put integrity at
filesystem level?
If we mess something at ciphered level, we could detect
it at filesystem level because it's really unlikely that somebody
could break the ciphered level *and* keep filesystem integrity.

Thanks

Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com

Re: [dm-crypt] Authenticated Encryption for dm-crypt

[Ralf Ramsauer]

Arno, your objections are legitimate.Though I think that authenticity
would be a nice feature to dm-crypt.
And i also think, that it *could* be realisable.

Head movement is a real problem, but not for SSDs. Another solution
could be to outsource additional tag
data onto other harddrives. Also, not all tags need to be stored at the
same location. Another point:
if you would tag a 512 Byte sector with a 512 Byte tag then you could
store data and tags consecutively.
Dm-verity does almost the same, but it needs two different partitions to
store data and tags.
If those partitions are on the same drive you loose performence because
of the massive head movement.
But if you store tag and data on one partition consecutively in chunks
of 512 Byte it should be no problem
any more.

Regards

On 05/21/2013 09:24 AM, octane indice wrote:
> En réponse à Arno Wagner <arno@wagner.name> :
>> The additional space is not the problem. The problem is
>> keeping  data and additonal data consistent and keeping
>> head-movements  minimal. There is quite a bit of discussion
>> and literature around about these problems as this gets
>> proposed time and again. 
>> If I remember correctly, some people even tried with custom
>> disks  that had 540 byte sectors or something like that. All
>> efforts failed, this idea always dies as soon as practical
>> filesystem aspects come  into play. 
>>
> Maybe it's off topic, but why we don't put integrity at
> filesystem level?
> If we mess something at ciphered level, we could detect
> it at filesystem level because it's really unlikely that somebody
> could break the ciphered level *and* keep filesystem integrity.
No, that's not off topic, it's a good thought. But if integrity would
get part of an "underlying layer" then it would be filesystem independent.
As far as i know only few filesystems support integrity.
>
> Thanks
>
> Envoyé avec Inmano, ma messagerie renversante et gratuite : http://www.inmano.com
>
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Ralf Ramsauer

PGP: 0x8F10049B

Re: [dm-crypt] Authenticated Encryption for dm-crypt

[Milan Broz]

On 21.5.2013 15:58, Ralf Ramsauer wrote:
> Arno, your objections are legitimate.Though I think that authenticity
> would be a nice feature to dm-crypt.
> And i also think, that it *could* be realisable.

... And you are not the first thinking about this :-)

We even talked about using GCM mode (around 2011) but unfortunately
student interested in some proof-of-concept implementation for dmcrypt
abandoned this project.
(Maybe time for another try...)

Whatever, there are at least three basic concepts:

- one said, this should be done on higher level (where you know
which sectors contains real data - e.g. btrfs)

- second, which prefers separation of integrity and encryption
(see e.g. dm-integrity patches on dm-devel or dm-verity for read-only)
(You can stack integrity above dmcrypt.)

- and the third, using auth mode directly in dm-crypt
Here I would prefer to have some "standardised" on-disk layout for auth
tag. There are several approaches. (Some would work
better with non-rotational media, some are more problematic.)

(If you don't mind losing half of the disk space, you can internaly
use 1+1 sector (wasting second sector just for auth tag) and play
with disk limits/topology and sector size. This would work nicely even
for rotational media.

(Storing more tags in one sector is just slightly more complicated,
but it adds more risk for data corruption if write fails during
powerfail or so.)

I am not sure how much useful is using authenticated encyption
for real applications, but as my former colleague would say - please
send a patch :-)

Milan