[dm-crypt] iv generation

[dm-crypt] iv generation

[David McGrew]

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

Re: [dm-crypt] iv generation

[Arno Wagner]

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@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
> 

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
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