Fix EDDSA_LEGACY signing/verification with Ed448 keys #1675
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When creating/verifying signatures made using
PublicKeyAlgorithmTags.EDDSA_LEGACY
, BC creates Signer object instances of Ed25519. While this is in line with the rfcs (EdDSALegacy is only specified for Ed25519), BC also supports key generation etc. using Ed448.(Do we want to retain support for LEGACY_EDDSA + Ed448?)
(Update: LEGACY_EDDSA + Ed448 is defined in LibrePGP, see #1677 )
As a result, when generating/verifying signatures made using Ed448+EDDSA_LEGACY, BC tries to use Ed25519 signers, which fails.
Further, PGPSignature parses EDDSA_LEGACY signatures only as Ed25519, which means Ed448 signature result in OOB exceptions.
This PR changes the signer/verifier methods to detect, which curve is actually used when a EDDSA_LEGACY key is provided and to return an appropriate signer object accordingly.
The patch also fixes signature parsing for EDDSA_LEGACY Ed448 signatures by inspecting the length of the encoded signature values.