RE: AES key sizes, etc.
Couple of comments:
1. I disagree with Shai's statement that "you can always add $500PC".
This type of approach is not taking into account the manageability of
resulting solutions and should, in general, be avoided. Adding a 500$ PC
costs much more in TCO than the initial 500$.
2. I would like to support Steven's point that one should limit the
number of transforms offered in order to simplify hardware.
3. As Shai pointed out in previous message, we should use "strongest
crypto possible given the constraints". To me, this means we should
mandate AES256 as the main engine. This is the strongest engine we know
of today, and using anything weaker does not make sense unless we claim
that "AES128 is good enough", and I think that most of us will agree
that we do not want to use such statements.
4. Decrypting data takes a substantial amount of time, even if we assume
that decryption itself is instantaneous. Even for high-end disks
sustaining more than 20MB/s (note that this is 60MB/s in reality, since
one has to account for failures) is not easy. At this speed, 10TB is
about a week. Most deployments cannot be taken down for a whole week,
and thus we need to be able to do decryption without taking the data
off-line. This makes a pure software solution very hard if not
infeasible.
(I do not want to get into an argument about disk speeds - even if
instead of a week, decryption takes a day, it is still unacceptable for
most customers).
-serge
-----Original Message-----
From: owner-stds-p1619@listserv.ieee.org
[mailto:owner-stds-p1619@listserv.ieee.org] On Behalf Of Shai Halevi
Sent: Monday, April 12, 2004 7:34 AM
To: stds-p1619@majordomo.ieee.org
Subject: 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