Re: [Cfrg] Requirements for elliptic curves with a view towards constrained devices

[Alyssa Rowan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 21 November 2014 12:51:04 GMT+00:00, "Lochter, Manfred" <[e-mail]> wrote:

>> [Watson Ladd] When my mobile phone's browser connects to a website whose certificate is signed by P384, a P384 verification better take place. Not supporting P384 introduces an interoperability problem.
> [Manfred Lochter] I'm glad that you agree with my previously stated position that 384-bit curves are needed.

No, with respect, I think perhaps you may have simply misunderstood what he's saying here.

What Watson is talking about is simply the practical requirement that many TLS-supporting peers will have to continue to support the NIST curves in existing deployments - because existing ECC root CAs in the PKIX tree, such as Comodo's, are apparently all using ECDSA_P384_SHA384 (i.e., the NIST curve secp384r1), and naturally they will need to verify that chain of trust to remain secure.

However, the NIST curves are of course firmly outside the scope of our recommendations here; such a legacy consideration regarding the NIST curves has no bearing at all on what curves we may choose, or not, to recommend.

secp384r1 appears to have particularly unfortunate performance in software, and this can have some impact on mobile devices forced to use it for interoperability (they almost always have no hardware acceleration for it). That is the context of Watson's post, I believe?

As discussed previously, there are no particuarly efficient special primes in the immediate area of 2^384, and as a result there are several curves such as Curve41417 and Ed448-Goldilocks which are both faster (in software) and stronger than secp384r1.


Regarding side channel defences, I refer you to my previous replies and reference above. I note again that the NIST curves are themselves special primes, and are quite widely deployed with plenty of 'high-assurance' implementations of them already: clearly therefore, most competent vendors have had no insurmountable problems producing implementations with effective side-channel defenses for special prime fields.

- --
/akr
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQI3BAEBCgAhBQJUb0GBGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
jtkWi2t6Gc4QAL7Q1BiytPBO84yeVMtOoioipnDiLJfQEatl7tWinARiHJT6evPC
1E3Wdm6JIfHERJEjNmcMr0TR4YH9Fn7NWXsKgZIqWX+uwo+rS3cnfDwSMUVK+tVK
5kJIF/CJAoOOwwugZ7KDFYZSDLErEMXexxAmABrBYe6y5zmVBTzudhO020MGiGiM
bGJlt2FLri4u4Yez4tmj8Ky2yIciGZa6zNJroooH/VUudcWZmk2hnloJTfEqSvHT
oeNQ7a7wHd3UlVkg4u4gvGxeCxH+ikeNmNfMA6cJ1lm8uglBrE5+alRKlUwtVxtL
R7y3bPK+0h7Hq1D+jqMUyDLQsp/65yX2cOvPMlSStJk6/AnaBm19XU63JN04sZ7y
z3z6huJ9WEEsdGs8kzJ+2jKHIMvvSmObqNg+Wd6hwKz3pYjY+9nCd3bO3ORV/pOz
S6H9X1sPye+laqphw5/wBTtM7FcawqdFGNit7qNf/Ne0cVxD4jbvugqfuwDV/xtO
4xHORPZjcBj2I6i6EgQhTrUs5wMNSIPfF5uT/RgA1UDgFNNlYjJ5ZhIurBbmtBRq
kFCWSlrODtYPpoZ4xoOtthu/DGlm8dkbb79HQaCuRUziEUm7y5lKPluqbUms7ewM
g6xXGTOTO+u+v8dEknimvpxnd8xxZ3/sof/nQBZeo18a3ZK2CReFbkZQ
=a5/K
-----END PGP SIGNATURE-----