[Cryptography] IETF discussion on new ECC curves.

John Kelsey crypto.jmk at gmail.com
Fri Aug 8 11:14:49 EDT 2014


> On Aug 3, 2014, at 11:06 AM, Michael Kjörling <michael at kjorling.se> wrote:
...
> 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.

I guess I don't see the point of this kind of user selection.  If all the options are secure, then you can use the same crypto for handling the payroll as you use for handling your child's birthday party invitation list.  If all the options aren't secure, then why on Earth are you offering the user insecure options? 

Where I see some benefit to giving the user (or sysadmin) the ability to configure the crypto that's used is:

a.  If there's some widely reported attack that means a particular ciphersuite is bad, you'd like it to be possible to turn that one off.  (It's much more important in this context to be able to turn a ciphersuite off than to be able to select it.)  

b.  If your organization has some rules about which ciphersuites you use (like federal users preferring FIPS approved algorithms), you may want to be able to select the ciphersuite.  It may even be that occasionally, there's a good reason to select those ciphersuites, though I suspect most of the time, it will be pointy-haired bosses mandating or forbidding something they read about (and didn't quite understand) in the news.  

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.  

Are there other reasons to allow many choices?  I mean, the practical reason we have a gazillion choices for every security standard is because that's how standards group politics works--everyone champions their favorite algorithm.  This has been known to have some downsides now and again, though, so it would be nice to eliminate it except where there's a real benefit you can point to in having different choices about ciphersuites or algorithms or curves or whatever.  

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

Yes, this.  If I go to the doctor with a sinus infection, I don't want him to write me a prescription with a complicated set of options based on whether I think the bacteria infecting me are gram negative or gram positive, how likely I think it is that they're producing beta-lactamase, etc.  I might specifically have a reason to exercise some choices ("I'm allergic to Sulfa drugs, so don't give me those"), but there's no value in giving me a bunch of options I don't understand.  

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

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.  

...
> Michael Kjörling • https://michael.kjorling.semichael 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)

--John


More information about the cryptography mailing list