Retired Microsoft Blog disclaimer

This directory is a mirror of retired "Decrypt My World" MSDN blog and is provided as is. All posting authorship and copyrights belong to respective authors.
Original URL: https://blogs.msdn.microsoft.com/alejacma/2008/05/28/dont-use-default-key-containers-if-possible/
Post name: Don’t use default key containers if possible
Original author: Alejandro Campos Magencio
Posting date: 2008-05-28T04:00:00+00:00


Hi all,

If you read CryptAcquireContext documentation, you'll see that setting pszContainer to NULL allow us to use a default key container.

Microsoft recommends that every application creates its own key container instead of the default one, because key containers can only contain one key or key pair for each key type. That is, it can have one session key, or one public-private key pair. If two or more apps use the default key container, and each stores a key pair there, the last app to write the keys overwrites the previous keys. If the other app has already encrypted data with the previous keys, the data is lost because the overwritten keys are not recoverable. A reasonable key container naming scheme would include your company name, product name, and possibly a version or incremented counter as a serial number. An alternative to this scheme would be togenerate a GUID and use it as key container name. Just don't lose the GUID so that you don't lose the location of your keys!

To obtain a GUID for your app you may i.e.use UUIDGEN.EXE tool (included in Platform SDK or Visual Studio Tools) or use the API (CoCreateGuid, UuidCreate).


More info here: CryptAcquireContext() use and troubleshooting.

I hope this helps.

Cheers,

 

Alex (Alejandro Campos Magencio)


Share this article:

Comments:

Comments are closed.