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

fix(dht)!: add message padding for message decryption, to reduce message length leaks (fixes #4140) #4362

Merged

Conversation

jorgeantonio21
Copy link
Contributor

Description
--- Message length is leaked while performing ChaCha20 encryption for message outbound/inbound. In order to mitigate this vulnerability, we use padding to every message before encryption. In this way, message length is always a multiple of a base length value.

Motivation and Context
--- Tackle issue #4140, see here.

How Has This Been Tested?
--- Add unit tests

stringhandler
stringhandler previously approved these changes Aug 2, 2022
Copy link
Collaborator

@stringhandler stringhandler left a comment

Choose a reason for hiding this comment

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

Could have also used a VarInt for the length, but since we're padding anyway, it's fine

Copy link
Member

@sdbondi sdbondi left a comment

Choose a reason for hiding this comment

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

Thanks for the corrections - tested and works! 🚀

comms/dht/src/crypt.rs Show resolved Hide resolved
@aviator-app aviator-app bot added the mq-failed label Aug 3, 2022
@sdbondi sdbondi changed the title fix: add message padding for message decryption, to reduce message length leaks (see issue #4140) fix(dht)!: add message padding for message decryption, to reduce message length leaks (see issue #4140) Aug 3, 2022
@aviator-app aviator-app bot added mq-failed and removed mq-failed labels Aug 3, 2022
@sdbondi sdbondi changed the title fix(dht)!: add message padding for message decryption, to reduce message length leaks (see issue #4140) fix(dht)!: add message padding for message decryption, to reduce message length leaks (fixes #4140) Aug 3, 2022
@aviator-app aviator-app bot removed the mq-failed label Aug 3, 2022
@jorgeantonio21
Copy link
Contributor Author

Thanks for the corrections - tested and works! rocket

Happy to hear that ! :)

@aviator-app aviator-app bot merged commit b56c63a into tari-project:development Aug 3, 2022
sdbondi added a commit to sdbondi/tari that referenced this pull request Aug 4, 2022
* development:
  fix: wallet database encryption does not bind to field keys tari-project#4137 (tari-project#4340)
  fix: use SafePassword struct instead of String for passwords (tari-project#4320)
  feat(dan): template macro handles component state (tari-project#4380)
  fix(dht)!: add message padding for message decryption, to reduce message length leaks (fixes tari-project#4140) (tari-project#4362)
  fix(wallet): update seed words for output manager tests (tari-project#4379)
stringhandler added a commit that referenced this pull request Sep 2, 2022
Description
---
[PR 4362](#4362) mitigates a metadata leak whereby encrypted messages are the same length as plaintext messages due to the use of a stream cipher. This work adds more complete length checks, such that padding can fail. It also more efficiently handles the edge case where no padding is needed.

Motivation and Context
---
To avoid directly leaking the length of plaintext messages after stream cipher encryption, [PR 4362](#4362) pads such messages to a multiple of a fixed base length after first prepending the original message length using a fixed encoding.

However, the following cases do not appear to be handled by the padding and unpadding code:
- The plaintext message length exceeds the fixed encoding length
- The ciphertext message is not long enough for extraction of the fixed encoding length
- The ciphertext message is not a multiple of the base length

Further, in the case where the message length (after length prepending) is exactly a multiple of the base length, an entire base length of padding is unnecessarily applied.

This work addresses these issues. The padding process now checks that the plaintext message does not exceed the limit enforced by the length encoding; as a result, it can now return an error that propagates to the encryption function caller. The padding algorithm has been simplified and now handles the multiple-of-the-base-length edge case by correctly applying no padding. The unpadding process now checks that it can safely extract the message length, and checks that the ciphertext message is a multiple of the base length.

How Has This Been Tested?
---
No test has been added for the case where the message length exceeds the limit allowed by the encoding, as this would imply very high memory usage (or swapping) exceeding 4 GB. Existing tests pass. A new test exercises the other failure modes.


* Updates to message padding

Adds better length checks. Simplifies the padding algorithm and handles an edge case hitting a base length multiple.

* Add test

* Propagate padding errors

* Rename parameter for clarity

* Better overflow and error handling

* Formatting

Co-authored-by: stringhandler <mikethetike@tari.com>
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