RE: Dumb question.

[Michael Hunley]

While this advice will work, it is not required to dump RSA just because 
you have have exceeded its block length.  Every cipher algorithm has its 
advantages and disadvantages and you should pick the one that best fits 
your needs.  The proposed alternative is more involved from a coding 
standpoint than writing a large message wrapper around RSA, but it will 
likely be faster if you are transmitting a lot of messages of any length 
(it is basically a form of SSL).  Assuming you picked RSA for a reason, you 
can write a simple routine (that I would vote for including in Crypto++ as 
a convenience API) that takes your message and encrypts in blocks.  You can 
query your RSA encryptor for the maximum plain-text length of each message 
(FixedMaxPlaintextLength).  You can also ask it for how large the 
ciphertext will be (FixedCiphertextLength) and allocate a buffer large 
enough for:
        bufSize = messageLength*(cipherBlockLength/maxPlainTextLength)
Then walk your message in that size chunks building up an in memory array 
of RSA encrypted blocks.  If you run an RSA decryptor on each block you get 
back a buffer that matches your input plaintext length for that block 
(guaranteed).  So you can either add a size prefix as the first 2-4 bytes 
of your message before you encrypt so you know the output size after you 
decrypt the first block, send the same in plaintext (not advisable in most 
situations) or just require that your message encoder always have a 
terminating block of size <  maxPlainTextLength.  I use the last one, then 
as soon as you decrypt a block that is not maxPlainTextLength in size, you 
know you are done.  Of course, you need to be able to dynamically resize 
your blocks or (ugh) have a fixed maximum message length.  If mem realloc 
is an issue for you, use the first solution with a temp buffer of size 
maxPlainTextLength and pay the memmove penalty (cheaper than re-allocing in 
a lot of cases).

HTH.
michael
At 12:49 PM 4/7/2003 -0700, you wrote:
RSA is a fixed/limited length crypto scheme.  For long messages, generate 
a symmetric session key (e.g. AES-128), encrypt that with RSA, and then 
encrypt the message with the session key. As a bonus you can MAC the 
message with the same session key (e.g. HMAC<SHA1>).   Note that some MACs 
(e.g. CBC) need a different key to the encryption key to avoid leaking key 
bits - in that case take a hash (SHA1) of the encryption key before using 
it as the MAC key.

Try VisualAssist (<http://www.wholetomato.com>http://www.wholetomato.com) 
better IntelliSense in VC++.

 -----Original Message-----
From: Julia Smith [mailto:[EMAIL PROTECTED]
Sent: Monday, April 07, 2003 12:28 PM
To: [EMAIL PROTECTED]
Subject: Dumb question.
RSA encryption blows up if you pass it a string that is beyond a certain 
length.

<rant>This is aggravating. Code samples don't deal with the simple idea of 
encoding something beyond a few dozen characters. I'd really vote for some 
sort of effort to create a usability API where calls do what you want to 
expect. Use the JCE as a basis. What I am finding is that half the time 
VC++ cannot provide method completion on data values which makes using 
crypto++ classes very trying. Manual inspection of the documentation takes 
orders of magnitude more time and effort to follow. It's like going back 
to 1980 development tools.</rant>

How do I deal with long messages? Does this mean that crypto++ RSA 
encryption doesn't handle adding random noise into the padding, exposing 
the encryption to differential attacks (i think that's what can happen .. 
i don't remember the exact details).