Hi Raffaello,
I think the concern over accepting non-canonical encodings would be
compatibility.
It would rude to implement the strictness and have applications start
failing.
But it is likely an oversight since existing code checks for other
invalid encodings.
Do any of the existing tests fail if the non-canonical encoding throws?
Thanks, Roger
On 6/23/20 9:00 AM, Raffaello Giulietti wrote:
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
