Robert J. Hansen wrote: > Faramir wrote: >> Well, I don't think you are crazy, but I am part of the group that >> likes to be able to chose between several options, provided all the >> options are secure. > > That "provided" is the sticking point. Small is beautiful, IMO. YMMV.
I agree that small is beautiful. I also think that there is something to be said for pruning seldom-used code paths in a security-related application since there is always the possibility of bit rot, as well as longstanding bugs that have not yet been identified yet because the code has not been exposed to a wide enough variety of use cases. OTOH, in something like PGP there is a definite need to maintain backwards compatibility. There is also the issue of needing options that can easily be exercised with existing tools should a current "favorite" be found to be insecure down the road. My personal opinion is that gnupg treads this line pretty well. If it were up to me I would like to see more configure --options to not include some of the options I'm not likely to ever need, but I don't care enough about it to put the work into making a patch. :) > The Air Force was shocked by this and canceled their cooperation in the > program. They learned from the F-4 and the F-15 that twin-engine > aircraft had more than twice the engine problems of single-engine > aircraft. The downside of the extra complexity was greater than the > upside of having a second engine. Regardless of whether this story is apocryphal or not, there is something to be learned here. The AF's conclusion seems obvious, however it ignores a critical factor of the Navy's use case. Because most of the time Navy jets operate over water (I would hazard a guess to say that it's a significant majority of the time, but I'm not an expert), and because having to eject over water has a much higher fatality rate than ejecting over land, "getting back to the carrier" is much, much more important for the Navy and (likely, again, not an expert) justifies the additional complexity. The lesson here being, make sure you understand ALL the parameters before you make your conclusions. BTW, to get back to Camellia, I had to do some research on this in another context and while I'm not prepared to judge the "safety" of the cipher, I did come across this post from David which I thought was important. Short version, don't use this for production stuff since things you encrypt now might be undecryptable in future versions of gnupg. http://www.nabble.com/Camellia-td11158599.html hope this helps, Doug _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
