search

WICG / webcrypto-secure-curves

Proposal for the addition of Curve25519 and Curve448 to the Web Cryptography API
https://wicg.github.io/webcrypto-secure-curves/
Other
40 stars 3 forks source link

Allow creating randomized EdDSA signatures? #28

Open twiss opened 2 days ago

twiss commented 2 days ago

WebKit's implementation of Ed25519, when using macOS's CryptoKit, produces randomized signatures (presumably as per draft-irtf-cfrg-det-sigs-with-noise).

The current specification of EdDSA, in RFC 8032 (which we refer to), defines Ed25519 and Ed448 as being deterministic, making this implementation technically noncompliant (although for most practical purposes it won't make a difference).

@annevk has requested that we refer to draft-irtf-cfrg-det-sigs-with-noise in Web Crypto, however, from my understanding from the CFRG mailing list, there's no clear consensus on whether this draft should be published as an RFC, yet. The main disagreement seems to be about whether the definition of "Ed25519" should be changed or a new algorithm, e.g. "rEd25519", should be introduced. Also, the draft is now expired again :/

So, we could either:

  1. Wait until IETF 121 and see if a consensus arises
  2. Refer to the draft anyway, and revert it if it isn't published as an RFC (however, it's a bit unclear how long we should wait for that)
  3. Refer to "RFC8032 or its successors", such that using the draft becomes legal automatically if it does get published as an RFC (and informally speaking, WebKit could keep its current implementation if it believes that that'll happen).

@Frosne and @davidben (and of course @annevk, @nmahendru and @chris-wood), do you have any opinions?

panva commented 2 days ago

Refer to "RFC8032 or its successors"

👍

annevk commented 2 days ago

How will we deal with tests?

Ideally:

  1. The language in the specification allows for what is known to be secure and does not attempt to constrain implementations unnessarily.
  2. The language in the specification encourages interoperable implementations, including for implementations that might not realize "or its successors" refers to "active" work. (Perhaps by pointing to it directly.)
  3. Tests can be written against the language in the specification.
twiss commented 2 days ago

How will we deal with tests?

I don't think the question of whether&how we allow randomized signatures in the test suite is really any different than the question of whether&how we allow implementations to create them. So basically if we think the spec text should allow creating randomized signatures (and we're happy that it does), then the tests should reflect that as well.

  1. The language in the specification allows for what is known to be secure and does not attempt to constrain implementations unnessarily.

I agree with this goal as stated but it's not really our job at the W3C to decide what this entails for EdDSA, exactly; that's the IETF's job, IMHO. As long as there's no consensus at the IETF, we can't really make a statement about what is "known to be secure".

  1. The language in the specification encourages interoperable implementations, including for implementations that might not realize "or its successors" refers to "active" work. (Perhaps by pointing to it directly.)

RFC 8032 and draft-irtf-cfrg-det-sigs-with-noise are interoperable wrt. verification (randomized signatures will verify for implementations of RFC 8032 and vice versa), so I don't think this is a huge concern.

My larger concern would be that an application that assumes (based on RFC 8032) that Ed25519 signatures will be deterministic (for some niche reason), and relies on this somehow, might be surprised to learn that it doesn't work in Safari. To prevent that, we could make a note about this on MDN.

  1. Tests can be written against the language in the specification.

I think if we're willing to include active work as a successor of RFC 8032 for the purpose of implementations, we should accept it for the purpose of testing as well, and vice versa.

Frosne commented 1 day ago

Hi,

I think we’re fine with allowing randomised signatures. However, we’re not that interested in providing it ourselves or exposing that detail to the user (via a different function or some other API difference).

The suggestion of phrasing it as "using RFC 8032 or its compatible successor" seems reasonable.