I have two chunks of base64 data in a bash variable. The usual line breaks within the base64 data have been replaced by spaces and the variable is basically one very long one-line string.
I can decode the two chunks of base64 data contained in the variable but I experienced some nuances when trying to do it. I'd like to understand if I am approaching this correctly or is there a better way to decode base64 data that does not contain line breaks. Here is what I have:
The first chunk is 350 characters and I can decode it successfully like this:
echo ${DATA::350} | openssl base64 -d | wc -c
256
The second chunk is 5745 characters but the above command doesn't produce the expected results. i.e:
$ echo {DATA:350} | openssl base64 -d | wc -c
432
However, it works if I put the line breaks back:
$ echo ${DATA:350} | tr ' ' "\n" | openssl base64 -d | wc -c
4240
I expect there is some line length issue that the first chunk is small enough to avoid, and it would appear to be a feature of the base64 decoder being used (the two usual ones, base64
and openssl base64
, behave differently).
The base64
decoder (instead of openssl base64
) stops at the first invalid character (the whitespace) and therefore just decodes the first "line" (48 bytes of output data) whereas OpenSSL outputs 432 characters (9 "lines"). The base64
command has an option to ignore garbage, so this works:
$ echo ${DATA:350} | base64 -d -i | wc -c
4240
The OpenSSL decoder doesn't appear to have such an option.
Also, removing the whitespace entirely works for base64
but not openssl base64
:
$ echo ${DATA:350} | tr -d ' ' | openssl base64 -d | wc -c
400
$ echo ${DATA:350} | tr -d ' ' | base64 -d | wc -c
4240
So, in the end, I replaced the newlines and used the OpenSSL decoder because I needed to further process the decoded data anyway:
$ openssl enc -d -a -in <(echo ${DATA:350} | /usr/bin/tr ' ' "\n") -aes-256-cbc -pass file:<(echo $skey) | ...
But I'd like to understand Can OpenSSL decode base64 data that does not contain line breaks ?
tr
, using${var//old[/new}
-- but not at the same time as substringing.