Clarify secret storage format #1695
Conversation
| For the purposes of allowing clients to check whether a user has | ||
| correctly entered the key, clients should: | ||
| 5. Encode the IV from step 2, the ciphertext from step 3, and MAC from step 4, | ||
| using base64, and store them as the `iv`, `ciphertext`, and `mac` |
There was a problem hiding this comment.
Question? Padded or unpadded base64? If padded, which variant?
Existing text just says "base64", which implies padded (of some variant). Web uses (I think) padded RFC4648 base64. But the spec also says
it’s expected that most encryption schemes would have
ciphertextandmac properties, where theciphertextproperty is the unpadded base64-encoded ciphertext
There was a problem hiding this comment.
Yeah, I made a mistake not specifying this originally. We want it to be unpadded, to be consistent with everything else in Matrix, but since it was left unspecified, clients should be able to handle either one, for example by base64-decoding the MAC and comparing the binary value instead of comparing the base64 strings.
| | iv | string | The 16-byte initialization vector, encoded with base64. | | ||
| | mac | string | The MAC of the result of encrypting 32 bytes of 0, encoded with base64. | |
There was a problem hiding this comment.
Question: are these required or not? If not, what are clients expected to do if they are absent? Reject the key, or carry on regardless?
There was a problem hiding this comment.
The MSC said that clients "should" calculate and store the IV and MAC, not "must", so I guess they're optional. I don't remember why we made it optional.
If they're not present, we have to assume the key is correct, and carry on.
| | iv | string | The 16-byte initialization vector, encoded with base64. | | ||
| | mac | string | The MAC of the result of encrypting 32 bytes of 0, encoded with base64. | |
There was a problem hiding this comment.
The MSC said that clients "should" calculate and store the IV and MAC, not "must", so I guess they're optional. I don't remember why we made it optional.
If they're not present, we have to assume the key is correct, and carry on.
| For the purposes of allowing clients to check whether a user has | ||
| correctly entered the key, clients should: | ||
| 5. Encode the IV from step 2, the ciphertext from step 3, and MAC from step 4, | ||
| using base64, and store them as the `iv`, `ciphertext`, and `mac` |
There was a problem hiding this comment.
Yeah, I made a mistake not specifying this originally. We want it to be unpadded, to be consistent with everything else in Matrix, but since it was left unspecified, clients should be able to handle either one, for example by base64-decoding the MAC and comparing the binary value instead of comparing the base64 strings.
|
@uhoreg: thanks for the clarifications. Have attempted to clarify the spec text. |
Introduced in matrix-org#1695. Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
* Fix typo in secrets module Introduced in #1695. Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr> * Add changelog Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr> --------- Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>
I found the description of how the
m.secret_storage.key.[key ID]account data object is calculated extremely confusing.Preview: https://pr1695--matrix-spec-previews.netlify.app