-
Notifications
You must be signed in to change notification settings - Fork 36.7k
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
Add fuzz test for FSChaCha20Poly1305, AEADChacha20Poly1305 #28263
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsNo conflicts as of last run. |
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.
Mostly comments on the fuzz tests. The last commit looks good to me (and maybe we want to split it off).
|
||
auto key = provider.ConsumeBytes<std::byte>(32); | ||
key.resize(32); | ||
auto aad = provider.ConsumeBytes<std::byte>(512); |
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.
This will always construct an AAD of 512 bytes, if that much data is available in the fuzzer input. I think it's better to make the AAD size dynamic, and a function of the fuzzer input data too.
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.
true! it's done like in bip324_cipher_roundtrip
fuzz test now.
}, | ||
[&] { | ||
bool ok = aead.Decrypt(cipher, aad, nonce, contents); // with splits too | ||
if (ok) { |
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.
This will never trigger, as the AEAD advances between between the preceding Encrypt call and the Decrypt call here, so encryption and decryption will never use the same key. With distinct keys, it should be cryptographically impossible for anyone (let alone a fuzzer) to get a match (and if, with extremely low probability, ok=true is returned, it'll be accidental, and plaintext and decrypted result won't match).
There are two possible styles of fuzz tests we could write here, and this feels like a mix between the two:
- A "exercise-the-API" fuzz test, which is only intended to make sure no crashes happen under arbitrary sequences of method calls. I personally think such tests are of rather low value, though of course better than nothing, and we do have some in the codebase (including
crypto_chacha20
andcrypto_fschacha20
). If that's the goal here, you can probably just ignore the return value ofDecrypt
. - A "test encryption and decryption match" fuzz test (possibly combined with a "if errors are introduced between encryption and decryption, the latter fails"). Such tests are a lot more interesting and they test some notion of correctness of behavior in addition to just not crashing. If you want that here, you'll need some approach that involves two
AEADChaCha20Poly1305
objects (one for encrypting, one for decrypting), initialized with matching (or deliberately mismatching) keys, and then running through some scenario that's applied to both to keep them in sync. Thebip324_cipher_roundtrip
fuzz test is of this style (but at a higher level).
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.
thanks for the interesting explanation! updated it to a "test encryption and decryption match" kind of fuzz test.
[&] { | ||
bool ok = aead.Decrypt(cipher, aad, contents); | ||
if (ok) { | ||
assert(plain == contents); |
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 same comment as I've given on the other test about mixing "exercise API" and "test correctness" fuzzing applies here: ok
will never be true (except with negligible probability), and if it does, plain
and contents
won't match.
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.
makes sense. updated it to a "test encryption and decryption match" kind of fuzz test.
src/bip324.h
Outdated
@@ -54,6 +54,7 @@ class BIP324Cipher | |||
|
|||
/** Initialize when the other side's public key is received. Can only be called once. | |||
* | |||
* initiator is set to true if the BIP324 cipher involves initiating the v2 P2P connection |
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.
Nit: .
at the end of the sentence so it's clear the lines are about different arguments.
Also perhaps say "if we are the initiator" or so; every v2 P2P connection involves initiating somehow; the question is whether it's us or the remote side doing that.
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.
done in #28267
@stratospher Want to also address #28008 (comment) and #28008 (comment) here? |
d2ee2f3
to
9ac4022
Compare
so split off the last commit into #28267 since they aren't related to the fuzz test. (included #28008 (comment) and #28008 (comment) there) thinking about #28263 (comment). will address it soon. |
Are you still working on this? |
2e48c8b
to
9494695
Compare
yes! updated the PR to address #28263 (comment). |
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.
Concept ACK
9494695
to
20f769a
Compare
e67634e fuzz: BIP324: damage ciphertext/aad in full byte range (Sebastian Falbesoner) Pull request description: This PR is a tiny improvement for the `bip324_cipher_roundtrip` fuzz target: currently the damaging of input data for decryption (either ciphertext or aad) only ever happens in the lower nibble within the byte at the damage position, as the bit position for the `damage_val` byte was calculated with `damage_bit & 3` (corresponding to `% 4`) rather than `damage_bit & 7` (corresponding to the expected `% 8`). Noticed while reviewing #28263 which uses similar constructs. ACKs for top commit: stratospher: ACK e67634e. dergoegge: utACK e67634e Tree-SHA512: 1bab4df28708e079874feee939beef45eff235215375c339decc696f4c9aef04e4b417322b045491c8aec6e88ec8ec2db564e27ef1b0be352b6ff4ed38bad49a
@theStack want to re-review this? :) |
Could rebase for fresh CI? |
20f769a
to
5a25e70
Compare
🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the Possibly this is due to a silent merge conflict (the changes in this pull request being Leave a comment here, if you need help tracking down a confusing failure. |
2dd6cf4
to
3980563
Compare
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.
tACK 3980563
3980563
to
8607773
Compare
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.
tACK 8607773
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.
Tested ACK 8607773. Ran both targets for ~200 CPU hours. Coverage of intended targets looks good to me. The simulation of damaged keys and checks that follow seem useful as well.
Timeout in #30505 |
Ported to the CMake-based build system in hebasto#280. |
This PR adds fuzz tests for
AEADChaCha20Poly1305
andFSChaCha20Poly1305
introduced in #28008.Run using: