harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Kleymenov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-2125) [classlib][crypto] RSA Cipher implementation corrupts the data
Date Fri, 10 Nov 2006 11:54:38 GMT
    [ http://issues.apache.org/jira/browse/HARMONY-2125?page=comments#action_12448713 ] 
            
Alexander Kleymenov commented on HARMONY-2125:
----------------------------------------------

According to the explanations received from developers of BC provider [1], the transformation
string used for RSA Cipher instantiating should be extended with padding information (i.e.
instead of "RSA", "RSA/ECB/PKCS1Padding" or something like this should be used).

The problem in Harmony should disappear after application of the patch from HARMONY-2029 report.

[1] http://www.bouncycastle.org/devmailarchive/msg06862.html :

    Alexander Kleymenov wrote:
    > Hello,
    >
    > While working on Apache Harmony project
    > (http://incubator.apache.org/harmony) I've discovered the following
    > problem with RSA Cipher implemented in BC Provider. If the data to be
    > encrypted has leading zero bytes they disappeared after
    > encryption/decryption by RSA Cipher. I've filed the bug report in
    > Harmony project containing the description of the problem and the test
    > to reproduce it. Please, see the report at:
    >
    > http://issues.apache.org/jira/browse/HARMONY-2125
    
    Are you using some padding?
    
    If not, you are using RSA in a wrong way. You use plain RSA. And plain
    RSA accepts only a number between 0 and the modulus-1. So 0001 is the
    same as 1. And what the implementation does is correct. You should use
    some padding scheme, e.g. OAEP or PKCS#1. If you want to use plain RSA
    you must at least include a leading bit or length indicator. But I would
    not suggest to do so, because in your example you only use 10 bytes from
    the whole modulus length of e.g. 1024 bit. That means for a known plain
    text attack except the last 10 bytes all are known. Well, a self
    invented scheme is very likely to be insecure.
    
    Regards,
    Karsten

    > 
    > Thank you,
    > Alexander Kleymenov
    > 


> [classlib][crypto] RSA Cipher implementation corrupts the data
> --------------------------------------------------------------
>
>                 Key: HARMONY-2125
>                 URL: http://issues.apache.org/jira/browse/HARMONY-2125
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>            Reporter: Alexander Kleymenov
>         Attachments: cipherbug.java
>
>
> RSA Cipher implementation used in Harmony corrupts the input data. So the data array
with the leading zero bytes after encryption-decryption cycle results in array without leading
zero bytes. To reproduce the problem run the attached test. Its output on Harmony is as follows:
>  
> -----------------------
> Initial data:
>  1 2 3 4 5 6 7 8 9 A B
> Encrypted and Decrypted:
>  1 2 3 4 5 6 7 8 9 A B
> PASSED
> -----------------------
> Initial data:
>  0 1 2 3 4 5 6 7 8 9 A
> Encrypted and Decrypted:
>  1 2 3 4 5 6 7 8 9 A
> FAILED: Encrypted/Decrypted data does not equal to initial
>  
> while on RI the output is:
>  
> -----------------------
> Initial data:
>  1 2 3 4 5 6 7 8 9 A B
> Encrypted and Decrypted:
>  1 2 3 4 5 6 7 8 9 A B
> PASSED
> -----------------------
> Initial data:
>  0 1 2 3 4 5 6 7 8 9 A
> Encrypted and Decrypted:
>  0 1 2 3 4 5 6 7 8 9 A
> PASSED
>  
> This problem causes unstable failure of the following unit test:
>  
> org.apache.harmony.tests.internal.net.www.protocol.https.HttpsURLConnectionTest

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message