tree 0e27e2b9c665eac06629a3d69af5675d32ba27c1
parent b8912d713cb82a748bbe63f28f28b17632c70964
author Theo Buehler <theorbuehler@gmail.com> 1714970828 +0200
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1715804386 +0000

Document and test stance on non-canonical base64

From RFC 4648:

3.5. Canonical Encoding

   The padding step in base 64 and base 32 encoding can, if improperly
   implemented, lead to non-significant alterations of the encoded data.
   For example, if the input is only one octet for a base 64 encoding,
   then all six bits of the first symbol are used, but only the first
   two bits of the next symbol are used.  These pad bits MUST be set to
   zero by conforming encoders, which is described in the descriptions
   on padding below.  If this property do not hold, there is no
   canonical representation of base-encoded data, and multiple base-
   encoded strings can be decoded to the same binary data.  If this
   property (and others discussed in this document) holds, a canonical
   encoding is guaranteed.

   In some environments, the alteration is critical and therefore
   decoders MAY chose to reject an encoding if the pad bits have not
   been set to zero.  The specification referring to this may mandate a
   specific behaviour.

OpenSSL's decoder has always accepted non-canonical encodings and it
still appears to be the prevalent practice in 2024. In particular Go's
encoding/base64 package requires you to opt into strict mode (which
encoding/pem does not use). Also, Bouncy Castle and NSS accept such
encodings.

So add a comment to the code that this is a deliberate, if perhaps
begrudging, choice and encode this in regress with a few test cases
that are more obviously of a degenerate nature than the current
non-canonical forms.

Also, group the test vectors straight from RFC 4648 section 10 together.

Change-Id: Ibcc22b7feed86fe1cb0fd51a1d61ec0c60dc8672
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68247
Auto-Submit: Theo Buehler <theorbuehler@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: David Benjamin <davidben@google.com>