From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <6f12e91dbc4ee6c9cd5b2bf33429ac06@plan9.bell-labs.com> From: presotto@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] passtokey question MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-bgjhrqrilyrkhtkryzdxedzmdg" Date: Wed, 11 Dec 2002 22:25:26 -0500 Topicbox-Message-UUID: 32e8c3ac-eacb-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-bgjhrqrilyrkhtkryzdxedzmdg Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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. --upas-bgjhrqrilyrkhtkryzdxedzmdg Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Wed Dec 11 21:58:17 EST 2002 Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Wed Dec 11 21:58:16 EST 2002 Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.20.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 0664E199B6; Wed, 11 Dec 2002 21:58:08 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from unicorn.math.spbu.ru (unicorn.math.spbu.ru [195.19.226.166]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id AB519199B6 for <9fans@cse.psu.edu>; Wed, 11 Dec 2002 21:57:36 -0500 (EST) Received: (from vugluskr@localhost) by unicorn.math.spbu.ru (8.9.3/8.9.3) id FAA02756 for 9fans@cse.psu.edu; Thu, 12 Dec 2002 05:57:35 +0300 From: "Roman V. Shaposhnick" To: 9fans@cse.psu.edu Message-ID: <20021212055735.A2709@unicorn.math.spbu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i Subject: [9fans] passtokey question Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 12 Dec 2002 05:57:35 +0300 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. --upas-bgjhrqrilyrkhtkryzdxedzmdg--