Dumb question.

25 views
Skip to first unread message

Julia Smith

unread,
Apr 7, 2003, 3:44:04 PM4/7/03
to crypto...@eskimo.com

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).


Chris Newcombe

unread,
Apr 7, 2003, 4:00:26 PM4/7/03
to jul...@macrovision.com, crypto...@eskimo.com
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) better IntelliSense in VC++.

Shawn Holmes

unread,
Apr 7, 2003, 4:31:16 PM4/7/03
to crypto...@eskimo.com
I second the use of VisualAssist.
 
- Shawn

Julia Smith

unread,
Apr 7, 2003, 4:47:29 PM4/7/03
to crypto...@eskimo.com
Thanks. You mean VC++ isn't God's gift to programmers? ;)
-----Original Message-----
From: Shawn Holmes [mailto:sho...@breckcomm.com]
Sent: Monday, April 07, 2003 1:23 PM
To: crypto...@eskimo.com
Subject: RE: Dumb question.

Julia Smith

unread,
Apr 7, 2003, 5:08:17 PM4/7/03
to crypto...@eskimo.com
;) The statement was meant to be a bit sarcastic. On the whole, jbuilder, perhaps because Java is a less cluttered language, is rock solid in this area and that's what I've been working in for the last couple of years most of the time. VC++ gets in my way regularly.
-----Original Message-----
From: Shawn Holmes [mailto:sho...@breckcomm.com]
Sent: Monday, April 07, 2003 1:51 PM
To: crypto...@eskimo.com
Subject: RE: Dumb question.

Oh, I am all for Visual C++, don't get me wrong. It just needs a little kick in the rear-hole to get anything done efficiently.  ^_^
 
- Shawn

Shawn Holmes

unread,
Apr 7, 2003, 5:08:41 PM4/7/03
to crypto...@eskimo.com
Oh, I am all for Visual C++, don't get me wrong. It just needs a little kick in the rear-hole to get anything done efficiently.  ^_^
 
- Shawn
-----Original Message-----
From: Julia Smith [mailto:jul...@macrovision.com]
Sent: Monday, April 07, 2003 2:33 PM
To: crypto...@eskimo.com
Subject: RE: Dumb question.

Michael Hunley

unread,
Apr 8, 2003, 9:00:55 AM4/8/03
to crypto...@eskimo.com
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:jul...@macrovision.com]

Julia Smith

unread,
Apr 8, 2003, 3:37:45 PM4/8/03
to crypto...@eskimo.com

Yeh, you mean read and write in chunks like you do in stdio. But to make it secure, you need to add some random data to the message, or successive messages can open you to differential attacks, no?

I chose the later option and just stuffed two char "noise" itoa of a byte of random data at the front end of each block. All I do is prune it off on decrypt.

Michael Hunley

unread,
Apr 9, 2003, 8:30:11 AM4/9/03
to crypto...@eskimo.com
At 12:30 PM 4/8/2003 -0700, you wrote:

>Yeh, you mean read and write in chunks like you do in stdio. But to make
>it secure, you need to add some random data to the message, or successive
>messages can open you to differential attacks, no?


RSA takes an RNG, which you should be passing as a param when you
instantiate the Encrypt/Decrypt object (Are you using 5.1?). The
difference in fixedMaxPlainTextLength and the fixedMaxCipherTextLength is
the random padding that makes two encryptions of the same message
completely different. So, you are adding your own "noise" in, which is
fine, but should not be necessary.

michael

Julia Smith

unread,
Apr 9, 2003, 2:18:37 PM4/9/03
to crypto...@eskimo.com
Thanks.

-----Original Message-----
From: Michael Hunley [mailto:mhu...@pocketpurchase.com]
Sent: Wednesday, April 09, 2003 5:23 AM
To: crypto...@eskimo.com
Subject: RE: Dumb question.

Reply all
Reply to author
Forward
0 new messages