Sorry for slow response here - I'll get to it when I'm back from FOSDEM. Speaking of FOSDEM, I'm going there and will be around if anyone wants to chat about oath-toolkit (or anything).
/Simon David Woodhouse <[email protected]> skrev: (30 januari 2015 10:48:48 CET) >On Fri, 2015-01-30 at 09:16 +0000, David Woodhouse wrote: >> >> Although I'm very sad my application is going to need to *know* about >> SHA256 support and jump through lots of compatibility hoops to >> optionally support it with newer liboath. All I want is a function >that >> will "generate a token code from <this> PSKC file and update the file >as >> necessary, with appropriate file locking, if it's HOTP". And then >SHA256 >> would have Just Worked™. > >Speaking of which, that also means I'm going to need to know precisely >what to be looking for in the result of pskc_get_key_algparm_suite() >and >how to turn that into a flags argument to oath_totp_generate2(). > >There's not even a helper function to do that string->flags conversion >for me? > >In fact, I can't actually work it out at all. In RFC6030 it says >(§4.3.4): > > The optional <Suite> element defines additional characteristics of > the algorithm used, which are algorithm specific. For example, in > an HMAC-based (Hashed MAC) OTP algorithm, it could designate the > strength of the hash algorithm used (SHA1, SHA256, etc.). Please > refer to the algorithm profile section, Section 10, for the exact > semantics of the value for each algorithm profile. > >But §10 only shows HOTP (for which SHA256 isn't defined) and PIN >profiles. TOTP was standardised later, in RFC6238, and AFAICT neglected >to provide an update for RFC6030. > >I filed http://www.rfc-editor.org/errata_search.php?rfc=6238&eid=4249
