Re: RSA decryption with PKCS1 1.5
- From: Hartmut <hartmut_99@xxxxxxxx>
- Date: Mon, 10 Jan 2011 19:52:27 +0100
Am 10.01.2011 05:58, schrieb Bryan:
Hartmut wrote:I encrypted a short message (about 32 bytes) with PKCS1 V1.5[...]
according RFC3447.
On decryption, i got a plain text of 63 octets, since my I2OSP
conversion stripped off the leading zero byte, which seems plausibe
when thinking in BigIntegers (same applies to Java's BigInteger
class). The message part and the rest of the padding was correct.
RFC3447 says: "If the first octet of EM does not have hexadecimal
value 0x00... stop"
Questions:
1) How do i deal correctly with this problem. Is it a legal
workaround to smuggle a leading zero into the plain text
before separating the message from the padding?
2) Is my I2OSP probably wrong?
Answering in reverse order: Yes, your I2OSP is wrong, and you deal
with the problem by fixing it. As specified in RFC 3447 (and also in
current PKCS#1), I2OSP takes two parameters:
I2OSP (x, xLen)
Input:
x nonnegative integer to be converted
xLen intended length of the resulting octet string
The result is always an octet string of xLen octets (or an error in
the case that x cannot be represented in xLen bytes). The decryption
procedure passes I2OSP the octet-length of the public modulus in xLen,
and the result will include appropriate leading zero bytes.
--
--Bryan Olson
....yep, you are right.
Thanks for input
regards
Hartmut
.
- References:
- RSA decryption with PKCS1 1.5
- From: Hartmut
- Re: RSA decryption with PKCS1 1.5
- From: Bryan
- RSA decryption with PKCS1 1.5
- Prev by Date: Re: Randomness using computers
- Next by Date: Re: RSA decryption with PKCS1 1.5
- Previous by thread: Re: RSA decryption with PKCS1 1.5
- Next by thread: Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars
- Index(es):