Use associated data to enforce policies

[marsella]

Associated data is a type used in AEAD schemes ("authenticated encryption with associated data") to add context to secret types (secrets, encryption keys, and data blobs). The purpose of including associated data with these types is to provide cryptographic authentication of properties that we want to maintain. Ideally, we'd use this associated data to validate and enforce our policies. For example, if we have a distinction between client- and server-generated secrets, we don't have to rely on the database policy alone to distinguish them for a given operation; we can encode the expected associated data when we decrypt a secret, and if it's not correct, the secret won't decrypt.

Right now, I think we're not taking advantage of this property of authenticated data. Secret types are paired with their expected authenticated data, and at decryption time, the AD description is not compared to the decryption context. This is partly blocked by the simplistic representation of AD right now -- see #237. Ideally, we'd be able to query specific fields on the associated data ("which party generated this secret?") and compare to our expected values.

To improve policy checking, we'd need to update all our decryption methods to either encode exactly the scenario into the AD, or to take parameters for any fields that might vary across decryptions (e.g. user id).

We also want to think about improving accessibility of associated data fields from the parent secret itself. For example, if we encode a protocol version into the associated data, that version should be the same one that's encoded into other locations (e.g. the database?). We want to enforce consistency across such fields so we don't have multiple points of truth.

Closing criteria: I don't know, this issue is still very vague.

[marsella]

@gatoWololo @indomitableSwan - I tried to capture the main points from our discussion last week but I'm not sure I remembered everything we talked about. Can you please review and comment on anything I missed or misremembered?

[indomitableSwan]

I'm particularly unclear what you mean by "protocol version" in the above. My guess is that this is hiding several types of objects that need version tracking, not just one. And e.g., the contextual information that we want to track as part of the secret itself is lower-level (i.e., ECDSA key on secp256k1 or maybe "Blockchain BlocketyBlocks ECDSA key") than the contextual information that is being tracked elsewhere.

[LordQ1]

@jakinyele Is this still relevant?