Opened 5 years ago

Closed 5 years ago

#1723 closed enhancement (fixed)

Implement EdDSAKey getEncoded()

Reported by: zzz Owned by: zzz
Priority: minor Milestone: 0.9.25
Component: api/crypto Version: 0.9.23
Keywords: Cc: str4d
Parent Tickets: Sensitive: no


… and related support for decoding. See #1510 comment 5.

Not making #1510 a parent of this as we'll use ECDSA for now.


Change History (10)

comment:1 Changed 5 years ago by zzz

Cc: str4d added
Milestone: undecidedsoon

This is also required to fully implement net.i2p.crypto.provider.I2PProvider.

I'd also like to implement ElG key support there. I would like to support storing ElG keys (for example persistent LS keys) as certificates in a keystore, but we can't import/export them without a provider. This would also enable putting full destinations in a keystore, at least as a few separate pieces that we could reassemble. Would programmatic keystore access work as long as we had our provider loaded?

I thought that adding a provider required the jar to be sealed and signed, but I just tried Security.addProvider(new I2PProvider()) and it worked fine. Can we count on it working?

As described in #1510 comment 5, all this is unpleasant due to ASN.1, and trying to grab any code from anywhere else such as BC means either dragging in or eliminating a lot of dependent methods.

comment:2 Changed 5 years ago by zzz

Milestone: soon0.9.25

In 1c27925ac4cb4232039350f5486cfda1493305fe i2p.i2p.zzz.test2 to be propped for 0.9.25.
Follows the spec at

Provider code to follow

comment:3 Changed 5 years ago by zzz

Owner: set to zzz
Status: newassigned

Decoding in 3f8684672b8220dac098d5899682e758871f61cd i2p.i2p.zzz.test2 to be propped for 0.9.25.
Untested, provider addition to follow.

comment:4 Changed 5 years ago by zzz

partial provider and keytool support for KeyStoreUtil? in 9a36f870f152e1bc7ec3a36971d46755c985d082 i2p.i2p.zzz.test2 to be propped for 0.9.25.
Not yet working.

comment:5 Changed 5 years ago by zzz

OK now I'm stuck again. We do need signing for keygen???


When instantiating a provider's implementation (class) of a Cipher, KeyAgreement?, KeyGenerator?, MAC or SecretKey? factory, the framework will determine the provider's codebase (JAR file) and verify its signature. In this way, JCA authenticates the provider and ensures that only providers signed by a trusted entity can be plugged into JCA. Thus, one requirement for encryption providers is that they must be signed, as described in later steps.

It doesn't include KeyPairGenerator? in that list though. So do we need a cert or not?

open source code signing cert here is Eur 17.22 incl. tax.
The certum root certs do appear to be in Debian/mozilla and thus will be trusted by Java.

I'm stuck at:

keytool error: unrecognized algorithm name: SHA512withEdDSA

even though we are registering that in the provider.

comment:6 Changed 5 years ago by zzz

I tested both the KeyPairGenerator? and the Signature in the I2PProvider programatically and they work fine. So something with the provider isn't right for keytool.

comment:7 Changed 5 years ago by zzz

fixed provider in 0d44806b696c47ae575d9e468b1fae47c54a370a i2p.i2p.zzz.test2 to be propped for 0.9.25.
Not yet working completely, have to fix privkey encoding to match the PKCS#8 standard.

comment:8 Changed 5 years ago by zzz

Privkey encoding fixed in 41dd6e0533ef7288c4e1054a188b188fcc48da98 i2p.i2p.zzz.test2 to be propped for 0.9.25. Everything works now. Email sent to IETF draft authors asking for clarification. If my guess was right, then we're finished with this, except if we want ElG keys too (see comment 1 above).

comment:9 Changed 5 years ago by zzz

My email:

re: draft 04

The draft does not fully specify the ASN.1 encoding of a EdDSA
private key. There's no section for private keys corresponding to
section 4 for public keys.

However, it's presumably meant to follow the PKCS#8 specification,
which requires (I think) a Version integer and an Algorithm
Identifier (OID).

Unfortunately, the base 64 example in the draft section 8.3
does not include those elements, and therefore cannot be decoded
by standard PKCS8 ASN.1 parsers.

Is the base 64 private key example correct?
Did you intend for the encoding include a Version and Algorithm
Identifier? Would you please fully specify the private key encoding?

Josefsson's reply:

Indeed, the private key part is missing from
this document, and we will update the draft.  The RFC 5915 format is
not very good for EdDSA keys, and it is not clear if it is worth
abusing it to gain re-usability with RFC 5915 implementations, or
whether it is easier to specify a new private-key format instead.  We
should probably bring up the issue of EdDSA private keys in the mailing


I naively assumed that there were only two choices, PKCS8 or what was in the draft, and that the decision had already been made.

However, there could be other standards, they haven't decided yet, and it sounds like it will be a while.

In practice, Java really wants private keys to be PKCS8 encoded, so even if the authors come up with some other way to do it, I think our code needs to stick with PKCS8 for now, and I'm happy with what I've checked in. If and when a new draft comes out with something different, we will evaluate and decide what to do next.

comment:10 Changed 5 years ago by zzz

Resolution: fixed
Status: assignedclosed

Have not received any additional info from the draft spec authors, nor has there been a new version published since version 04 in Oct. 2015. As I said in comment 9 above, when we get more info or a new spec version, we'll evaluate at that time.

Note: See TracTickets for help on using tickets.