When the input is not multiple of 3 some bits of the encoded values are not used, Convert.ToBase64XYZ(...) encoder overloads sets those bits to 0, but Convert.FromBase64XYZ(...) decoder overloads currently doesn't check those bits and allows any combination of values. Therefore multiple input could decoded to same value, for example when the input is 1 byte character 'A', encoder encodes it to 2 base64 characters and 2 padding "QQ==" , the last 4 bits of the 2nd Q is not used and set to 0s, but decoder doesn't validate that and allows 2^4 = 16 values decoded into same value, for example: "QQ==", "QR==", "QS==", "QT==", "QV==", "QU==", "QW==", "QX==", "QY==", "QZ==", "Qa==", "Qb==", "Qc==", "Qd==", "Qe==", "Qf" will be decoded to a same value, 65, ascii of 'A'.
The spec mentions that unused bits MUST be set to zero by conforming encoders. It also mentions that decoders may reject an input if pad bits have not been set to zero. Don't see any reason to keep allowing non-zero value for those other combinations that produce same result when encoders are expected to produce only one value.
This doesn't seem to be a breaking change, when encoders expected to set unused bits to 0. Though it could break tests that randomly generates Base64 encoded text for decoding.
When the input is not multiple of 3 some bits of the encoded values are not used, Convert.ToBase64XYZ(...) encoder overloads sets those bits to 0, but Convert.FromBase64XYZ(...) decoder overloads currently doesn't check those bits and allows any combination of values. Therefore multiple input could decoded to same value, for example when the input is 1 byte character 'A', encoder encodes it to 2 base64 characters and 2 padding "QQ==" , the last 4 bits of the 2nd Q is not used and set to 0s, but decoder doesn't validate that and allows 2^4 = 16 values decoded into same value, for example: "QQ==", "QR==", "QS==", "QT==", "QV==", "QU==", "QW==", "QX==", "QY==", "QZ==", "Qa==", "Qb==", "Qc==", "Qd==", "Qe==", "Qf" will be decoded to a same value, 65, ascii of 'A'.
The spec mentions that unused bits MUST be set to zero by conforming encoders. It also mentions that decoders may reject an input if pad bits have not been set to zero. Don't see any reason to keep allowing non-zero value for those other combinations that produce same result when encoders are expected to produce only one value.
This doesn't seem to be a breaking change, when encoders expected to set unused bits to 0. Though it could break tests that randomly generates Base64 encoded text for decoding.
Related to https://github.com/dotnet/runtime/pull/105262