[Ach] [cryptography] Better Crypto

[ianG]

forwarding to list!


On 5/01/14 15:28 PM, Peter Gutmann wrote:
> ianG <iang at iang.org> writes:
>
>> Not sure if it has been mentioned here.  The Better Crypto group at
>> bettercrypto.org have written a (draft) paper for many of those likely
>> configurations for net tools. The PDF is here:
>>
>> https://bettercrypto.org/static/applied-crypto-hardening.pdf
>>
>> If you're a busy sysadm with dozens of tools to fix, this might be the guide
>> for you.
>
> 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.  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, 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) which is pretty much guaranteed to lock out the zillion third-party
> SSH implementations that do 3DES-CBC and AES-CBC (the same can apply for SSL
> in older systems that don't support the newer fashion-statement ciphers while
> still supporting the perfectly secure 3DES), 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, the IPsec predefined suites
> seem to be restricted only to Suite B (that's the crypto designed and promoted
> by the nation-state adversary that we're supposed to be defending against),
> and so on.
>
> 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.  So while disabling obviously dangerous settings (many of which are
> disabled by default anyway) is a good thing, obsessing over which colour of
> algorithm you're using is at best a distraction from securing other aspects of
> a system, and at worst a problem when restricting yourself to oddball
> algorithms breaks the ability of clients to connect.
>
> Peter.
>