🚀 go-pugleaf

In article <2830@cheviot.newcastle.ac.uk> amh@mari (Andrew Hilborne) writes:
> I have also written (an even shorter) program which appears to show that
> the setkey(3)/encrypt(3) library routines are broken, this time on
> BSD4.2.  I don't have it here, but the basics are that the program
> fragment:
>
>	setkey(key);
>	encrypt(block, 0);
>	encrypt(block, 1);
>
> Should be a no-op on "block", but is not.

[ The orignal posting said that it looked broken under SysV and SCO XENIX ]

I was contacted after my posting to this newsgroup by someone who works at SCO
(great company, BTW, second time someone from there has called to help and both
times they've been great help, but anyway...) he said that 1) the code I posted
*should* have worked and 2) he looked at the source for encrypt(3) and it is,
in fact, broken.  In his opinion, encrypt(3) has been broken for at least 6
years.

The plot thickens.  My 7th edition manual talks about DES-this and DES-that in
crypt(3).  It describes encrypt(3) such:

	encrypt(block,ed_flag);
	unsigned char *block;
	int ed_flag;

If ed_flag was 0 it encrypted, else decrypted.

BUT! When I actually went to the SysV manuals, crypt(3) no longer mentioned
DES, calling it the "hashing function".  The reeeealy interesting part is that
encrypt is now...

	void encrypt(block,ignored);
	unsigned char *block;

It said that the second variable is ignored but must be given.  This, of
course, makes encrypt(3) a one way function.

Did AT&T break crypt on purpose?  To satisfy export regulations?  Surely they
didn't know it was broken and then didn't feel like fixing it!

Seems a little fishy to me... enquiring minds wanna know!

Jon
-- 
Jon Boede		jboede@auscso.UUCP, jon%bodedo@im4u.cs.utexas.edu
1301 Trace Dr. #204, Austin, TX 78741-1735		(512) 462-3287
	"People who are incapable of making decisions are
	 the ones that hit those barrels at freeway exits."