[Cryptography] IETF discussion on new ECC curves.

[Michael Kjörling]

On 3 Aug 2014 14:13 +0100, from iang at iang.org (ianG):
> Having options is good, as a systems designer.  But if you pass those
> options on to users, that is bad.  Users have no idea what to do, and
> they spin wheels while listening to so-called experts pontificate.

I would argue that this depends on the type of software, and the type
of user.

Certain types of software probably can usefully allow the user to pick
among options; other types of software might, by making the user go
well out of their way; others would choose based on what they key is
going to be used for (PFS, ephemeral, long-term; active or passive
adversary expected; military or diplomatic secrets, controversial or
non-controversial web browsing; ...); yet other types of software
definitely should not offer a choice at all, and just stick to one or
another.

If I, even as someone who _is_ interested in all this, save an
encrypted, password-protected spreadsheet, I don't want to have to
consider the minutiae of the key length choice or key derivation
algorithm; just make a choice for me already, preferably an
interoperable and secure one.


> For this motive, now I suggest well supported by history, I propose that
> the designer should pick one suite for the whole lot, and take on the
> responsibility for everyone that the choice is good.

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.

If against a determined attacker the weakest option is little better
than a Caesar cipher, then yes, that's _asking_ for trouble.

If curves can be chosen that correspond, at least roughly, to commonly
used symmetric key lengths, then the choice between those curves
becomes similar to picking 128, 192 or 256 bit keys for AES. That's a
choice a systems designer, even one without extensive knowledge of
cryptography, can grasp: either the shorter key with faster crypto, or
the longer key with slower crypto. The performance difference can be
stated (and hopefully explained well), tested against acceptable user
experience criteria on target classes of hardware, and possibly given
time code can be optimized such that the difference is reduced. The
implication of either choice on an attacker, particularly a passive
attacker, can to some degree be quantified. These are matters about
which a technical discussion can be held, and an appropriate choice
made in each instance. Boss wants to be able to tick "256-bit security
throughout"? Just pick that curve and key length, and live with the
performance penalty. Boss wants to be able to show off the
performance? Pick the faster options, and optimize the code like
you're (and the boss is) a madman. And so on.

Hence my position that, as a designer or implementer, having _a few_
_clear_ choices each with _known_ advantages and drawbacks provides
choices for those who want them. Assuming that the weakest choice is
"good enough" (for some definition of "good enough"), then no matter
what choice is made out of those the result will be "good enough".
That is within the constraints of the particular implementation, but
the implementation should essentially be unaffected by whether one
curve/key length or another is chosen; the assumption being that the
algorithm itself is the same.

We can't prevent software writers from giving choice to users who are
not in a position of being able to make an informed decision. It _is_
possible to give software writers a set of options such that none of
the options offered are terrible for any reasonable scenario, which
means that even _if_ someone makes an uninformed decision the
consequences aren't horrible (fail safe!). Don't discount the
possibility of a designer or implementer making an uninformed decision
on which alternative to go with, either; again, if all choices are
reasonable, the results might not be great, but they also won't be
terrible.


> But that choice can still be stripped as an option, the
> software choosing what it needs according to purpose.

Indeed, that is definitely one approach for some types of software,
particularly those that target regular end-users.

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