Crypto Fun BitMessage

Crypto Fun BM-2cVUcKtDv7wqDXBgJD5cm35YjQ8Bq2skLu
Mar 7 20:15

Crypto Fun
The following seem to be commonly listed as "best practices" for doing crypto things...

No SSL version should be used ( SSLv1 has been known to be insecure, SSLv2 had problems, and SSLv3 had public issues like POODLE), use TLS instead
TLS v1.2 is the most current, and accepted practice is to use this.
Disable the ability to downgrade the protocol (e.g., wanted TLSv1.2, but didn't have it available, do the protocol auto-downgrades to SSLv2 for example)
Disable TLS compression (see public vulns like CRIME, BEAST, ...)
(Perfect) Forward Secrecy is a great thing.  Ephemeral Keying/Ephemeral Diffie-Hellman.
Use of RC4 is a no-no
AES w/ GCM mode is commonly accepted as the go-to right now
Certificate Pinning is also a best practice.
SHA1 is a no-no
HTTP Compression can cause problems (see vulns TIME & BREACH)
Beware/Disable Session ID/Session Tickets (i.e., SSL/TLS Session Resumption)  caching of key material can be bad....
Disabling session renegotiation is likely a good thing.
Diffie-Hellman parameters should be greater than RSA key size
For ephemeral DH (e.g., Perfect Forward Secrecy), the normal way TLS does it is that DH parameters are generated ahead of time and "belong" to the server
The above implies that for a "communication pair" (composed of keys and certs for a client<->listener combo), one should probably generate new parameters along with keys & certs?
Elliptic Curves are considered preferred, but not necessarily widespread.
Finding out about elliptic curve selection (e.g., specifying a curve to use) is a PITA.  ECC has a "bit rating" which is equivalent to some (greater) amount of RSA-bits.
NIST has preferred/specified curves (e.g., P-384, P-521) which made it into a FIPS standard (186-3)
Standards for Efficient Cryptography (SECG) also has recommended curves (SEC-2 Recommended Elliptic Curve Domain Parameters) (e.g., secp256r1, secp521r1)
ANSI also has standards (e.g., X9.62, X9.63)
in general, one selects a 'generic' "key strength" in units of bits, then determines an equivalent key strength for elliptic curve, then selects a provided, "standard" curve (e.g., P-384)
So, for teh ultimateZ in fun:

 TLS v1.2, AES-256, GCM, SHA2+, EC bits >= 256, DH Params >= 2048
 AES-256, EC512, SHA512
Some useful links/references:

Standards for Efficient Cryptography (www.secg.org) (Version 2 was current as of this writing)
 Applied Crypto Hardening, https://bettercrypto.org
Security/Server Side TLS, https://wiki.mozilla.org/Security/Server_Side_TLS
SSL/TLS Deployment Best Practices, https://www.ssllabs.com
NIST Cryptographic Toolkit, csrc.nist.gov/groups/ST/toolkit/
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security, rfc4492, https://tools.ietf.org/html/rfc4492
www.keylength.com (shows comparison for key lengths)
ECRYPT II, www.ecrypt.eu.org/ecrypt2 (check out the yearly reports on algorithms and key lengths)