On end-to-end encryption
Whats is end-to-end encryption?
Let's assume that you want to get a secret message from device [desktop, laptop, tablet, smartphone] A to device B. Both devices are connected to some network you don't control [a mobile network, the Internet] but you want to avoid that anybody else than the intended recipient can read the message. End-to-end encryption (short: E2EE) achieves this by having code on device A encrypt the message before it leaves device A, and some other code on device B that decrypts the message once it has entered. All of the intermediate nodes on the network are considered untrusted and can only see the message's encrypted payload as well as its metadata that is necessary to route the message from A to B, notably the destination address of B [phone number, IP address].
Note that the message is only encrypted while moving from A to B (in transit) but is unencrypted on both end-devices A and B.
A desirable property is perfect forward secrecy. If implemented, the encryption keys change at every session (ideally every message), and breaking the keys of one session only affects the messages exchanged during that session.
What end-to-end encryption is NOT
Anonymous
The metadata usually permits to identify both the sender and the receiver, at least the receiver is necessary to the routing protocol. Metadata may be temporarily hidden by using a VPN or some other kind of relay, but ultimately the destination address must be known in order to deliver the message.
Anonymity can be combined with E2EE but both concepts are not related.
Permanent
After the message has been transmitted it continues to live as plain-text on both end-devices, as far as E2EE is concerned.
An eternal guarantee
Some vendors advertise encryption but fail to mention that they manage the keys. While this makes sense for some use cases it does not prevent them from reading the message.
Every encryption is breakable given enough time. So it's not a matter if the message can be decrypted, but when.
Additional measures to E2EE
Establish a threat model
This part is crucial. No communication method protects a message in every situation, not every protection method always makes sense, and the threat model determines what to do in a specific case. Protecting from a spouse is an entirely different thing to protecting from an employer or a nation-state actor.
End-point security
Since the message is readable on both A and B, the access control measures on those end-points matter a lot. The device should have strong access control and be fully encrypted (this is a different encryption from E2EE). Physical security can be an additional layer, if applicable.
Specific attention must be paid to the confidentiality of application-level and system-level backups. Unencrypted backups to a public cloud for example are an easy way to circumvent state-of-the-art encryption.
The quality of the operating system is relevant. An OS that properly protects processes from each other, publishes regular security updates and is generally security-minded is a safer bet but still no guarantee.
Another vector of attack is the hardware itself, since it can easily circumvent every software protection of the OS or the encryption software.
One mitigation method are ephemeral (a.k.a. self-destructing) messages. However, true deletion of messages can be hard to achieve or even impossible on some media (such as SSDs). It's nevertheless an additional layer to consider.
Trust
To make sure that the communication is safe requires trust in
* the person who has developed the encryption and decryption code on the end-points (i.e. the code must be reliable, not have any back-doors or involuntary errors)
* the auditor of the code (it is essential that code be audited)
* the place you got the code from (the code must not have been tampered with; the binary must correspond to the audited source)
* the producers of the end-points hardware and software
* the person receiving the messages
Thats a lot of trust to have.
Re-assess regularly
Assuming that you set up a secure communication, you should re-assess the situation on regular basis. Encryptions get broken, trust may vanish, better options may be available.