> ----------
> From: No User[SMTP:[EMAIL PROTECTED]]
>
> "Hardware Performance Simulations of ..." is an exercise in irrelevance.
>
> NSA (hi, guys, tough stuff these remailer chains ?) wants us to
> believe that if a cypher is 2x faster in someone's implementation
> than some other cipher's implementation on the same process, then
> that is a criteria for selection. Or that it matters in any way.
>
> No shit.
>
Yes, speed in hardware matters. While there has been a lot of groups
studying performance in software, far fewer have looked at HW
implementations.
Don't try to argue that Moore's law will solve the problem; people's hunger
for
bandwidth grows faster - if you want to encrypt a gigabit VPN at a corporate
firewall, or megabit connections to a G3 (video) cellphone, going the HW
route is
very cost-effective. I'm glad that the NSA is looking at this - it's not as
if
no one else is allowed to, or that the AES selection process will place
undue
credibility on their reccomendations.
[...]
> First, encryption is one of the most computation-intensive tasks in
> mass use (so meterological models and similar do not count). More cycles
> per bit processed usually means that brute forcing the cypher is harder.
> Burning cycles is a part of being a cipher (not sufficient, of course.)
>
[As someone on this list used to say, he who will not do arithmetic is
doomed
to speak nonsense].
Beyond a certain key length, brute force ceases to be an interesting attack.
Consider: 18 months ago, distributed.net and Deep Crack found a 56 bit DES
key in 23 hours, searching 24% of the key space. There is also a 64 bit RC5
challenge underway at distributed.net. D.net is almost 25% of the way
through
that one, but it's taken 2.5 *years* to do so. With a 128 bit key, even if
you
could test 1key/cycle on a billion 1GHz processors, it would take trillions
of
years to get to the 25% mark. The protons will decay before that happens.
> Second, what we really want to know is what NSA knows about candidates
> that we will find out in 20 years (that's what happened with DES.)
>
What we know about DES and the NSA is: They greatly strengthened the
S-boxes against differential analysis, a technique not in the open
literature
at the time. They did not strengthen it against linear analysis - perhaps
they did not know about it. The key was shortened from 64 to 56 bits:
a move which many believe, then and now, was to allow the NSA to
build key-crackers (though I've heard arguments that the extra 8 bits in
the original Lucifer design did not add to the security of the cipher).
> And third, are Feistel nets doomed (cryptanalyzed) ? Looking at the
> history
> of crypto, it's about the time for the major paradigm shift. Unselfish
> help
> in creating AES by the agency whose sole purpose is to read traffic is a
> clear sign that something is ROTten. Would you buy a radar detector from
> highway patrol ?
>
Free-floating paranoia over the NSA's unknown level of cryptanalytic
superiority
is easy to throw around, but where's the evidence?
The AES design process is so open compared to the DES design process (which
produced a pretty damn good cipher for it's time), and so many more
independent
groups are taking part, that it's a reasonable bet that it would be very
hard for the
NSA to spike the process. No one is going to passively accept changes
reccomended
by the NSA. If you have particular concerns about Feistal networks, reveal
them. Calling
for a 'major paradigm shift' to some new, unspecified, and unanalyzed system
is not
helpful.
Peter Trei
[EMAIL PROTECTED]
Disclaimer. The above is my personal opinon, and does not neccesarily
represent that
of my employer. In the interests of openess, be aware that my employer is
sponsoring
one of the AES finalists (RC6).
pt
