| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| Hi Matt, The ability of 1619.2 to handle blocks of differing lengths is an advantage; if 1619.1 doesn't have this property, then I suggest that we document it as an advantage over the earlier standard. It is a very useful feature of the AES-XCB algorithm that it can accept plaintexts of different sizes, and the definition of that algorithm should not unnecessarily restrict it. If for some standards-compatibility reason it is not possible to allow 1619.2 to have blocks with variable length, then the definition of AES-XCB should be such that it accepts varying lengths (as it is currently written) and the standard should include a sentence like "For reasons of compatibility with 1619-2007, plaintext blocks must have a fixed size, for any fixed key ..." But it would be a shame to have to do that. These questions were raised: 1. "If different sizes are allowed, how does an implementation track each size?" A good example of why it is useful to have an algorithm accept plaintexts of different sizes is the case in which a single key encrypts the disk blocks on two different disks that have blocks of different sizes. In this case, the encrypter/decrypter will know the size of the block based on information about the disk on which it resides. 2. "... are there security implications with an adversary being potentially able to change these sizes, since there is no authentication in this system?" The security model for XCB assumes that an attacker can submit plaintexts and/or ciphertexts that are adaptively chosen, and can have any lengths (within the admissible range). The cipher was designed with the expectation of being used with varying-length plaintexts. On Oct 24, 2009, at 8:08 AM, Matt Ball wrote: Hi Bob, But wouldn't it be better to let 1619.2 deliver to users all of the advantages that it has? Let's give the user all of the functionality that we've developed. Ideally, the size should be static based on design (e.g., the data unit is always a 512-byte hark disk logical block) so that an attacker can't change this size and change the meaning of the data. In the above description, it sounds like you are assuming that the data-storage system would be willing to write encrypted data of any length, i.e. that the system built around the encryptor has no idea what size the blocks are. If that were the case, the problem would not be with the cipher, but with the system. To deal with this issue, the standard could add a sentence like "The system must be aware of the sizes of the data blocks, and must not write a ciphertext data block that has the inappropriate value." This statement would be just as appropriate for 1619-2007 as the current work.
Using a single key to protect data on multiple disks, or multiple logical domains. For instance, a disk with 512 byte blocks and one with 520 byte blocks. In this example, if the associated data identifies the disk on which the block resides (as it should), then the information about the plaintext/ciphertext length is implicitly included in the associated data. David I can't think of such a system off-hand. On the other hand, I can think of many ways to abuse P1619.2 encryption by allowing variable data unit sizes, but omitting cryptographic integrity checking. |