Offsite access for FoilAuth and family ... about foil HOT 5 OPEN

For FoilAuth, the content being encrypted is the secret in its binary form. The rest (number of digits, hash algorithm, totp vs hotp and so on) goes as metadata, or headers if you like, which are also encrypted of course. If you give -v switch to foilmsg, it will print the metadata too, for example:

$ foilmsg -v -d -f 9D5CF9DECB38A32D -s foil.key -o secret -P $PASSWORD
[foilmsg] Private key fingerprint: ab:6d:e6:1d:79:97:33:91:2e:c3:cb:0b:73:9a:b7:69
[foilmsg] Found 4 header(s)
[foilmsg]   OTP-Type: hotp
[foilmsg]   OTP-Label: Test
[foilmsg]   OTP-Digits: 6
[foilmsg]   OTP-Counter: 8
$

All that together contains enough information for transforming the secret into whatever format you prefer, otpauth:// or otpauth-migration:// URL, QR code or whatnot.

The metadata keys are listed here, default values are here.

from foil.

That looks great, thanks. This helps to write a wrapper script to transfer the entries directly into an URI but one thing is still obscure; the decrypted secret. The output file shows for example for the secret "testthis" following:

$ foilmsg -v -d -P {{pass}} -s foil.key -f FoilAuth/{{fileid}} -o /tmp/test.txt
$ hexdump -C  /tmp/test.txt
00000000  99 25 39 9d 12                                    |.%9..|

Is there any way to decode it via CLI tools? I really appreciate your help. Thanks.

from foil.

As an example, something like this:

echo -n "otpauth://totp/Secret?secret=`foilmsg -d -f $INPUT -s foil.key -P $PASSWORD | base32`" | qrencode -o /tmp/secret.png

would produce an importable QR-code. Perhaps I should modify foilmsg to make it easier to extract the headers, i.e. OTP-Label, OTP-Digits and such. Those are necessary to reconstructing an exact copy of the auth token.

from foil.

Ah,okay. It did already tried to use "base32 -d" but the output uses a inverted base32 encoding
direction. That helps greatly to recover from backups offline (e.g. phone stolen).

Just curious, the above coding implies that the secret only supports 32 symbols in the alphabet.
Its a RFC spec requirement, right?

Anyway, thank you very much for the fast response and help!

from foil.

Base32 encoding is simply what Google_Authenticator expects to see in its otpauth:// urls but I don't think it's been actually standardized. One could call it a de-facto standard, I guess. For generating the password you need the secret in the binary form, the textual presentation doesn't affect the core functionality.

BTW Google also uses a binary format for otpauth-migration://offline urls, so it's really no more than a presentation issue. The secret itself it an arbitrary sequence of bytes.

from foil.