Re: [cryptography] [Ach] Better Crypto
on this here: http://lists.cert.at/pipermail/ach/2013-December/000616.html and here: http://lists.cert.at/pipermail/ach/2013-December/000617.html (just follow the thread) Again: we could include SRP but then we'd have to write something on how to use it . --> pull request? Often it's enough to simply link to the right HOWTO. Finally: we will have our next bettercrypto.org meetup on Tuesday 18:00 CET. I'll be very happy to include anyone via video conf or jabber. Announcements will be on the a...@lists.cert.at Mailing list. Aaron. --- // L. Aaron Kaplan - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
On Jan 7, 2014, at 2:34 AM, Peter Gutmann wrote: > "L. Aaron Kaplan" 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. > I like that idea >> 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". > I agree... that's how most people will read it probably. Unfortunately. As Aaron Zauner already mentioned, we thought about this a lot and ended up with 1. writing a "How to read this guide" section in the beginning including a flowchart 2. moving the theory section to the end (so that people can quickly find the copy & paste section) and 3. always try to pull in the readers interest to follow up in the theory section. None if this is perfect yet of course. One of the very productive feedback results was that we should make a HTML version. So, Peter, how about this approach? 1. We will have three config options: cipher String A,B,C ( generic safe config, maximum interoperability (== this also makes the mozilla people happy then) and finally a super-hardened setting (with reduced compatibility)). Admins will get a choice and explanations on when to use which option. 2. (time-wise) first we focus on some of the weak spots in the guide like the ssh config (client config is missing...), the theory section etc. 3. we give people a config generator tool on the webpage which gives them snippets which they can include into their webservers, mailservers etc. The tool also shows admins (color codes?) which settings are compatible, unsafe etc. 4. In addition to having the config generator on the web page, the config snippets are moved to the appendix (as you suggested). The theory section moves up. Would that be more in your line of thinking? Anyway, we will have a authors' meeting today at ~ 19:00 CET and can discuss this. Anyone who wants to join via teleconference: please get in contact with me. We will arrange for remote participation. Aaron. > Peter. > --- // L. Aaron Kaplan - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
On Jan 7, 2014, at 11:24 AM, stef wrote: > On Tue, Jan 07, 2014 at 11:18:45AM +0100, L. Aaron Kaplan wrote: >> 1. We will have three config options: cipher String A,B,C ( generic safe >> config, maximum interoperability (== this also makes the mozilla people >> happy then) and finally a super-hardened setting (with reduced >> compatibility)). > > lacking the context on >> this also makes the mozilla people happy then There were some discussions on the bettercrypto list regarding also supporting Windows XP (which means RC4 or 3DES). And there was a very good argument that a *lot* of people still use XP and for many sites it is not an option to exclude them. On the other hand, WinXP is end of life. It's a hard choice So, I guess that was a really good reason and personally I don't see any reason so far to assume: > > if that refers to firefox lack of tlsv1.2 support, it's in there starting from > +24, but the mozilla people are still doing everything to maintain my > suspicion of being complicit with the nsa, so it's not advertised and disabled > by default. you can enable this in about:config where you set > security.tls.version.max to 3 > --- // L. Aaron Kaplan - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
Hi Peter, hi list, On Jan 16, 2014, at 1:13 PM, Peter Gutmann wrote: > "L. Aaron Kaplan" writes: > >> So, Peter, how about this approach? > > Sorry about the delayed reply, too much other stuff on my plate at the > moment... > >> 1. We will have three config options: cipher String A,B,C ( generic safe >> config, maximum interoperability (== this also makes the mozilla people happy >> then) and finally a super-hardened setting (with reduced compatibility)). >> Admins will get a choice and explanations on when to use which option. > > That sounds good. > okay. We'll discuss this at the next meeting of co-writers then . >> 3. we give people a config generator tool on the webpage which gives them >> snippets which they can include into their webservers, mailservers etc. The >> tool also shows admins (color codes?) which settings are compatible, unsafe >> etc. > > Now that would be very useful. > :) >> 4. In addition to having the config generator on the web page, the config >> snippets are moved to the appendix (as you suggested). The theory section >> moves up. > > Yup, good idea. The single-location-for-config solves the problem of having a > cut&paste of the same (or possibly somewhat out-of-sync when the doc is > updated) text in a dozen or more locations. > same comment applies: I'll discuss this with the co-writers. We skipped the meeting the last Monday and there are many pull requests and change requests in the queue. So, we'll have to resume working on the draft version soon. Thanks very much for your great input and comments! Aaron. --- // L. Aaron Kaplan - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
