[Ach] [cryptography] Better Crypto

coderman coderman at gmail.com
Sun Jan 5 18:23:27 CET 2014


On Sun, Jan 5, 2014 at 4:28 AM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> ...
> There are some pretty weird choices in there though, a number of which seem to
> have been dictated mostly by fashion-statement requirements rather than any
> security need.... they enable Camellia but disable 3DES (why?),
> they optionally allow ECC but only with P384 (which requires the oddball
> SHA-384, why not the universal P256 with SHA-256?), for OpenSSH they only
> allow a bunch of fashion-statement ciphers (aes256-gcm at openssh.com and some
> others)

in purely technical measures, i agree this has zero impact on risk for
the vast majority.

as a practical matter, i've found this useful repeatedly.  consider
the lack of certain suites or protocols symbolic of non-maintenance
and neglect.  c.f. that device on the network can't use AES; only RC4
or 3DES?  what is it? (often: something old we can replace with better
or remove entirely)

said another way: for all but exceptional circumstances, any
!NULL-NULL suite is going to drive risk somewhere that is not crypto.
however forcing current, strong suites is likely to expose high risk
systems on your network for reasons other than crypto...

[as a side note, there were a few systems and browsers where i could
not load the https://bettercrypto.org site.  guess what?  all of them
old bug ridden browsers that either needed updates or were
end-of-life'd and should be moved away from.]



> For example they recommend disabling (if I'm reading the
> OpenSSL config line-noise correctly) PSK and SRP, which are the only mutual-
> auth mechanisms provided in TLS,

i have only ever used mutual authentication in SSL/TLS when also using
client certificates, thus this seems reasonable to me.  i would wager
a bet that SRP is as unused in TLS as Dual_EC_DRBG was in OpenSSL.



> ... I'm not seeing much (if anything)
> about actually verifying the certs and/or checking that the information in
> them matches what you think you're connecting to

explicitly managing the OS certificate store would be useful
information, as would a plain-english result of validation.  they
accept patches... ;)



> 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.  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...

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.*"


* 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!



best regards,



More information about the Ach mailing list