java.util.Base64 accepts non-canonical encodings

Raffaello Giulietti raffaello.giulietti at gmail.com
Tue Jun 23 13:00:44 UTC 2020


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


More information about the core-libs-dev mailing list