[ pycrypto-Bugs-1402843 ] RSA encryption failing.

Bugs item #1402843, was opened at 2006-01-11 13:35
Message generated for change (Comment added) made by idsvandermolen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&group_id=20937

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Noyau (eric_noyau)
Assigned to: Nobody/Anonymous (nobody)
Summary: RSA encryption failing.

Initial Comment:
I'm using RSA encryption to encrypt binary data. I've
notice that sometimes the decrypted data do not match
the encrypted one.

After a lot of searching I narrowed it down to block of
data starting with '\0'. See the attached test suite.

This bug may be the same as the badly explained bug
1212602.

----------------------------------------------------------------------

Comment By: Ids van der Molen (idsvandermolen)
Date: 2006-04-08 16:12

Message:
Logged In: YES 
user_id=1390172

I implemented some padding/encryption/signing schemes. For 
use with RSA and block ciphers. You can find them in the 
patches section as patch 1466857 (pycrypto padding and 
support functions) 

----------------------------------------------------------------------

Comment By: Ids van der Molen (idsvandermolen)
Date: 2006-04-06 16:37

Message:
Logged In: YES 
user_id=1390172

As far as I understand things (reading bug id 1266515 and
PKCS#1 v2.1) it is apparantly not safe to use RSAobj
directly for encryption/signing without applying
encryption/signing schemes (RSAES-OAEP/RSAES-PKCS1-V1_5 and
RSASSA-PSS/RSASSA-PKCS1-V1_5) as mentioned in PKCS#1
standard first. 
I have found this to be a problem in using pycrypto: it
provides just the bare crypto algorithms, no padding
algorithms or other PKCS standards.

----------------------------------------------------------------------

Comment By: Eric Noyau (eric_noyau)
Date: 2006-04-06 15:50

Message:
Logged In: YES 
user_id=1388768

Without entering into the quality of the algorithm (I'm not
qualified to know if it is safe enough to use as is) a
simple approach to fix the issue is to ensure that the
decrypted string is always prepended with enough '\0' so
that its size is equal to the blocksize.

Of course this suggestion is valid only if the plaintext
blocks to be encrypted are validated to be exactly the
blocksize as well. 

----------------------------------------------------------------------

Comment By: Ids van der Molen (idsvandermolen)
Date: 2006-04-06 14:23

Message:
Logged In: YES 
user_id=1390172

Apparrently according to PKCS#1 v2.1 you need to apply
padding algorithms first, RSAES-OAEP (rfc3560) with
encrypt/decrypt and RSASA-PSS (rfc4056) with sign/verify.
Pycrypto bug id 1266515 has a RSAES-OAEP implementation
attached (haven't tested it).

----------------------------------------------------------------------

Comment By: Ids van der Molen (idsvandermolen)
Date: 2006-04-06 10:27

Message:
Logged In: YES 
user_id=1390172

The encrypt method of Crypto.PublicKey.pubkey.pubkey
converts a string to a long using
Crypto.Util.number.bytes_to_long. As a consequence all
heading 'zero' bytes within the string are
discarded/useless, i.e. 'A', '\x00A' and '\x00\x00A' all are
converted to 65L. 
pubkey.decrypt(pubkey.encrypt(65L)) will return 'A'

I think this is a serious problem, for which I haven't got a
solution (yet).

Tested with pycrypto 2.0.1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=120937&aid=1402843&group_id=20937


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642