[anologwintermut]

So this appears to naively use DJB's NACL/crypto_box construction, which is a curious choice given the existence of OTR for messaging protocols which would handle things like session key negotiation and provide deniability.

First, If I'm reading the source correctly, they are doing public key encryption for every message. Which, ok, DJB was a fan of at least for DNSCurve, but is generally regarded somewhat dimly for efficiency reasons. So I guess this puts them on one extreme of the Bell Curve or the other. I wonder which?

[EDIT, removed point about nonce's in handshake]

Funnily enough, at first glance it looks like they covered at least some of the obvious issues: they do at least attempt to authenticate the session key and the crypto_box's use of a Nonce prevents replay and re-ordering attacks.

How do they handle video chat? Crypto_box won't work there naively sense packets will get lost and the nonce's won't be in sync.

[irungentoo]

> Nonce's are "Numbers used ONCE", they 1) don't need to be secret and 2) ARE NOT encryption keys.

We know.

Putting the nonces in the handshake along with the session public key was simple.

In the NaCl docs it is advised that if you can keep the nonces secret that you do so.

[anologwintermut]

Out of curiosity, why not use OTR for messaging?

[znq]

Probably because OTR only works when both parties are online at the same time.

Edit: that said I haven't looked at their solution. Maybe it has the same issues. Or worse.

[anologwintermut]

Looking at their crypto code, it appears they assume both parties are online. There is a two way hand shake for key negotiation.

My guess was they wanted to handle things like video chat and file transfer that OTR doesn't handle. But at least for video chat, I don't think it NACL will work out of the box either