Falcon key-recovery mode support for blockchain-style signatures

[Federico2014]

Hi Bouncy Castle team,

I’m evaluating the Falcon implementation in bcprov-jdk18on 1.84 and would like to ask whether Falcon key-recovery mode is currently supported, planned, or intentionally out of scope.

From the current lightweight API, FalconSigner appears to expose the standard signing/verification flow:

• sign(sk, message) -> signature
• verify(pk, message, signature) -> boolean

Verification requires an explicit FalconPublicKeyParameters. I could not find an API for the Falcon key-recovery signature variant, where the verifier can recover the public key from the message and signature payload.

This mode seems especially useful for blockchain-style transaction signatures. In many blockchain protocols, transactions are expected to be self-contained: the verifier should be able to identify or derive the signer from the transaction authentication payload itself, without requiring the full public key to be stored separately or transmitted in another channel.

With standard Falcon-512, the verifier needs both:

public key: 896 bytes
signature: 1..752 bytes

So if the public key is not already available, each signed object must carry roughly:

896 bytes + Falcon signature

With key-recovery mode, the signature payload is larger than a normal Falcon signature, but the public key does not need to be transmitted separately. For blockchain transactions, where the same public key would otherwise be repeated across many signed objects, this can significantly reduce the total authentication data and provide an interface closer to ECDSA-style recoverable signatures.

Questions:

• Does Bouncy Castle currently support Falcon key-recovery mode through any API that I may have missed?
• If not, is support for Falcon key-recovery mode planned for a future release?
• Is this expected to depend on FN-DSA / FIPS 206 finalization?
• Are there standardization, security, or interoperability reasons why Bouncy Castle would avoid exposing this mode?
• If key-recovery mode is not planned, would the recommended approach be to continue using only the standard verify(publicKey, message, signature) interface?

Relevant classes I checked:

• org.bouncycastle.pqc.crypto.falcon.FalconSigner
• org.bouncycastle.pqc.crypto.falcon.FalconNIST

Thanks.

[roy-basmacier]

Does Bouncy Castle currently support Falcon key-recovery mode through any API that I may have missed?

No, key recovery mode is not available and there is no API for it. We deliberately left verify_recover and is_invertible commented out.

If not, is support for Falcon key-recovery mode planned for a future release?

There has been discussion on adding key recovery mode, if the FIPS document for FN-DSA specifies key recovery, we'll add it.

Is this expected to depend on FN-DSA / FIPS 206 finalization?

Yes, but if there is a large demand and a standardized encoding we'll think about it.

Are there standardization, security, or interoperability reasons why Bouncy Castle would avoid exposing this mode?

Lack of a standard encoding and OID makes interoperability a pain.

If key-recovery mode is not planned, would the recommended approach be to continue using only the standard verify(publicKey, message, signature) interface?

Yes. From the discussion above, it looks like it'll only be a couple hundred byte difference .