SN.EXE and Exported Public Keys

G

Guest

I am using SN.exe to generate key pairs and to extract the public key from
the pair so that our developers can do delayed signing without having to give
them the private key. Here's my concern. The public key and public key
token displayed from the key pair and the public key only are different.
Should this be?

Try this:

sn -k privatepair.snk
sn -p privatepair.snk publickey.snk
sn -tp privatepair.snk
sn -tp publickey.snk

Note that the results of the last two lines is distinctly different.
Shouldn't the extracted public key match the public key from the key pair?
If I am delayed signing files and using app.confg to reference other
assemblies via an assemblyIdentity, what public key token would I use?

Thanks,
 
S

Steven Cheng[MSFT]

Hi Brian,

Thanks for your posting, regarding on the question you mentioned, here're
my understandings:

the SN.exe tool can help generate public/private key pairs or display
publickey/public key TOKEN from a key file or an assembly which is
strong-named. Here is the functions of the sn.exe commands you mentioned:

sn -k keyfile ------will write BOTH public and private key into the keyfile
sn -p infile outfile ---------will write the public key only (in the infile
) into the outfile
sn -tp infile will display the public key TOKEN and public key from the
infile (which need to be generated
by sn -p ).

sn -t will only display the public key TOKEN(rather than public key)

So you can use "sn -k" to genertae the key pair(both public and private)
into a file. And then, we can use
"sn -p" to write the public key from the key pair file into another
separate file. For detailed reference, you can have a look at the following
msdn document:

#Strong Name Tool (Sn.exe)
http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfstrongnameutilitys
nexe.asp?frame=true

Also, if we want to delaysign an assmbly, we can use the following
attribute in AssemblyInfo.cs file generated by
VS.NET if he is using the IDE

[assembly: AssemblyDelaySign(true)]
[assembly: AssemblyKeyFile("key file path")]

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
G

Guest

I thank you for your response, but it did not even address my original
question. My question was not what the SN.exe options were. My question is
why I get different output when I try to examine the public key from a
public/private key pair against the public key that was extracted from the
public key pair. SN.EXE shows me that they are different, but they should
not be.

Try the steps I mentioned in my original post. You will see that the public
key extracted differs from the original public key.

Try this:

sn -k privatepair.snk - Generate a public/private key pair
sn -p privatepair.snk publickey.snk - Extract only the public portion of the
key to file
sn -tp privatepair.snk - use SN.exe to display public key and public key
token
sn -tp publickey.snk - use SN.exe to display public key and public key token

Note that the results of the last two lines are distinctly different.
Shouldn't the extracted public key match the public key from the key pair?
Maybe this is confusing, but shouldn't the public keys match? Because they
don't.
 
S

Steven Cheng[MSFT]

Hi Brian,

Thanks for your quick response. As for the different result of the last two
line you mentioned,:
============================
sn -tp privatepair.snk - use SN.exe to display public key and public key
token
sn -tp publickey.snk - use SN.exe to display public key and public key token
=============================

I think this is a apparent behavior since the
"sn -tp infile" command need that the infile's content must be generated
by the "sn -p" command ,so the
===========
sn -tp publickey.snk - use SN.exe to display public key and public key token
=============
is correct and

==========
sn -tp privatepair.snk - use SN.exe to display public key and public key
token
============

is incorrect. Please have a look at the msdn reference I mentioned in tha
last reply, it has the following comment on the "sn -t[p]" :
=============================
-t[p] infile Displays the token for the public key stored in infile. The
contents of infile must be previously generated using -p.
........
=============================

#NOTE this line "The contents of infile must be previously generated using
-p. "

http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfstrongnameutilitys
nexe.asp?frame=true

That's why the last two command you mentioned will return different
results. Hope this help.
If you have any other questions, please feel free to post here. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
 
R

Richard Blewett [DevelopMentor]

Brian,

The problem is you are giving sn -t too much credit for it's intelligence. All it does is run the hashing algorithm over *whatever* you give it. You could give it the complete works of shakespear in a pdf document and it will happily show you a hash of contents of the file. The file with only the public key and the file with both keys are different and so produce different hashes (It is theoretically possible that they could just coincidently generate the same hash I suppose).

When referencing an external assembly the has of just the public key is stored as the token, therefore to check that value from the key file you must run sn -t on the file containing *only* the public key

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

I thank you for your response, but it did not even address my original
question. My question was not what the SN.exe options were. My question is
why I get different output when I try to examine the public key from a
public/private key pair against the public key that was extracted from the
public key pair. SN.EXE shows me that they are different, but they should
not be.
 
G

Guest

I read the description in the MSDN documentation and now see that it is only
valid to run sn-tp against a key file that ONLY contains the public key that
was generated via 'sn -p'.

Question: How many bytes is a valid public key? Is it variable or fixed?

I only ask because I reread Jeffrey Richter's book "Applied Microsoft .NET
Framework Programming" in chapter 3 pp 75-76 that describes how to generate a
private key pair and then how to view botht he public key portion and public
key token of the key pair. His steps are:

sn -k MyCompany.keys
sn -tp MyCompany.keys

The MSDN documentation and your comments would lead me to believe that this
section of his book is incorrect.

Are you confirming that his text is indeed incorrect?

Thanks,

Brian R.
 
R

Richard Blewett [DevelopMentor]

If he states that to see the public key token that gets burned into the calling assemblies manifest you can run the sn -t against the file with the key pair in it ... then yes, he's wrong. I don't have his book to hand to read the paragraph myself

And sn currently generates a keypair as follows

public key = 128 bytes + 32 byte header
private key = 436 bytes

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

I read the description in the MSDN documentation and now see that it is only
valid to run sn-tp against a key file that ONLY contains the public key that
was generated via 'sn -p'.

Question: How many bytes is a valid public key? Is it variable or fixed?

I only ask because I reread Jeffrey Richter's book "Applied Microsoft .NET
Framework Programming" in chapter 3 pp 75-76 that describes how to generate a
private key pair and then how to view botht he public key portion and public
key token of the key pair. His steps are:

sn -k MyCompany.keys
sn -tp MyCompany.keys

The MSDN documentation and your comments would lead me to believe that this
section of his book is incorrect.

Are you confirming that his text is indeed incorrect?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top