Ah, I they see they're using libolm, as is the Matrix project! I have a number of critiques of libolm that I haven't developed into a practical attack, but are

Ah, I they see they're using libolm, as is the Matrix project! I have a number of critiques of libolm that I haven't developed into a practical attack, but are simple enough to fix (if you ignore the massive legacy support and backwards compatibility t̵r̵a̵p̵ ̵t̵h̵e̵y̵'̵v̵e̵ ̵s̵e̵t̵ ̵f̵o̵r̵ ̵t̵h̵e̵m̵s̵e̵l̵v̵e̵s̵ EDIT: see Arathorn's comment below). Libolm is encrypting with AES-CBC [1]. In addition to side-stepping entire classes of attack (i.e. padding oracles), CTR would allow better performance: You can parallelize both encryption and decryption with CTR mode. With CBC mode, you can only parallelize decryption (but not encryption) since the IV for all but the first block is the previous block of ciphertext, which means you'll know the correct IV when decrypting but not when encrypting (since you have to calculate it sequentially). Yes, they HMAC the ciphertext [2]. However, their variable name choice doesn't inspire confidence in its correctness. Furthermore, they truncate the HMAC to 8 byes and attempt to justify the truncation by appending an Ed25519 signature, but that sort of configuration is just begging for a confused deputy scenario, like an old iMessage vulnerability [3]. It's no where near as bad (iMessage eschewed MACs entirely, this still uses a MAC, so it's not exploitable), but it's something that probably would make anyone working in cryptography (and any adjacent fields) give a confused puppy head tilt when they read it. Regarding their ratcheting protocol [4]: Instead of feeding HMAC-SHA256 back into itself at each ratchet step, I'd feel way more comfortable if the protocol did HMAC-SHA512 and used one half of the output to derive encryption/authentication keys and the other half the ratcheting-forward key (instead of one HMAC-SHA256 for both purposes). Using two distinct 256-bit secrets (even if they're generated from the same input at i=0) instead of reusing a secret strengthens the forward secrecy of the entire protocol. HMAC-SHA256: One ring to rule them all (at any given ratchet step). HMAC-SHA512-split: If you (against all odds) guess one of the keys, that doesn't give you the ratchet-forward key too, since they're two distinct keys (albeit generated deterministically from the same input). Nothing I said above is exploitable, otherwise I'd be emailing their security team instead of posting on HN. :) That being said, if the Libolm devs want to shore up the security of their protocol in a future revision, the following changes would go a long way: 1. Use HMAC-SHA-512 and split it in half for the ratcheting step of Olm/Megolm 2. Use AES-CTR instead of AES-CBC 3. Stop truncating MACs [1]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#message-encryption https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me... [2]: https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547ebb3058680a9c3ad88186bb2030da/src/cipher.cpp#L64-96 https://gitlab.matrix.org/matrix-org/olm/-/blob/930c4677547e... [3]: https://blog.cryptographyengineering.com/2016/03/21/attack-of-week-apple-imessage/ https://blog.cryptographyengineering.com/2016/03/21/attack-o... [4]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#the-megolm-ratchet-algorithm https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...