tomaswolf commented on issue #830: URL: https://github.com/apache/mina-sshd/issues/830#issuecomment-3380027953
1. The problem is not BC-FIPS specific, it also occurs with normal BC. 2. The public key from `cert.getPublicKey()` is a sect131r2 EC key. This curve is not supported in SSH. See [RFC 5656](https://datatracker.ietf.org/doc/html/rfc5656#section-10.1) 3. From the KeyStore, your code gets a key generated by SunEC, not by Bouncy Castle. SunEC encodes the key's algorithm ID as OID 1.2.840.10045.2.1 ("EC public key") with parameters OID 1.3.132.0.23 ("sect131r2"). When that key is read back for the network buffer by Bouncy Castle, it is reconstructed correctly , but is then a BCECPublicKey. This BCECPublicKey is encoded by writing the algorithm ID as OID 1.2.840.10045.2.1 ("EC public key") followed not by the curve OID but by the curve parameters. This explains the different X.509 encodings. 4. Using `allowedKey.equals(incomingKey);` may return `false` if comparing a SunEC key against a BC key. Maybe use `KeyUtils.compare()` instead. (Not sure it'll help.) 5. Didn't have the time to investigate further, in particular not why it works if not using BC. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
