Re: [Curdle] Ed25591ctx

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, August 16, 2016 8:37 PM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Curdle] Ed25591ctx
> 
> On Tue, Aug 16, 2016 at 02:36:40PM -0700, Jim Schaad wrote:
> > Ilari has done edits on a local draft to respond to my comments and it
> > appears he is planning on introducing a new mode to the EdDSA drafts
> > for 25519.  Specifically one would have:
> >
> > EdDSA25519 - the traditional signature algorithm EdDSA25519ctx - a new
> > mode for 25519 which has a context structure available to it.
> > EdDSA25519pre - a pre-hash mode that uses the same structure as
> > EdDSSA25519ctx
> 
> The names aren't right (the right ones are 'Ed25519ctx' and 'Ed25519ph'), but
> otherewise quite so (assuming contexts will be part of the document!)
> 
> > This means that we would no longer have the huge problem between ctx
> > and pre hash modes conflicting quite as much as one could require the
> > use of ctx and pre instead.  One still has the problems between pure and the
> other modes.
> 
> That change also solves the problem of using the same key for Ed25519 and
> Ed25519ph.
> 
> However, Ed25519ctx and Ed25519ph can't be computed using standard
> Ed25519 software. There is no way to do so while remaining safe to key- share.
> Fortunately, the places that are modified are likely not to be too inaccessable
> (i.e. written in high-level-language) in practical implementations, if you can
> modify one.
> 
> > The questions I have are:
> >
> > Should we issue an OID for the new ctx mode?
> >
> > Should we require the use of the ctx mode for signing of certificates?
> >
> > Should we have any advisory language which says that new usages SHOULD
> > use the ctx mode over the pure mode?
> 
> It occurs to me that one could avoid use of prehashed EdDSA variants by adding
> OID that is defined to sign a hash object[1] instead of the actual data. If then
> one could avoid contexts, one could just use standard-issue
> Ed25519 code (which is dime dozen).
> 
> That could be also be used to avoid the potentially annoying SHAK256 hashing if
> one wants long-input Ed448.
> 
> 
> While contexts could help against things like that TLS 1.2 LURK SKI attack EKR
> came up with, there are plenty of RSA or ECDSA keys that are unprotected
> against such abuse.
> 
> And then there is the issue that contexts are a new input, and many signature
> APIs just doesn't have it.
> 
> And with regards to new stuff using contexts, I think it is a bad idea, unless the
> stuff used only contextualized signatures. And PKIX fails that criteria.
> 
> 
> 
> [1] One rough sketch (excuse me for not using the correct notation):
> 
> SEQUENCE {
> OID <some-assigned-oid>
> OCTET_STRING zeroes_64octets
> AlgorithmIdentifier hash_algorithm
> OCTET_STRING hash_value
> }
> 
> DER-encode that (easily templateable if you know the hash, which would come
> from the signature algorithm OID) and use that as message for algorithm.
> 
> The OID in the beginning is to distinguish it from other ASN.1 structures.
> 
> I threw that zeroes_64octets in there to make it more difficult to abuse with
> TLS.
> 
> Specifically, valid TLS 1.3 signatures can't look like that because those start with
> 0x20, not 0x30 like that one does.
> 
> Nor can valid TLS 1.2 signatures, because that one presumably has a zero in 65th
> and 66th position, which would code curve type 0
> (undefined) for ECDHE and p=0 (division by zero) for DHE.
> 
> One minor problem being that it breaks a SHA-512 block (which is like 2% speed
> penalty for signing, less for verfication).

This worries me from the following perspective:

Ok - this would work if we had just TLS and ASN.1, but I start worrying about this when you also decide to do the same thing for CBOR, XML, JSON and who knows what other formats.  YAML anybody?  It is easy to potentially avoid the collisions with two, but harder as new people without the same experience as we have decide to do the same type of thing.

I would rather tell people to design a content structure that does the prehash thing and sign that content than have fancy structure as part of the signature processing.  This is the basic approach I have suggested for signing of large detached files for CBOR and JOSE.  It is also similar to how CMS is designed where the content is hashed and that result is part of what is signed.

Jim

> 
> 
> 
> 
> -Ilari