Search code examples
bashbase64

bash base64 producing inconsistent output?


Can anyone explain this?

[vagrant@centos ~]$ echo "10IXydrdsc4DVAgxzrXldNw5GMeVAHKG:TAO04JuWz4PBVWYm" | base64
MTBJWHlkcmRzYzREVkFneHpyWGxkTnc1R01lVkFIS0c6VEFPMDRKdVd6NFBCVldZbQo=
[vagrant@centos ~]$ echo "MTBJWHlkcmRzYzREVkFneHpyWGxkTnc1R01lVkFIS0c6VEFPMDRKdVd6NFBCVldZbQ==" | base64 -d
10IXydrdsc4DVAgxzrXldNw5GMeVAHKG:TAO04JuWz4PBVWYm

The first string encodes with o= at the end, but the encoded string with == at the end instead, decodes to the same original string...

GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)


Solution

  • Compare these

    echo "10IXydrdsc4DVAgxzrXldNw5GMeVAHKG:TAO04JuWz4PBVWYm" | base64 | od -c
    echo "MTBJWHlkcmRzYzREVkFneHpyWGxkTnc1R01lVkFIS0c6VEFPMDRKdVd6NFBCVldZbQ==" | base64 -D | od -c
    echo "MTBJWHlkcmRzYzREVkFneHpyWGxkTnc1R01lVkFIS0c6VEFPMDRKdVd6NFBCVldZbQo=" | base64 -D | od -c
    

    If we don't send the newline when using echo the o is missing, have a look at this...

    echo -n "10IXydrdsc4DVAgxzrXldNw5GMeVAHKG:TAO04JuWz4PBVWYm" | base64
    

    It's the newline that's being encoded that gives the o in o=

    The = is padding and it might not always be there. Have a look here..

    https://en.wikipedia.org/wiki/Base64#Padding

    Different implementations may also use different padding characters. You can see some of the differences here

    https://en.wikipedia.org/wiki/Base64#Variants_summary_table

    From the RFC

    3.2. Padding of Encoded Data

    In some circumstances, the use of padding ("=") in base-encoded data is not required or used. In the general case, when assumptions about the size of transported data cannot be made, padding is required to yield correct decoded data.

    Implementations MUST include appropriate pad characters at the end of encoded data unless the specification referring to this document explicitly states otherwise.

    The base64 and base32 alphabets use padding, as described below in sections 4 and 6, but the base16 alphabet does not need it; see
    section 8.