Key Hierarchy in CipherSweet

CipherSweet uses a series of key expansion/splitting techniques to turn a single key (which is handled by the KeyProvider object and may be sourced from third-party key management services) into:

At a super high-level, the picture looks like this:

Key Hierarchy

Where:

The constants C1 and C2 were chosen to have a Hamming distance of 32*4 = 128b between them, and are used to achieve domain separation for secure key splitting.

The Field Enc. Key in the above diagram is the Field Encryption Key, which allows data to be securely encrypted or decrypted in the database.

The Index Root Key in the above diagram is the root key for each blind index on the field. Each index's corresponding key is calculated by taking the HMAC-SHA256 of the packed table name, field name, and index name as the message, and the Index Root Key as the HMAC key, and truncating the result to 32 bytes.

Why were 0xB4 and 0x7E selected?

The primary purpose of these two byte values was to achieve a simple property called domain separation, which helps side-step accidental misuse of cryptographic secrets.

As long as two distinct constants were used, this property is achieved. 0x01 and 0x02 would have been sufficient for satisfying this security goal. Any further design decision would not weaken this security goal.

However, consider that the security proof for HMAC made it clear that a high Hamming distance between the padding values was desirable.

Indeed, a 2012 paper on generic related-key attacks for HMAC demonstrated that poor choice in padding constants could make their attacks significantly more powerful.

This led us to choose padding constants with a high Hamming distance per byte (4, as per HMAC), but distinct from the HMAC padding constants.