[Bug 25839] Curve25519 Named Curve

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25839

--- Comment #52 from Trevor Perrin <webcrypto@trevp.net> ---
(In reply to Ryan Sleevi from comment #51)
> (In reply to Trevor Perrin from comment #50)
> > The "raw" definitions would be straightforward, as the Curve25519 and
> > Ed25519 papers specify exact encodings for keys and signatures.
> 
> Though I don't agree with that, it's something better discussed when
> reviewing a spec you wrote, rather than on this bug.
> 
> > > Of the multiple Curve25519 implementations, very few that I'm aware of try
> > > to actually interoperate with eachother, or with any other protocol.
> > 
> > I've talked to some developers of these libraries who indeed have performed
> > interop tests.  The DJB specs are very clear, and the formats are very
> > simple.  I'd be surprised if any serious implementations of Curve25519 ECDH
> > and Ed25519 signatures failed to interoperate.
> 
> Though I don't agree with this either, it's something better discussed when
> reviewing a spec you wrote, rather than on this bug.
> 
> > That speaks to the quality of these implementations, it doesn't imply
> > interop problems.
> 
> If the only way to interop is to read source, that is an interop problem.
> If the only way to interop is to use one of the canonical sources, that too
> is an interop problem (c.f. WebSQL)

That's not the case - the DJB papers on Curve25519 and Ed25519 specify
byte-level detail.

But I appreciate this would be better discussed via a full proposal.


> While I appreciate the enthusiasm, it may be worth re-reading that paper. It
> doesn't (at least as far as I recall and found) specify how to deal with
> octet strings. That is, the algorithms are defined in terms of integers, but
> the format conversions are left ambiguous.

Byte-level encodings for public keys and signatures are on pages 6 and 7:

http://ed25519.cr.yp.to/ed25519-20110926.pdf

They could be more prominent, but they're there (search for "encoding").


> Specifically, if you only support "raw", then you cannot "securely" (a term
> I use based on other members' recorded views) support unwrapping of
> Curve25519 keys. That is, the 'sender' can control extractability by setting
> the JWK "ext" attribute prior to wrapping, then wrap the key. The recipient
> is documented as respecting the "ext" attribute independent of the content
> script's parameters to unwrapKey.

I see.  I didn't realize JWK was the privileged format for wrap / unwrap.


> The point being that, as a WG, we'll "consider" all submissions. But the
> choice or absence of some features will have an affect on whether or not the
> WG adopts it as a WG item, and whether or not the WG is able to progress on
> this.
> 
> > Is there an example template for producing add-on algorithm documents?  Are
> > any spec editors or other people willing to help, as I'm new here?
> 
> No example templates. New territory being charted here.

OK, I'll see what I can do.  Could take a few weeks, if anyone wants to help
let me know.


Trevor

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 25 July 2014 19:32:10 UTC