4

I'm currently experimenting with the Windows Cryptography API and running into some problems with Public-Key-Cryptography. I can find lots of examples of how to encrypt items, but nothing directly addressing a start-to-finish public key model.

Here's a rough outline of how my current code looks to generate an encryption key pair, I've removed the error checking code for readability

// MAKE AN RSA PUBLIC/PRIVATE KEY:
    CryptGenKey(hProv, CALG_RSA_KEYX, CRYPT_EXPORTABLE, &hKey);

// NOW LET'S EXPORT THE PUBLIC KEY:
    DWORD keylen;
    CryptExportKey(hKey,0,PUBLICKEYBLOB,0,NULL,&keylen);
    LPBYTE KeyBlob;
    KeyBlob = (LPBYTE)malloc(keylen);
    CryptExportKey(hKey,NULL,PUBLICKEYBLOB,0,KeyBlob,&keylen);
    ofstream outputkey;
    outputkey.open("TestPublicKey.txt", ios_base::out | ios_base::binary);
    for(size_t i=0; i &lt keylen; ++i)
        outputkey&lt&ltKeyBlob[i];
    outputkey.close();
    free(KeyBlob);

// NOW LET'S EXPORT THE PRIVATE KEY:
    CryptExportKey(hKey, 0, PRIVATEKEYBLOB,0,NULL,&keylen);
    KeyBlob = (LPBYTE)malloc(keylen);
    CryptExportKey(hKey,NULL,PRIVATEKEYBLOB,0,KeyBlob,&keylen)
    outputkey.open("TestPrivateKey.txt", ios_base::out | ios_base::binary);
    for(size_t i=0;i&ltkeylen;++i)
        outputkey&lt&ltKeyBlob[i];
    outputkey.close();
    free(KeyBlob);

// ENCRYPT A (SHORT) TEST MESSAGE [SHOULD JUST BE ANOTHER ALG'S KEY LATER]:
    DWORD encryptBufferLen=0;
    CryptEncrypt(hKey, 0, true, 0, NULL, &encryptBufferLen, 0); // how much space?
    BYTE* encryptionBuffer = (BYTE*)malloc(encryptBufferLen);
    memcpy(encryptionBuffer, TestMessage, TestMessageLen); // move for in-place-encrypt
    CryptEncrypt(hKey,0,true,0, encryptionBuffer, &bufferlen, encryptBufferLen );

    ofstream message;
    message.open("Message.txt", ios_base::out | ios_base::binary);
    for(size_t i=0;i&ltencryptBufferLen;++i)
        message&lt&ltencryptionBuffer[i];
    message.close();

My two exported keys are different, but both are able to decrypt message without the other key being loaded. Additionally, if I encrypt a new message in a new session that loads the exported public key, I can still decrypt it with either key.

Can anyone advise me on what I might be doing wrong or missing? Am I on completely the wrong path?

Raj
  • 1,113
  • 1
  • 17
  • 34
Tom
  • 73
  • 1
  • 9

4 Answers4

0

Go through the links below provided by microsoft

http://msdn.microsoft.com/en-us/library/windows/desktop/aa382358(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/aa382044(v=vs.85).aspx

Sreejith
  • 9
  • 1
0

Are you using CryptImportKey on both keys? It looks like your encrypt is just using the handle to thekey you generated. To do Public/Private pairs correctly you should export just the public key with CryptExportKey and give it to whomever needs it. Although this isn't true "encryption" its a way for that person to know it is from you.

cylus
  • 357
  • 1
  • 4
  • 14
Arcite
  • 214
  • 2
  • 11
0

I do not fully understand your query. But generally

  1. You do not encrypt data directly using a public key.

  2. During Encryption: You use a session/symmetric/private key to encrypt data. This session key is then being encrypted by the AT_EXCHANGE public key.

  3. During Decryption: The AT_EXCHANGE private key will decrypt the session key. In turn this session key will be used to decrypt the actual data.

Raj
  • 1,113
  • 1
  • 17
  • 34
  • Re comment one: I'm not really understanding this comment -- I'd like to encrypt with both the public and private keys (traditionally you encrypt with the public to send 'to' the key owner, and with the private to 'sign' as from the key owner). As for #2/#3 that's fine but somewhat irrelevant -- I want raw access to the keys, I'm not using the encryption for standard message exchange but am instead taking advantage of other aspects of public/private encryption. The point remains -- why can't I decrypt with either of the public/private keys appropriately? – Tom Apr 16 '11 at 17:15
  • @Tom, The following post might help, http://stackoverflow.com/questions/3121740/decrypt-data-using-an-rsa-public-key – Raj May 03 '11 at 09:29
0

I am not an expert with this encryption stuff just yet! but I am working with this at the moment so can feel your pain...

