From owner-freebsd-current Sat Aug 26 19:57:38 2000 Delivered-To: freebsd-current@freebsd.org Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by hub.freebsd.org (Postfix) with ESMTP id 1CD2537B423; Sat, 26 Aug 2000 19:57:28 -0700 (PDT) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id 0668E4D; Sat, 26 Aug 2000 22:57:26 -0400 (AST) Message-ID: <39A88396.A0D06237@vangelderen.org> Date: Sat, 26 Aug 2000 22:57:26 -0400 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: Adam Back , current@freebsd.org, kris@freebsd.org Subject: Re: yarrow & /dev/random References: <200008262032.PAA05849@cypherspace.org> <200008262035.e7QKZsp26706@grimreaper.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: [...] > > Crypto construct-wise I don't think you can treat BF-CBC of a 256 bit > > plaintext with a 256 bit key as a virtual 256 bit block cipher > > operation. I suspect the result will be weaker than 256 bits because > > of the internal structure of BF-CBC. > > I'm not sure I understand this? 256-bit Davies-Meyer is considered secure if a blockcipher with a 256-bit block is being used. Encrypting 256 bits in CBC mode is not the same as a blockcipher with a 256-bit block. For one, it will not obfuscate certain plaintext patterns. Consider what happens if the first 64 bits of two plaintext blocks are equal... Using the current construct allows for a variety of attacks on the compression function of the constructed hash. > > If you want 256 bit hash (and it is desirable for AES) you could use > > what Jeroen suggested: abrest Davies-Meyer, and a 128 bit block > > cipher. Or we could wait for the AES hash mode. > > That is doable; But we don't have any 128-bit block blockciphers in the kernel? > at the moment I only have SHA1, MD5, DES and Blowfish > available in FreeBSD's kernel crypto API; I'd need a lot more evidence > before I feen I can pull in any more :-) You could argue that AES belongs in the kernel as soon as it is selected. You could then go ahead and import Serpent now (as the most conservative possible choice of AES) with the comment that it will be replaced with the real AES later. Waiting for the AES hash mode requires a lot of patience. I suspect a 256-bit hash will accompany the next-generation DSA but that will take at least a year or so... In any case, the currently available building blocks are not sufficient and I doubt you will encounter much objections against importing another cipher. Have you actually asked or is it more of a perceived objection? > > Twofish in abrest Davies-Meyer mode is going to blow away BF-CBC-256 > > pseudo 256 bit block cipher Davies-Meyer performance wise, because of > > the key agility. But Twofish is not neccessarily the best choice. Yes, it's being pushed by Bruce Schneier but that's for marketing purposes, not for technical merits. Iff you are going with a 128-bit-block blockcipher you ought to select the most conservative one and that currently isn't Twofish IMO. [...] > > The quality of the de-skewing function, conservative assumptions about > > distribution of entropy across samples and conservativeness of the > > entropy estimates don't help. It's the yarrow output function which > > blows it. > > Yeah; that monotonically-increasing counter bothers me slightly. Why? How would it affect security if one assumes the blockcipher is secure? Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ jeroen@vangelderen.org _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_ \_| \ _|/' \/ (_)>(_) (_) (_) (_) (_)' _\o_ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message