Skip to content
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 that the key backup MAC is implemented incorrectly #1712

Merged

Conversation

sumnerevans
Copy link
Contributor

@sumnerevans sumnerevans commented Jan 16, 2024


name: Clarify that the key backup MAC is implemented incorrectly
about: Clarify that the key backup MAC is implemented incorrectly
title: Clarify that the key backup MAC is implemented incorrectly
labels: ''
assignees: ''


Due to a bug in libolm, all implementations of the
m.megolm_backup.v1.curve25519-aes-sha2 key backup algorithm incorrectly
pass an empty string through HMAC-SHA-256 to generate the mac property
of the session_data.

It was intended for the entire raw encrypted data to be passed through
HMAC-SHA-256, but the issue was caught too late in the process, and thus
we are stuck with this until a new key backup algorithm is introduced.

This commit clarifies the real-world behavior of all current
implementations.

Signed-off-by: Sumner Evans [email protected]

Pull Request Checklist

Preview: https://pr1712--matrix-spec-previews.netlify.app

Due to a bug in libolm, all implementations of the
m.megolm_backup.v1.curve25519-aes-sha2 key backup algorithm incorrectly
pass an empty string through HMAC-SHA-256 to generate the `mac` property
of the `session_data`.

It was intended for the entire raw encrypted data to be passed through
HMAC-SHA-256, but the issue was caught too late in the process, and thus
we are stuck with this until a new key backup algorithm is introduced.

This commit clarifies the real-world behavior of all current
implementations.

Signed-off-by: Sumner Evans <[email protected]>
@sumnerevans sumnerevans requested a review from a team as a code owner January 16, 2024 18:01
@tulir
Copy link
Member

tulir commented Jan 16, 2024

This was found while implementing key backup in mautrix-go (mautrix/go#154)

For reference, this is implemented in matrix-rust-sdk for libolm compatibility: decrypt, encrypt (it never calls update on the hmac). I think the libolm implementation is somewhere around https://gitlab.matrix.org/matrix-org/olm/-/blob/3.2.16/src/pk.cpp#L408-427, but I don't understand C++ well enough to tell why it's wrong.

@sumnerevans
Copy link
Contributor Author

Specifically, I think that https://gitlab.matrix.org/matrix-org/olm/-/blob/master/src/cipher.cpp#L127 is the line that is incorrect in libolm. I think it should be passing ciphertext, ciphertext_length instead of input, input_length - MAC_LENGTH.

Given the function call that @tulir mentioned: https://gitlab.matrix.org/matrix-org/olm/-/blob/3.2.16/src/pk.cpp#L424, it appears that the MAC key is passed as input, and the MAC_LENGTH is passed as input_length, meaning that when input_length - MAC_LENGTH is 0, and regardless of how long input is, nothing will be hashed.

Signed-off-by: Sumner Evans <[email protected]>
Copy link
Member

@uhoreg uhoreg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@uhoreg uhoreg merged commit 9a5cacd into matrix-org:main Jan 16, 2024
12 checks passed
@sumnerevans sumnerevans deleted the clarify-key-backup-mac-doesnt-pass-ciphertext branch January 16, 2024 19:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants