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

[Daniel Pocock]

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:
> >
> > http://dynalogin.svn.sourceforge.net/viewvc/dynalogin/trunk/
> >
> > 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