Re: [Cfrg] Finishing Ed448 definition

[Bryan Ford <[e-mail]>]

> On Nov 26, 2015, at 9:58 AM, Simon Josefsson <[e-mail]> wrote:
> 
> Gilles Van Assche <[e-mail]> writes:
> 
>> Hi Bryan,
>> 
>> I have a preference for your second proposal "twoshakes-d", for its
>> domain separation between PureEdDSA and HashEdDSA. This would have the
>> practical advantage of allowing a single key to be used for both options
>> (if certified as such), without input clashes at the internal hash level.
> 
> That would be nice -- but having Ed25519 and Ed448 differ this
> significantly would appear like a strange design choice to me.

This occurred to me to and I agree that it would be nice for the two to be (more) consistent.  I think a domain separation scheme like the one I proposed would be trivial to "back-port" to Ed25519 to make them consistent if we feel that's valuable; I didn't want to suggest this in my proposal for Ed448 though since the call was formally only for Ed448 hash proposals and I didn't want to violate the scope of the call. :)

I suggest we treat the possibility of "back-porting" domain separation to Ed25519 as a separate discussion issue that's (mostly) orthogonal to what to do for Ed448 - but with that in mind, here are three possible back-porting approaches I considered:

1. Direct back-port: just change the Ed25519-based spec to add the same 'dom' prefixes to the hash inputs in exactly the same way as for Ed448, with the 'SigEd448' changed appropriately to (eg) 'SigEd255' or 'SigEd25519'.  Advantage: domain separation features completely consistent across the two curves. Disadvantage: breaks binary signature compatibility with existing "classic" Ed25519 signatures. 

2. Back-port with silent compatibility exception: define the Ed25519 sig scheme to do domain separation in the same way as Ed448, *except* in the one special case of PureEd25529 with an empty context string, in which case the dom prefix becomes empty (no domain separation) for backward compatibility with classic Ed25519. Advantage: mostly consistent across curves, and backward compatible. Disadvantage: hokey special case, and the slight security risk that a use of PureEd25519 with empty context string being confused with a domain-separated use of Ed25519. 

3. Back-port directly as in #1, so both PureEd* and HashEd* are always domain separsted and incompatible with classic Ed25519, but define an additional eg 'BareEd25519' scheme variant just for backward compatibility with non-domain-separsted classic Ed25519. Encourage all new applications/protocols to use PureEd* or BareEd* while defining BareEd25519 as being available for legacy compatibility. 

I guess my (slight) preference would be for #3 followed by #1. I'm sure other variants are possible. 

Cheers
B

> So for me, at this point, I would prefer twoshake-s, or both my other
> proposals (SHAKE256+SHA3-512 and SHA2-512/912+SHA2-512), over
> twoshakes-d.
> 
> /Simon