[messaging] Forward secrecy in the EFF messaging scorecard

[Ximin Luo]

Hi,

I just saw that in the EFF messaging scorecard [1], the column for forward secrecy gives a tick even if the application does not actually have forward secrecy:

"Note: For this phase of the campaign, we accept [..] forward secrecy on the transport layer [..] and non-forward-secret end-to-end encryption, plus an explicit guarantee that ciphertexts are not logged by the provider. This is a compromise [..] but we prefer this setup to having no forward secrecy at all."

According to the changelog, this clarification was added on 2015-01-29, but the wording of the changelog entry seems to imply that this criteria was *applied* in older versions of the table as well, just not clarified.

Together with the clarification for #1 ("Note that we are not requiring encryption of data that is transmitted on a company network, though that is ideal.") these caveats, if both satisfied in the weakest way, do not give us much confidence - "SSL added and removed here". Holes that are this big, render extra strength in the rest of the system worth not much more than a marketing exercise, like using 4096bit DH with MD5, and also pollutes the meaning of the other ticks in those columns.

I'm not going to suggest that you should change the table to be more strict; it's your table and you can do it how you like. However, do you have the raw data behind the tick/cross ratings?

For example, I seem to remember being told that Threema uses forward-secure TLS but non-forward-secure end-to-end encryption. So that's why they have a tick on this table. But then I wonder which other systems do this, instead of having actual forward secrecy.

X

[1] https://www.eff.org/secure-messaging-scorecard

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git