
6 September 1999
Date: Sat, 4 Sep 1999 21:01:28 +0100 To: cypherpunks@cyberpass.net From: Adam Back <adam@cypherspace.org> Cc: shamrock@cypherpunks.to, andrew@cryptonym.com Cc: cryptography@c2.net Subject: MSFT's NSA key as key escrow solution Several people (Carl Ellison?, others) have suggested over the years of the key escrow debate that if the government wants a voluntary key escrow system all they have to do is publish a public key, and anyone wanting to use it can Cc them. A good source of a public key we know is the NSA's public key is the one buried in Lotus notes 'differential crypto' partial key escrow mechanism (24 bits of 64 are escrowed). Andrew do you have the modulus & public exponent in hex? I am thinking we could take the NSA's key from windows and format it as a PGP public key. As a 2nd issue in doing this  what email address would one put on the NSA's PGP public key? Suggestions? Big Brother <dirnsa@nsa.gov>? You need the email address to Cc or Bcc the NSA with. I guess even a non working email address would do  they'll read it anyway with ECHELON, and probably feel duty bound to decrypt it. A disadvantage of doing this with the Microsoft NSA key over the Lotus one is that we know for a fact that the Lotus one is the NSA's; whereas there is some doubt (though in my opinion a rather small doubt) that this is NSA's key. Anyway, if people started encrypted messages to the NSA with it, the NSA would probably obtain it from Microsoft one way or another. The political value of publishing an NSA public key is probably lower now than earlier in the key escrow / GAK debate, because for quite some time the US government was sticking to the line that it would be strictly voluntary  more lately this has been less emphasied, and key escrow itself as a government proposal is probably relatively dead right now. Adam
Date: Mon, 6 Sep 1999 05:20:46 +0200 (CEST) From: Anonymous <nobody@replay.com> Subject: Re: MSFT's NSA key as key escrow solution To: cypherpunks@cyberpass.net According to http://www.cryptonym.com/hottopics/msftnsa.html the keys are stored in the following way: Before CSP loading in ADVAPI32.DLL Address 0x77DF5530 > A9 F1 CB 3F DB 97 F5 ... ... ... Address 0x77DF55D0 > 90 C6 5F 68 6B 9B D4 ... ... ... After RC4 encryption using we see A2 17 9C 98 CA => R S A 1 ... 00 01 00 01 ... (looks like an RSA public key) A0 15 9E 9A CB => R S A 1 ... 00 01 00 01 ... (looks like an RSA public key) In other words you decrypt/encrypt the ADVAPI32.DLL data with the specified RC4 keys and you see what is shown. (Wonder how they figured out the magic RC4 decryption keys???) Let's try it. Looking at a hex dump of ADVAPI32.DLL we find the following data for the two key buffers (which are adjacent): a9 f1 cb 3f db 97 f5 08 b4 ca ae e4 90 0f 36 75 00 0f 6c 9d 85 dd 9b f4 4d 0b c4 96 3e 79 86 30 6d 27 31 ee 4a 85 f5 ff bb a9 bd 81 86 f2 4f 87 6c 57 55 19 e4 f4 49 a3 19 27 08 82 9e f9 8a 8e 41 d6 91 71 47 48 ee d6 24 2d dd 22 72 08 c6 a7 34 6f 93 d2 e7 72 57 78 7a 96 c1 e1 47 38 78 43 53 ea f3 88 82 66 41 43 d4 62 44 01 7d b2 16 b3 50 89 db 0a 93 17 02 02 46 49 79 76 59 b6 b1 2b fc b0 9a 21 e6 fa 2d 56 07 36 bc 13 7f 1c de 55 fb 0d 67 0f c2 17 45 8a 14 2b ba 55 00 00 00 00 90 c6 5f 68 6b 9b d4 97 d2 d9 cc 1d 52 9b ec a5 d7 29 fd 64 03 8c a3 9e fb 93 b6 72 2a da 6f a5 ec 26 39 58 41 cd 3f 49 10 4c cc 7e 23 94 f9 5d 9b 2b a3 6b e8 ec 52 d9 56 64 74 7c 44 6f 36 b7 14 9d 02 3c 0e 32 b6 38 20 25 bd 8c 9b d1 46 a7 b3 58 4a b7 dd 0e 38 b6 16 44 bf c1 ca 4d 6a 9f cb 6f 3c 5f 03 ab 7a b8 16 70 cf 98 d0 ca 8d 25 57 3a 22 8b 44 96 37 51 30 00 92 1b 03 b9 f9 0d b3 1a e2 b4 c5 7b c9 4b e2 42 25 fe 3d 42 fa 45 c6 94 c9 8e 87 7e f6 68 90 30 65 10 00 00 00 00 Note that the last four bytes in each block of 160 bytes are zeros and are probably not encrypted. Decrypting these with the RC4 keys shown above doesn't quite work; the second RC4 key has a typo (noting that each key byte comes from the one above by xoring with 2, we conclude that the last byte of the second key should be C8 not CB). Fixing this, the decryption leads to: 52 53 41 31 88 00 00 00 00 04 00 00 7f 00 00 00 01 00 01 00 95 50 6b 34 21 80 9e f4 bb 99 14 53 9a 82 18 bc 47 50 df e1 8f 8b af ae fb 0c b1 e9 90 5c 4e 85 72 85 5f dd 02 9d da f7 ea 77 b8 c0 17 1b 71 25 29 01 28 7b d7 cb 69 dd ba 0f 3b 0b 26 f8 1b af e9 a2 1f 49 b3 4d 54 d3 26 c9 6e 9f a3 79 e2 9d 14 bd 93 48 4c 7b 7c 45 0c 82 51 69 d9 18 6c da f3 f1 12 ac cc 6a be 31 ba 09 d6 6a 62 76 e9 62 69 b3 b0 52 3e 49 b7 0b c7 75 c3 a9 77 e2 73 b2 00 00 00 00 00 00 00 00 52 53 41 31 88 00 00 00 00 04 00 00 7f 00 00 00 01 00 01 00 1f 2d 68 51 5d 80 a9 8c 7e aa f7 d2 d6 ba 2b a3 29 e8 96 34 1a 51 c7 9c 86 b3 d8 97 30 28 d8 6f 39 7b 66 bc 27 bf 31 eb 01 ed 90 17 e1 a3 88 b1 c5 26 6c b6 1c d7 32 2d 17 db 9a 43 f5 97 5b e8 71 cd 9c 09 cd 22 fd 07 0f e9 76 19 35 9e 4f eb 6e 3f 24 1d 77 08 39 ff 01 a4 1d 56 7b 22 0a 89 50 a4 3a 7d a2 35 dc 1e d8 64 92 65 f0 23 af 15 26 84 4d 2b 3e f9 7c b4 0f 16 cd e3 fe 15 8e ba 00 00 00 00 00 00 00 00 This has the structure indicated on the web page: RSA1 followed by some data, the pattern 01 00 01 00, then 128 bytes of hex data. Note that the hex data must be interpreted in littleendian form to produce an odd number, so the MSB of the RSA moduli will be b2 and ba respectivelly. The exponent is probably 0x010001, a very commonly used RSA exponent. From this it should be easy to construct PGP versions of these two RSA public keys.
Date: Mon, 6 Sep 1999 09:15:53 +0100 To: nobody@replay.com Cc: cypherpunks@cyberpass.net Cc: cryptography@c2.net From: Adam Back <adam@cypherspace.org> Subject: NSA & MSFT CAPI keys as PGP keys Anonymous provided the NSA and Microsoft CAPI keys in hex, so here are their RSA CAPI keys formatted as PGP keys. I've signed them. I put the keys at: http://www.dcs.ex.ac.uk/~aba/nsakey/ Adam Type Bits/KeyID Date User ID pub 1024/51682D1F 1999/09/06 NSA's Microsoft CAPI key <postmaster@nsa.gov> BEGIN PGP PUBLIC KEY BLOCK Version: 2.6.3i mQCPAzfTdH0AAAEEALqOFf7jzRYPtHz5PitNhCYVryPwZZJk2B7cNaJ9OqRQiQoi e1YdpAH/OQh3HSQ/butPnjUZdukPB/0izQmczXHoW5f1Q5rbFy0y1xy2bCbFsYij 4ReQ7QHrMb8nvGZ7OW/YKDCX2LOGnMdRGjSW6CmjK7rW0veqfoypgF1RaC0fABEB AAG0LU5TQSdzIE1pY3Jvc29mdCBDQVBJIGtleSA8cG9zdG1hc3RlckBuc2EuZ292 PokBFQMFEDfTdJE+e8qoKLJFUQEBHnsH/ihUe7oq6DhU1dJjvXWcYw6p1iW+0euR YfZjwpzPotQ8m5rC7FrJDUbgqQjoFDr++zN9kD9bjNPVUx/ZjCvSFTNu/5X1qn1r it7IHU/6Aem1h4Bs6KE5MPpjKRxRkqQjbW4f0cgXg6+LV+V9cNMylZHRef3PZCQa 5DOI5crQ0IWyjQCt9br07BL9C3X5WHNNRsRIr9WiVfPK8eyxhNYl/NiH2GzXYbNe UWjaS2KuJNVvozjxGymcnNTwJltZK4RLZxo05FW2InJbtEfMc+m823vVltm9l/f+ n2iYBAaDs6I/0v2AcVKNy19Cjncc3wQZkaiIYqfPZL19kT8vDNGi9uE= =PhHT END PGP PUBLIC KEY BLOCK Type Bits/KeyID Date User ID pub 1024/346B5095 1999/09/06 Microsoft's CAPI key <postmaster@microsoft.com> BEGIN PGP PUBLIC KEY BLOCK Version: 2.6.3i mQCPAzfTc8YAAAEEALJz4nepw3XHC7dJPlKws2li6XZiatYJujG+asysEvHz2mwY 2WlRggxFfHtMSJO9FJ3ieaOfbskm01RNs0kfoumvG/gmCzsPut1py9d7KAEpJXEb F8C4d+r32p0C3V+FcoVOXJDpsQz7rq+Lj+HfUEe8GIKaUxSZu/SegCE0a1CVABEB AAG0L01pY3Jvc29mdCdzIENBUEkga2V5IDxwb3N0bWFzdGVyQG1pY3Jvc29mdC5j b20+iQEVAwUQN9Nz5j57yqgoskVRAQFr/gf8DGm1hAxWBmx/0bl4m0metM+IM39J yI5mub0ie1HRLExP7lVJezBTyRryV3tDv6U3OIP+KZDthdXb0fmGU5z+wHt34Uzu xl6Q7m7oB76SKfNaWgosZxqkE5YQrXXGsn3oVZhV6yBALekWtsdVaSmG8+IJNx+n NvMTYRUz+MdrRFcEFDhFntblI8NlQenlX6CcnnfOkdR7ZKyPbVoSXW/Z6q7U9REJ TSjBT0swYbHX+3EVt8n2nwxWb2ouNmnm9H2gYfXHikhXrwtjK2aG/3J7k6EVxS+m Rp+crFOB32sTO1ib2sr7GY7CZUwOpDqRxo8KmQZyhaZqz1x6myurXyw3Tg== =ms8C END PGP PUBLIC KEY BLOCK