| commit | 1a9edc3e3b1024af4f6dc1ed6bb391510cb494ba | [log] [tgz] |
|---|---|---|
| author | Theo Buehler <theorbuehler@gmail.com> | Mon May 06 06:47:08 2024 +0200 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed May 15 20:19:46 2024 +0000 |
| tree | 0e27e2b9c665eac06629a3d69af5675d32ba27c1 | |
| parent | b8912d713cb82a748bbe63f28f28b17632c70964 [diff] |
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>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
There are other files in this directory which might be helpful: