> > "known bug", or an imperfect implementation (i.e. with blowfish), they > > have a responsibility to fix it, and offer a transition path to correct > > it. > btw, that cryptoapi thing is more a 'known issue' than a 'known bug' > > why? because a bug usually leads to loss of data or something different; > but since the patch-int was the only encryption package to read and > write such blowfish encrypted volumes there was no real need to change > that... or was there any established volume-encryption format, to which > compatibility would have been broken? > ok, the bug about it is, that on big-endian machines the on-disk format > is different... but as said in a mail before, this blowfish issue will It _is_ a bug, because the Blowfish algorithm is clearly specified and the cryptoapi implementation breaks this spec. The same bug exists in CIPE, btw., although the code was developed independently the authors made the same mistake (while the 32-bit words are processed internally in host byte order, they have to be _read from memory_ in defined big-endian byte order). This also leads to interoperability problems not only because of different on-disk formats but of different _network_ formats - CIPE uses this implementation in the development version. I've resolved this problem by re-specifying the CIPE network format to use a mutated little-endian Blowfish and coding the internal Blowfish module in a way which uses this byte order even on big-endian machines. (Btw. has anyone ever tested that?) What has mainly kept me from releasing the new, cryptoapi based CIPE as a stable 1.6 about a year ago was that this issue had not been resolved - it would be impossible for a BE and a LE machine to communicate; while this may be tolerable for disks it absolutely isn't for networks. 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? Olaf - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
