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
_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging
