[PR #70] [MERGED] implement cryptographic suggestions #77

New issue

Closed

opened 2026-03-03 01:21:31 +03:00 by kerem · 0 comments

kerem commented

2026-03-03 01:21:31 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/cs01/termpair/pull/70
Author: @cs01
Created: 7/25/2021
Status: ✅ Merged
Merged: 7/28/2021
Merged by: @cs01

Base: master ← Head: cs01/encryption-improvements

📝 Commits (2)

c0a4ade add key roation; use two AES keys; retrieve AES keys with RSA pubkey
36e7dcb do not use random nonces in browser

📊 Changes

11 files changed (+927 additions, -468 deletions)

View changed files

📝 CHANGELOG.md (+1 -0)
📝 README.md (+9 -7)
📝 docs/termpair_architecture.excalidraw (+238 -209)
📝 docs/termpair_architecture.png (+0 -0)
📝 termpair/encryption.py (+26 -5)
📝 termpair/frontend_src/src/App.tsx (+215 -33)
📝 termpair/frontend_src/src/encryption.tsx (+95 -11)
📝 termpair/frontend_src/src/events.tsx (+23 -3)
📝 termpair/server.py (+9 -4)
📝 termpair/server_websocket_subprotocol_handlers.py (+1 -3)
📝 termpair/share.py (+310 -193)

📄 Description

I have added an entry to CHANGELOG.md

Summary of changes

Use new key sharing scheme and address points 1, 3, and 4 from https://github.com/cs01/termpair/issues/36#issue-907434506. I know I said I wasn't going to work on this, but it seemed like a fun challenge to get it all working, and I got to learn some things along the way.

Different keys used in different directions
- AES GCM IV nonces now use distinct, monotonically increasing counters in the sharing terminal and browser.
- For each session, the terminal client creates an AES key to encrypt data from terminal and another to encrypt from browsers. All browsers for that session use the same key to encrypt (until rotated, see next bullet). Each browser window gets its own number space to monotonically increase the nonce until its exhausted, then request a key rotation from the broadcasting terminal.
Keys rotated. I chose what I thought was a (very) conservative number of encryptions to rotate after, 2^20 or ~1 million (see message_count_rotation_required). I can also switch from 128 bit keys to 256 if necessary since I saw a key rotation is recommended after 2^32 when using 256 bit keys.
Secret keys retrieved by browsers via RSA public key rather than embedding in the URL. Each browser window creates a new RSA key pair using the subtle crypto API at initialization time, requests the AES keys and passes the pk along with the request, and receives back the AES keys encrypted with the pk (and a random salt because I thought there might be a way to take two messages that different only by their public keys and derive the rest of the message?).
Updated documentation to reflect the changes

Test plan

Tested by running

make build_frontend
nox -s serve
# in new terminal
nox -s share

Would appreciate any input from @colmmacc or @ignoramous if you have the time. I realize it's a big PR so feel free to ask questions, I'm happy to answer any.

closes #36

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/cs01/termpair/pull/70 **Author:** [@cs01](https://github.com/cs01) **Created:** 7/25/2021 **Status:** ✅ Merged **Merged:** 7/28/2021 **Merged by:** [@cs01](https://github.com/cs01) **Base:** `master` ← **Head:** `cs01/encryption-improvements` --- ### 📝 Commits (2) - [`c0a4ade`](https://github.com/cs01/termpair/commit/c0a4ade609e065eac90f0826c4b8c55cbb041409) add key roation; use two AES keys; retrieve AES keys with RSA pubkey - [`36e7dcb`](https://github.com/cs01/termpair/commit/36e7dcb29486bbd4216901e058041a550cf0fa0b) do not use random nonces in browser ### 📊 Changes **11 files changed** (+927 additions, -468 deletions) <details> <summary>View changed files</summary> 📝 `CHANGELOG.md` (+1 -0) 📝 `README.md` (+9 -7) 📝 `docs/termpair_architecture.excalidraw` (+238 -209) 📝 `docs/termpair_architecture.png` (+0 -0) 📝 `termpair/encryption.py` (+26 -5) 📝 `termpair/frontend_src/src/App.tsx` (+215 -33) 📝 `termpair/frontend_src/src/encryption.tsx` (+95 -11) 📝 `termpair/frontend_src/src/events.tsx` (+23 -3) 📝 `termpair/server.py` (+9 -4) 📝 `termpair/server_websocket_subprotocol_handlers.py` (+1 -3) 📝 `termpair/share.py` (+310 -193) </details> ### 📄 Description  * [x] I have added an entry to `CHANGELOG.md` ## Summary of changes Use new key sharing scheme and address points 1, 3, and 4 from https://github.com/cs01/termpair/issues/36#issue-907434506. I know I said I wasn't going to work on this, but it seemed like a fun challenge to get it all working, and I got to learn some things along the way. * Different keys used in different directions * AES GCM IV nonces now use distinct, monotonically increasing counters in the sharing terminal and browser. * For each session, the terminal client creates an AES key to encrypt data from terminal and another to encrypt from browsers. All browsers for that session use the same key to encrypt (until rotated, see next bullet). Each browser window gets its own number space to monotonically increase the nonce until its exhausted, then request a key rotation from the broadcasting terminal. * Keys rotated. I chose what I thought was a (very) conservative number of encryptions to rotate after, 2^20 or ~1 million (see `message_count_rotation_required`). I can also switch from 128 bit keys to 256 if necessary since I saw a key rotation is recommended after 2^32 when using 256 bit keys. * Secret keys retrieved by browsers via RSA public key rather than embedding in the URL. Each browser window creates a new RSA key pair using the subtle crypto API at initialization time, requests the AES keys and passes the pk along with the request, and receives back the AES keys encrypted with the pk (and a random salt because I thought there might be a way to take two messages that different only by their public keys and derive the rest of the message?). * Updated documentation to reflect the changes ## Test plan  Tested by running ``` make build_frontend nox -s serve # in new terminal nox -s share ``` Would appreciate any input from @colmmacc or @ignoramous if you have the time. I realize it's a big PR so feel free to ask questions, I'm happy to answer any. closes #36 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>