[Cryptography] IETF discussion on new ECC curves.

[Michael Kjörling]

On 1 Aug 2014 11:42 -0700, from trevp at trevp.net (Trevor Perrin):
> Scaling up symmetric crypto is low-cost.  AES-256 is only ~40% slower
> than AES-128.  SHA512 is *faster* than SHA256 on 64-bit systems.
> 
> In contrast, doubling keysizes for asymmetric crypto will often be a
> factor of 6-8 slowdown in what is already your crypto bottleneck.

I get the feeling that this is comparing apples to oranges. AES-256
uses 14 rounds, AES-128 uses 10 rounds. There's your 40% difference
right there. Now, there were reasons for going for more rounds with
AES-256 than with AES-128, but to me, they do not appear to be
intrinsic to the key length _itself_, but rather a function of known
attacks on the cipher for a given key length. For another example,
neither Blowfish, Twofish or Threefish have different numbers of
rounds for the varying key lengths, although Threefish has more rounds
for the largest block size.

In general, this discussion seems a lot like it is about choosing the
One Curve to rule them all. What if that isn't possible, let alone
desirable?

Personally, _as a systems designer and developer_, I'd prefer to have
a few options. Not many, mind you, but a few. Sort of like AES does by
specifying 128, 192 and 256 bit key lengths; I can go with "fast, and
sufficient for almost any needs" (128 bits) or I can accept the
performance penalty and use "even more" if for some reason I feel 128
bits of key is not sufficient (very long term secrecy needs against a
potentially determined and powerful adversary, for example). I could
then make the argument in each specific instance why I'd choose one
over the other and what considerations went into the trade-off between
key length and encryption/decryption throughput on a particular class
of hardware.

The way to do that with ECC would appear to be to have multiple curves
with different work factors which I can trust to not be bongoed. Don't
force me to use a comparatively fast WF128 curve for very long term
secrets which are rarely accessed, for example, or a much slower WF256
curve for things that pretty much only need to be kept secret while
they are actually _in transit_ (for example, because other parts of
the protocol make them useless for more than one time usage).

128 and 256 bits are common enough key lengths to, in my mind, warrant
widely vetted (and well described how chosen, and how those
considerations stem from algorithm requirements) corresponding work
factor curves. 192 bits, maybe. Longer keys, _possibly_, but by then
you could easily argue that we are well into tin-foil hat territory;
even a meet-in-the-middle attack against a 256 bit key appears totally
unrealistic to me, so at that point, other kinds of attacks than
directly against properly implemented cryptography appear much more
likely.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)