-
-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
ciphertext
andma
c properties, where theciphertext
property is the unpadded base64-encoded ciphertext
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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