by redmail.netbsd.org with SMTP; 30 Jan 2000 18:29:09 -0000
	by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id SA12710;
	Mon, 31 Jan 2000 05:29:05 +1100 (from kre@munnari.OZ.AU)
From: Robert Elz <kre@munnari.OZ.AU>
To: tech-security@NetBSD.ORG (NetBSD Security Technical Discussion List)
Subject: Re: [harikiri@ATTRITION.ORG: S/Key & OPIE Database Vulnerability] 
In-Reply-To: Your message of "Sun, 30 Jan 2000 13:07:50 CDT."
             <m12EylK-000g6HC@most.weird.com> 
Date: Mon, 31 Jan 2000 05:29:04 +1100
Message-Id: <10352.949256944@munnari.OZ.AU>

    Date:        Sun, 30 Jan 2000 13:07:50 -0500 (EST)
    From:        woods@most.weird.com (Greg A. Woods)
    Message-ID:  <m12EylK-000g6HC@most.weird.com>

  | I'm also now confused as to how it's not possible for someone to
  | determine the next appropriate challenge (and thus calculate the
  | appropriate response) if the /etc/skeykeys file is publicly readable.
  | Obviously if this is true there must be some cryptographically secure
  | algorithm that can combine the seed and the secret to generate a new and
  | hopefully unique challenge.  Unfortunately the documentation is
  | completely silent about the algorithms involved.

Is it?   Maybe I read about it elsewhere.

Its a simple one time hash on the seed and the secret, performed
N times.   Each time it is used the result replaces the known hash
(in skeykeys) and N-1 is used next time.   This relies upon the
uninvertability (if there is such a work) of the hash.  MD5 (or sometimes
MD4) is used as the hash function - it is believed to be hard to invert.
That is, it is easy to go from secret to hash(secret)^N, but very
hard to get from hash(secret)^N to hash(secret)^(N-1).

  | I worry about this
  | because in other implementations of challenge/response systems, such as
  | "CryptoCard(tm)", it's possible to compute the challenge response if one
  | knows RNG seed (and the calculator PIN?).

As it is here - but the seed is the secret, only you know that (in theory).
The skeykeys file is just like the traditional unix passwd file, and only
stores the hashed value (the N times hasshed value, then after that is
used once, the N-1 times hashed value).

  | Thanks for verifying.  I thought it might be but I've been unable to
  | boot a newer sparc release on my spare ss1 and have no non-i386 -current
  | machines to test on.

It was fixed before 1.4.1, maybe even before 1.4 (might have been as
early as 1.3.2 - though I remember being annoyed it wasn't fixed in 1.3.1)

  | 'md5 -x' (a test I'd forgotten completely about) seems to match on all
  | the different machines I've got....

The problem was a mismatch in the theory as to who was supposed to byte
swap the md5 output - it some early version, the md5 results it that were
used produced an endian dependent result, so the skey mainline compensated.
Someone fixed md5 (or switched to a new version) but didn't undo the
skey hack around the bug.

kre