From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 13 Apr 2005 21:23:28 +0200 From: "Devon H. O'Dell " To: 9fans@cse.psu.edu Subject: Re: [9fans] crypto question Message-ID: <20050413192328.GA13046@smp500.sitetronics.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i Topicbox-Message-UUID: 37876a12-ead0-11e9-9d60-3106f5b1d025 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 12, 2005 at 12:54:20PM -1000, Tim Newsham wrote: > Hi, > I noticed that the libc function encrypt() uses some non-standard form= =20 > of cipher chaining. In the normal case one byte from the previous block= =20 > is reencrypted with 7 bytes from the new block. Additionally there is no= =20 > initialization vector used. >=20 > This chaining is not very strong (only slightly better than using ECB=20 > mode). In particular: >=20 > - 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). Indeed, this provides means for so-called `birthday attacks' in which repeating characters can be guessed which may help an attacker gain further knowledge of the plaintext or key by=20 effectively reducing the effort necessary to brute force (at least part of) the plaintext. > These weaknesses could open the way for attacks on the code where=20 > encrypt() is used. I was looking over the p9sk1 authentication and didn'= t=20 > notice any obvious attacks, but I'm not particularly good at cryptography= =20 > (the fact that the challenge has to be matched in tickets encrypted by tw= o=20 > different keys offers some protection against splicing). Doesn't p9sk1 still use DES? DES was nice, but has several recognized ways to speed up cryptanalysis of the algorithm. 3DES is an alternative, but with combinations such as Rijndael-256 in CBC mode (or indeed, using a strong stream cipher -- Helix looks neat, but it's still too new, I think), I really don't see why we should stick with these things. Of course, we can discuss this all we want, but without code it remains a bikeshed :) > Is there any reason this scheme was chosen over more traditional chaining= =20 > modes? >=20 > Tim Newsham > http://www.lava.net/~newsham/ Perhaps just due to simplicity of implementation? I dunno :). --Devon --gKMricLos+KVdGMg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCXXGwSkf3jVXOdl0RAj/FAJ9NPJS+twTjRJRimkns3st7SPI+NQCglvWg FLt9C/07r+Z1BnGzn7nwwdE= =vwjQ -----END PGP SIGNATURE----- --gKMricLos+KVdGMg--