[artemgr]

Great project - especially how it leverages what we already have!

And actually, perhaps PKI is not that good for this case all together. Instead we could extend the original idea with simple primitives like an infinite hash chain (https://ieeexplore.ieee.org/document/7509492). In this scheme, during every authentication round, a user reveals a pre-committed secret and simultaneously commits to a new one for the next interaction. This approach is already used on websites where authentication tokens are exchanged based on known hashes, and there are proven methods to keep these tokens continuously updated. It relies solely on hashes — just like your scheme — and can work by having both parties scan each other’s QR codes on every interaction, which both performs an authentication check and also updates the application’s state each round.

The beauty of this method compared to PKI is first, it is based on a weaker assumption, but more importantly is that even if an attacker intercepts the initial QR code, they cannot afford to miss any message exchange, or they’ll lose the ability to authenticate. Moreover, if an attacker ever impersonates a party by following the protocol, the genuine authentication sequence will break down, revealing a discrepancy that exposes the impersonation.

And it should not be too hard to build, so I might give it a try.

[k_sze]

That sounds interesting! I'm looking forward to seeing what you build.

[artemgr]

Actually, I thought a bit more about it, and it seems there is a trivial potential attack when an adversary opens two calls - one to each user - and deepfakes each user’s feed to the other.

If all authentication keys (QR codes, TOTP codes, even PKI) are exchanged in the communication channel and do not authenticate the communication channel feed itself, the attacker can simply forward them between the two victims, maintaining a perfect “bridge” with no obvious sign of tampering. Once the authentication phase is complete, they can terminate the redundant call and continue conversation with the target having passed the authentication.

It seems to me that the only way against it is to authenticate messages (text or feed) themselves, and for that we go back to regular MACs that are already used today.