Re: Insecure Implementation of RSA Encryption in PEAR Crypt_RSA

On Thu, Aug 11, 2011 at 1:10 AM, Daniel Roethlisberger <
[email protected]> wrote:

> Hi,
>
> I work for SWITCH-CERT, the incident response team of the Swiss
> national research and education network and the .ch/.li domain
> registry.
>
> I am contacting you as the author of Crypt_RSA.  I am also
> copying Daniel O'Connor, since he appears to have worked on
> Crypt_RSA in the recent past.
>
> I have discovered a security vulnerability in PEAR Crypt_RSA
> which leads to loss of confidentiality against passive attackers.
>
> Hereby I'd like to confirm the vulnerability with you in order to
> start a responsible disclosure process.  A coordinated release
> date would be desirable because a number of other (non-PEAR)
> libraries are also vulnerable.
>
> If my analysis is correct, Crypt_RSA uses the following scheme
> for encryption:
>
>   ciphertext = RSA_encrypt(plaintext || 0x01);
>
> Using modulus n, exponent e, concatenation ||, and RSA_encrypt()
> being plain RSA in ECB mode with null padding.  There is no
> randomness in this scheme.
>
> This is essentially plain textbook RSA with deterministic
> padding.  There is a number of well-known attacks against plain
> RSA [1,2].  An attacker with the ability to read the ciphertext
> can use these attacks to break the RSA encryption.  The most
> obvious attack:  Because the scheme is not semantically secure
> [3], an attacker can guess likely plaintexts, encrypt them using
> the public key, and compare the resulting ciphertext to the
> original ciphertext.
>
> In order to fix this, Crypt_RSA ought to use a secure RSA padding
> scheme such as PKCS#1 OAEP [4].
>
> I'd further suggest to encrypt the actual payload symmetrically
> using a random session key, and only encrypt the symmetrical
> session key using RSA, thus getting rid of the ECB mode, but that
> is not strictly necessary and outside of the scope of this
> vulnerability.
>
> Please let me know whether you think the above analysis is
> correct, whether you plan to fix Crypt_RSA and when you will be
> able to have a fix ready for coordinated public disclosure, so we
> can agree on an embargo date.  I am contacting the
> authors/maintainers of the other vulnerable libraries in separate
> e-mail as well in order to be able to agree on a common date (if
> feasible).
>
> Thanks and kind regards,
> Daniel Roethlisberger, SWITCH-CERT
>
> [1] http://en.wikipedia.org/wiki/RSA#Attacks_against_plain_RSA
>
> [2] D. Boneh, A. Joux, P. Nguyen:
>    Why Textbook ElGamal and RSA Encryption are Insecure
>
> http://www.comms.engg.sussex.ac.uk/fft/crypto/Why_Textbook_ElGamal_and_RSA_Encryption_are_Insecure.pdf
>
> [3] http://en.wikipedia.org/wiki/Semantic_security
>
> [4] RFC 3447: Public-Key Cryptography Standards (PKCS) #1:
>    RSA Cryptography Specifications Version 2.1
>    https://www.ietf.org/rfc/rfc3447.txt
>
> --
> SWITCH
> Serving Swiss Universities
> --------------------------
> Daniel Roethlisberger, Security Engineer, SWITCH-CERT
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 29, fax +41 44 268 15 78
> [email protected], http://www.switch.ch
>