On 10/04/2013 07:38 AM, Jerry Leichter wrote:
> On Oct 1, 2013, at 5:34 AM, Ray Dillinger <b...@sonic.net> wrote:
>> What I don't understand here is why the process of selecting a standard
>> algorithm for cryptographic primitives is so highly focused on speed.
> If you're going to choose a single standard cryptographic algorithm, you have
> to consider all the places it will be used. ...
> It is worth noting that NSA seems to produce suites of algorithms optimized
> for particular uses and targeted for different levels of security. Maybe
> it's time for a similar approach in public standards.
I believe you are right about this. The problem with AES (etc) really is that
people
were trying to find *ONE* cryptographic primitive for use across a very wide
range of
clients, many of which it is inappropriate for (too light for first-class or
long-term
protection of data, too heavy for transient realtime signals on embedded
low-power
chips).
I probably care less than most people about the low-power devices dealing with
transient realtime signals, and more about long-term data protection than most
people. So, yeah, I'm annoyed that the "standard" algorithm is insufficient to
just *STOMP* the problem and instead requires occasional replacement, when
*STOMP*
is well within my CPU capabilities, power budget, and timing requirements. But
somebody else is probably annoyed that people want them to support AES when they
were barely able to do WEP on their tiny power budget fast enough to be
non-laggy.
These are problems that were never going to have a common solution.
Bear
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
