问题
Every TOTP implementation (even FreeOTP by RedHat) I find is using Base32 encoding/decoding for it's generated secret. Why is it not using Base64, since Base32 is using roughly 20% more space and it's (mainly) only advantage is, that it is better human-readable? It is not being shown to the user for generation anyways.
While every comment within the implementation says, that its implementation follows RFC6238 / RFC4226, I cannot find anything being said about base32 within the RFC documents.
It obviously makes sense for it to be converted to either Base32 or Base64 because of data safety through transportation, but why not just use Base64 then?
回答1:
The reason base32 is used is to avoid human error. Has nothing to do with space. The reason Base32 is not mentioned in RFC4226 is because it has nothing to do with private key and HMAC and token generation. Base32 is only used to deliver the private key in a human readable form to a human.
More details if interested.
The private key in TOTP should be a 20 byte (160bit) secret. The private key is used with HMAC-SHA1 to encode the epoch time counter. A token is extracted from the genetated 160bit HMAC.
BUT to enter this secret into a tool like google authenticator is not easy. Ok there is the option of a QR code that collects this private key from a website. But this feature isnt always available.
So when you have to enter this private key, you share with the user in base32 format. ie the key is encoded as to produce a BASE32 string.
So why is BASE32 better than base64 in this case.
One important and simple reason and why BASE32 even exists. Is uses A-Z uppercase only (no lowercase) and the numbers 2-7. No 0189. 26 + 6 chars = 32.
There is no lowercase letters and no 0189 so "i" "l" "I" and "1" are not confused. There is only I. B and 8 0 and O confusion is also eliminated.
To the point that if 0 was entered, it can be treated as a O. A 1 as a I etc.
Whether the tools attempts to auto correct, or my preference, just tell user invalid entry is a matter for taste. But what is clear, the human error non-unique interpretation of the string is reduced significantly.
This is not the case with base64.
All of the above issues with upper and lowercase and numbers being confused all apply to base64.
回答2:
I believe it's just a historical context. Someone at the beginning chose Base32, a tool became popular and descendants use the same encoding to comply.
I also saw a lot of implementation using hex format, and examples in the provided RFC6238 use hex as well.
来源：https://stackoverflow.com/questions/50082075/totp-base32-vs-base64