Hacker News Reader

Comment by tptacek | Hacker News Reader

If it's HMAC'd, there's no sidestepping of padding oracles needed. Error side channels are a consequence of chosen ciphertext attacks, not of padding. Switching to CTR would not "go a long way" towards shoring up the security of their protocol.

I do not understand your "confused deputy" attack. Can you outline it in more detail?

View on HN

> I do not understand your "confused deputy" attack. Can you outline it in more detail?

I'm literally referring to "the iMessage attack".

If you recall, iMessage did ECDSA(AES(m, ek), sk) without an intermediary HMAC. Libolm does have an (albeit truncated) HMAC, so the attack doesn't apply at all here. But it's still a design smell.

If I could extend their construction (which looks like the setup to the iMessage attack, without the punchline) into a real attack, I would have just disclosed it to them and not commented publicly.

How the attack I envision would work if their HMAC suddenly got erased from the protocol: Establish a multi-device setup, flip bits in ciphertext you want to decrypt, sign with Ed25519, observe padding oracle.

(A truncated HMAC does prevent that in the real world, but at a 32-bit security level rather than a 128-bit security level.)

These are (somewhat nitpicky) design critiques, not security vulnerabilities. :)

Edit to add: Also, the iMessage attack had some other weirdness that isn't relevant for what I'm describing, but was very relevant for iMessage being broken.

Isn't it a little weird to tell people to do major surgery on a crypto design, especially in ways that depart from the well-regarded design they derived it from, on account of attacks that don't work against that design?

It's only weird if you put Signal's specific design decisions from 2013 on a pedestal and declare it perfect and incapable of being improved.

(N.b. I don't expect my specific suggestions to be adopted. However, I view complaining without offering solutions to be poor form, so I offered some alongside my complaints.)

Of course, any deviation from Signal's design can and should be vetted by the same experts that vetted Signal's. And if they're unavailable to vet the derivations, the conservative thing to do is grit your teeth and bear Signal's legacy until they become available.

However, if Signal still targets Android 4.4 phones in 2020, there's a lot of devices without AES-NI and thus improving upon their AES-CBC design decision is worth probing at least.

In addition to my previous comments, I also have a thing about reflexively suggesting that people eliminate CBC from their designs. Depending on circumstances, CBC can be a safer choice than CTR (and CTR-derived modes like the AEAD stream ciphers); different failure modes.

You're entitled to your thing. Granted, CBC mode has a better misuse story than CTR, but an extended-nonce ChaPoly AEAD is likely to be safer in most of Signal's installed userbase (n.b. the same userbase Matrix and Jitsi would be targeting in a lot of cases), given the ARM SIMD (AES-NI equivalent) situation.

Is it really HMAC’d? 8 bytes isn’t cryptographic protection. It may be secure, but the standard arguments don’t apply.

Write a sketch of how a padding oracle attack would work against a CBC-encrypted message authenticated with truncated HMAC.

It's like a standard padding oracle attack, but 4 billion times slower (on average) and requires 4 billion times more CPU work and bandwidth, and you have to be able to distinguish between a HMAC failure and a padding error.

(a.k.a. isn't happening)

Reply on news.ycombinator.com