Re: [P1619-2] Question: Should we only allow one data unit size within a key scope?
I still think changing the standard is not necessary, as argued before.
Does anyone know a real life application of random access data storage, where the block size varies? Its description would help us understanding the requirements. The controller still has to be able to read/write blocks, without knowing anything about the rest.
Variable block-lengths equally concern P1619 and P1619.2.
With the proposed new paragraph we have to define "metadata", and tell, what is not metadata. It would be better just to require that the encryption module must be able to "securely" determine the length of blocks, meaning that an adversary cannot set or change this information.
With the new text the source of associated data cannot be only the position of the data block within the key scope. It has to depend on the size of the current block, too, but leaving the details to the implementer is dangerous: his choice can be insecure (e.g. simply adding the block length to the block offset).
Laszlo
David McGrew <mcgrew@xxxxxxxxx>
David McGrew <mcgrew@xxxxxxxxx>
No Phone Info Available
11/11/2009 10:20 AM
Please respond to
David McGrew <mcgrew@xxxxxxxxx> |
|
|
Hi Matt,
On Oct 25, 2009, at 2:27 PM, Matt Ball wrote:
Hi David,
Thank you for your responses.
[Just as a clarification, I made a minor typo below concerning 1619 vs. 1619.1: IEEE Std 1619-2007 standardizes XTS-AES, which requires fix data unit sizes within a keyscope. IEEE Std 1619.1-2007 standardizes the authenticated encryption modes of CCM, GCM, CBC-HMAC-SHA and XTS-HMAC-SHA, all of which can have variable data unit sizes within a key scope (using 1619 terminology). I had incorrectly said 1619 instead of 1619.1 for the authenticated encryption modes.]
Overall, I think it's possible to allow differently sized data units within a key scope, but we'll need to be careful about correctly crafting the language. I prefer to keep the data units the same size (because it's simpler), but if there is a need for allowing variable-length data units, here is some proposed text to append to P1619.2/D11, page 4, starting after line 14:
An implementation should keep the size of the data units the same within a key scope. If an implementation allows variable-length data units within a key scope, then the implementation's design should be such that it is able to unambiguously determine the length of each data unit without using metadata that is potentially under the control of an adversary.
Feel free to suggest any changes to this text. I'd like to use a 'shall' in this text instead of a 'should', but I'm having difficulty determining how to verify or enforce such a fuzzy requirement.
looks good to me. Here is a short possible addition:
An implementation should keep the size of the data units the same within a key scope. If an implementation allows variable-length data units within a key scope, then the implementation's design should be such that it is able to unambiguously determine the length of each data unit without using metadata that is potentially under the control of an adversary, and the associated data for two data units with distinct lengths must be distinct.
David
See comments below:
On Sun, Oct 25, 2009 at 7:27 AM, David McGrew wrote:
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.
(See clarification above concerning 1619 vs 1619.1: 1619.1 does have the property of allowing variable block sizes; 1619 does not, within a key scope). Allowing blocks of differing lengths is an advantage only if used securely. But I do understand that there's only so much you can do as a block cipher mode designer to prevent the users from abusing the mode.
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.
There are no 'compatibility' issues between 1619 and 1619.2, only consistency issues. That said, we can always change things to suit new requirements.
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.
I think this is the case we're trying to avoid or at least discourage. If these two hard disks are part of the same system, it's potentially secure to use the same key to encrypt both (if the tweak values are uniquely maintained), but if these two hard disks are independent, then you have the problem of potentially reusing tweak values in the two different contexts. I think it would be much better in this example to use different keys for each hard disk, or to derive them from a master key.
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.
From the perspective of the XCB transform as an isolated black box, this is true. However, from a system perspective, using XCB within several consecutive variable-length blocks could lend itself to attacks where the attacker changes the meaning of the data by changing its geometry. Valid data units could be truncated or extended with random data.
On Oct 24, 2009, at 8:08 AM, Matt Ball wrote:
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.
Personally, I take this as a security-relevant issue because in P1619.2 encryption, we're assuming that there is no authentication, including within the metadata. If the data unit size is fixed, the only knob an attacker has is randomizing an entire data unit. If the data unit size is variable, the attacker can also arbitrarily change data unit sizes, potentially making them so small that the benefit of wide-block encryption is negated. It would also be possible to shift the data geometry by changing data unit sizes.
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.
We can probably address this issue with such a statement, but will need to be careful in crafting the requirements so that they are verifiable (see top).
Let me pose the question slightly differently: What is an example of a system where using P1619.2 encryption with variable data unit sizes is a secure solution, but it is not possible in the same system to use an authenticated encryption mode (like those in IEEE Std 1619-2007)?
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.
Here again, I would argue that it is not a good idea to use the same key to encrypt data on two different disks, unless these disks also coordinate the tweak values (a.k.a. associated data). That said, such systems can be secure, so we'll need to find a way to allow them without allowing blatantly insecure systems.
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.
Any other thoughts?
Cheers,
-Matt
On Fri, Oct 23, 2009 at 12:07 PM, Robert A. (Bob) Lockhart <rlockhart@xxxxxxxx> wrote:
Matt,
If I understand what you are asking I think this is an implementation issue and not a specific mode issue. If someone wants to build an implementation that makes use of variable data unit sizes that should be their call as long as they can determine the sizes of the data units.
Doesn't do much for interoperability but it does leave the mode extensible for different applications and open to other standards to make use of it in a way that suits their needs.
Bob L.
Robert A. (Bob) Lockhart
Senior Solutions Architect
Thales Information Systems Security
Matt Ball wrote:
Hi Folks,
One of the questions from the P1619.2 sponsor ballot is as follows:
(Page 4, Subclause 5, line 12): Note that for IEEE Std 1619-2007, all data units within a particular key scope are required to have the same size. The sentence here allows for them to be different sizes. Do we want this? If different sizes are allowed, how does an implementation track each size, and are there security implications with an adversary being potentially able to change these sizes, since there is no authentication in this system?
What are the thoughts from the group?
--
Thanks!
Matt Ball, Chair, IEEE P1619 Security in Storage Working Group
Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021
Work: 303-272-7580, Cell: 303-717-2717
--
Thanks!
Matt Ball, Chair, IEEE P1619 Security in Storage Working Group
Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021
Work: 303-272-7580, Cell: 303-717-2717
--
Thanks!
Matt Ball, Chair, IEEE P1619 Security in Storage Working Group
Staff Engineer, Sun Microsystems, Inc.
500 Eldorado Blvd, Bldg #5 BRM05-212, Broomfield, CO 80021
Work: 303-272-7580, Cell: 303-717-2717
