> i believe i have found a bug in BF_cbc_encrypt() in 0.9.5a.
> still not sure if it was repaired in 0.9.6beta2, i hope to test
> this with 0.9.6beta2 sooner (if you can, please).
>
> from cbc definition:
>
> P1 P2 Pi
> | | |
> IV->->(X) +>->->->(X) +>->->->(X)
> v ^ v ^ v
> +-----+ ^ +-----+ ^ +-----+
> k1->| E | ^ k1->| E | ^ k1->| E |
> +-----+ ^ +-----+ ^ +-----+
> v ^ v ^ v
> +>->->+ +>->->+ +>->->
> | | |
> C1 C2 Ci
>
> if IV is all zero, C1 must be equal to ciphertext generated by
> simple single block cipher, like
> C1 == encrypt(P1, k1)
> but this is not the case for openssl BF_cbc_encrypt.
as far as I understand, the problem is rather severe.
- the problem is still present in 0.9.6beta2.
- the issue with blowfish will be present for little endian machines
(like i386). the source of the problem is the (mis)use lf
n2l()/l2n() in bf_cbc.c. the functions fetch/put cleartext/
ciphertext in wrong endian.
- a similar problem seem to be present in des-cbc code, for big endian
machines, due to (mis) use of c2l()/l2c().
i would like to hear a comment, about how endianness should be handled
in openssl tree, especially when block cipher functions take a pointer
to non-char (like BF_LONG = 32bit). if I were to update crypto/*
functions, i make all the block cipher functions to take
unsigned char *, not something like BF_LONG *.
itojun
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
