On Thu, 2002-02-28 at 14:23, IT3 Stuart Blake Tener, USNR-R wrote: > present the same level of crypto support (or maybe even more crypto > choices than the i-patch) in terms of algorithms that the i-patch > supports, then this is good! just to make one thing clear: I have no problem at all w/ giving the user more choice, as to which software to use; that's why I like cryptoapi's variety of ciphers... [..] > Secondly, I must tell you I do not agree with this idea of > "known bugs", if someone (or a corporation, like SuSE) knows there is a > "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 be resolved... i.e. by fixing the current, and providing a compat-blowfish cipher... > Not that all of these problems are the fault of the authors of > the i-patch, clearly they all are not, but, since loop-aes fails to > enact these issues, I see it as a clear advantage for the moment. if you only need disk-encryption, then cryptoapi may be overkill... but the projects using cryptoapi as their cipher-repository is growing... [..] regards, -- Herbert Valerio Riedel / Phone: (EUROPE) +43-1-58801-18840 Email: hvr@hvrlab.org / Finger hvr@gnu.org for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
Attachment:
signature.asc
Description: This is a digitally signed message part
