Base64.decode accepts and decodes invalid data

[hannesm]

I tried to use base64 in some security-sensitive contexts, and figured it accepts invalid input (i.e. any amount of trailing =):

# let enc = Base64.encode_string "aa";;
val enc : string = "YWE="
# Base64.decode enc;;
- : (string, [ `Msg of string ]) result = Ok "aa"
# Base64.decode "YWE==";;
- : (string, [ `Msg of string ]) result = Ok "aa"
# Base64.decode "YWE===";;
- : (string, [ `Msg of string ]) result = Ok "aa"

my expectation was that only the first decode to be successful. may be worth to adapt the unit tests from mirleft/ocaml-nocrypto#96 about trailing data (as far as I can see, anything apart from = is rejected with Malformed input -- but = may be enough for an attacker).

[dinosaure]

If I remember correctly, it's an expected behavior in my mind when we discussed about that on the initial PR, And from what I know, it will be a bit complex to invalid such contents.

I mean, currently we invalid contents where we don't have enough "pad" characters (like YWE with pad = true). We really need to invalid a contents if we have "garbage" (where "garbage" should only be the "pad")?

[hannesm]

Yes, I would like if pad = true to get an error if the padding is wrong. The padding in YWE=== is wrong. I thought there was some kind of bijection invariant (encode (decode x) = x), or is it only (decode (encode x) = x) (if so, why?)?