On Thu, Nov 21, 2013 at 12:50 PM, Daniel Holth <[email protected]> wrote:
> On Thu, Nov 21, 2013 at 11:01 AM, Richard Barnes <[email protected]> wrote: > > Indeed, according to the EdDSA papers, a public (verifying) key is an EC > > point, and the private (signing) key is an integer. > > <http://ed25519.cr.yp.to/ed25519-20110926.pdf> > > > > So the existing "x", "y", and "d" parameters would be sufficient. You > would > > just need new values for "alg" and "crv". > > The implementation does not accept an x, y, or curve parameter. The > public/verifying and private/signing keys are each compressed > representations of x and y and would take up twice the space if > represented as (x, y). IMO this lack of parameters is a major feature > of the Ed25519 algorithm. It implements the recommended parameters > from the EdDSA paper in an optimized way. > > My implementation does store a redundant copy of the public key as > half of the signing key. I have not worried about that yet since it is > not transmitted; I don't personally need my private/signing key to be > a JWK. > > In the signing key the 256 truly private bits are just the random > number seed used to generate the other keys. IIUC [in the simple API] > the secret curve point is generated from a hash of these bits during > each signature. > > The Python implementation at http://ed25519.cr.yp.to/software.html > might be helpful. > Honestly, I don't really care format what the software takes. It's pretty trivial to convert between the compressed format and (x,y). On the other hand, I could see defining something different for the private key, since it's not directly a point multipler. --Richard
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
