open-source cryptocard libraries

Frank Cusack fcusack at
Tue Jan 23 13:00:54 EST 2007

On January 23, 2007 10:14:32 AM -0500 Ken Hornstein <kenh at> 
>>> And how would the attacker know what the old cryptocard response is?
>> By brute forcing the AS_REQ.  If use-sad-as-key is set, game over.
>> If send-encrypted-sad is set, it's probably better, but presumably
>> you use hardware preauth to prevent against weak passwords.  But
>> in the case where a weak password can be guessed, send-encrypted-sad
>> makes the hardware auth superfluous if it can be replayed.  Both
>> of these cases are actually noted (to some degree) in the SAM draft.
> I know these are all issues with SAM ... but we were specifically
> talking about CRYPTOCard, and of course in that case neither
> use-sad-as-key nor send-encrypted-sad is used (well, you _could_ use
> send-encrypted-sad, I suppose, but there is no need ... and it's not
> clear to me if the MIT codebase supports use-sad-as-key).  So, I still
> stand by my original statement ... if you're using SAM with CRYPTOCard
> _properly_ then there is no issue with replaying an exchange against

I agree.

I just thought it would be useful to talk about it in more general terms.
I should have explicitly said that for your specific case there were no

> another KDC.  If you are really paranoid, I can think of a simple fix:
> place inside the sam-track-id the hostname or some other KDC-specific
> identifier, and have the KDC check that when it processes the preauth
> data.

great idea!  very effective and easy.

>> In any case, my company, TRI-D Systems ( solves
>> this problem with a kdc plugin to talk to our server (otpd) which
>> then handles all the OTP stuff including global token state mgmt
>> and safe to use in use-sad-as-key mode.  Thus giving the possibility
>> to eliminate user passwords altogether but without the difficulty
>> of a smartcard/PKI deployment.
> Hm.  My big issue with use-sad-as-key is that none of the tokens I have
> seen have enough entropy where I would be comfortable using them as the
> only source of keying material (e.g., the CRYPTOCard only gets you 32
> bits best-case).  Do you guys have a solution to that?  If so, that
> would be pretty cool.

We use HOTP which gives the full range (ie 5 digits = 40 bits), I think.
Please correct me if my thinking is flawed here.

Please educate me why this is important?  use-sad-as-key doesn't
establish the session key does it?  Or are you worried about online
guessing attack.


More information about the krbdev mailing list