Bug: base64 decoding adds extra null bytes

[Tschrock]

Describe the current behavior

When decoding base64 text, there will sometimes be extra padding bytes added to the end of the decoded data.

Here's an example where I'm encoding and decoding the same value, and you can see it added extra null characters to my string:

Describe the expected behavior

base64 encoding should be symetric and not add extra bytes.

Steps to reproduce the bug

1. Navigate to ciphereditor.com.
2. Add two "Binary to text encoding" blocks
3. Link the encoded data fields

Version, Environment, Platform

• ciphereditor version: Whatever the current release on https://ciphereditor.com/ is (I can't find a version number listed anywhere)
• Browser and browser version (if applicable):
  • Google Chrome Beta - 130.0.6723.31
  • Firefox Developer Edition - 131.0b5 and 132.0b5
• Operating system:
  • Windows 10 Home - 22H2 - 19045.4894

[anderium]

I've dug around a bit, and found that it's because the transformUnits function incorrectly appends a null byte when used here:

ciphereditor/extensions/essentials/src/binary-to-text.ts

Lines 197 to 199 in 534ff1a

	// Transform unit size (decode)
	const units = transformUnitSize(encodedUnits, outUnitSize, inUnitSize)
	const buffer = Uint8Array.from(units).buffer

The parameters have values […, length=18], 6, 8. If this was encoding, the transformation would need 13.5 units of 8 bits to encode 18 units of 6 bits. Since this is decoding, the truth is that there is actually only 2 bits of information in the final unit, so we can losslessly store it in 13 bytes.

It isn't fixable for arbitrary transformations, because e.g. encoding one or two 3 bit units into 8 bits is indistinguishable if the second 3 bit is all zero. But if you know that ceil(x * 8 / 6) = 18 then you can conclude that 12.75 < x ≤ 13.5, i.e. x = 13. So the fix here would likely be to add a forward/backward switch into the function, which then calculates the maximum number of units that could have lead to that 18 with floor(18 * 6 / 8). Actually, it's impossible to avoid null units if and only if inUnitSize < outUnitSize, so if we've made it impossible to transform into larger units then we can fix it without adding a parameter.

I'll try to make a PR to fix this later.