Re: [Cfrg] Query about ECDAA security

[Peter Gutmann <[e-mail]>]

Scott Arciszewski <[e-mail]> writes:

>As frustrating as it is, unless we produce standards that are easy for non-
>cryptography folks to use securely in their software (and, even better,
>difficult to use insecurely), we will encounter insecure implementations in
>the wild.

Absolutely.

There's another problem though, in that a lot of the more secure mechanisms
are both really, really complex (compare just the basic OAEP vs. PKCS#1 v1.5)
and often have very little mainstream library support, or if support is
present it's little-tested and little-evaluated because of it's non-mainstream
nature.  As a result, developers have the choice of (say) RSA-PKCSv1.5 and
hoping the library gets it right, or RSA-PSS, possibly having to roll it
themselves, and being non-interoperable with most of the planet when the get
it implemented.

That's another issue with point compression that follows on from the patent
issues, standards like TLS have allowed point compression since forever (the
ec_point_formats extension is mandatory for TLS with ECC), but the spec says:

  Implementations of this document MUST support the uncompressed format for
  all of their supported curves and MUST NOT support other formats for curves
  defined in this specification.

  If the client sends the extension and the extension does not contain the
  uncompressed point format, and the client has used the Supported Groups
  extension to indicate support for any of the curves defined in this
  specification, then the server MUST abort the handshake and return an
  illegal_parameter alert.

The same thing is reflected in other standards, and in crypto libraries.  So
you often have to make a choice between "less than perfect theoretically but
universally deployed" and "(allegedly) perfect theoretically but you'll be in
for a shock when you try and deploy it".

Peter.