[6430] in cryptography@c2.net mail archive
Re: small authenticator
daemon@ATHENA.MIT.EDU (Arnold G. Reinhold)
Wed Jan 19 16:06:06 2000
Mime-Version: 1.0
Message-Id: <v04210102b4abc3d66dd8@[24.218.56.92]>
In-Reply-To: <3.0.3.32.20000119111332.00b59b60@mailhost.sctc.com>
Date: Wed, 19 Jan 2000 14:55:40 -0500
To: Rick Smith <rick_smith@securecomputing.com>, staym@accessdata.com,
cryptography@c2.net
From: "Arnold G. Reinhold" <reinhold@world.std.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 11:13 AM -0600 1/19/2000, Rick Smith wrote:
>At 04:49 PM 01/18/2000 -0700, staym@accessdata.com wrote:
>>I've got something with around 100 bytes of ram and an 8-bit multiply.
>>Is there an authentication mechanism that can fit in this?
>
>What types of attacks are you concerned with? That's the main question. If
>you have a direct, unsniffable connection from the device to the person
>being authenticated, then just stick some secret data in there, and make
>the guy provide the secret. Be sure to give him/her a way to change the
>secret.
>
>If you're passing the authentication data across a sniffable connection,
>then I doubt you have the resources to do unsniffable authentication. That
>requires a reasonably strong crypto computation. You can throw some sand in
>attackers' eyes by doing challenge/response authentication with weak
>encryption, but a determined attacker should be able to recover the secret
>from intercepted challenge/response pairs.
>
You might consider the RC4 algorithm with a 64 byte state array. That
leaves enough space for a 90 bit secret, stored as 15 six-bit bytes,
a similar sized or slightly smaller challenge vector, and a few
bytes for indexing. The secret and challenge form the key, of course.
After the key setup, I would generate and discard a large number of
cypher bytes, say 512, and use the next 15 cypher bytes as the
response. The challenge array can be overwritten at this point.
Arnold Reinhold
