Mr. Ruusu: Forgive me for being so blunt, but dare I state we are not dealing with kernel bloat, but in fact "ego bloat" and "arrogance bloat". Once again, I would think carefully about an olde Jewish proverb my father once said, "People whom speak out of both sides of their mouth often stick their foot in their mouth. After all, how do you think they get their mouths big enough to talk out both sides? They stretch it when they put their foot in their mouth". I am not saying this proverb applies to you Mr. Ruusu, but it does seem to fit the situation, does it not? Whatever has caused you to affix "need" to public domain GPL style software? Perhaps you can explain why we need support for the i386 in Linux. Is anyone using i386 platform en masse to support Linux? Of course not, but we do it because we can, because of our ability to achieve such technical excellence enables us too continue to increase the capabilities of Linux even on an i386. The entire Linux development core (worldwide) and other GPL based projects, are all doing what they are doing for fun, and to demonstrate the technical capabilities of the developers and the hardware / software architectures employed. I am sure some of the people are writing code to enhance their own ego as well (what I refer to as "ego bloat"). In retrospect, perhaps I am wrong. perhaps you don't have ego bloat. In fact, if you were interested in simply developing a product to out do the I-patch, it would not be deficient any of the I-patches capabilities, now would it? Conversely perhaps the reason you are touting your solution so strongly is because you want to refocus the deficiency issues on the I-patch when in fact deep down you are aware it is your product which may also (in comparison to the I-patch, a comparison you are continuing to force people to make with your statements) is absent functionality the I-patch has. Besides, if you were truly trying to out do people, you would have fixed the I-patch a while back. Instead, you leave us to believe that somehow your software is better. Why? Because it does not do all the encryptions, the I-patch does. Several people have in fact commented as to the lack of diversity in terms of algorithms, which your solution fails to provide. Now you are welcome to say, I do not care to write what I have not written thus far, but then you will understand why people are using a different solution as well. What does this mean? It means people, may in fact be desirous of implementing your ideas but cannot, due to limitation. If in fact you wish to write code in order for others to use it, and not as an exercise in exemplification, you must consider the commentary exacted by your user base. Perhaps I have a client that has a company policy of using strictly DES. I cannot use your driver, no matter how superior it might be in its design. If you are going to claim that the I-patch is so significantly deficient in its capabilities, how about at least providing software which has no less the advantages of the I-patch before making such statements. While I agree one good cipher will fit most people's needs, I disagree that you ought to be the one to choose it. In this world of powerful free GPL software, silly me, I prefer to be the one that choose the one good cipher that fits my needs. So, absent your software being updated to provide that flexibility, what do you recommend? The I-patch? It is in fact my policy as a consultant, to always compel my clients to donate to the authors of GPL style software if it is being used for commercial purposes, even if not requested. I do not (in the instant) have a client fitting this mold, but had clients with such policies before I knew of your software even existing. Of course, the true ego maniac would not miss out on such an opportunity as is presented here. After all, what better way to prove the problems with the I-patch but to fix them, or write your own kernel patch? However, if in fact it is your own cognitive deficiencies (I am not saying it is, but "if it is") which prevent you from helping to improve the I-patch, or add ciphers to your software, or even write your own kernel patch, then in fact I humbly apologize for all I have said, absent that fact, I would request that you think about what I (and others) have said about what we are looking for. What boggles the mind (for me), is that someone (you) whom I think is so very intelligent, seems to miss the point as to what people want in a Linux based cipher software, while insisting the entire time, it us whom really are desiring the wrong thing, not you whom is not providing the software we wish to have. Now no one is saying its your job in the world to write the best encryption software for Linux as a gift to us all, but, if you wish to purport the advantage of yours of your software, and I think we are all willing to consider its use (even in respect of its author's ego and arrogance bloat), you expect some level of request for features and comparison as you seem to be continuing to force the comparative issue. Very Respectfully, Stuart Blake Tener, IT3, USNR-R, N3GWG Beverly Hills, California VTU 1904G (Volunteer Training Unit) stuart@xxxxxxxxxxx west coast: (310)-358-0202 P.O. Box 16043, Beverly Hills, CA 90209-2043 east coast: (215)-338-6005 P.O. Box 45859, Philadelphia, PA 19149-5859 Telecopier: (419)-715-6073 fax to email gateway via www.efax.com (it's free!) JOIN THE US NAVY RESERVE, SERVE YOUR COUNTRY, AND BENEFIT FROM IT ALL. Thursday, September 06, 2001 6:13 PM -----Original Message----- From: owner-linux-crypto@xxxxxxxxxxxx [mailto:owner-linux-crypto@xxxxxxxxxxxx]On Behalf Of Jari Ruusu Sent: Thursday, September 06, 2001 11:36 AM To: Robert Varga Cc: linux-crypto@xxxxxxxxxxxx Subject: Re: I-patch problem statement (update) Robert Varga wrote: > A couple questions: > Is encrypted loopback the only place in kernel where encryption can be used? No. But loop driver has a good interface for different ciphers. Crypto-api for loop devices adds an extra unnecessary layer. Small and fast is beautiful. > Is AES the only cipher worthy enough to be used ? How many ciphers does one need? One good one will fill most peoples' needs. > Is it better to have aes_set_key, des_set_key, and probably quite a few others > rather than: > > struct crypto_ctx *ctx = crypto_newctx("aes"); > crypto_setkey(ctx, "blahblah"); > crypto_encrypt(ctx, dest, src, len); > ? Above code is AES specific (since you hardcoded the string "aes"), so yes. :-) Using low-level functions (aes_set_key(), aes_encrypt(), and aes_decrypt()) directly gives programmer more flexibility over block chaining and initialization issues. It would be silly to expect crypto_encrypt() to support all possible weirdo setups. Operation of aes_encrypt() will not change. Code calling aes_encrypt() may change to adapt to different situations: running in Linux kernel, userspace, or other operating systems, whatever. > <flame> > Do you think of VFS as "kernel bloat" ? > </flame> No. Regards, Jari Ruusu <jari.ruusu@xxxxxxxxxx> Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/ ?{±r¼©¶?+Ê?h?¶©?(§jwh?Ø^.)îÆ̬µé?Èb½èm¶?ÿ?¨¥?Yb?ìh®å?{±r¼©¶?
