Signature Crypto Algorithm Details

Hi all,

In the Signatures draft, we’ve got a bunch of strictly-defined algorithms for people to be able to use out of the box. Crypto primitives are often parameterized, giving a lot of flexibility and choice. The idea here though is that if you’re pulling something out of the named algorithm registry, you wouldn’t have choices to make about how to apply it. (You can, as always, go off and do your own algorithm within your own ecosystem without using the registry values.)

In any event, two elliptic curve algorithms have caught my attention the last couple weeks and I am looking to drum up feedback. First, Edwards curve algorithms, specifically ed25519. It’s been requested by a number of people out there that we add this, so I’ve been working out what parameters we’d need within the spec text to make it interoperable. From early implementations and feedback, we’ve settled on a PureEdDSA algorithm with no pre-hash of the message input, since that seems to be the most common and accepted version of this. We’re preparing text to add this to the draft, and I’m looking to confirm that choice if anyone has any strong feelings on the matter.

Second, the ECDSA algorithm that we define over curve P256 has its own snag that we didn’t realize: the signature in the mathematical model is two separate numbers, r and s. We need to encode a single value, and all the libraries that I used take the approach that you just concatenate the two into a single 64-byte array and call that the signature. However some implementors have gotten back to me that their libraries use an alternative method of encoding, using ASN.1 to wrap the two integers into an ASN.1 structure. A quick survey shows that this is supported on many libraries, but it does have the drawback of pulling in explicit ASN.1 into the signature definition where it isn’t needed elsewhere. I’m currently leaning towards more carefully defining the concatenation approach, similar to what JOSE uses in this case, but I am seeking feedback on this choice.

I know that this is a question more for the security/crypto crowd, and we’ll be reaching out there as well for sure, but I wanted to get a feel for any preference within this community that would be implementing and dealing with this spec on the other side. What do your libraries support for ECDSA and EdDSA inputs and outputs? Do you have a strong feeling on either of these choices?

Thanks,
 — Justin

Received on Friday, 14 January 2022 16:39:28 UTC