add details about AEAD library

[marsella]

This updates the "current development phase" with details about the AEAD library.

Closes #70 Closes #27 I think. Please let me know if there should be more details about the (lack of) derivation method for a key for ChaCha20Poly1305. Also, the spec says (in generate-a-key) that the context should include specific parameter selections for the encryption scheme, but I didn't define exactly what that string would be. Should I add that to the "Implementation dependencies" section? Checks off one box in #49

I removed the details about what an AEAD scheme is because they are repeated in cryptographic flows.

[indomitableSwan]

This updates the "current development phase" with details about the AEAD library.

Closes #70 Closes #27 I think. Please let me know if there should be more details about the (lack of) derivation method for a key for ChaCha20Poly1305.

Can you clarify what you mean here? Isn't this just the (already-included) derivation of storage_key? Generating storage_key is where I would expect to see context for usage of storage key to be included (i.e., as part of the storage key itself).

Also, the spec says (in generate-a-key) that the context should include specific parameter selections for the encryption scheme, but I didn't define exactly what that string would be.

Can you clarify what you mean here? Are you referencing the usage of "generate-a-key" to create storage_key here, or something else?

Should I add that to the "Implementation dependencies" section? Checks off one box in #49

This would not belong in "Implementation dependencies", but instead where it's used, i.e., when you create a key for use with the AEAD. I'm OK with not specifying the actual string used (and leaving that to the implementation), but I think the information that is meant to be captured by the context should be specified.

I removed the details about what an AEAD scheme is because they are repeated in cryptographic flows.

[marsella]

Please let me know if there should be more details about the (lack of) derivation method for a key for ChaCha20Poly1305.

Can you clarify what you mean here? Isn't this just the (already-included) derivation of storage_key? Generating storage_key is where I would expect to see context for usage of storage key to be included (i.e., as part of the storage key itself).

We have previously discussed the need to list out any properties of / constraints on the encryption scheme key once we choose it. In this case, there are no constraints beyond being the correct length and generated pseudorandomly. I wondered if we should be explicit about the fact that there are no additional constraints (e.g. so future us / auditors don't wonder whether we missed them).

Also, the spec says (in generate-a-key) that the context should include specific parameter selections for the encryption scheme, but I didn't define exactly what that string would be.

Can you clarify what you mean here? Are you referencing the usage of "generate-a-key" to create storage_key here, or something else?

I mean that I did not explicitly define the parameter selection string that will be included in the associated data, like "ChaCha20Poly1305 with a 96-bit nonce". If we're aiming for interoperability with another implementation, we would want to be explicit, but I'm not sure if it's necessary right now.

Should I add that to the "Implementation dependencies" section?

This would not belong in "Implementation dependencies", but instead where it's used, i.e., when you create a key for use with the AEAD. I'm OK with not specifying the actual string used (and leaving that to the implementation), but I think the information that is meant to be captured by the context should be specified.

Sounds good. I think the context that needs to be included is specified right now, so I won't change anything.

For the record, I suggest "Implementation dependencies" for the specific string because it would change depending on which scheme we use, and I wouldn't want to hard-code a scheme into the more generic key generation function. But it sounds like it's fine to not put it in at all.

[indomitableSwan]

Please let me know if there should be more details about the (lack of) derivation method for a key for ChaCha20Poly1305.

Can you clarify what you mean here? Isn't this just the (already-included) derivation of storage_key? Generating storage_key is where I would expect to see context for usage of storage key to be included (i.e., as part of the storage key itself).

We have previously discussed the need to list out any properties of / constraints on the encryption scheme key once we choose it. In this case, there are no constraints beyond being the correct length and generated pseudorandomly. I wondered if we should be explicit about the fact that there are no additional constraints (e.g. so future us / auditors don't wonder whether we missed them).

Things of that nature would belong in "Implementation dependencies", I guess, but I don't think there is anything we need to capture on this point.

Just to confirm, we aren't attempting to include versioning for "storage key" in the implementation at this point, right? i.e., we are not attempting to close #57 in this PR.

Also, the spec says (in generate-a-key) that the context should include specific parameter selections for the encryption scheme, but I didn't define exactly what that string would be.

Can you clarify what you mean here? Are you referencing the usage of "generate-a-key" to create storage_key here, or something else?

I mean that I did not explicitly define the parameter selection string that will be included in the associated data, like "ChaCha20Poly1305 with a 96-bit nonce". If we're aiming for interoperability with another implementation, we would want to be explicit, but I'm not sure if it's necessary right now.

Should I add that to the "Implementation dependencies" section?

This would not belong in "Implementation dependencies", but instead where it's used, i.e., when you create a key for use with the AEAD. I'm OK with not specifying the actual string used (and leaving that to the implementation), but I think the information that is meant to be captured by the context should be specified.

Sounds good. I think the context that needs to be included is specified right now, so I won't change anything.

For the record, I suggest "Implementation dependencies" for the specific string because it would change depending on which scheme we use, and I wouldn't want to hard-code a scheme into the more generic key generation function. But it sounds like it's fine to not put it in at all.

Yes, that makes sense. I was thinking along the same lines when determining we don't have to include the actual string used to capture context in the spec, we just have to document the need to include parameter choices in context where appropriate. (As it is, I think I went a little too implementation-specific in the spec for derivation of particular keys with respect to context already. Perhaps this should be fixed in #57?)

[marsella]

No, I was not attempting to solve #57 here. I think it would be reasonable to expand that issue to address removing implementation-specific derivations, but I'll let you update the issue because I'm not sure what your specific concern is.