1781344560 english chat2026-devblog

Chat2026 part 11: Making it simpler

In the previous weeks/months I was quite distracted from this project. I've written a YAML based plain text accounting program to better do my taxes. And I've dumped a lot of thoughts that kept going in my brain in the loop. After those posts, now I can walk my daily kilometers without my inner voice constantly talking. At work the company rolled out agentic AI stuff, that can do changes in the company codebase on its own. So it's more than a glorified autocomplete it can do major part of my job. Last week they even made a demo where they created an agent that can pick up Jira tickets and do the whole development process and creating the PR. So yeah the end in near.

Another thing is that I'm overcomplicating this chat thing. There is already a Swiss knife network protocol, everything uses HTTP. Then putting TLS over that is simply HTTPS. In the previous part I've even talked about that we may want to conceal traffic HTTPS + CONNECT method. Then why don't we create a HTTP based protocol then? Heck why even bother with the CONNECT protocol thing, when the eavesdropper cannot see anything except domain? You put the thing on your website at a hidden place in a directory and give the URL to people.

Now there is another issue: the pesky user interface. I'd need to create an app for every single platform: Windows, Linux and Android at the very least. Then for Android I'd need to go through an extra amount of hoops to get it included in Play store, then I have maintain it actively. So I've decided that I'll simply stick to something web based.

However web based end-to-end encryption has a problem: the server gives the users the client program to use. If the server is not trustworthy, then it can send a client to the user that can simply send the plain text to the server. That's not good. However if the server's host is the person you want to talk with, then this isn't a concern, because all the chat you have is already known to the host, so they do not need any tricks. In fact a simple HTTPS website with a form can do the job. So the general idea is to create a "Chat with me" web app, where users can chat only with the server's admin (and not each other). The host then can invite users on the server, who can register and chat with the host. And that's it.

Of course I feel a little bit uncomfortable about that the messages just sit plaintext on the server. Some kind of encryption is needed. And this can only be done if users have a cryptographic key, and the client only sends the encrypted stuff. And the server stores the ciphertext only. JavaScript has added cryptography primitives to the language a while ago, so we can use that. But somehow the user still needs to have the private key.

Now here is the neat thing, there is a protocol called OPRF, which can be used to generate a symmetric encrypted key with the help of the server. The basic gist is this:

  1. Encode the password into an elliptic curve point $H$.
  2. Multiply it with a random scalar $r$ to get $rH$.
  3. Send $rH$ to the server. The server the multiplies it with its secret key $k$ to get $rkH$ and sends this back.
  4. The client then divides this by $r$ to get $kH$.

The $kH$ is then used to generate a symmetric key. Then this symmetric key can be used to encrypt the asymmetric keypair, and then the encrypted keypair can be stored on the server. So if the server is pwned and the database is stolen, the attacker cannot simply decrypt the keys or the messages. However if the compromise is bad enough that allows the attacker to change the client sent by the server, then they can collect the passwords anyway... But a non interfering adversary e.g. a VPS admin simply cannot steal our chats.

So that's the basic principle: just create a damned web app in JavaScript, that put a database behind it in the server side. So I was looking around and realized the the WebCrypto API does not have OPRF yet. So I needed a library. So I decided to use the noble/curves elliptic curves library. But that's a Node.JS library. So I need to compile it such that I can use it from the browser. I've used npx esbuild for that.

And while I'm at it, I also looked at Node.JS. It seems to be JavaScript is all the rage. So maybe I should learn to use Node.JS for the server side of this project. So that's what I did. The server side will use JavaScript too in Node.JS. And the cool thing is I can use the very same Elliptic curve library to do the server side part of the OPRF.

So in the last few weeks I've worked on this. I can't remember the last time I was on flow in a hobby project. This is a hobby project for my enjoyment, so I did not use AI to write any of this. Currently I'm testing the web app with some friends now, once the code is stable for a week or a month, I will post a code walkthrough.

Feedback

Posts

See the latest posts below, click the "..." to see them all. Click the tags to filter by tag. You can also subscribe to RSS in those lists.

Wet bulb, dew point and absolute humidity calculator - 1782975780 english tools

Water and calories - 1782896580 english tools

Age of Empires 2, late game compositions - 1782635640 english aoe2

Chat2026 part 11: Making it simpler - 1781344560 english chat2026-devblog

The cloud transition is the biggest threat to digital privacy - 1779030840 english privacy

...