[Ach] [cryptography] Better Crypto

[L. Aaron Kaplan]

Hi coderman, hi Peter, hello cryptography list and ACH list,

> 
(...)

I have followed your comments on our small project bettercrypto.org (which we started only in Sept/Okt 2013) with great interest. In fact, comments like these are very valuable to our project and help us to write a better version.

Upfront: We can change any part of the text - it is still a DRAFT and I am super happy about the interesting feedback we are getting. Also the archived discussion on public mailing lists helps other users to find their own cipher strings.

> 

>> 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. In fact, we added the "theory" chapter at the end just in order to help people decide on their own. So, I take this as a good feedback in order to change the text in section "howtoreadthis.tex".


>> The crypto is pretty much the last thing you need to worry about,
>> since the attackers will ignore it and go for all the other weak points
>> instead...
> 
100% agreed.

That's what we state in the abstract as well as in the disclaimer.
See also coderman's comment:

> i did not get the impression that it promotes a silver bullet mindset.
> indeed, the second paragraph of the introductory abstract clearly
> states:
> """
> ... it seems that intelligence agencies and adversaries on the
> Internet are not breaking so much the mathematics of encryption per
> se, but rather use software and hardware weaknesses, subvert
> standardization processes, plant backdoors, rig random number
> generators and most of all exploit careless settings in server
> configurations and encryption systems to listen in on private
> communications. Worst of all, most communication on the internet is
> not encrypted at all by default...
> 
> This guide can only address one aspect of securing our information
> systems: getting the crypto
> settings right to the best of the authors’ current knowledge. Other
> attacks, as the above mentioned,
> require different protection schemes which are not covered in this guide.
> """
> 
> 
> but perhaps a better disclaimer would be more like:
> "WARNING: if your adversary can mount attacks against your RC4 and MD5
> using protocols, hardening your cipher suite configuration will not
> materially reduce your risk.*"
> 
@coderman: good suggestion :) Yes... I agree. In fact, the that's what we saw in the 30C3 talks:(

However, I want to add something here: personally I am less worried about that Never Say Anything agency but about the "nuclear proliferation" issues with all the leaked attack possibilities: other nation-states-agencies or simply criminal groups or "business intelligence" units will be very keen to learn from that biggest agency and adapt and modify their tool-kits. That is why we need to all harden our settings today. And by "all" I really mean all (that includes the Never Say Anything agency). If the NSA had used proper group encryption (like you know PGP works when you send to groups, D'oh), then maybe they would not have had a problem with leaked documents now. 
In fact, the Surveillance Review Report clearly states on p. 250: "the government’s classified networks require immediate internal hardening." I guess that now applies to all networks. Worldwide. 
The discussions on how to applied good crypto practices to real world servers is of course just one part of the whole hardening process.


For 2014 I have a dream:

Just imagine getting 95% of Mail Server sysadmin operators to start using good opportunistic TLS (with whatever cipher) for Mailserver to Mailserver communication within one year. That would for sure be better than what we have now.



> 
> * the only entities for whom this is not true don't need to read this guide. ;)
> 
> 
> 
> 
> last but not least, the most important section of all in my oh so
> humble opinion: "Random Number Generators" is also the least useful.
> no mention of physical true random number generator sources and how to
> use them (and how NOT to use them,*cough* RDRAND).  poor platform
> support.  etc.  i'm trying not to complain too much, as i have not yet
> submitted a patch myself either!
> 
> 

Please send a pull request on github . That would be really much appreciated.

We really are simply just trying to push that topic as hard as we can and depend on the feedback of this and similar communities. 
Send us all your change requests, critique and suggestions please. 

Concerning Peter's comments on "!SRP": there was some discussion 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 ach at lists.cert.at Mailing list.

Aaron.

--- 
// L. Aaron Kaplan <kaplan at cert.at> - 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




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20140105/b2e60328/attachment.sig>