A Base64 Surprise(cendyne.dev)
cendyne.dev
A Base64 Surprise
https://cendyne.dev/posts/2022-01-23-base64.html
5 comments
Your example [1] on twitter for PHP is actually quite telling.
I do not think it is well known among application developers, which is why I wrote this post. In fact, my base64 implementation elsewhere is vulnerable to this and it never occurred to me.
Thank you for the rust library recommendation, I was using base64ct.
[1]: https://archive.is/RZwlH
I do not think it is well known among application developers, which is why I wrote this post. In fact, my base64 implementation elsewhere is vulnerable to this and it never occurred to me.
Thank you for the rust library recommendation, I was using base64ct.
[1]: https://archive.is/RZwlH
Interestingly (and somewhat confusingly), the number of the padding characters appears to indicate both how many (6-bit) characters are missing from the last quadruple in the output of the encoder and, at the same time, how many (8-bit) bytes will be trimmed from the last triple by the decoder.
You have a knack for writing these sorts of blog posts. Keep it up.
This has nothing to do with Rust, as suggested in pp#1, and all the guff leading up to the real topic seems to be an attempt at some sort of perverted virtue signaling.
The little grapthics explaining stuff is really cute!
Other than that, cool article :)
Other than that, cool article :)
Hey thanks!
Python and Zig reject invalid padding.
PHP's base64_decode() function accepts it, but the sodium_base642bin() function doesn't.
Since Rust doesn't have base64 support, it depends on the crate being used. The ct-codecs crate rejects invalid padding, the base64 crate doesn't.
So... it depends.
But that issue is well known, and I think most modern implementations reject invalid padding. And in the context of cryptographic operations, you are supposed to use codecs from the cryptographic libraries you are using anyway. These implementations avoid side channels, and, of course, reject non-canonical encodings.