Re: [9fans] passtokey question

[presotto@plan9.bell-labs.com]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

The original passtokey took a (at most) 8 byte key and turned it into
a 56 bit DES key.  The easiest way to do it was to throw out the
high order bit since it conveyed no information in ASCII, a 7 bit
encodeing.  It survived our excursion into UTF encoding mostly
by inertia and a desire not to retype everyone's keys into the
auth server should we do something else, like take 56 bits of the
sha1 encoding of the key + a salt.

[-- Attachment #2: Type: message/rfc822, Size: 2025 bytes --]

From: "Roman V. Shaposhnick" <vugluskr@unicorn.math.spbu.ru>
To: 9fans@cse.psu.edu
Subject: [9fans] passtokey question
Date: Thu, 12 Dec 2002 05:57:35 +0300
Message-ID: <20021212055735.A2709@unicorn.math.spbu.ru>

I'm quite new to the world of auth related algorithms, so my question
might be a FAQish one, but nevertheless, here it is anyway. Why
passtokey works the way it does. I suppose there were some security
related considerations, by I can't seem to grasp, why, for example,
this is being done:

    for(i = 0; i < DESKEYLEN; i++)
	key[i] = (t[i] >> i) + (t[i+1] << (8 - (i+1)));

where you kinda shuffle bytes around, but why ? Just to stuff
8 bytes from t into 7 bytes of key ?

On the similar note, why did you chose to re-encode parts of t with
a previous key, and not some other way of stuffing long passwords
into 7bytes long DES key ?

Thanks,
Roman.