search

awslabs / aws-encryption-sdk-specification

AWS Encryption SDK Specification
Other
29 stars 27 forks source link

Generalize "Encrypted Data Key" term #158

Open robin-aws opened 3 years ago

robin-aws commented 3 years ago

The message header format defines the primary artifact that OnEncrypt produced as "Encrypted Data Keys". Not all encryption schemes will need to literally create only multiple encrypted copies of the plaintext data key, however. The binary format does not actually use these terms directly, so we have the opportunity to adjust these names without breaking backwards compatibility; we only have to update our documentation to refer to these existing fields with new names.

I would propose renaming "Encrypted Data Keys" to "Encryption Artifacts", but open to other suggestions.

The specification itself currently allows that the current naming is overly prescriptive:

"Note: "Encrypted" is a misnomer here, as the process by which a key provider may obtain the plaintext data key from the ciphertext and vice versa does not have to be an encryption and decryption cipher. This specification uses the terms "encrypt" and "decrypt" for simplicity, but the actual process by which a key provider obtains the plaintext data key from the ciphertext and vice versa MAY be any reversible operation, though we expect that most will use encryption."

(https://github.com/awslabs/aws-encryption-sdk-specification/blob/master/framework/structures.md#structure)

We should consider generalizing this language a bit further to allow the possibility of recovering the plaintext through operations that require multiple encryption artifacts, as in Shamir's Secret Sharing scheme for example: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing.

Note that the specification labels the actual binary data inside an Encrypted Data Key as "Ciphertext", whereas the developer guide confusingly uses "Encryption Data Key" for this as well. The latter should probably be changed to "Ciphertext" as well, independently of whether we rename the enclosing concept.

seebees commented 3 years ago

It may be a little too abstract but we could change the Ciphertext to Artifact. Since some kind of tokenization scheme is very reasonable but clearly NOT encryption.

robin-aws commented 3 years ago

I definitely feel that we should use a different term for the structure that attaches the provider ID and info to the ciphertext than the ciphertext itself, so I wouldn't be happy with "Encryption Artifact" and just "Artifact". Perhaps something bland like "Data" or "Payload"?

These things have to be at least related somehow to the plaintext data key, so perhaps we shouldn't drop "key" entirely, even if the ciphertext isn't literally an encrypted data key. "Encrypted Data Key Artifact"?