Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Test and document decision around CFB8 padding #64949
Conversation
For compatibility purposes with .NET Framework ciphertexts, we permit CFB8 to contain excess, up to BlockSizeInBytes, padding.
|
Tagging subscribers to this area: @dotnet/area-system-security, @vcsjones Issue DetailsI initially thought I found a small bug in how CFB8 padding was validated with the one shots. Fortunately, I remembered why the code was the way that it is. Unfortunately, this decision was neither documented in tests nor with a comment. This PR aims to document why it is the way that it is, both with a comment and a test. The core issue was that a place we expect to be passed "padding size" was being passed "block size". This is not correct for CFB since padding and block size are not the same for CFB8. However, this is a compatibility decision to be compatible with the .NET Framework CFB8 cipher texts. The .NET Framework always padded CFB to the block size, and we want the one-shot to be able to continue to do that. That was not immediately obvious why decryption was using block size and not padding size. Encryption is fine - it always pads to the feedback size.
|
| alg.Key = Key; | ||
|
|
||
| // This is a plaintext that is manually padded. Though it is going to be | ||
| // encrypted with CFB8, it's padded to BlockSizeInBytes-1. |
There was a problem hiding this comment.
By writing BlockSizeInBytes-1 and having 1 semantic byte, we're really manually padding to the block size.... which I assume is what you meant.
At least, to me, "padded to BlockSizeInBytes-1" would be "we turned a one byte message into a 15 byte message" (for AES. 7 for DES)
There was a problem hiding this comment.
Ah okay, yeah I see how that was not clear. It was 1 byte of data with N-1 bytes of padding, to make a block-size worth of data. Hopefully that is more clear.
I initially thought I found a small bug in how CFB8 padding was validated with the one shots. Fortunately, I remembered why the code was the way that it is. Unfortunately, this decision was neither documented in tests nor with a comment.
This PR aims to document why it is the way that it is, both with a comment and a test.
The core issue was that a place we expect to be passed "padding size" was being passed "block size". This is not correct for CFB since padding and block size are not the same for CFB8. However, this is a compatibility decision to be compatible with the .NET Framework CFB8 cipher texts. The .NET Framework always padded CFB to the block size, and we want the one-shot to be able to continue to do that.
That was not immediately obvious why decryption was using block size and not padding size.
Encryption is fine - it always pads to the feedback size.
The text was updated successfully, but these errors were encountered: