AES key sizes, etc.
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