Re: AES key sizes, etc.
As I recall, the discussion on key size also had some additional points.
One concern was that the encryption would be implemented in hardware and
the more options allowed the more complex the hardware. Transistors are
cheap, but for example to go from supporting one transform to supporting
all current standard transforms would increase gate counts from about
15k to over 150k. Then there is the need for speed. Today's storage
interfaces can run up to 10 gigabits/sec. Therefore not only do we need
hardware but it needs to be fast and able to encrypt large globs in
parallel. This will increase gate count even more.
I think another goal we have is to keep it as simple as possible (it
will get more complex over time anyway) and since we do not have any
legacy implementations we have the opportunity to keep it simple. If we
were to pick just one solution then it would make sense to pick the
strongest one that is practical to implement and that meets long term
needs. Data may be around for a long time.
A third goal is interoperability. One may wish to read the data on a
different system now or in the future, particularly if it is removable
or moveable as in remote archiving. Since the data is already encrypted,
the hardware will need to support all possible formats. This is not like
a communication protocol where options can be negotiated. If we support
multiple transforms then a mechanism will be needed to determine which
one was used.
My two cents worth,
Steve
Shai Halevi wrote:
>Recall that last time we had a long (and futile) argument about which
>AES key sizes we need to allow and/or mandate. And notice that the exact
>same argument is also applicable to which of the two transforms (EME/LRW)
>we want to allow and/or mandate. Applying here the argument that we
>should only mandate the "strongest" solution would imply mandating only
>EME, yet the whole reason for suggesting LRW was to allow vendors to opt
>for the cheaper option.
>
>I suggest going for one of the following two options: one is to allow
>a complient implementation to choose any (one or more) combination of
>transform and AES key-size. Yes, this allows two complient implementations
>that are not inter-operable, but this is a very "weak form" of non-
>interoperability. Specifically, given the appropriate libraries for
>AES and for EME and LRW, one could easily write a short conversion
>program (maybe 300 lines of code in C) to translate from one format to
>the other. Since we don't really think of changing vendors as something
>that is done twice a day, it doesn't strike me as such a terrible thing.
>We can even attach the above 300 LOC program to the standard as a
>"supporting document".
>
>The other option is to allow a complient implementation to choose any
>combincation for encryption, but to mandate that it has to implement
>ALL the options for decryption. This way, one can still market a hardware
>box, claiming that it cannot possibly encrypt with a key shorter than
>256 bits (not even due to admionistrator error). Moreover, there is no
>need to add "universal decryption" to the hardware box. It is enough to
>provide with the box also a small software utility implementing the
>300 LOC program from above.
>
>I hope that one of these options will be acceptable to all, so we
>can put this unnecessary argument behind us.
>
>-- Shai
>
>
>