From owner-freebsd-bugs  Tue May  9 10:21:04 1995
Return-Path: bugs-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id KAA20004
          for bugs-outgoing; Tue, 9 May 1995 10:21:04 -0700
Received: from CRASH.ECO.TWG.COM (crash.eco.twg.com [143.172.16.201])
          by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA19998
          for <FreeBSD-bugs@freebsd.org>; Tue, 9 May 1995 10:21:01 -0700
Message-Id: <199505091721.KAA19998@freefall.cdrom.com>
Received: from CRASH.ECO.TWG.COM via Pony Express VMS Mail FPI
	  (v9.5.0-moe002); Tue, 9 May 95 13:20:36 EDT
Date: Tue, 9 May 95 13:20:36 EDT
From: "Reece R. Pollack" <reece@eco.twg.com>
To: freebsd-bugs@FreeBSD.org
Cc: reece@eco.twg.com
Subject: DES Key generation bug
X-Vms-To: pony%"FreeBSD-bugs@freebsd.org"
X-Vms-Cc: REECE
Sender: bugs-owner@FreeBSD.org
Precedence: bulk

FreeBSD version: 2.0-950412-SNAP

It appears that the function des_random_key() (in eBones/des/rand_key.c)
does not consistantly generate keys with odd byte parity. The MIT Kerberos
V4-PL10 code (function des_key_sched() in lib/des/key_sched.c) checks
session keys for odd byte parity, and returns an error if the check fails.
This causes the FreeBSD eBones implementation to be unusable as a Kerberos
V4 ticket server when MIT Kerberos V4-PL10 systems are present in the realm.

Adding an additional invocation of des_set_odd_parity() corrects this
problem:

        des_set_odd_parity((des_cblock *)key);
        des_cbc_cksum((des_cblock *)key,(des_cblock *)key,
                (long)sizeof(key),ks,(des_cblock *)data);
        des_set_odd_parity((des_cblock *)key);		/* <-- new line */

        bcopy(key,ret,sizeof(key));


I'm new to the Unix world, but I understand it's customary to supply the
output of 'diff' for changes. A 'diff -e' comparison reports the following:

38a
        des_set_odd_parity((des_cblock *)key);