[Cryptography] IETF discussion on new ECC curves.

[Michael Kjörling]

On 8 Aug 2014 11:14 -0400, from crypto.jmk at gmail.com (John Kelsey):
> c.  If there's a performance/security tradeoff, that might be
> worthwhile to expose to the user, but only if the performance option
> is still secure and the secure option still performs okay.

Well, that's pretty much the point I'm making, or at least tried to
make, when I wrote:

>> If the "weakest" option is "good enough for most purposes", as for
>> example is the case with AES' weakest option being a 128-bit key, I
>> don't see giving choices _to those who are in a position of making
>> an informed selection among them_ as being a major problem. Who
>> that is depends on the target audience.

_Personally_, most of the time I'd rather have "slow by default" over
"insecure by default", but I am certainly _not_ advocating insecure
alternatives being offered in the first place. The choices I see would
be somewhat like choosing between "good" and "better" security (or
"good" and "somewhat worse" performance, whichever way you prefer
looking at it). Not choosing between "mediocre", "good" and "great"
security, because if you do that then yes someone _will_ choose the
"mediocre security" option for one reason or another, and in that case
they are often better off _knowing_ that their data is unprotected
against a determined adversary. All options should be secure against
reasonably practical attacks for the foreseeable future; some options
could be offered which are _more_ secure, but come at a performance
penalty. We can never guard completely against large quantum leaps in
the relevant fields, but we can work within what we know about
currently and add a safety margin for the future which is reasonable
in both directions.


>> If the "weakest" option is "good enough for most purposes", as for
>> example is the case with AES' weakest option being a 128-bit key, I
>> don't see giving choices _to those who are in a position of making an
>> informed selection among them_ as being a major problem. Who that is
>> depends on the target audience.
> 
> One big downside of more options is that it means more things to
> test. If your choices are, say, the FIPS ciphersuite and the DJB
> ciphersuite, then there are only a couple things to test. If you
> allow an independent selection of every component, then testing gets
> a lot nastier.

Perhaps now I'm showing off my ignorance in public, but I was under
the impression that choosing the curve is a bit like choosing the key
length, or perhaps even more apt choosing the value of _e_ in a RSA
implementation, in that it is a value that _only peripherally affects
the implementation itself_, by essentially being a constant somewhere
that must be chosen according to a set of criteria but which can be
replaced with another constant also chosen according to those criteria
without adversely affecting the _validity_ of the software. (The
security of the full cryptosystem as implemented being a different
matter, with some values offering higher levels of security than
others, but that happens everywhere in cryptography.)

Have I misunderstood on some fundamental level how this works?

And _implementors_ would of course always have the choice of only
implementing support for a single curve, assuming interoperability
across implementations of a standard is not a requirement. (If it is,
then obviously all curves mandated by the standard would need to be
supported in some fashion.)

-- 
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)