Implement end-to-end private chat encryption

[klesun]

• Implement end-to-end private chat encryption like in telegram so that server hosted only the encrypted text and had no access to the key... or not to host the text altogether, just keep it in client's browser history or something. Anyway the idea is to make sure server has no way to get the actual text, so that if some government guys barged into my office I could honestly say them "sorry guys, it is not possible to leak you the chat history, all communication happens on client side".

  I'll think about it more and update when I have a solution.

  короче, я кажется знаю что делать с секурностью:

  • Пользователь генерирует как в ssh приватный и публичный ключи.
  • Посылает публичный ключ через сервер собеседнику.
  • Собеседник криптует свои сообщения через этот публичный ключ и отправляет обратно.
  • Пользователь исполльзует свой приватный ключ чтоб расшифровать эти сообщения.

  https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API

  I will write a scratch code with key generation after I deal with the rock-paper-scissors game.

  Upd.: no, this won't work either. Server could replace your public key with it's own before sending it to your buddy and decrypt what he sends.

  Ok, I came up with a genious idea yet again. To store public key on a service instead of passing it through the server and to check it every couple seconds. Here are the steps:

  • Take user's private/public keys from window.localStorage if any, else generate them with CryptHelper.js and store to the localStorage.
  • Every Math.random() * 10` seconds check that value on the service is either empty or matches the user's public key with:

    fetch('https://keyvalue.immanuel.co/api/KeyVal/GetValue/7p6a4g00/${atob(userEmail)}/${base64PublicKey}', {method: 'GET'}).then(out => out.text()).then(txt => console.log(txt));

    If it does not match, show the error to the user with BIG RED LETTERS and do not allow him to send encrypted messages. In addition, show him a button "It's OK, I simply logged from different device" - if he presses it, rewrite the value in the service (see further) and continue normally.
  • Store public key on the service: (publicKey is an ArrayBuffer, so it should be base64-encoded as well)

    fetch(`https://keyvalue.immanuel.co/api/KeyVal/UpdateValue/7p6a4g00/${atob(userEmail)}/${base64PublicKey}`, {method: 'POST'}).then(out => console.log(out));

  • Retrieve the public key of your buddy from window.localStorage or with GetValue of the service same way as above, but with atob of his email and write to localStorage.
  • Encrypt the message user is willing to send with CryptHelper.js::encrypt and your buddy's public key.
  • Send it to the server using func=sendPrivateMessage and encryption=CryptHelper_v001 (possibly will need to atob() the message before sending to server).
  • To decrypt incoming messages from func=getPrivateMessages with encryption=CryptHelper_v001 use CryptHelper::decrypt and the private key.

[klesun]

Update: it appears immanuel.co has a limit on the url size of 288 characters. So base64-ed email and publicKey may not exceed 226 characters. Since we don't posses the techonogy to compress anything into 36 bytes via a black hole, we'll have to think of a workaround.

What we will do - chunk the base64-ed public key into 2 urls:
https://keyvalue.immanuel.co/api/KeyVal/UpdateValue/7p6a4g00/vasya@gmail.com_1/publickeyinbase64part1
and
https://keyvalue.immanuel.co/api/KeyVal/UpdateValue/7p6a4g00/vasya@gmail.com_2/publickeyinbase64part2
If you pull you'll see that I tweaked CryptHelper.js a bit (f87a3e1) so now public key consists of 210 bytes instead of 1024. After base64 it becomes 280 characters. You should split this string in half, so you get two 140-characters strings - store them in vasya@gmail.com_1 and vasya@gmail.com_2 keys respectively. Likewise when you fetch the key to encrypt the message on the other end or to check that it did not change - fetch these two strings from both urls and join them back.

Besides the key chunking, everything else stays same - let's stick to the plan described above.

P.S.: it would be nice if amount of chunks was actually configurable in case we ever decide that btoa(226 - 140) - _1 = 62 characters is too little for email. So that we could just change a constant from 2 to 4 and everything started working with public key being split into 4 chunks.

[brxkensmile]

@klesun the way we are now encrypting/decrypting messages works fine on Chrome, also, possibly will work fine on Firefox, but how it reacts on other browsers? (MS IE & MS Edge isn't working at all). Need to think about solution. (Or we just forget about all other browsers except Chrome :D)

[klesun]

In edge it does not work because of a bug in their engine, as I already mentioned before. I personally don't give a damn about this microsoft crap, so I would ignore this browser as you suggested.

Firefox should work, safari should too, at least MDN page says so.

Any other browsers don't exist.

[klesun]

Oh, lol:

[brxkensmile]

ahahah