4 ms·
It’s not “fluff”, it’s overhead. The real work there is done in about 4 lines (which could be compacted to two and still be somewhat readable). The rest as some
by jsjohnst 4y ago
It’s not “fluff”, it’s overhead. The real work there is done in about 4 lines (which could be compacted to two and still be somewhat readable). The rest as someone else already said, imports, helper functions (there’s no technical need for totp to just be a wrapper around hotp unless you want to expose hotp or be illustrative), function overhead, etc.
That said, TOTP shouldn’t be treated as code golf, especially in production code. The point is the protocol is trivially simple to implement not that it’s X lines in Y language.
- tyingq 4y agoAh, okay. It doesn't appear overly golfed to me. It felt like the point of publishing it was probably similar to what you're saying. That the TOTP algorithm isn't terribly complicated.
- masklinn 4y agoIt's not golfed at all, it's more or less where you get when you implement TOTP by hand from the RFCs. Except for the final reduction, which in the RFC is implemented via a mod, and the base32 decoding, which is not part of either HOTP or TOTP RFCs, but is instead part of the ad hoc "key uri" format. Which is a funny spec because it was defined for Google Authenticator yet AFAIK GA uses none of the parametrisation so that's only useful if you specifically want to exclude GA users.