Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Mon, 1 Aug 2016 15:31:16 +0000

Hi Ilari,

On 7/22/16, 12:02 PM, "Curdle on behalf of Ilari Liusvaara"
<[email-masked] on behalf of [email-masked]> wrote:

>On Mon, Jun 13, 2016 at 10:12:55AM +0000, Dang, Quynh (Fed) wrote:
>> Hi all,
>> 
>> Prehash or non-prehash, choosing the one which works well for all uses
>> (not just signing certs) is the right thing to do. I don¹t know how much
>> the non-prehash version is actually used right now (different from how
>> much it is supported in libraries).
>
>Well, I think that anything that:
>- technically _could_ sign "not technically constrained" CA certificate
>  (regardless of if the key was ever intended to do that), and
>- _could_ ever sign anything that even partially comes from external
>  sources (this includes cross-certs).
>
>Should use non-prehash.
>
>
>The reason for this is that non-prehash versions look to be
>_substantially_ weaker against attacks to the hash function (going by
>historical percedent), and the ultimate nightmare scenario is attacker
>managing to collide issued data with unconstrained CA certficate.

I believe that Ed25519, Ed448, SHA-512 and SHAKE256 (as a hash function)
are all secure. I don’t know which one will fall first, but I know that a
practical quantum computer will break Ed25519 and Ed448, BUT not the hash
functions, and this could happen within 5, 10, 15 or 20 years. Therefore,
in that respect, the additional risk with the prehash is practically none.

The more important thing is that are you worried about security of SHA-512
and/or SHAKE256? Were this worry worth buffering long messages all the
times everywhere in any situations including all kinds of constrained
environments?

>
>
>Also, if one looks at the basic signed data items that float around in
>various PKIs, those include:
>
>- Certificates
>- OCSP responses
>- CRLs
>
>Now, certificates and should be fairly small. Few kilobytes (or at
>most few tens of kilobytes for certs with PQ key in them) or so.
>
>OCSP responses should be even smaller. On order of 100 bytes for
>signed size?
>
>This leaves CRLs, which could potentially be largish. But are
>those actually used that much? I did search for CRL for one
>practicular very high-activity WebPKI cert, and couldn't
>find it (it might not even exist).
>
>
>So presumably using non-prehash for everything would be feasible.
>
>
>-Ilari
>

One algorithm which works well for all situations would be better. In TLS,
IPSEC, S/MIME etc…., an additional hash is not a concern for the
protocols. When signing large messages, the prehash version is the best
option and the right option to go. I don’t know all of the places where
the signature algorithm is going to be used, but I am sure there will be
situations where large messages get signed. Currently, I think S/MIME
should use the prehash version (I have no ideas which one the S/MIME
working group is  going to use/adopt).

Quynh.