
Ask HN: End-to-end encryption – how do you know? - _bxg1
If something is open-source you can audit it (assuming you trust the official builds to be the same), maybe if it&#x27;s a big enough company you trust that they don&#x27;t want to risk being outed, but how to people <i>really</i> verify that end-to-end encryption is being done? Inspecting network traffic perhaps?
======
wildtaco
I agree that the open-source ability to audit is one of the strong points of
foss and that's an allure to keep everyone honest. Look at Signal, ProtonMail,
Telegram, and to a lesser extent WhatsApp, AWS and Zoom. Once things get
increasingly proprietary, they tend to pull the curtain wider across the
stage.

Network traffic - or rather lack thereof - could conceivably be a good place
to start. Wireshark not showing you any tangible information when you're
sniffing the data? You stand a good change of being positively encrypted, but
that's only one end of the end-to-end.

There's an interesting research paper from the 1984 IEEE Symposium on Security
and Privacy written by Dianne E. Britton entitled, "Formal Verification of a
Secure Network with End-to-End Encryption" \- the abstract being:

A formal specification and verification of a simple secure communications
network using end-to-end encryption is presented. It is shown that all data
sent over the network is encrypted and all heats on the network exchange
messages only if they are authorized to do so. The network and its hosts are
modelled by a set of concurrent processes that communicate via unidirectional
buffers. Each process is viewed as a state machine. The specification has been
formally verified using the commercially-available VERUS verification system.

I feel like this would at least illustrate the groundwork current systems have
expanded on over the last twenty-odd years, but the paper is behind a research
wall. If I can get a copy, I'll link to it here.

The other aspect worth mentioning is Asynchronous messaging with as strong as
security as possible - the paper that details this
([https://people.cispa.io/cas.cremers/downloads/papers/CCGMM20...](https://people.cispa.io/cas.cremers/downloads/papers/CCGMM2018-groupmessaging.pdf))
uses the word "Guarantees", but is it ever? - the abstract for that being:

In the past few years secure messaging has become mainstream, with over a
billion active users of end-to-end encryption protocols such as Signal. The
Signal Protocol provides a strong property called post-compromise security to
its users. However, it turns out that many of its implementations provide,
without notification, a weaker property for group messaging: an adversary who
compromises a single group member can read and inject messages indefinitely.
We show for the first time that post-compromise security can be achieved in
realistic, asynchronous group messaging systems. We present a design called
Asynchronous Ratcheting Trees (ART), which uses tree-based Diffie-Hellman key
exchange to allow a group of users to derive a shared symmetric key even if no
two are ever online at the same time. ART scales to groups containing
thousands of members, while still providing provable security guarantees. It
has seen significant interest from industry, and forms the basis for two draft
IETF RFCs and a chartered working group. Our results show that strong security
guarantees for group messaging are practically achievable in a modern setting.

KeyBase and Wire ([https://medium.com/@wireapp/making-your-conversations-
secure...](https://medium.com/@wireapp/making-your-conversations-secure-
dab207ab77fd)) are both doing interesting things with end-to-end encryption,
but verification from a user perspective - especially in the case of
proprietary software - leaves the onus on the user to simply stay as paranoid
as (reasonably) possible for the time being.

~~~
_bxg1
So yeah- sounds like "make the code open-source and use a tested protocol" is
about all you can do.

