CryptEncrypt & CryptDecrypt: Support public/private keys???

[Arsalan Ahmad]

Hello all,

I have two peers (A and B) communicating with each other. A knows B's public
key and B knows A's public key (they are not using certificates, just assume
that they know public key blob some how). I have following questions:

1. A wants to send a message to B by encrypting it with B's public key. Can
it be done using CryptEncrypt() API? and can B use CryptDecrypt() to decrypt
the message or not?
2. A wants to sign a message and send this message to B. B needs to verify
the message. How A can sign the message and B can verify it in the above
scenario (no certificates)?

Thanks,

Arsalan

[lelteto]

Yes, you can do both. What you need is
1. for message security (encryption) A will need to import B's public key
blob (CryptAcquireContext with CRYPT_VERIFYCONTEXT then CryptImportKey with
PUBLICKEYBLOB). Now A needs to generate a so-called session key using
CryptGenKey (pick a strong ecryption eg. AES), encrypt the actual message
with this session key using CryptEncrypt and also wrap the session key with
the recipient's public key using CryptExportKey (hExpKey will be the handle
you got from CryptImportKey of the public key and hKey is the symmetric key
handle you got from CryptGenKey). A will have to send the exported key blob
to B in addition to the encrypted message.
Now on B's side B will first get the private key (opening the container with
CryptAcquireContext then calling CryptGetUserKey AT_KEYEXCHANGE). Then the
key blob accompanying the message will be imported using CryptImportKey
(hPubKey is the handle you got from CryptGetUserKey). The result is the
recovered session key which now can be used to decrypt the message using
CryptDecrypt.

Note that for this you need an AT_KEYEXCHANGE key pair. AT_SIGNATURE will
not allow you to wrap the session key.

2. To sign the message A will need first to get the private key
(CryptAcquireContext of the container holding the AT_SIGNATURE or
AT_KEYEXCHANGE private key followed by CryptGetUserKey). After that the
message hash needs to be calculated (CryptCreateHash, CryptHashData) then
signing the hash (CryptSignHash). The signature will be sent to B together
with the (plain text or encrypted) message.
B will have to first import A's public key (CryptCreateContext
CRYPT_VERIFYCONTEXT and CryptImportKey PUBLICKEYBLOB), then similarly get the
message's hash (CryptCreateHash, CryptHashData). Finally CryptVerifySignature
will do the message authentication.

Note that for all these you don't need any certificate. You work directly
with public key blobs and the private keys in the user's CAPI container.

hope this helps...

Laszlo Elteto
SafeNet, Inc.