[9fans] passtokey question

[9fans] passtokey question

[Roman V. Shaposhnick]

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.

Re: [9fans] passtokey question

[Boyd Roberts]

Roman V. Shaposhnick wrote:

>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 ?
>
This was probably done to reduce the the possibility that the
key would be limited to typeable/printable ASCII.  Any limit
of the keyspace will make brute forcing easier.

Re: [9fans] passtokey question

[presotto]

We needed a mixing (i.e. hash) algorithm to go from > 56 bits to 56 bits.
At the time DES was the best mixing algorithm we had.  It was, and still
is, used in a number of pseudo random number generators so there was some
precedent.  If I had to do it from scratch today, I'ld probably run sha1
or mda5.

Re: [9fans] passtokey question

[Roman V. Shaposhnick]

On Wed, Dec 11, 2002 at 10:25:26PM -0500, presotto@plan9.bell-labs.com wrote:
> 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.

Thanks. That explains the first part very nicely, but what about the
second part, where you're using key built-so-far to econde the rest
of the given password over and over again ? Is there something special
about this approach, or is it there by a mere chance ?

Thanks,
Roman.

P.S. Pardon my ignorance, but do you know about any other softwre that
has something similat to passtokey ?

Re: [9fans] passtokey question

[presotto]

[-- 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.