You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NIST SP 800-56B requires that, when an RSA private key is used, that we verify that our public key is consistent with the private key.
Presumably, the purpose of this check is to prevent the use of a private key different from the one that is intended (the public key is correct, the private key is wrong), or we advertise the wrong public key for out private key (the private key is correct, the public key is wrong). I'm guessing that such mistakes are probably bad for both RSA signing (which we support) and for RSA encryption (which we do not currently support), but off the top of my head it's only obvious why it's practically bad for RSA encryption.
There are two cases to consider:
The application is loading only the private key, and is extracting the public key from the private key for the purpose of sending the public key to the peer. In this case, no consistency check is needed because we only have one copy of the public key (the public key embedded in the private key) to check.
The application is loading the private key for use with a (X.509) certificate or other public key stored separately from the private key. In this case, we we want to implement a consistency check.
Therefore, it may make sense to have two constructor functions for RSAKeyPair: one that supports #1, and one that supports #2. The constructor that supports #2 would take the encoded private key as a parameter, and return the RSAKeyPair augmented with public key info. The constructor that supports #2 would take a reference to the public key in addition to a reference to the encoded private key..
However, if we were to have such separate APis, would we really be helping users avoid the situation where they use an external public key (e.g. from a certificate) that isn't consistent with their private key? It seems like it may be impossible or impractical to prevent such misuse in ring. However, we may be able to prevent such misuse in webpki, with a new API for webpki. Presumably JOSE (JWK) implementations would need to do similar as well.
So, basically, if there's something we can do in ring to help prevent this kind of error, let's do it. Otherwise, let's close this without trying to do it. But, either way, we should document what we do and what we don't do to prevent this issue in the (public) documentation of RSAKeyPair.
The text was updated successfully, but these errors were encountered:
NIST SP 800-56B requires that, when an RSA private key is used, that we verify that our public key is consistent with the private key.
Presumably, the purpose of this check is to prevent the use of a private key different from the one that is intended (the public key is correct, the private key is wrong), or we advertise the wrong public key for out private key (the private key is correct, the public key is wrong). I'm guessing that such mistakes are probably bad for both RSA signing (which we support) and for RSA encryption (which we do not currently support), but off the top of my head it's only obvious why it's practically bad for RSA encryption.
There are two cases to consider:
The application is loading only the private key, and is extracting the public key from the private key for the purpose of sending the public key to the peer. In this case, no consistency check is needed because we only have one copy of the public key (the public key embedded in the private key) to check.
The application is loading the private key for use with a (X.509) certificate or other public key stored separately from the private key. In this case, we we want to implement a consistency check.
Therefore, it may make sense to have two constructor functions for
RSAKeyPair
: one that supports #1, and one that supports #2. The constructor that supports #2 would take the encoded private key as a parameter, and return theRSAKeyPair
augmented with public key info. The constructor that supports #2 would take a reference to the public key in addition to a reference to the encoded private key..However, if we were to have such separate APis, would we really be helping users avoid the situation where they use an external public key (e.g. from a certificate) that isn't consistent with their private key? It seems like it may be impossible or impractical to prevent such misuse in ring. However, we may be able to prevent such misuse in webpki, with a new API for webpki. Presumably JOSE (JWK) implementations would need to do similar as well.
So, basically, if there's something we can do in ring to help prevent this kind of error, let's do it. Otherwise, let's close this without trying to do it. But, either way, we should document what we do and what we don't do to prevent this issue in the (public) documentation of
RSAKeyPair
.The text was updated successfully, but these errors were encountered: