Default padding '=' used in Base32 decoder causes problems

[GoogleCodeExporter]

1. Trying to generate appropriate TOTP for the following URL, for example:

otpauth://totp/android?secret=VPGRENCWPA======

The base32 encoded 'secret' in the above URL had to be padded, and the original 
secret was "abcd12345678" in this example.

2. The 'secret' after parsing the URL will be VPGRENCWPA (i.e the '=' signs in 
the 'secret' are skipped as the '=' sign is used as a token to split the 
parameters in TokenList.java).

3.  Because of that, and because the default padding used in Base32.java is '=' 
sign, the decoded secret will be 'abcd1234563448d159e0' instead of the correct 
value of 'abcdef12345678'.

I was trying to use the androidtoken 2.0.2 on Samsung Galaxy phone, running 
Android 4.2.2, and it was generating wrong TOTP codes.  So, I downloaded the 
androidtoken sources on to Windows machine, and tried it out (after 
retrofitting it for commandline usage) using JDK 1.7 and found the above cause.

I changed the default padding in the Base32.java to use '.' instead of '=' and 
then, it works fine.

Original issue reported on code.google.com by pjeevan...@gmail.com on 25 Feb 2014 at 12:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

After going through the source code, for now, I got around the problem by 
choosing a secret string such that length of it's byte array that is passed to 
Base32.encodeBytes(..) method is multiple of 5.  This way, the 
Base32.ecnodeBytes() method does not have to do the padding of the base32 
encoded string.

So, in the above example, the secret key I chose is 'abcdef12345678901234', so 
that it's byte[] is 10 bytes long.

This generates the following URL:

otpauth://totp/android?secret=VPG66ERUKZ4JAERU

And, when this is parsed and Base32.decoded, it gives the correct secret of 
'abcdef12345678901234'.

This work around is good enough for me.

Original comment by pjeevan...@gmail.com on 25 Feb 2014 at 5:24