[PM-2460/24639] Allow empty arrays, and fix string plaintext length hiding #379
+189
−9
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
quexten
changed the title
|
Great job! No new security vulnerabilities introduced in this pull request |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #379 +/- ##
==========================================
+ Coverage 74.09% 76.23% +2.14%
==========================================
Files 253 265 +12
Lines 21781 24228 +2447
==========================================
+ Hits 16138 18471 +2333
- Misses 5643 5757 +114 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Hinton
reviewed
Aug 11, 2025
|
@Hinton good call, I added the tests for the first 3 padding sizes. |
mzieniukbw
reviewed
Aug 12, 2025
mzieniukbw
previously approved these changes
Aug 12, 2025
Hinton
previously approved these changes
Aug 22, 2025
coroiu
reviewed
Aug 25, 2025
Comment on lines
364
to
422
| /// XChaCha20Poly1305 encstrings should be padded in blocks of 32 bytes. This ensures that the | ||
| /// encstring length does not reveal more than the 32-byte range of lengths that the contained | ||
| /// string falls into. | ||
| #[test] | ||
| fn test_xchacha20_encstring_string_padding_block_sizes() { | ||
| let key_id = [0u8; KEY_ID_SIZE]; | ||
| let enc_key = [0u8; 32]; | ||
| let key = SymmetricCryptoKey::XChaCha20Poly1305Key(crate::XChaCha20Poly1305Key { | ||
| key_id, | ||
| enc_key: Box::pin(enc_key.into()), | ||
| }); | ||
|
|
||
| // This test setup considers the minimum and maximum lengths of the first and second block, | ||
| // and the minimum length of the third block. We ensure that the minimum and maximum | ||
| // plaintext values map to the same ciphertext length, but the next block has a different | ||
| // ciphertext length. | ||
| let empty_string = ""; // Padded to 32 bytes | ||
| let empty_string_encrypted = empty_string | ||
| .encrypt_with_key(&key) | ||
| .expect("Encryption should succeed"); | ||
|
|
||
| let largest_first_block_string = "a".repeat(31); // Padded to 32 bytes | ||
| let largest_first_block_string_encrypted = largest_first_block_string | ||
| .encrypt_with_key(&key) | ||
| .expect("Encryption should succeed"); | ||
|
|
||
| let smallest_second_block_string = "a".repeat(32); // Padded to 64 bytes | ||
| let smallest_second_block_string_encrypted = smallest_second_block_string | ||
| .encrypt_with_key(&key) | ||
| .expect("Encryption should succeed"); | ||
|
|
||
| let largest_second_block_string = "a".repeat(63); // Padded to 64 bytes | ||
| let largest_second_block_string_encrypted = largest_second_block_string | ||
| .encrypt_with_key(&key) | ||
| .expect("Encryption should succeed"); | ||
|
|
||
| let smallest_third_block_string = "a".repeat(64); // Padded to 96 bytes | ||
| let smallest_third_block_string_encrypted = smallest_third_block_string | ||
| .encrypt_with_key(&key) | ||
| .expect("Encryption should succeed"); | ||
|
|
||
| assert_eq!( | ||
| empty_string_encrypted.to_string().len(), | ||
| largest_first_block_string_encrypted.to_string().len() | ||
| ); | ||
| assert_ne!( | ||
| largest_first_block_string_encrypted.to_string().len(), | ||
| smallest_second_block_string_encrypted.to_string().len() | ||
| ); | ||
| assert_eq!( | ||
| smallest_second_block_string_encrypted.to_string().len(), | ||
| largest_second_block_string_encrypted.to_string().len() | ||
| ); | ||
| assert_ne!( | ||
| largest_second_block_string_encrypted.to_string().len(), | ||
| smallest_third_block_string_encrypted.to_string().len() | ||
| ); | ||
| } | ||
|
|
There was a problem hiding this comment.
suggestion(non-blocking): I think this could be more readable by using a table-like approach.
Example:
#[test]
fn test_xchacha20_encstring_string_padding_block_sizes() {
let cases = [
("", 32), // empty string, padded to 32
("a".repeat(31), 32), // largest in first block
("a".repeat(32), 64), // smallest in second block
("a".repeat(63), 64), // largest in second block
("a".repeat(64), 96), // smallest in third block
];
let ciphertext_lengths: Vec<_> = cases
.iter()
.map(|(input, _)| encrypt_with_xchacha20(input).to_string().len())
.collect();
// Block 1: 0-31 (same length)
assert_eq!(ciphertext_lengths[0], ciphertext_lengths[1]);
// Block 2: 32-63 (same length, different from block 1)
assert_ne!(ciphertext_lengths[1], ciphertext_lengths[2]);
assert_eq!(ciphertext_lengths[2], ciphertext_lengths[3]);
// Block 3: 64+ (different from block 2)
assert_ne!(ciphertext_lengths[3], ciphertext_lengths[4]);
}
I think this would give the reader a much better instant overview over what lengths are expected for the various inputs
There was a problem hiding this comment.
Nice so much nicer. I applied this
Comment on lines
84
to
91
| #[test] | ||
| fn test_pad_bytes_roundtrip_empty() { | ||
| let original_bytes = Vec::new(); | ||
| let mut cloned_bytes = original_bytes.clone(); | ||
| pad_bytes(&mut cloned_bytes, 32); | ||
| let unpadded = unpad_bytes(&cloned_bytes).unwrap(); | ||
| assert_eq!(Vec::<u8>::new(), unpadded); | ||
| } |
There was a problem hiding this comment.
suggestion: add a test to also check that the if-statement returns an error when appropriate (i.e. don't just check the happy-path)
There was a problem hiding this comment.
I realized a lot of test cases were missing and I added more and coverage should be fairly good now. Note: I noticed a case where a large padding size would result in invalid padding, so I added an extra error condition now, which means pad_bytes can return error in some cases.
|
coroiu
approved these changes
Aug 26, 2025
mzieniukbw
approved these changes
Aug 27, 2025
|
Again, will hit merge since it's minimal changes since everyone reviewed, and I have 2 reviews. |
This was referenced Aug 28, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-24640
https://bitwarden.atlassian.net/browse/PM-24639
📔 Objective
""is a valid value to encrypt, and the current vault code in clients sometimes does encrypt""(and sometimes just returns null). This was not anticipated when writing the padding initially. This changes the padding to allow padding empty byte arrays.Further, it seems the block padding for strings was done incorrectly and only hides the first block's plaintext length, but afterwards has a 1:1 correlation to plaintext length:
Before:
After:
Both of these changes don't break compatibility. However, even if they did, the code is not rolled out yet so it would be OK.
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes