On Fri, 1 Mar 2002, Olaf Titz wrote: > It _is_ a bug, because the Blowfish algorithm is clearly specified and > the cryptoapi implementation breaks this spec. ack - as it concern the crypto API, of which one would expect to implement the algorithm correctly; especially wrt network protocols > I've also long suspected that the cryptoapi IDEA implementation has > the same problem. Has anyone ever verified this? (Sorry, I don't have > a big-endian box to test.) > > > be resolved... i.e. by fixing the current, and providing a > > compat-blowfish cipher... > > Which is the only sane way out of this mess, yes. > While we're at it, can anyone tell me why the IV argument in the > cryptoapi functions since 2.4.16 is specified as u32[] ? I see the > imminent danger that the same implementation mistake as cited above > will be made again, as someone will write code which reads and writes > the IV in 32-bit chunks. For the same reason as for the ciphers > themselves, this does not work. Can this possibly be changed to a byte > pointer? sure; planned anyway... and btw, the old API used the context struct to store the IV, but this lead to non-reentrancy issues when the IV was changed frequently; I've been told CIPE's cvs version still uses the context for IV; shall I re-introduce context-IV's for compatibilities sake, and change the API a bit as well? (i.e. 2 calls, encrypt () and encrypt_iv ()) regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142 - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
