On 08/26/2013 02:24 PM, Brian Smith wrote: > On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea <rrel...@redhat.com> wrote: > >> So looking at this list, I think we have a major inconsistency. >> >> We put Ephemeral over non-ephemeral, but we put 128 over 256. >> >> While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think >> in doing so we are taking a much more significant performance hit we get >> back by putting 128 over 256. >> > It is not exactly true that PFS always has more of a negative performance > impact than AES-128 vs AES-256. In Chromium, PFS ciphersuites will be > faster than non-PFS cipher suites because Chromium requires PFS > ciphersuites to be used for False Start. Also, I have an idea for how we > can make PFS cipher suites + False Start work much more commonly on the > web, that won't work for RSA key exchange. So, ultimately, I expect PFS > cipher suites to be a performance win over non-PFS cipher suites.
So at this point I want to point out that: 1) I don't disagree with PFS before the other ciphers, I just wanted to point out that they are not clearly as big a win for security as is normally touted. 2) It does have a significant downside speed wise. I was responsible for measuring this once from the server perspective (we were trying to convince people to use ECC. I could only get wins over RSA at the 2048 bit range with ECDH (224bit) not ECDHE... and that was ECDHE where we used a single private key generated at server startup). Note that we are using 256 bit ECC at the low end. Those figures are old, so it would be good to try to get new ones from the client perspective (not how many connections a server can use). I'm not as worried about the order for servers as servers can manage their performance by only supporting the fast algorithms. > > But, raw performance isn't the only issue. We expect that PFS cipher suites > *can* have significantly better security properties (see below) if the > server puts in the effort to make the encryption keys actually ephemeral, > and we expect that they are generally no worse they are no worse regarding > security (barring disastrous implementation errors). > > Conversely, it isn't clear that AES-256 offers any significant security > advantage over AES-128, though it is clearly slower, even on my > AES-NI-equipped Core i7 processor. First, AES-128 has held up pretty well > so that it might just be "good enough" in general. So as I pointed out, we should list performance measurements as to the difference in cost. If you can see the difference, simply include those numbers. > Secondly, as I already > pointed out in my proposal, some research has shown that AES-256 doesn't > seem to offer much more security than what we understand AES-128 to offer. My bad, I missed that point. Sorry. > See http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html and > https://cryptolux.org/FAQ_on_the_attacks. Thirdly, when non-constant-time > implementations are used, AES-256 seems to offer more opportunity for > timing attacks than AES-128 does, due to more rounds and larger inputs. This is argument does have teeth, probably more than the performance (depending on the actual performance). When using performance as a criteria at all, it should be quantified. For clients 3x slower doesn't mean anything if it's 3x 100 microseconds, but if its 3x 1s it makes a big difference. We should measure both on big platforms and small ones. So in summary. 128 is actually considered as secure as 256 (based on recent attacks) or better (based on timing attacks), so performance isn't the primary criteria. If we were to shop this list around to other browsers, it would probably be good to get the performance numbers. Particularly ECDHE 256 versus RSA 2048 on an arm (If that doesn't show a significant cost, we can safely say performance of the key exchange is negligible). bob
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
