Cryptoapi Blowfish implementation and IV argument issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

> > "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


Linux-crypto:  cryptography in and on the Linux system

[Home]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]     [Network Security Reading]

Add to Google