[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Hotp-toolkit-help] client/server extension of HOTP toolkit

From: Daniel Pocock
Subject: Re: [Hotp-toolkit-help] client/server extension of HOTP toolkit
Date: Thu, 16 Dec 2010 22:29:52 +0100
User-agent: Mozilla-Thunderbird (X11/20100329)

Simon Josefsson wrote:
Daniel Pocock <address@hidden> writes:

Do you think some of your modifications would make sense to incorporate
into HOTP Toolkit?  I'm thinking in particular of libhotp that you
copied -- if there are changes we could make to support your project, it
would be good to discuss this.  I think it would be nice if you could
use libhotp directly as an external library.
Actually, I didn't have to modify your code - I simply borrowed the
files hotp.[ch] and used them as the HOTP implementation within my own
process.  It is also intended that I could plug in other code in a
modular way (e.g. TOTP or OCRA)

If you could expose that functionality in a shared library, I could
use that too, just as I'm using unixODBC and apr libraries.

This is already the case -- did you notice that './configure && make
install' installs a library called libhotp?  The library has the hotp.h
header file.

I think I did look at that when I originally put this together, but I felt that it would be more convenient packaging it all in one library.

In retrospect, possibly my project should be called OATH Toolkit rather
than HOTP Toolkit, since I would like to implement TOTP/OCRA as well.
What are your thoughts on this?  It would give it a bit broader scope...

I definitely want my own code to be able to handle TOTP/OCRA - you'll notice plenty of abstractions to support that. So OATH toolkit would be a good name - if you produce liboath, and maybe even go as far as producing .rpm and .deb packages, then I could rely on that as a building block.

I haven't read your source code in too much detail yet, so I may be
missing something.
You can have a look over the SVN browser here:


Essentially, the structure is:

libdynalogin/datasource - backend storage for user data/keys

libdynalogin/ - the controller functionality (selection of algorithm,
selection of user data from backend)

dynalogind/ - a daemon process

(still coming: libdynaloginclient - a client library)

Nice!  I've done some similar and related work for Yubico that may be
useful to get some inspiration from.  I'm especially thinking of the
validation server and its design to separate token secrets from the
validation.  But there are other stuff too.

I certainly understand that - there is always too much to do. That's one reason why I would look positively at using a liboath library rather than trying to have too much of that in libdynalogin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]