* [dm-crypt] Authenticated Encryption for dm-crypt @ 2013-05-20 22:31 Ralf Ramsauer 2013-05-20 23:41 ` Arno Wagner 0 siblings, 1 reply; 7+ messages in thread From: Ralf Ramsauer @ 2013-05-20 22:31 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-crypt] Authenticated Encryption for dm-crypt 2013-05-20 22:31 [dm-crypt] Authenticated Encryption for dm-crypt Ralf Ramsauer @ 2013-05-20 23:41 ` Arno Wagner 2013-05-20 23:59 ` Ralf Ramsauer 0 siblings, 1 reply; 7+ messages in thread From: Arno Wagner @ 2013-05-20 23:41 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-crypt] Authenticated Encryption for dm-crypt 2013-05-20 23:41 ` Arno Wagner @ 2013-05-20 23:59 ` Ralf Ramsauer 2013-05-21 2:17 ` Arno Wagner 0 siblings, 1 reply; 7+ messages in thread From: Ralf Ramsauer @ 2013-05-20 23:59 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-crypt] Authenticated Encryption for dm-crypt 2013-05-20 23:59 ` Ralf Ramsauer @ 2013-05-21 2:17 ` Arno Wagner 2013-05-21 7:24 ` octane indice 0 siblings, 1 reply; 7+ messages in thread From: Arno Wagner @ 2013-05-21 2:17 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-crypt] Authenticated Encryption for dm-crypt 2013-05-21 2:17 ` Arno Wagner @ 2013-05-21 7:24 ` octane indice 2013-05-21 13:58 ` Ralf Ramsauer 0 siblings, 1 reply; 7+ messages in thread From: octane indice @ 2013-05-21 7:24 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-crypt] Authenticated Encryption for dm-crypt 2013-05-21 7:24 ` octane indice @ 2013-05-21 13:58 ` Ralf Ramsauer 2013-05-21 17:22 ` Milan Broz 0 siblings, 1 reply; 7+ messages in thread From: Ralf Ramsauer @ 2013-05-21 13:58 UTC (permalink / raw) Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-crypt] Authenticated Encryption for dm-crypt 2013-05-21 13:58 ` Ralf Ramsauer @ 2013-05-21 17:22 ` Milan Broz 0 siblings, 0 replies; 7+ messages in thread From: Milan Broz @ 2013-05-21 17:22 UTC (permalink / raw) To: Ralf Ramsauer; +Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-05-21 17:23 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-05-20 22:31 [dm-crypt] Authenticated Encryption for dm-crypt Ralf Ramsauer 2013-05-20 23:41 ` Arno Wagner 2013-05-20 23:59 ` Ralf Ramsauer 2013-05-21 2:17 ` Arno Wagner 2013-05-21 7:24 ` octane indice 2013-05-21 13:58 ` Ralf Ramsauer 2013-05-21 17:22 ` Milan Broz
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.