Re: AES key sizes, etc.
On Thursday 25 March 2004 01:21 pm, Steven Sletten wrote:
> 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.
But that assumes that you have to implement everything in hardware,
which is never really true. Nowadays, nobody sells hardware anymore,
vendors sell "solutions". So you can always add to you "solution" a
$500 PC, and implement in software all these tarnsforms that you never
really intend to use (but have to implement in order to claim standard
compliance). I'm not saying that forcing vendors to do this stupidity
is a good thing, only that it is workable with no catastrophic
consequences.
> 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.
I can't really argue with that. From my perspective, this means mandating
EME-AES-32 with 256-bit AES key. Some members of this group will not be
happy with this choice, I think.
> 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.
Again, I don't why interoperability means that you have to be able to
decrypt every transform in hardware. You would only need that if you
plan on send data back and forth between two systems that use different
transforms, as a matter if everyday operation. This seems (to me) like
an extremely unlikely scenario. The more likely scenario is that you
usually work with just one transform, (the one implemented in hardware
in your system), and you may only be forced to switch to a different
transform when you replace your system. This is a "one time event",
and you can plausibly handle this by decrypting data off the old system
using software, and then send it to the new system to be encrypted with
the new transform.
-- Shai