Base64 encode gives different result on linux CentOS terminal and in Java

Question

I am trying to generate some random password on Linux CentOS and store it in database as base64. Password is 'KQ3h3dEN' and when I convert it with 'echo KQ3h3dEN | base64' as a result I will get 'S1EzaDNkRU4K'. I have function in java:

public static String encode64Base(String stringToEncode)
{
    byte[] encodedBytes = Base64.getEncoder().encode(stringToEncode.getBytes());
    String encodedString = new String(encodedBytes, "UTF-8");

    return encodedString;
}

And result of encode64Base("KQ3h3dEN") is 'S1EzaDNkRU4='.

So, it is adding "K" instead of "=" in this example. How to ensure that I will always get same result when using base64 on linux and base64 encoding in java?

UPDATE: Updated question as I didn't noticed "K" at the end of linux encoded string. Also, here are few more examples:

• 'echo KQ3h3dENa | base64' => result='S1EzaDNkRU5hCg==', but it should be 'S1EzaDNkRU5h'
• echo KQ3h3dENaa | base64' => result='S1EzaDNkRU5hYQo=', but it should be 'S1EzaDNkRU5hYQ=='

Answer 1

Found solution after few hours of experimenting. It seems like new line was added to the string I wanted to encode. Solution would be : echo -n KQ3h3dEN | base64

Result will be the same as with java base64 encode.

Answer 2

Padding

The '==' sequence indicates that the last group contained only one byte, and '=' indicates that it contained two bytes.

In theory, the padding character is not needed for decoding, since the number of missing bytes can be calculated from the number of Base64 digits. In some implementations, the padding character is mandatory, while for others it is not used.

So it depends on tools and libraries you use. If base64 with padding is the same as without padding for them, there is no problem. As an insurance you can use on linux tool that generates base64 with padding.