Hi,
RFC 4648, in section "3.5. Canonical Encoding", prescribes that pad bits
must be set to zero.
However, the current decoder implementation in java.util.Base64 accepts
non-canonical encodings as well. For example, all of the following four
encodings
KCk=
KCl=
KCm=
KCn=
where only the first is canonical, decode to the sequence of two bytes
0x28 0x29. Padding positions could act as a (very low bandwidth) covert
channel.
Since I'm preparing a patch for [1] (see [2]), I'm asking if this is
intentional behavior or if it is an oversight. Of course, checking for
strictness would slightly impact performance.
If checking for non-zero padding bits is desired, should the API be
extended to allow for both the strict and the (current) lenient
behaviors? Would the current API suffice?
Greetings
Raffaello
----
[1] https://bugs.openjdk.java.net/browse/JDK-8222187
[2]
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067066.html
