[Ach] [cryptography] Better Crypto

[Aaron Zauner]

Hi Peter,

Peter Gutmann wrote:>
> 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.
We try to offer two OpenSSL cipher-strings currently: A and B with A
being the tinfoil-hat version. Now we need input from people like you,
people that run large-traffic sites, develop SSL libraries, Client and
Server software and so forth to find a good common ground. We have
recently got a lot of useful feedback from e.g. the Firefox crypto team
and I'm sure we'll incorporate that into our paper. We're still in a
DRAFT stage and intent to update the paper even after our first release
regularly since the world of SSL/TLS changes a lot these days.


> 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 
Yup. But that's a issue we won't be able to solve. If serious system
engineers can't find the time to read through a paper and it's reasoning
but instead look up ubuntuforums than they probably should not be
employed to do security critical decisions. We all know that problem
very well - some people just wont RTFM - this is also why the paper is
pretty terse and has put the configurations in front of the theory part
(used to be the other way around).

I still have the feeling that such a project is important since you
cannot find anything similar on the web that is useful for operations
people. Most people end up reusing configuration settings that someone
proposed somewhere on github or in an online forum, often without any
prior research.

Thanks for your input,
Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/ach/attachments/20140107/120150b4/attachment.sig>