Hacker News Reader

Inside of HushChat, libsodium secretstreams are used, which get the job done: https://doc.libsodium.org/secret-key_cryptography/secretstre...

https://git.hush.is/hush/hushchat

HushChat Protocol is like Signal Protocol, but phone numbers replaced with shielded addresses, fully open source (actually GPLv3 Free Software) and not backdoored.

> and not backdoored.

Are you saying that Signal is backdoored? Evidence?

This quote from GP's link could possibly be interpreted as "Signal does not look very trustworthy":

> Signal requires phone numbers and is a centralized service. HushChat is completely anonymous and decentralized and requires absolutely no metadata be given to any centralized third parties. Signal is also not fully open source, the backend servers are NOT OPEN SOURCE, and so, Signal should be considered "open core" and not fully open source. HushChat is Free Software! We are about your freedom, Moxie cares about his Silicon Valley friends.

I believe Signal requires phone numbers to be usable at all. I maybe vaguely recall plans to get rid of this restriction, but I'm not sure.

The Signal protocol is explicitly designed to trust servers as little as possible, so even if the server code were proprietary, that doesn't mean much.

Ultimately, HushChat and Signal are probably chasing slightly different goals. HushChat seems to be focused on privacy at all costs. Signal is focused on privacy for everyone. There's a usability tradeoff here, between usability and security.

---

While I'm at it, the following quote rubs me the wrong way:

> Are you rolling your own crypto like stupid people?

> No. We use the industry standard libsodium to provide cryptographic primitives: […]

My first objection here is that there's nothing wrong with writing your own implementation of known primitives. The problem when you do so is taking the time to get it right¹, which is why it is almost always much cheaper to just use an existing crypto library.

[1]: https://loup-vaillant.fr/articles/crypto-is-not-magic.html

My second objection is that they are designing and implementing their own protocol. Not that there's anything wrong with that, but they are suggesting it's easier than implementing a primitive. In my experience, it's not. It tends to take less time, but it's also more delicate. Overall, it evens out.

Really, I don't fault them for what they do here. But it sucks that they have to defend against the "rolling your own crypto" in this way.

>That proof can in theory be tied to a particular message.

It's a good point that a signature is needed, so code is not simpler.

But it can't be tied cryptographically to a particular message. The DH generates a shared key, and the signature proves that a DH exchange happened. But the signature proves nothing about the message, the signature isn't over the message. The receiver has access to the shared key and thus can forge messages.

> > That proof can in theory be tied to a particular message.

> It's a good point that a signature is needed, so code is not simpler.

A common misconception. One that I would forgive, if I didn't already linked to a counter-example in this very thread: https://noiseprotocol.org

Noise protocols don't use signatures. Their existence proves beyond the shadow of a doubt that mutual authentication can be achieved without signatures. Here's an example:

  Before the protocol
  -------------------
  sa : Alice's private key
  SA : Alice's public key (known to Bob)
  sb : Bob's private key
  SB : Bob's public key (know to Alice)

  Protocol
  --------

  Alice:
    ea = random
    EA = public_key(ea)
    send -> EA, SA

  Bob:
    eb = random
    EB = public_key(eb)
    send -> EB, SB

  Alice:
    verifies that SB is indeed Bob's key
    ee  = DH(ea, EB)
    es  = DH(ea, SB)
    se  = DH(sa, EB)
    key = HASH(ee, es, se)

  Bob:
    verifies that SA is indeed Alice's key
    ee  = DH(eb, EA)
    es  = DH(sb, EA)
    se  = DH(eb, SA)
    key = HASH(ee, es, se)

At this point, Alice and Bob have a mutually authenticated, secret, shared session key. We only needed key exchange (and hashing) to achieve that.

Now if you need a public key infrastructure, that's another matter. Stuff like certificate does require signatures. But that's a separate matter from the protocol itself, which can verify the trustworthiness of a key buy a simple lookup. For instance, an IoT device can hold a copy of its Company's public key. Or, Alice and Bob could have met in a crypto party.

The beauty with DH based schemes like Noise is that when Alice sends a message to Bob, Bob doesn't quite get a cryptographic proof that Alice sent a message. Bob gets a cryptographic proof that Alice or Bob sent a message. Bob only know it came from Alice because he did not send the message to himself.

He could have, though. So he can't (cryptographically) prove to the rest of the world that the embarrassing message really came from Alice. At best, he can prove that the message came from [Alice or Bob], but he'll have to disclose his private key to do it. But as soon as he discloses his own key, anyone can forge messages to him.

(Note: it is possible, still without using signatures, to make sure Bob is not fooled by forged messages from the outside even if his key was leaked: he only have to provide a freshly generated ephemeral key pair into the mix, which necessarily hasn't leaked yet. This provides what we call Key Compromise Impersonation resistance, so we can't force Matrix goggles on him just be cause we stole his key. Unfortunately, this requires Bob to provide that ephemeral key, and that only really works with online protocols. On a PGP-like system, this means that we have to chose between deniability or KCI resistance: if you use signatures, you lose deniability, and if you use only DH, you lose KCI resistance. My personal opinion is that one should be responsible for their own keys. Therefore, I'd sacrifice KCI resistance before I sacrifice deniability.