As far as I can tell, the draft does not deal with storage encryption. Storage encryption is different from normal encryption, that you need to generate the same IV repeatedly, namely when accessing the same sector. At the same time the IV for a sector must be hard to predict without the key. And the same IV is used to encrypt different data, namely when a sector is written. And to add to the issue, you do not have any additional space for the IV generation to store additional input data. These are fundamental differentce to communication encryption, where you must avoid using the same IV twice, but IVs but IV predictability is far less of a problem and you can transfer additional data. Also, session keys in communication encryption do usually not live that long, while in storage encryption they (and the IVs) stay the same for the lifetime of the storage container, potentially for decades. In my experience, the two scenarios require separate treatment. If you do storage encryption IV generation with only communication encryption IV generation knowledge, you are bound to mess it up. I have seen it several times, and some of these people should really have known better. So my feedback at this time would be to make it very, very clear in the draft that the draft does not at all apply to storage encryption and that storage encryption has very different requirements from communication encryption. Should you (or somebody else) want to write an RFC on storage encryption IV generation (or storage encryption in general) I would be happy to contribute. I have before contributed to RFC5655. I would also be willing to contribute a section to your draft on why storage encryption is different from communication encryption and has different requirements and attack scenarios. Something along the lines of what I said above, but more detailed and with an overview on the attacks against storage encryption in contrast to communictaion encryption. Arno On Fri, Aug 19, 2011 at 01:47:32PM -0700, David McGrew wrote: > Hi Christophe, > > I was recently looking into dm-crypt, and I was interested to see > the different IV-generators that are defined in the code. That > looks like the right technical approach to me, and it occured to me > that you might have some insights on the IV generation draft [1] and > the implementation and testing guidance that it outlines. I would > be glad to hear comments from you (or others). > > regards, > > David > > [1] http://tools.ietf.org/html/draft-mcgrew-iv-gen-00 > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
