Re: [PEAR-QA] Re: Insecure Implementation of RSA Encryption in PEAR Crypt_RSA

PEAR can't fix this without breaking backwards compatibility with
Crypt_RSA.  Crypt_RSA2 was recently proposed but it's no more immune
to the stuff described in this article than Crypt_RSA is.

I've pitched it before and I'll pitch it again.  phpseclib's Crypt_RSA
ought to be adopted by PEAR.  It fully implements Mr. Roethlisberger's
suggestion of using OAEP padding and is, indeed, the only pure PHP
implementation of RSA that does, to my knowledge.

Also, let's not forget that that there's been an open feature request
requesting this kinda be fixed that's been sitting around for a year
and a half:

http://pear.php.net/bugs/bug.php?id=16870

On 8/12/2011 8:14 PM, Daniel O'Connor wrote:
> 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
>>
>