Signature verification fails on handshake if 1024 bit RSA key is used

[zeroxbt]

Summary

I am trying to connects to existing js-libp2p nodes using rust-libp2p, but signature verification fails on handshake, as these nodes have 1024 bit keys, and the current rust-libp2p implementation only allows 2048 or more. While I agree on enforcing stricter security policies to prevent users from inadvertently using weaker cryptographic standards on identity creation, shouldn't the nodes be able to verify signatures of 1024 bit RSA keys ?

Expected behavior

Signature verification during handshake not to fail.

Actual behavior

Signature verification during handshake fails.

Relevant log output

IncomingConnectionError { connection_id: ConnectionId(1), local_addr: "/ip4/127.0.0.1/tcp/49618", send_back_addr: "/ip4/127.0.0.1/tcp/49625", error: Transport(Other(Custom { kind: Other, error: Other(Left(Right(Apply(BadSignature)))) })) }

Possible Solution

Update this line to use RSA_PKCS1_1024_8192_SHA256_FOR_LEGACY_USE_ONLY instead of RSA_PKCS1_2048_8192_SHA256.

Version

0.54.0

Would you like to work on fixing this bug ?

Yes

[dariusc93]

My question would be, is this actually needed? Not against adding RSA_PKCS1_1024_8192_SHA256_FOR_LEGACY_USE_ONLY though but at the same time Im not sure if it really fits to validate weaker keys. Further more, we wouldnt know if such key size would even be supported in the future in other libp2p implementation (assuming they have such option to allow it vs just accepting any size key). .

[zeroxbt]

The main issue is backwards compatibility. Future versions of other libp2p implementations might not support weaker keys, but they do currently and I think we can expect to see cases where users can't update their nodes' network identity. Maybe a better solution would be to let users optionally enable signature validation and key creation of weaker keys ?

[jxs]

Hi, can't you use another of the [supported key types](https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md#key-types? All Implementations must support Ed25519