Does Convert.ToBase64String return the same length as the original byte array?

Question

I don’t know if I am asking a stupid question, but I want to know if the Convert.ToBase64String function in .NET returns the same length as the size of the original byte, or is it different? I wanted to try an article from MSDN itself How to use authentication with SQL Server 2000 to hash my password, but I found out that they used the function to create a salt string that returns 3 more lengths than it should have returned. For clarification, here is the code for this article.

private static string CreateSalt(int size) { // Generate a cryptographic random number using the cryptographic // service provider RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider(); byte[] buff = new byte[size]; rng.GetBytes(buff); // Return a Base64 string representation of the random number return Convert.ToBase64String(buff); } 

Answer 1

The basic encoding of a byte string is longer than the byte string, because this byte string has 2 ^ 8 possibilities for a "location", whereas a basic 64-string has only 2 ^ 6 possibilities for each location (therefore we call it base 64).

Think of the logarithms and holes of pigeons. Take number 5000. How many places (pigeon holes, bytes) do you need to store it in the 256 base?

 "Locations in base256" = ceil(log_2(5000) / 8) = ceil(1.54) = 2 

Where log_2 tells you how many bits you need. Now how much is base64?

 "Locations in base64" = ceil(log_2(5000) / 6) = ceil(2.04) = 3 

Answer 2

No, Base64 returns 4 bytes to enter 3 bytes, rounded up (padded =) to the next 4-byte boundary.

 int outputLength = ((inputLength+2)/3)*4 

This is because it uses only 6 bits (basically the number 0-63) per byte to use only ASCII characters that are not control characters in the 7-bit range. Therefore, when encoding data with Base64, you get 3 * 8 => 4 * 6 bits.

Answer 3

base-64 rarely returns a string of the same length as the input. In fact, it uses only 6 available 8 bits, so for large messages (in particular), an additional 1/3 of the volume will be required. At the end, there are a few packing bytes (usually "=") to make the message unambiguous.