On 26/10/2023 16:38, Pádraig Brady wrote:
Unconditionally disallow encodings that don't have
appropriate zero bits before padding characters.
This handles one class of encoding variations discussed at:
https://eprint.iacr.org/2022/361.pdf
Note the other variations discussed there, due to optional
padding characters are already disallowed.
* lib/base32.c: Check that discarded bits in the encoding are zero.
* lib/base64.c: Likewise.
* tests/test-base32.c: Add test cases.
* tests/test-base64.c: Likewise.
To give a little more context, this will avoid
round trip issues like the following, by failing early:
$ echo "HelloWorld==" | base64 -d | base64
HelloWorlQ==
In general that would make the decoder a bit better
at detecting corruption in the encoded stream,
and more resilient to attacks where users tweak the
encoded stream for nefarious purposes.
I can't see any legitimate case where one would not want/have
zero bits in this case.
Note RFC4648 says:
"In some environments, the alteration is critical and therefore
decoders MAY chose to reject an encoding if the pad bits have not
been set to zero."
So it's within spec, but I don't see a reason why
you would want the behavior of allowing non zero pad bits.
cheers,
Pádraig.
