java.util.Base64 accepts non-canonical encodings

[Raffaello Giulietti]

Hi Roger,

I didn't yet implement the strict check since, as you point out, it 
could harm existing code in the wild, even if the OpenJDK test would all 
pass.

That's why I'm wondering if it would make sense to extend the existing 
API to have the check as an additional option.


Greetings
Raffaello


> 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