Re: RSACryptoServiceProvider questions
From: Daryn Kiely (anonymous_at_discussions.microsoft.com)
Date: 10/29/03
- Next message: Daryn Kiely: "Another RSACryptoServiceProvider question"
- Previous message: Michel Gallant: "Re: RSACryptoServiceProvider questions"
- In reply to: Thomas Pornin: "Re: RSACryptoServiceProvider questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 29 Oct 2003 10:02:19 -0800
Thanks Thomas and Michel,
I am just playing with this encryption stuff in an
attempt to get a better understanding of how things
work. We are using SSL/TLS in real life, but I hate
black boxes without some understanding of the underlying
architecture. Which leads me to my next question.
If I am encrypting a message of say, 384 bytes, I will
need to break it into chunks. Will each block need the
OAEP padding, or is it sufficient to do this on the last
byte of the message?
Thanks again
Daryn
>-----Original Message-----
>According to Daryn Kiely
<anonymous@discussions.microsoft.com>:
>> 1) Why is it that if I try to encrypt something that
is
>> longer than 117 bytes I get an cryptographic exception
>> with an invalid length? My key is 1024 bits, so I
would
>> expect to be able to use a block size of 128 bytes
(ok, I
>> must be missing something here, but what????).
>
>-- A RSA public key is a bit integer and the core
algorithm handles
>only inputs up to but not including that integer value.
Therefore,
>whatever happens, you cannot encrypt 128 arbitrary bytes
with a
>1024-bit RSA key; you are limited to 127 bytes and 7
bits.
>
>-- The core RSA algorithm is a simple modular
exponentiation but this
>leads, in practical situations, to a number of security
problems. Those
>problems are solved by applying a correct "padding
scheme" on the input
>data, which uses a few input bytes. The standard padding
scheme is
>defined in PKCS#1 and uses 11 bytes (actually 10 bytes
and the "partial
>byte" at the upper end of the modulus), hence your
figure of 117 bytes.
>Newer versions of PKCS#1 include a new padding scheme
called OAEP which
>uses a few more bytes, but is believed to be even more
secure (not that
>the old scheme has been broken, but OAEP security has
been "proven" [in
>a sense which is not easily explained to the non-
cryptographer]).
>
>Besides, the encrypted text always has the size of the
modulus, 128
>bytes if the key is a 1024-bit key. With RSA you cannot
have a
>non-expanding encryption.
>
>
>> 2) What does a Cryptograhic exception with the
>> message "Bad Data" really mean? I have not been able
to
>> find any documentation anywhere and have been getting
>> this regularly when trying to decrypt a message. I am
>> just a little frustrated!!!
>
>Upon decryption, the presence of the padding used for
encryption is
>verified. If that padding fails to be present, you get
an error message.
>
>
>I don't know what you are trying to do, but it
suspiciously looks
>like a home-made protocol with a few cryptographic
algorithms thrown
>it partly at random. Be advised that the design of a
cryptographic
>protocol is a very difficult task and home-made designs
achieve almost
>never a decent level of security. What I call
a "protocol" is the
>assembly of one or more algorithms into an implementable
software
>which provides some security functionality; for
instance, the SSL
>protocol uses several algorithms (RSA, 3DES, SHA-1...)
and provides an
>authenticated bi-directionnal channel for arbitrary
data, and ensures
>confidentiality and integrity of such data. If security
matters for you
>(and I expect it does, otherwise you would not try to
use cryptographic
>algorithms), you should stick to published protocols
which have been
>inspected and corected for several years by many experts
in the field.
>
>
> --Thomas Pornin
>.
>
- Next message: Daryn Kiely: "Another RSACryptoServiceProvider question"
- Previous message: Michel Gallant: "Re: RSACryptoServiceProvider questions"
- In reply to: Thomas Pornin: "Re: RSACryptoServiceProvider questions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]