From owner-tn3270e@LIST.NIH.GOV Wed Jul 30 07:30:58 2003 Received: from gdecker.net.nih.gov (list.nih.gov [165.112.130.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27081 for ; Wed, 30 Jul 2003 07:30:58 -0400 (EDT) Received: from list.nih.gov (list.nih.gov [165.112.130.6]) by gdecker.net.nih.gov (8.12.9/8.12.9) with ESMTP id h6UBLKbI008460; Wed, 30 Jul 2003 07:21:22 -0400 (EDT) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8d) with spool id 83465 for TN3270E@LIST.NIH.GOV; Wed, 30 Jul 2003 07:21:19 -0400 Received: from viper.net.nih.gov (viper.net.nih.gov [165.112.130.32]) by gdecker.net.nih.gov (8.12.9/8.12.9) with ESMTP id h6UBLJbI008455 for ; Wed, 30 Jul 2003 07:21:19 -0400 (EDT) Received: from viper.net.nih.gov (localhost [127.0.0.1]) by viper.net.nih.gov (8.12.8p1/8.12.8p1) with ESMTP id h6UBLIqM005155 for ; Wed, 30 Jul 2003 07:21:18 -0400 Received: from neoware.com ([146.145.187.115]) by viper.net.nih.gov (8.12.8p1/8.12.8p1) with ESMTP id h6UBLIQG005150 for ; Wed, 30 Jul 2003 07:21:18 -0400 Received: from [62.232.68.2] (HELO Davehspc) by neoware.com (CommuniGate Pro SMTP 4.0.5) with SMTP id 1233502 for tn3270e@LIST.NIH.GOV; Wed, 30 Jul 2003 07:28:13 -0400 Message-ID: <031301c3568c$f7ac4be0$3d7e7f80@Davehspc> From: "Dave Hefford" To: Subject: RFC 2877, DES encryption of passwords Date: Wed, 30 Jul 2003 12:23:14 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0310_01C35695.591FADB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-tn3270e@LIST.NIH.GOV This is a multi-part message in MIME format. ------=_NextPart_000_0310_01C35695.591FADB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was looking for some clarification and help of RFC 2877 re DES = encryption of passwords.=20 All queries refer to section 6.1, 7=20 a) "A 16 value created by padding the user id" - I assume this is the = potentially 10 byte id not the folded 8 byte id? b) I assume the padding is right padding? c) Finally (less on topic & more asking for help) I'm not familiar with = CBC mode. That would be=20 des_key(pw_token); // set key as schneier=20 res =3D 00 00 00 00 00 00 00 00; // set Initial Vector to 0's res =3D des_enc(res ^ (RDrSEQ+1)); // encode ecb mode random value = from host + seq no. xor'ed with previous result res =3D des_enc(res ^ RDs); // ditto my random value xor'ed = with previous result res =3D des_enc(res ^ ID1st8); // ditto "DUMMYUSR" xor'ed with = previous result res =3D des_enc(res ^ IF2nd8); // ditto " " 8 0x40's = xor'ed with previous result res =3D des_enc(res ^ PWSEQs); // ditto 00 00 00 00 00 00 00 01 = xor'ed with previous result pw_sub =3D res ; // the value to send at last! i.e. using PW_TOKEN as key ECB encode each 8 byte value Xor'ed with the = previous result and start with 0 to give a "previous result" for the = first 8 bytes. ?? I thought that was what I was doing but I don't get the right answer! Some intermediate values would help - the nature of encryption means = where the error is should be obscured. Using the example from page 12 7D 3E 48 8F 18 08 04 04 server seed 4E 41 42 33 4E 41 42 33 client seed 44 55 4D 4D 59 55 53 52 (DUMMYUSR) 44 55 4D 4D 59 50 57 (DUMMYPW) I get c4 2c 11 ce a9 1c de d4 as the PW_TOKEN could anyone confirm this = is correct please? The correct PW_TOKEN for the example could be added to the RFC? All the = intermediate values could be added? (who said technology is no place for = wimps?) Thanks, Dave ------=_NextPart_000_0310_01C35695.591FADB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

I was looking for = some=20 clarification and help of RFC 2877 re DES encryption of=20 passwords. 

All queries refer = to section=20 6.1, 7

a) "A 16 value created = by padding=20 the user id" - I assume this is the potentially 10 byte id not the = folded 8=20 byte id?
 
b) I assume the padding is = right=20 padding?
 
c) Finally  (less on = topic &=20 more asking for help) I'm not familiar with CBC mode. That would be =

des_key(pw_token);        = ;           =20 // set key as schneier
res =3D 00 00 00 00 00 00 00 = 00;        // set Initial Vector to=20 0's
res =3D des_enc(res ^=20 (RDrSEQ+1));      // encode ecb mode = random value=20 from host + seq no. xor'ed with previous result
res =3D des_enc(res ^ = RDs);           &n= bsp; //=20 ditto my random value xor'ed with previous result
res =3D des_enc(res = ^=20 ID1st8);          // = ditto=20 "DUMMYUSR" xor'ed with previous result
res =3D des_enc(res ^=20 IF2nd8);          // = ditto=20 "        " 8 0x40's xor'ed with = previous=20 result
res =3D des_enc(res ^ PWSEQs);   =20       // ditto 00 00 00 00 00 00 00 01 xor'ed = with=20 previous result
 
pw_sub =3D=20 res   ;        &nb= sp;           =20  // the value to send at last!
 
i.e. using PW_TOKEN as key = ECB encode=20 each 8 byte value Xor'ed with the previous result and start with 0 to = give a=20 "previous result" for the first 8 bytes.
 
?? I thought that was what I = was doing=20 but I don't get the right answer!
 
Some intermediate values = would help -=20 the nature of encryption means where the error is should be=20 obscured.
 
Using the example from page=20 12
7D 3E 48 8F 18 08 04 04 = server=20 seed
4E 41 42 33 4E 41 42 33 client seed
44 55 4D 4D 59 55 53 52=20 (DUMMYUSR)
44 55 4D 4D 59 50 57    = (DUMMYPW)
I get c4 2c 11 ce a9 1c de = d4 as the=20 PW_TOKEN could anyone confirm this is correct please?
 
The = correct PW_TOKEN=20 for the example could be added to the RFC? All the intermediate values = could be=20 added? (who said technology is no place for wimps?)
 
Thanks,
 
 
Dave
 
------=_NextPart_000_0310_01C35695.591FADB0--