On Saturday 19 Apr 2014 14:17:56 Joe User wrote: > On 19.04.2014 13:51, Mick wrote:
> > It seems that many sites that use ECDHE with various CA signature > > algorithms (ECC as well as conventional symmetric) use the > > secp521r1 curve - aka P-256. I just checked and gmail/google > > accounts use it too. > > > > Markus showed secp384r1 (P-384) in his example. > > > > The thing is guys that both of these are shown as 'unsafe' in the > > http://safecurves.cr.yp.to tables and are of course specified by > > NIST and NSA. > > > > Thank you both for your replies. I need to read a bit more into > > all this before I settle on a curve. > > 1.) secp521r1 is *not* P-256 I beg your pardon! I went all cross-eyed scanning different RFC pages and tables. > 2.) I used secp384r1 aka P-384 as it's defined by RFC 6460 while > secp521r1 is not, and all TLS1.2 implementations implement > secp256r1 and secp384r1 as defined in RFC 6460, while secp521r1 > is implemented only by some. So better to be RFC compliant and > reach all possible users/customers as to violate the RFC and > loose possible users/customers. > https://tools.ietf.org/html/rfc6460 Yes, you are right. Also, some of these 'safe curves' are not currently available through openssl and some are just "toy examples". One would have to be technically competent enough to develop their own implementation of e.g. Curve25519 - in my case this would be decidedly dangerous to attempt! ha, ha! > 3.) Even the people behind http://safecurves.cr.yp.to have no proof > that secp[256|384|521]r1 are unsecure, they just don't trust the > NIST. So that list is mostly useless and possibly untrue. Well, from what I understand their argument is that the alleged criteria of efficiency assumed by the standards are not necessarily supportive of a better security model and often do not provide computational efficiency either. In addition, the derivation of the supposedly random integers k are allegedly either not random, or in any case arbitrarily chosen. > 4.) ECC in certificates is not widely used and therfor also not > extensivly audited, so it might be less secure than SHA256+RSA, > or may suffer from implementation failures like heartbeat did. > 5.) ECDSA has the same problems i mentioned in 4, so it may be a bad > idea to use it in production. Stick to ECDHE and as a fallback > to DHE. I use the following ciphers for my services: > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) > TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) > TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) Thanks! I need to use certificates with strongswan, so I think I will be limited to: prime256v1 secp384r1 secp521r1 http://wiki.strongswan.org/projects/strongswan/wiki/EcDsaSecret -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
