Internal key strings

[New in Version 3.0]

As of version 3.0, the "internal" RSA key strings are stored in encrypted form. A fresh, random key-encryption key (KEK) is generated for each new process. That means

• You cannot hardcode the internal keys to re-use at a later date
• You cannot share an internal key string between different processes
• You cannot rely on getting the same string when re-reading a key from a file, even in the same process. If you need to compare internal key strings, use the new RSA_KeyHashCode function.

You should always read in the key data from the private and public key files, PFX files, or X.509 certificates at the time they are required.

Internal key string format

The old-style internal key strings would have been a string of base64 characters starting with an "M", e.g.

MIICXAIBAAKBgQDOMfnp2hxoUuapC0oAits0T0cs0uQb7mRa+...

The new encrypted internal key strings are still in base64 format, but will begin with either "PVT" or "PUB" to denote a private or public key respectively.

PVTRujwuI4e5gQP1SRLmc0n9viayF37krSHbHE...
PUBRg1UO9GCVDFLoxE1ihi5p0PoR3Bdrx1U7ky...

Encryption mechanism

The key strings are encrypted using a slightly-modified version of the HMAC key wrapping method described in [RFC3537]. Each process has its own 192-bit key-encryption key (KEK) generated at random when first needed. The same KEK is used for all subsequent key wrapping in that process and for all its threads.

Why?

The original design of the Tookit envisaged the internal key strings only being used with great care and attention by thoughtful programmers who would never compromise the security of the unencrypted data in the strings by saving them or printing them or letting the operating system make unauthorised copies. Yes, indeed!

We always said we might change the format in future versions. Now we have. We may do it again.

[Contents] [Index]