"L. Aaron Kaplan" <[email protected]> writes: >> As a general observation, it also promotes the thinking that all we need to >> do >> is choose magic algorithm A instead of magic algorithm B and everything is >> fixed. > >No, if we created that impression then we failed.
The problem is that as you read through the text you see, again and again, a large amount of material telling you how to configure algorithms for OpenSSL (and then to a lesser extent OpenSSH and others). It seems to be the overriding theme throughout the document. A better option would be to refer to a single location for this (in an appendix) and then give users a choice: a generic safe config (disable null, export ciphers, short keys, known-weak, etc), a maximum-interoperability config (3DES and others), and a super- paranoid config (AES-GCM-256, Curve25519, etc), with warnings that that's going to break lots of things. >That's what we state in the abstract as well as in the disclaimer. That assumes that people will read all of that, as well as the theory chapter that follows. Since the document is laid out as a cookbook, I have the feeling that most people who just want to get a server up and running will flip through until they find the bit corresponding to the software they'll be running and then cut&paste the config lines they find there. Or at least that's been my experience in maintaining an open-source crypto library for nearly two decades, the documentation isn't an instruction manual in the usual sense but a set of code templates ready to cut&paste into a finished app. Look at the popularity of HOWTOs for any number of how-to-set-up-XYZ issues, most people just want a cookbook and won't read long, detailed discussions. Or for that matter any discussion that goes beyond "do this to get it running". Peter. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
