[
https://issues.apache.org/jira/browse/SSHD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098493#comment-17098493
]
Thomas Wolf commented on SSHD-986:
----------------------------------
For the ecdsa-256 test, kp.getPublic() has an ECCurve$Fp curve and a ECPoint$Fp
for G, while kp2.getPublic() has a SECP256R1Curve and a SECP256R1Point. The
curve specs are also different; kp.getPublic() has an ECNamedCurveSpec, while
kp2.getPublic() has an ECParameterSpec. The internal values appear to be the
same. The generated private key kp.getPrivate() also contains the public key,
while the read kp2.getPrivate doesn't.
Are there different equivalent X.509 encodings for an EC key? (Named vs.
unnamed, or some such?)
> Implement ECDSA public key recovery
> -----------------------------------
>
> Key: SSHD-986
> URL: https://issues.apache.org/jira/browse/SSHD-986
> Project: MINA SSHD
> Issue Type: New Feature
> Affects Versions: 2.4.0
> Reporter: Thomas Wolf
> Assignee: Lyor Goldstein
> Priority: Minor
> Attachments: ECRecoverTest.java
>
>
> {{KeyUtils.recoverPublicKey(PrivateKey)}} (and also
> {{OpenSSHECDSAPrivateKeyEntryDecoder.recoverPublicKey(ECPrivateKey)}}, but
> that doesn't seem to be called at all) are not implemented for ECDSA keys.
> EC public key recovery is a ECPoint scalar multiplication and can be done via
> Bouncy Castle. So if the code to do this can be guarded as other BC-dependent
> code this might be one way to implement this.
> Seems to me that lack of {{KeyUtils.recoverPublicKey(PrivateKey)}} for ECDSA
> currently prevents reading a key pair from a PKCS#8 PEM ECDSA private key
> file because {{PKCS8PEMResourceKeyPairParser}} calls that recovery method.
> Attached is small JUnit test showing how to compute the ECDSA public key from
> a given ECDSA private key using Bouncy Castle.
> According to [RFC 5915|https://tools.ietf.org/html/rfc5915], a PKCS#8
> representation of a ECDSA private key SHOULD contain the public key, too, so
> if it's present it might perhaps even be possible to avoid this scalar
> multiplication altogether, but exploiting this might require some larger code
> refactoring?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
