Randomly generated secrets: encoding the random bytes in base64 vs keeping them

Question

Today this came to my attention.
When generating random secrets for e.g. JWT (in node.js the most common way is using the crypto.randomBytes() method), I have noticed a lot of people save these tokens in a base64-encoded manner (i.e. crypto.randomBytes(len).toString('base64').

Charset
However, I thought to my self: doesn't saving a random byte buffer in a base64 encoded string undermine the whole principle of them being 'random bytes'? Base64 has a charset of only 64 characters while the native crypto.randomBytes.toString() method supports 2^8 = 256 characters.

Ratio
Lets say we have a buffer with length n. For a not-base64-encoded buffer of n the encoded counterpart has the length of , which means a base64 encoded string has a overhead of approximately 133% their non encoded counterpart.

Many of you already know this, but for those who don't know: each base64 character represents 6 bits ().
4 * 6 bits = 12 bits = 3 bytes. this means there are 4 characters encoded for a three byte buffer.

However, I said approximately 133% because the output length is rounded up to a multiple of 4. This means that e.g. 1, 2, 3 bytes become 4 bytes; while 4, 5 and 6 are rounded up to 8 bytes. (this is the trailing = you see on base64 encoded buffers most of the time).
Thus, the ratio is approximately 1 to 4 thirds (1:1.33)

With the following explaination, what is the smartest thing to do? Saving the buffer itself (short with big charset) or saving the base64 encoded buffer (long with small charset)?
Or doesn't it matter for bruteforce applications because the amount of bits is almost the same? Or is base64 even safer because base64 is always 0-2 characters longer?

const crypto = require('crypto');
const random = crypto.randomBytes(128);
const lenBuffer = random.length;
const lenBase64 = encodeURI(random.toString('base64')).split(/%..|./).length - 1;

console.log(lenBuffer, lenBase64); // 128 172 => 128 * 1.33 = 170

Edit:
I might not have been clear in my question, my apologies. My primary question here is - what would be faster to bruteforce, the short and complex byte buffer or the longer and less complex base64 encoded string? According to password entropy the length and complexity are not equally proportional, for they are logaritmic instead.

Answer 1

It doesn't matter. A number doesn't change because you change the encoding of it.

101₂ and 5₁₀ is the same number, and contain the same amount of information.

The reason we use base64 is that it is safe printable characters; they won't screw up your terminal if you output them to it, and they will transmit nicely in any computer system capable of handling 7-bit ASCII. The drawback is as you observed the increased overhead.

Or doesn't it matter for brute force applications because the amount of bits is almost the same? Or is base64 even safer because base64 is always 0-2 characters longer?

It's not almost the same. It is the same. Computers treat information as numbers – large numbers. If you represent that number as 8-bit bytes, each digit conveys 8 bits of information. If you represent that number as base64, each digit conveys 6 bits of information. It's still the same number, but the number of digits increased due to lower information content per digit.

Your question is like asking which bus is the soonest: the one in 600 seconds, the one in ten minutes or the one in 10 minutes.

Answer 2

As you say, base64 uses 4/3 times as many symbols to represent the same value.

Each symbol of base64 encodes 6 bits, instead of 8. That's a ratio of 3/4.

(4/3) * (3/4) = 1. The information content is the same.

Answer 3

The binary password has 256^n possibilities, where n is the password length in bytes.

The base64 password has 64^(n*4/3) possibilities, where n is the original password length in bytes and, since the base64 string becomes longer, it's multiplied by 4/3 (as you found out, ignoring potential padding, because you can remove it). We have a smaller base, though (64).

Now,

256^n = 
(2^8)^n = 
2^(8n) = 
2^(4/3*3/4 *8n) =      | 4/3 * 3/4 == 1
2^(3/4*8 * 4/3*n) = 
2^(6* 4/3*n) = 
(2^6)^(4/3*n) = 
64^(4/3*n)

Qed. The number of possibilities to be brute forced is the same in both cases.

Answer 4

You may be wondering which option is more "secure" if you were to take the output and use it directly as a password in, say, a password field on a website.

In that case, it depends on the brute force attack. A straightforward one that uses every possible input value for length n before moving on to length (n+1), of course the better answer is the longer one; the base64 version. But you could also imagine brute force attacks that don't use really uncommon characters at all, in which case the "raw" one might never be cracked. There isn't a single correct answer here.

Additionally, there are a couple problems:

• Using the "raw" output isn't "short with big charset" -- it's likely got bytes in it that don't represent valid character data at all. You need to encode the data in some way to actually turn it into a "charset".
• JWT keys aren't used like passwords on a website. As the other answers correctly state, JWT encryption and signing algorithms use the number directly, not the encoded number.

Answer 5

Thanks to Lodinn, here is the simplest answer:

If it was easier to crack a base64 encoded key rather than a binary key, then the very first thing an attacker with a binary key would do is to base64-encode it.