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.
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:15:20