otrv4 VS end-to-end

I may have missed something here, but the write-up seems to be missing the main problem with OTR, which is that both parties need to be online at the same time to do the key-exchange to set up the session - at least in OTRv3 (https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html)

This is why the Double Ratchet Algorithm was created (back in 2013!) where you prepublish a pool of one-time-keys which can be used to establish sessions without you having to be online - as well as defining how to ratchet the message keys forwards both by new DH exchanges and simple hash ratchets (hence the name Double Ratchet).

OTRv3 has the sole advantage that you can trivially tunnel it over any existing synchronous transport (e.g. an IRC DM), given it doesn't have the concept of setting up sessions asynchronously. However, this is a bit of a moot point these days, given modern messaging systems like Matrix, XMPP and Signal natively support the Double Ratchet via Olm, OMEMO & libsignalprotocol respectively - so OTRv3 really is a bit of a historical curiosity at this point.

Meanwhile OTRv4 does introduce the idea of offline conversation initialisation (https://github.com/otrv4/otrv4/blob/master/otrv4.md#offline-...), but it doesn't seem to have got much traction, relative to the fairly ubiquitous Double Ratchet. (Has anyone seen it in the wild? It looks like coy.im might speak it? https://github.com/otrv4 seems fairly dead :/)

Finally, lots of E2EE research is going into efficient shared ratchets for group communication rather than 1:1 sessions - such as MLS (https://datatracker.ietf.org/wg/mls/about/), DMLS (https://matrix.uhoreg.ca/mls/decentralised.html) and DCGKA (https://www.cylab.cmu.edu/news/2021/11/23-group-messaging.ht...).

AES gets all the marketing glory. You ask the company how are they doing security? Marketing person says: "It's secure we're using AES.". AES is often the only technical word they use when they say it's secure in product brochures because they know this is going to satisfy a clueless CISO with a purchasing budget to cover their behind.

But fast forward from 2009 take a look at OTR and their decision[1] to switch from AES to ChaCha20 (see https://github.com/otrv4/otrv4/blob/master/architecture-deci...) - the whole document is very interesting and pretty brief to highlight why AES might not be the best choice:

> We use ChaCha20 as the encryption stream cipher because it is faster than AES in software-only implementations, it is not sensitive to timing attacks and has undergone rigorous analysis ([3], [4] and [5]). We chose this over AES as future advances in cryptanalysis might uncover security issues with it, its performance on platforms that lack dedicated hardware is slow, and many AES implementations are vulnerable to cache-collision timing attacks [[6]].

But AES is so much faster because some SSD's can offload it to hardware right? See:

256-bit AES encryption broken in SandForce SSD controllers: https://techreport.com/news/23096/256-bit-aes-encryption-bro...

Self-encrypting SSDs can easily be cracked: https://portswigger.net/daily-swig/self-encrypting-ssds-can-...

Crucial and Samsung SSDs' Encryption Is Easily Bypassed: https://www.tomshardware.com/news/crucial-samsung-ssd-encryp...

...

So it seems to me that if I have a large number of architectures and devices my software might be running on which is outside my control then the ability to predict how my crypto implementation will affect the performance of my device is a good enough reason alone to not use AES. But I might be wrong maybe others can throw in some thoughts here.

OTRv3 is definitely not considered secure now, there is an unimplemented (and possibly unfinished) OTRv4 that updates the crypto though:

https://github.com/otrv4/otrv4

So you shouldn't be using Cryptocurrency based communication or PGP at all. You should be using modern deniable protocols like The Signal Protocol (in Signal), OTRv4 (work in progress, no implementations yet), OMEMO (e.g. ChatSecure), and MEGOLM (used by Element).

[1] No warning on decrypting Tag 9 (no integrity protection) packets

In contrast, companies like Standard Notes actually uses their own home-built encryption library, which is why it's a bit more critical that they go through these audits more often and quickly than others. And despite the audits, this home-brewed encryption library puts them at a much bigger risk, due to the fact that it's never going to be as thoroughly battle tested as an open industry-standard encryption like OpenPGP, used by much larger companies like Google, Protonmail, etc.

https://github.com/google/end-to-end ?

When Google was looking at implementing E2E mail via a browser plugin, it gave up in part because of the difficulties of doing it right. They published the library and documentation, but the more valuable part was the threat model. In it they examine the assets to protect, threat sources both inside and outside the threat model, UI threats, message threats, key-related threats, cryptographic threats, and other threats. It's an excellent walk-through of just how difficult it is to do general encryption right, and why doing it in the browser is so hard.

With that in mind, secure messaging in a browser is a nightmare. Google tried to figure out a way to do end-to-end in a browser, mostly in the context of e-mail but it could be extended to chat applications. They wrote up a threat model that you really should read. They identified five threat sources within the architecture and six more that they acknowledge but don't delve into. They also discuss four UI-based threats, four message-based, four key-based, and two cryptographic threats, and each of those threats has subthreats. Finally, they wrap with three "Other" threats. They dropped the project soon after.

Google E2E Library — Unsure how up-to-date this ... limited GitHub activity.