Key distinguisher attack (Was: how serious is the leak of K2?)
I will jump in here. First, I will not force through the standard
with issues that we can clearly describe in english that we all can
understand and agree with. Laszlo, please be patient and trust me for
a minute. I believe I am arguing your side of this issue.
Below there are numbered questions. Please, please, please, if you do
not agree with any of these items, please respond to all the
questions so that we can determine what we agree to and what we do not.
Lets accept some statements of fact that we can agree to.
1) I suspect that we can all agree that if an attacker learns K2 then
LRW is the same as ECB. Is there any problems with this statement?
2) In general, Given 2 sectors, s1 and s2, and random data coming in,
x1 and x2, the probability of any x1*s1 ==x2*s2 is the birthday
surprise. The security proof of LRW states this. with ~2^64 blocks (a
large number) there is a 50/50 chance that there is one equal input
to the AES stage. Isn't this probability is covered in our key
lifetime statements, so this is not an issue?
Given these two statements there are three key disclosure attacks can
be described....
3) Assume that an attacker has a non-trivial probability to gain
access to both suspected K1 and K2 values, he can do trial decryption
with these keys. This is a "Full key disclosure event", and there are
no FIPS certified modes that can withstand a disclosure like this. Is
this correct?
4) If the attacker has non-trivial probability of access to K2 and
not K1, then the attacker has an ability to determine if the K2 that
they have is indeed K2 by crafting numbers n1, n2 and n3 such that
K2*s1*n1 == K2*s2*n2 == K2*s3*n3 and then determine the value of K2
with overwhelming probability. Lets call this "Partial Key Disclosure
of K2 event", and the system has now degraded to ECB. Is this correct?
5) If the attacker has non-trivial probability of accessing K1 and
not K2, then I believe the information is still secure as long as K2
remains private up to the birthday bounds? Is this correct?
Question 4 describes a distinguisher for suspect K2 values. (This is
not true for suspect K1 values.) I think that this is an issue we can
discuss as long as we can get agreement. Please.
Jim
On Jun 2, 2006, at 3:05 PM, Laszlo.Hars@SEAGATE.COM wrote:
> We have seen that there is a possibility in real-life systems that K2
> accidentally lands on the encrypted disk drive, and so exposed to an
> eavesdropper. An attacker can increase the chance of this to happen to
> dangerous levels. The question is: how serious is the leak of K2?
>
> It allows attacker A to create any plaintext P in any location i on
> disk,
> which means the worst malleability possible, like with ECB mode.
> (Secrets
> are not necessarily revealed.)
>
> We assume the following:
> (a) A can make user U to store a prefabricated single block of data
> Q to a
> chosen location j.
> (b) later A can read the ciphertext Cj
> (c) A can write a new ciphertext in place of Ci.
>
> The critical step is (a). Q is 16 bytes of personalized data, so no
> virus
> checker complains. It is going to be stored in a place, where it
> never gets
> executed, so this attack is less suspicious than planting malware.
>
> By inspecting an encrypted drive several times, the attacker can
> find where
> temporary internet files are going to be stored following the last
> inspection (so A lures U to a website, where an embedded picture
> ends up as
> a temporary internet file). The area of the swap- and hibernation
> data is
> also easy to find (so a special picture in memory can be swapped
> out). For
> a new file, Windows chooses the beginning of the unused disk space,
> easily
> identified by the location of recent changes on disk (so A
> persuades U to
> save a link, a document or some other not executable "safe" file).
>
> The attack is easy: Q = P ^ jK2 ^ iK2 is written to location j, so
>
> Cj = jK2 ^ K1(P^jK2^iK2 ^ jK2) = jK2 ^ K1(P ^ iK2)
>
> A writes in place of Ci the data
>
> Cj ^ jK2 ^ iK2 = iK2 ^ K1(P ^ iK2), which will decrypt to P.