Indeed, --totp=SHA384 is ignored and treated as SHA1, you can confirm this with --verbose. I opened https://gitlab.com/oath-toolkit/oath-toolkit/-/issues/37 to fix that.
I looked in https://datatracker.ietf.org/doc/html/rfc6238 and SHA384 is not specified for TOTP. Can you name specific products that generate these kind of QR-codes or TOTP secrets? Supporting TOTP-SHA384 is quite weird to me: there is no real practical speed or security difference compared to SHA512 for the small output space that TOTP uses. I'm not saying NO to support it, but we need more details. /Simon fre 2023-09-08 klockan 16:43 +0300 skrev Sergey Yudin: > Simon, thank you very much for your answer! I mean TOTP and oathtool. > We've got QR-code for our new logins which looks like this: > QR- > Code:otpauth://totp/username:someuuid?issuer=username&secret=LONGBASE > 32KEY&digits=6&algorithm=SHA384&period=30 > > oathtool --totp=SHA384 -d 6 -s 30 -b "BASE32KEY..." gives wrong code. > I thought SHA384 just ignored > > Regards... > > On Tue, Sep 5, 2023 at 11:21 AM Simon Josefsson <si...@josefsson.org> > wrote: > > Sergey Yudin <berem...@gmail.com> writes: > > > > > We faced new login case which requires SHA384 algo. Temporary > > > workaround is > > > to use RedHat's FreeOTP which supports it. Is it possible to add > > > SHA384 ? > > > > Can you point to a specification or product specification? Do you > > mean > > HOTP or TOTP? Support for it in liboath, oathtool, pam_oath, > > libpskc, > > and/or pskctool? What kind of support? > > > > /Simon > > > -- > Regards..
signature.asc
Description: This is a digitally signed message part
