[EMAIL PROTECTED] wrote:
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.n 16 byte blocks on disk where data is encrypted ONLY with K1The 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 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 |
- RE: LBA-to-I mapping & key scopes laszlo
- RE: LBA-to-I mapping & key scopes Colin Sinclair
- RE: LBA-to-I mapping & key scopes laszlo
- RE: LBA-to-I mapping & key scopes laszlo
- Re: LBA-to-I mapping & key scopes Michael Torla
- RE: LBA-to-I mapping & key scopes laszlo