There is no problem with K2 being different. The issue is rather, if K1 is the same in many drives (key scopes) and I=0 is allowed. Independent on the values of K2, there will be a single 16-byte block encrypted with the same key material/tweak value on these drives. If an attacker can collect these from many-many drives, he could mount an attack on AES. This is not a real threat.
What is a more realistic weakness is that this attacker can tell if the corresponding plaintext blocks are the same or not. LBA0 is most likely the master boot record, so an attacker could guess if the drive is used to boot Windows or Linux or Mac, or it has a modified MBR, like at a multi-boot setup. Still, to get this information the attacker has to destroy the drives, and he cannot do much with this knowledge. Nevertheless, Rob's proposal that the disk ID be included in the initial I value (maybe key-hashed) would solve the I=0 problem. The more I think about it, the more I like this idea. Laszlo > -------- Original Message -------- > Subject: Re: LBA-to-I mapping & key scopes > From: Michael Torla <[EMAIL PROTECTED]> > Date: Fri, December 16, 2005 2:23 pm > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > > [EMAIL PROTECTED] wrote: n 16 byte blocks on disk where data is > encrypted ONLY with K1 > The second block is already tweaked with I=1, making the encryption > dependent on K2. Only the 16-byte block with I=0 is encrypted alone > with K1, that is one 16-byte block per disk drive (or key scope). If > there are many drives using the same K1 key (which should not happen, > being bad practice), and an attacker knows which ones, and he has the > ability to put every one of them on a spin stand, then he can gain a > few plaintext/ciphertext pairs corresponding to the same, unknown key > K1. If AES was so weak that this few pairs presented some security > problems, we had to replace AES with something else, anyway. > > Laszlo > Unless scoping restrictions are documented in the specification, you have > to assume the worst case deployment for K1 and K2. For worst case, I would > assume that K1 applies to every disk drive deployed at the US Government, and > that a different K2 is applied to every sector in every disk drive. > > In all seriousness, I could see a unix-like environment where data is owned > by multiple different users, and each user gets a unique K2 value. Are you > going to restrict the number of users who can store data to a disk? > > mt >
