java.util.Base64 accepts non-canonical encodings

[Roger Riggs]

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