[messaging] Forward secrecy in the EFF messaging scorecard

[Jeff Burdges]

Just a another comment : ChatSecure is listed as ChatSecure + Orbot,
but only the ChatSecure properties are discussed.  Orbot brings a level
of metadata protection not found with most tools.  It's worth
encouraging people to use Orbot, and ChatSecure is the only tool that
really tries, but that's not comparable with the others.


I doubt the EFF wants long explanations of the more subtle short
comings of many of the systems, but they might accept a contributed
"Bonus Round" section for the small print at the bottom that singles
out various nice features : 
- All the XMPP+OtR messengers, and some others, have forward-secrecy
- TextSecure and Signal have long-term forward-secrecy
- ChatSecure integrates with Orbot
etc.


Yes, Threema has forward secrecy only in the transport layer, not for
end-to-end encryption.  It says so on page 8 of their whitepaper :
https://threema.ch/press-files/cryptography_whitepaper.pdf




On Wed, 2015-10-07 at 15:04 +0200, Ximin Luo wrote:
> 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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151008/5284ee63/attachment.sig>