DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] iv generation
Date: Sat, 20 Aug 2011 16:15:29 +0200	[thread overview]
Message-ID: <20110820141528.GA29578@tansi.org> (raw)
In-Reply-To: <EDB0C613-0E84-4780-A283-78E272FCDE2A@cisco.com>

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 

      reply	other threads:[~2011-08-20 14:15 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-19 20:47 [dm-crypt] iv generation David McGrew
2011-08-20 14:15 ` Arno Wagner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110820141528.GA29578@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox