[prev in list] [next in list] [prev in thread] [next in thread]
List: full-disclosure
Subject: [Full-disclosure] question regarding RSA
From: jf () b08s74ur ! corenetworks ! net
Date: 2010-08-31 2:32:06
Message-ID: 20100831023206.GA22739 () b08s74ur ! corenetworks ! net
[Download RAW message or body]
Hi,
i'm not really a crypto guy and I'm having problems explaining something; basically my \
understanding of RSA PKI is that the padding bytes are added because RSA is a deterministic \
algorithm and that without the padding an attacker with knowledge of the plaintext and access \
to the resultant ciphertext can significantly reduce the keyspace in deducing the private key, \
but the question is by how much? Assuming the absence of OAEP/et al, is it realistic to expect \
one to be able to brute force this keyspace? Theres really no documentation on the subject \
because well RSA is not expected to be secure in this environment, even though its deployeed \
this way more often than expected.
I'm trying to write up a test to do this, but I'm running into the problem that I'm having to \
modify what simplified implementations I can find to make sure no padding (or attacker \
controlled padding) exists, and therefore I'm gonna have the problem of either modifying \
something i didnt mean to, or more likely having the results discarded because it was my own \
implementation.
So, what I'm hoping for is someone with a fairly in-depth knowledge of RSAES-OAEP who can tell \
me what the reduction in complexity would be given an attacker that can control the plain-text, \
can receive the ciphertext, and can control the variables associated with OAEP; they just dont \
have access to the private key.
Thanks.
jf
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic