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/