IPaddingProvider to provide Max Message length?

Developer
Dec 8, 2010 at 10:23 PM

Love your RSACrypto class.  I'm using it right now to encrypt messages that may exceed the max length.  In your code for the OAEP provider, I see...

    if (this.m_mLen > ((this.m_k - (2 * this.m_hLen)) - 2))
    {
        throw new CryptographicException("Bad Data.");
    }

I am considering breaking up the message into blocks for encryption, but it would be handy if IPaddingprovider could tell me the max allowed size for a message block.  Is this a reasonable request or is there something else that I should be doing here?

Thanks,

David Maltby

 

Developer
Dec 8, 2010 at 10:27 PM

If so, then I'm more than happy to submit a patch to this effect.

Coordinator
Dec 9, 2010 at 12:15 PM

David -

You're right, we could add a max message length.  It will be different however depending on the padding type used as they use different schemes for adding padding and hashing.  I'll have to take a look at the padding providers and refresh my memory as to how long the message can be for each and I'll try to get that property added today (unless you've already written it and want to submit the patch).  In the case of OAEP for example, II believe m_k is the length of the modulus used for encryption.  m_hLen is the length of data produced by the SHA-1 hash algorithm.  Since OAEP involves creating two hashes, plus the two extra bytes to separate identify and separate the padding, the message length is calculated as the length of the modulus, minis the size of two hashes, minus two extra bytes.

Thanks,

Dustin Horne
http://www.dustinhorne.com

Coordinator
Dec 9, 2010 at 1:19 PM

Just another note...you'll need to know the cipher strength in order to get the max data length since the max data length is dependent on teh strength of the cipher.

Developer
Dec 9, 2010 at 2:46 PM

Right. Maybe I don’t understand this well enough, but isn’t m_k in the equation this.m_k - (2 * this.m_hLen)) – 2 the key size and hence the cipher strength?

From: DustinHorne [mailto:notifications@codeplex.com]
Sent: Thursday, December 09, 2010 8:20 AM
To: david.maltby@hotmail.com
Subject: Re: IPaddingProvider to provide Max Message length? [scrypt:237665]

From: DustinHorne

Just another note...you'll need to know the cipher strength in order to get the max data length since the max data length is dependent on teh strength of the cipher.

Read the full discussion online.

To add a post to this discussion, reply to this email (scrypt@discussions.codeplex.com@discussions.codeplex.com)

To start a new discussion for this project, email scrypt@discussions.codeplex.com@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com

Coordinator
Dec 9, 2010 at 3:02 PM

Sort of...

  • this.m_K is the key size (cipher strength)
  • (2 * this.m_hLen)) – 2 is the size of the padding.  Must be subtracted from the key size to obtain the maximum data length.

So herein lies the problem:  The padding providers I've constructed (OAEP and PKCS1) don't know what the key size is until it's been given to them.  This happens internally when the padding is applied.  The RSAParameters instance of the current RSACrypto instance is passed into the method that adds or removes padding.  The padding providers use this to determine the key length.  It's done this way because you could call:  new RSACrypto(1024);  or you could call new RSACrypto(2048); etc.  This changes the cipher strength and also changes the maximum message size.  So, you'll have to supply the key size. 

In most cases in Silveright, you'll be using an existing public key that was generated elsewhere.  So, what you can do is create an instance of the padding provider, load the public key data into the RSACrypto class, and export as an RSAParameters object.  In the case of encrypting, the N and E values will be set.  So, since those are just large numbers stored as byte arrays, you can get the Length property of the N value which will also be your cipher strength and supply that to a MaxMessageSize method, so:

int iLen = oParamsInstance.N.Length;

and

int iMaxLen = oPaddingProviderInstance.GetMaxMessageLength(iLen);

Then the GetMaxMessageLength method would return as follows:

public int GetMaxMessageLength(int keyLength)
{
   return keyLength - (2 * this.m_hLen)) – 2
;
}

That would apply to OAEP only, it's a different size for PKCS.

Developer
Dec 9, 2010 at 3:11 PM

Of course... still too early for me this morning, I guess..  but yea, I understand now.

Jul 30, 2011 at 5:16 AM

I have an issue where using no padding produces a max length of "2147483647", which is Int.MaxValue.  Is this intended?  I'm in the same situation where the value I need to encrypt is larger than the allowed size for other padding schemes.

Coordinator
Jul 30, 2011 at 5:36 PM

mkrain -

This is not intended.  If you're not using padding, the max length is actually the size of your key (i.e. 2048-bit).  I only implemented "no padding" for compatibility with existing code, however I would not recommend using it.  If your data is too large to encrypt, break the data into smaller chunks.  Split your data into two byte arrays and encrypt each one using OAEP (recommended).  You'll have to decrypt two blocks then as well, but then you can put them back together.

Jan 21, 2012 at 10:48 PM
Edited Jan 21, 2012 at 11:25 PM

Hi, not well versed in encryption, but using your library to implement encryption of certain data. The data is longer then the MaxMessageLength, but i was curious if there was a standard on how to handle these events. I'm now implementing my own way of splitting up the messages and decrypt them again, but i want my encrypted message to work on other systems that have their own RSA / Crypto libraries. So do you know if there are specific guidelines on how to implement this? thank you!

EDIT: or should i go for this approach:

http://stackoverflow.com/questions/5866129/rsa-encryption-problem-size-of-payload-data

The normal way of using RSA for encrypted a big message (say, an e-mail) is to use an hybrid scheme:

  • A random symmetric key K is chosen (a raw sequence of, e.g., 128 to 256 random bits).
  • The big message is symmetrically encrypted with K, using a proper and efficient symmetric encryption scheme such as AES.
  • K is asymmetrically encrypted with RSA.

EDIT 2: Ok, after some reading on StackOverflow and some other websites I decided to use Symmetric encryption for long messages and using assymetric encryption for the key and signing the long message. Shame that c# currently limits symmetric encryption to 256bit.

Coordinator
Jan 23, 2012 at 12:51 PM

The option you chose is definitely the best option.  You're still going to have to break it up because of the size limitation.  .NET actually supports larger bit sizes, however the AES and SHA algorithms in Silverlight / WP7 don't.  The main reason I believe is for performance purposes since especially in the case of WP7 it is generally running on less powerful hardware.  This is likely also one of the reasons MS didn't include asymmetric encryption in Silverlight.

The reason option #2 is better though is because RSA is a pretty expensive algorithm to run processing wise.  With Scrypt you could certainly process larger messages by increasing the size of they key (like generating a new key at 4096bit).  Scrypt limits the size to 4096 but you could download the source and modify it to allow larger sizes.  The problem is that it has a pretty negative performance impact.  Symmetric algorithms such as AES are faster to run so it will always be recommended to use a symmetric algorithm for large payloads and use RSA to encrypt the key.

Jan 23, 2012 at 10:29 PM

Thank you! I'll drop you a line when I publish my WP7 app.

Coordinator
Jan 24, 2012 at 12:56 PM
Sounds great, if you drop me the AppHub buy link I'll share it on the CodePlex site.

On Mon, Jan 23, 2012 at 5:29 PM, southernsun <notifications@codeplex.com> wrote:

From: southernsun

Thank you! I'll drop you a line when I publish my WP7 app.

Read the full discussion online.

To add a post to this discussion, reply to this email (scrypt@discussions.codeplex.com)

To start a new discussion for this project, email scrypt@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com