Re: New crypto in 2.3.4

Denis Corbin <[email protected]> Fri, 06 Jul 2007 11:35:41 +0200
Newsgroups gmane.comp.sysutils.backup.dar.general
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Dave,

Dave Vasilevsky wrote:
> The new crypto stuff in 2.3.4 is posing a slight problem for me.

That's anoying, I agree. There is two reasons for the need of evp.h. the
first is to make a hash function applied to the password given by the
user before using is as a key for encryption. The idea is that human
usually use a reduced set of caracters, finding the key is thus a bit
less easy.

For this point I can add an option to disable it and have dar make a
conditional use of this feature depending on the presence of evp.h. this
would let dar compile but need that the user specify this new option to
disable this hash function for dar to run normally.

The second point is necessary to fix the Initial Vector (IV) too
frequent collision (only a few of the different possible IV were used).
In fact an IV is needed for each block of encryption, and the algorithm
used to know the IV of the Nth encryption block was dependant on N which
 is not the best solution. the patch proposed by Dwayne C. Litzenberger
does follows the state of the art basing the IV on a secondary
encryption key (no more on the the number N of the encryption block).

As I have not enough knowledge in the domain of strong encryption to
evaluate the risks and avoid generating weakness, I have not much
solution to propose here.

I will thus contact Dwayne, maybe he will have some hints about that
second point.

> Strong crypto support no longer compiles without openssl/evp.h and
> openssl/hmac.h. Some of the earlier versions of OS X did support
> strong crypto previously, but now they can't anymore since they don't
> have those headers

yep.

> 
> I don't like the idea of removing crypto support from people who
> previously had it. 

I don't neither, even if the crypto algorithm used was not perfect.
Another solution is to keep the original algorithm beside the new and
lable the old algorithm "wbf" (or "weak-blowfish"). Thus, having the
real blowfish "bf" available in the resulting binary based on the
presence of theses offending headers.

> Can you think of any other option, or some way to
> work around this problem?
> 
> Dave
> 

Regards,
Denis.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGjgztpC5CI8gYGlIRAiUtAJ90nv5T7bEFfiO3ORRRtUyrto6noQCgy0jx
p37qnc9Z8EPMWiofeP/+8so=
=Mx9f
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/