Something looks amiss with the encrypt bit

// ENCRYPT A (SHORT) TEST MESSAGE [SHOULD JUST BE ANOTHER ALG'S KEY LATER]:
DWORD encryptBufferLen=0;
CryptEncrypt(hKey, 0, true, 0, NULL, &encryptBufferLen, 0); // how much space?
BYTE* encryptionBuffer = (BYTE*)malloc(encryptBufferLen);
memcpy(encryptionBuffer, TestMessage, TestMessageLen); // move for in-place-encrypt
CryptEncrypt(hKey,0,true,0, encryptionBuffer, &bufferlen, encryptBufferLen );

It appears that you are asking the function to give you the size of the encrypted message so that you can assign its memory i.e. size... BUT you are not passing anything in apart from the key itself so I dont think it would be able to give that information surely..

You have CryptEncrypt(hKey, 0, true, 0, NULL, &encryptBufferLen, 0); // but why "NULL" when you actually should pass in the buffer containing the string to be encrypted, so that it can work out the size and return it for you! Then you can move on with the rest.. I know thats how the export bit works (because your working with the keys in that context), whereas here you are dealing with the actual message. Try passing in the parameter and see how that goes?

I think you'll find that your not actually able to decrypt with both keys, as you haven't actually encrypted anything yet???? Your encrypting a message into a zero sized buffer I think.

As I said not an expert but it does look wrong to me... Strangest thing is I found your post the other day and harvested the working bits to help me understand it, so I really hope that this info helps you!

LeeC
  • 11
  • 3
  • 1
    Hi LeeC, good question. This is a common microsoft pattern and here's the relevant doc line from MSDN: If pbData is NULL, then no error is returned, and the function stores the size of the data, in bytes, in the variable pointed to be pdwDataLen. This lets an application determine the correct buffer size unambiguously. -- http://msdn.microsoft.com/en-us/library/aa925235.aspx – Tom May 05 '11 at 15:25
  • Hi Tom, Oh I now Agree! you are trying to determine the actual size of the buffer based on the Provider etc (chosen in Aquire Context bit). So that implies that all encrypted blocks are the same size regardless of the original message, but dependent on the Provider. Sorry I couldn't be of help! To be honest I wish I had never started with this - I have an assignment due where I will be passing the public key from server to client - client encrypts messages and returns to server - but the public key just wont play nicely! Good Luck to us all! – LeeC May 05 '11 at 20:13
  • LeeC, to solve this problem I eventually gave up and went with CryptoPP -- http://www.cryptopp.com/ -- it was much more useable if that's an option for you. – Tom May 05 '11 at 22:15
  • Thanks Tom, I will certainly have a look. I just worry that I am too far in to start again. I think I have it all encrypting as the message gets turned in something that looks like"-- " in the debugger and then gets decrypted back to the original - exported public key works again on import on the server but something just goes amiss in, after or before transfer to client. On clientside import it gives Bad provider error- but all looks o.k, so I have no idea. I must have read everything on Google but still no solution. Perhaps its time that I ask for a bit of help... Anyways thanks again. – LeeC May 05 '11 at 23:47
  • Hi Tom, I am back and I think I now know what was wrong with your code! Is the code posted above the actual code you are using to acheive your goal? – LeeC May 07 '11 at 20:10
  • I know you have moved on, but thought an explanation may help... If the code above is what you are using then it is wrong! Although you are exporting the keys to the BLOB's and it passes without error, you dont actually import those keys back in to the CSP in order to gain new handles. So the key you use: i.e. (hKey) is more than likely the session key which you have generated somewhere else in the app( in the constructor perhaps), so thats why that key does both en-decrypt! If you imported the BLOB's back to CSP you will gain the new handles; and then I beleive the problem is solved! – LeeC May 07 '11 at 20:19
  • @Raj What do you mean by : 1.You do not encrypt data directly using a public key. Surely you do! Thats the whole point of a Public/Private Key systems. I agree with 2-3 but what do you mean by 1. I am sure you have some logic behind that comment, could you share your thoughts before we all go potty?? – LeeC May 07 '11 at 20:21
  • @Raj My Bad, I now understand what you meant by 1. Basically the public key is used to encrypt the session key, and not the data. – LeeC May 08 '11 at 15:49
  • @LeeC The reason you don't encrypt data directly with a public key is because *public-key* encryption is ***slow***. The accepted solution (e.g. used by PGP, SSL, WPA) is to encrypt the data using the standard AES **symmetric** encryption algorithm, using a random 16-byte key. You then encrypt that **16-byte key** using the public key, and send it, along with the encrypted data. Because you're only encrypting 16-bytes, rather than a whole file, it's much faster. – Ian Boyd Oct 03 '12 at 18:59