On Tue, Jun 21, 2011 at 03:38:39PM +1200, Peter Gutmann wrote: > Jeffrey Walton <[email protected]> writes: > > >The 'details' mentioned above is at http://www.schneier.com/blowfish-bug.txt, > >and here's the crux of Morgan's report: > > > > [bfinit] chokes whenever the most significant bit > > of key[j] is a '1'. For example, if key[j]=0x80, > > key[j], a signed char, is sign extended to 0xffffff80 > > before it is ORed with data....
Wow. I was aware that some buggy Blowfish implementations existed, but I was not aware of what the bug was. > When I saw Solar's post I actually wondered whether it was this bug, Same kind of bug, yes. > propagated through the use of that BF implementation. No, I invented it on my own. ;-( Anyhow, here's how I am dealing with the issue in code: Bug fix, plus a backwards compatibility feature: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/crypt_blowfish.c.diff?r1=1.9;r2=1.10 8-bit test vectors added, for both modes (correct and buggy): http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/wrapper.c.diff?r1=1.9;r2=1.10 These are only used by "make check", which I felt was not enough - many people are taking just the main C file and use it in their programs. Obviously, my "make check" would not exist in their source code trees. So if those programs are ever miscompiled or otherwise broken, it might not be detected. To deal with this, I added: Quick self-test on every use: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/crypt_blowfish.c.diff?r1=1.10;r2=1.11 I am likely to go ahead and release this. Alexander _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
