Re: Can someone please poke some holes in this idea?

New Message Reply About this list Date view Thread view Subject view Author view

David Wagner (daw@CS.Berkeley.EDU)
7 Oct 1998 11:16:16 -0700


In article <9810070253.AA20720@out-of-band.media.mit.edu>,
Lenny Foner <foner@media.mit.edu> wrote:
> An application I'm writing saves its state to disk every so often,
> using IDEA in CBC mode. [...]
>
> The question is, what's a reasonably safe way to do this?
>
> My current guess is this. We generate a 128-bit session key, Ks,
> which is used for keying the cipher. [...]
> We ask the user for a passphrase P. We compute:
> Pmd = MD5(P)
> Kx = Ks XOR Pmd
> So we now have the session key XOR'ed with a hash of the passphrase.
> We store it somewhere on disk.

Two observations:

o This provides no integrity protection for the stuff stored on disk.
   If protection against modification matters to your application, MAC
   the data before encrypting.

o I'm a little suspicious of using XOR to generate Kx from Ks and
   MD5(passphrase). I don't see an attack (if you're using Ks with IDEA),
   but my initial reaction is to suggest that it might be better to
   encrypt Ks with some cipher (e.g. IDEA) using MD5(passphrase) as
   the key, and store the result on disk.

   Here's why I say this. The reason is that if IDEA were vulnerable
   to differential related-key cryptanalysis, this protocol might be
   weak. The observation is that the attacker can flip a bit in Ks by
   flipping a bit or two on disk. Thus, if the attacker can get access
   to your disk sometime between two application runs, the attacker
   can force an arbitrary difference dKs into the session key: if the
   application originally encrypts the data with Ks, the attacker can
   force the application to decrypt with Ks \xor dKs the next time it
   runs. This is exactly the pre-condition needed for differential
   related-key cryptanalysis.

   Some ciphers are vulnerable to differential related-key cryptanalysis;
   others seem to be resistant. For IDEA, I don't know of any differential
   related-key attacks. Also, even if a related-key attack on IDEA were
   available, the assumptions needed to attack the application (roughly
   known plaintext, plus access to the disk between application runs) might
   not be terribly realistic in practice. Still, the related-key attack
   model has not been studied in nearly as much detail as standard
   chosen-plaintext attack models, so I think it is entirely possible that
   there might be some attack which just haven't been found by the academic
   community yet.
   
   For that reason, I am a little suspicious of any protocol like this
   which fails if the underlying cipher is vulnerable to related-key attacks.
   Then again, I'm very conservative.


New Message Reply About this list Date view Thread view Subject view Author view

 
All trademarks and copyrights are the property of their respective owners.

Other Directory Sites: SeekWonder | Directory Owners Forum

The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:15:20