From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <425C6552.6090908@Princeton.EDU>
Date: Tue, 12 Apr 2005 20:18:26 -0400
From: Martin Harriss <martin@Princeton.EDU>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.0.2) Gecko/20030208 Netscape/7.02
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] crypto question
References: <Pine.BSI.4.61.0504121245410.5044@malasada.lava.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 36f8949a-ead0-11e9-9d60-3106f5b1d025

Done to please the export controllers, methinks.  From the 2nd edition 
ENCRYPT(2) man page:

BUGS
The source is not included in the public distributions. The 
implementation is broken in a way that makes it unsuitable for anything 
but authentication.

Martin


Tim Newsham wrote:
> Hi,
>   I noticed that the libc function encrypt() uses some non-standard form 
> of cipher chaining.  In the normal case one byte from the previous block 
> is reencrypted with 7 bytes from the new block. Additionally there is no 
> initialization vector used.
> 
> This chaining is not very strong (only slightly better than using ECB 
> mode).  In particular:
> 
>   - common prefixes will encrypt the same way.
>   - large common sequences within the middle or end of the
>     data have a reasonable chance of encrypting the same
>     way (2^-8 chance of rejoining at each encryption boundary).
> 
> These weaknesses could open the way for attacks on the code where 
> encrypt() is used.  I was looking over the p9sk1 authentication and 
> didn't notice any obvious attacks, but I'm not particularly good at 
> cryptography (the fact that the challenge has to be matched in tickets 
> encrypted by two different keys offers some protection against splicing).
> 
> Is there any reason this scheme was chosen over more traditional 
> chaining modes?
> 
> Tim Newsham
> http://www.lava.net/~newsham/
>