Welcome to MSDN Blogs Sign in | Join | Help

Generating Larger Keys with SN

A while back, I wrote about using the StrongNameKeyGenEx API to generate keys to sign assemblies with.  That API lets you pass in a dwKeySize parameter to specify the number of bits to generate in the key.  If you're calling the API from your own code, that's great, but what if you're using the sn.exe tool?

With Whidbey, you can use SN to generate keys of different sizes.  The -k flag takes a key size option as its first parameter. So you could do:

sn -k 2048 largekey.snk

And get a 2048 bit key.  If the key size is not specified, it defaults to 1024 bits, the same as the v1.0 and v1.1 versions of SN produce.  Not all key sizes are valid, you'll need to pick a valid size for an RSA key.  So for instance

sn -k 2105 invalidKey.snk

Will result in:

Failed to generate a strong name key pair -- Invalid flags specified.

Of course if you specify a key too large, SN will take a long time to generate it.  In fact, our test lead once tried to generate a key of 16,384 bits (which is the maximum supported size).  It took just over an hour to do, so it's probably best to stay with 1024 or 2048 bit keys for a while.  :-)

Once you've generated the key, you use it in the same way that you would use any key.  Just pass it as a /keyfile: parameter to your compiler of choice, and everything should work as normal.

It's interesting to note that no matter what size key you use to sign your assembly, the public key token will remain eight bytes long.

Published Friday, January 21, 2005 6:12 PM by shawnfa

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# re: Generating Larger Keys with MSI

Saturday, January 22, 2005 5:44 AM by Nicole Calinoiu
Did anyone actually try to sign an assembly with the max size key? I'm wondering if there's a practical limit on key size for assemblies compiled to any given PE file alignment size.

# What Happens When You Sign With A Larger Key

Monday, January 24, 2005 7:40 PM by .Net Security Blog

# re: Generating Larger Keys with SN

Monday, January 24, 2005 4:40 PM by Shawn
Nope, we just increase the size of the area used to store the signature. More details here: http://blogs.msdn.com/shawnfa/archive/2005/01/24/359861.aspx

-Shawn

# re: Generating Larger Keys with SN

Tuesday, January 25, 2005 3:06 PM by William
Can you get the actual signature bytes from the PE file?

# re: Generating Larger Keys with SN

Tuesday, January 25, 2005 3:10 PM by Shawn
Absolutely ... you might want to look at http://blogs.msdn.com/shawnfa/archive/2005/01/24/359861.aspx for some hints as to how. But this seems like a good topic for another post.

-Shawn

# re: Generating Larger Keys with SN

Wednesday, January 26, 2005 9:29 PM by dominick baier
Hi,

so why didn't microsoft choose 2048 bits from the beginning - and why is 1024 still the default?

three years ago it was easily forseeable that 1024 are not sufficient anymore -> http://www.win.tue.nl/~klenstra/key.pdf

wondering..
dominick

# re: Generating Larger Keys with SN

Thursday, January 27, 2005 10:09 AM by Shawn
Hi Dominick,

The paper you point to actually doesn't say that 1024-bit RSA will be broken in 2002, in fact it says "Note that it does not follow from Table 1 or the default settings that 1024-bit RSA keys will be safe only until 2002".

Thinking about what a strong name is vs what it isn't is also instructive here. First and foremost, strong names exist to help form the name of an assembly. They are not used to make your assembly tamper-proof by a malicious user, rather they work in the reverse way. If you provide me a signed assembly, I can use the strong name to verify that nobody has modified it since it left your development shop. However, if I want to modify it, removing the strong name is a relatively easy task.

The reason we stuck with 1024 bits for Whidbey is that, while we do want to give users the option to use longer keys if necessary, we also needed to think about backwards compatibility.

-Shawn

# re: Generating Larger Keys with SN

Thursday, January 27, 2005 10:11 AM by Shawn
And to re-reply to William, check out http://blogs.msdn.com/shawnfa/archive/2005/01/26/361109.aspx for some sample code to pull out the signature itself.

-Shawn

# A Few Observations about Raw Signatures

Friday, January 28, 2005 9:03 PM by .Net Security Blog

# re: Generating Larger Keys with SN

Tuesday, February 08, 2005 10:19 PM by dominick baier
hi shawn,

i don't quite agree with you - e.g. you can base CAS policy on SN evidence, can't you?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/strongNames.asp

dominick
www.leastprivilege.com

# re: Generating Larger Keys with SN

Wednesday, February 09, 2005 9:41 AM by Shawn
Yes, you can. But cracking a 1024 bit encryption, and being able to fake a signature are two different beasts. And as I said above, the paper explicitly says: "Note that it does not follow from Table 1 or the default settings that 1024-bit RSA keys will be safe only until 2002".

-Shawn

# What's New in Security for v2.0

Wednesday, August 24, 2005 10:46 AM by .Net Security Blog
There's a ton of new and enhanced security features coming with the v2.0 release of the CLR.  However,...

# What's New in Security for v2.0

Wednesday, August 31, 2005 5:08 PM by .Net Security Blog
There's a ton of new and enhanced security features coming with the v2.0 release of the CLR.  However,...

Leave a Comment

(required) 
required 
(required) 

  
Enter Code Here: Required
 
Page view tracker