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. 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. 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. 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. > The attack profile protection of PFS versus non-PFS is basically two > points: > 1) some government agency could force a server to give up it's private > keys and decrypt all the traffic sent to that server. But we already > know that government agencies with such power simply ask for the the > data on the server. > This argument seems to assume that all the data that was transferred over the network is stored on the server. But, this is not necessarily the case. I don't think that is a reasonable assumption. The site may have already deleted the data (perhaps at the request of the user) from the server. Also, there is a lot of transient data that is never stored anywhere. Finally, sometimes it is more interesting for the attacker to know what data was transmitted than to know what data is on the server. For example, if somebody is trying to prosecute me for posting my album collection to MegaUpload, the existence of the album data on the MegaUpload server may not be too useful, whereas a record of me doing the upload of that data with my actual credentials may be. > I still think PFS algorithms are useful and agree with preferring them, > but compared to 128 versus 256 it seems like the cost/security tradeoffs > are actually less for the PFS algorithms. > First, I agree with the overall idea that the performance cost of AES-256 over AES-128 isn't huge. However, I do think that it is significant, at least for mobile clients where such concerns are most critical--not just speed, but also battery life. We can gather the numbers (perhaps others already have them) if that helps. Something to note is that MSIE has always put AES-128 cipher suites ahead of AES-128 cipher suites. They also put RSA cipher suites ahead of PFS cipher suites, though. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
