3
$\begingroup$

I'm wondering if the algorithm 1.2.840.113549.1.1.1 (rsaEncryption) is still secure to use for S/MIME encryption. I'm afraid that the scheme is vulnerable against attacks against raw/textbook RSA.

I'm considering to change to 1.2.840.113549.1.1.7 (id-RSAES-OAEP) but with no insecurity of 1.2.840.113549.1.1.1 (rsaEncryption), I cannot push the change.

BTW, the ciphertext of the mail messages are also signed with RSASSA-PSS.

Thanks for any links and/or suggestions.

Improve this question
$\endgroup$
0

1 Answer 1

Reset to default
1
$\begingroup$

The RSA encryption that you seem to be using is specified in PKCS#1, I've linked to the latest version, 2.2:

rsaEncryption    OBJECT IDENTIFIER ::= { pkcs-1 1 }

where

pkcs-1    OBJECT IDENTIFIER ::= {
    iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 1
}

with the description:

The object identifier rsaEncryption (see Appendix A.1) identifies the RSAES-PKCS1-v1_5 encryption scheme. The parameters field associated with this OID in a value of type AlgorithmIdentifier SHALL have a value of type NULL. This is the same as in PKCS #1 v1.5.

So your application is using PKCS#1 v1.5 padding. Attacks on textbook/plain/raw RSA - which you mention in your comment - are therefore not possible.

PKCS#1 is secure for static text, but it may be vulnerable to the Bleichenbacher attack that uses a padding oracle to try and find the message - in this case undoubtedly the secret key that is used to encrypt the actual data.

However, you've indicated that your ciphertext is signed. If we assume that this signature is correctly verified (and you'd be amazed how many times it is not) then this attack is not possible.

Of course, signing the ciphertext also has drawbacks: the encryption is lost for the plaintext message. More importantly, the scheme is not protected against the removal of the signature or the replacement of signatures. So an adversary can try and show that the message is theirs by simply substituting his own signature.

Signature substitution sounds horrible, but it may not be a problem if only signatures are accepted from one or more specific, trusted parties. In that case substituting the signature will simply result in the message being rejected by the receiving party (who hopefully knows what to do when receiving such message).

Conclusion: I would deem the current scheme secure. The fact that RSA PSS is used for signing gives hope that the person creating the scheme knew what she was doing. There seems to be no pressing need to implement OAEP instead.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Note that I've send a question for correction to the (more independent) OID repository to have their description of OID 1.2.840.113549.1.1.1 altered. Neither the Alvestrand, OID-info nor RFC description is abundantly clear in my opinion. The RFC is most clear and is of course leading, but it doesn't contain the full OID's in any notation, which I consider horrible as nobody but the experts will find them. I'll mail them as well. $\endgroup$
    – Maarten Bodewes ♦
    Commented Nov 13, 2018 at 11:25
  • $\begingroup$ Thank you very much! I read the RFCs and OID-Info, etc. before but coudn't find the important part: tools.ietf.org/html/rfc8017#appendix-A.2.2 until you mentioned it. $\endgroup$
    – 0xcd
    Commented Nov 13, 2018 at 12:30
  • $\begingroup$ The OID repo has now been updated and shows the correct padding mech for rsaEncryption and references the new standard. Thanks to Thomas, it certainly helps if you know that they're part of the crypto site :). $\endgroup$
    – Maarten Bodewes ♦
    Commented Nov 13, 2018 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.