commit 9bf7671c9f677ce3bca8a34c8e211baea021fc88
parent 03a9f178c9c0b216dd4869f0da9d31ce7a23f11b
Author: Daniel Barlow <dan@telent.net>
Date: Thu, 5 Mar 2026 22:08:26 +0000
remove outdated rambling
Diffstat:
| M | notes.md | | | 39 | --------------------------------------- |
1 file changed, 0 insertions(+), 39 deletions(-)
diff --git a/notes.md b/notes.md
@@ -170,42 +170,3 @@ O wifi provisioning over ble
- add an IMU to get lean angles
- stop hardcoding BLE address
```
-
----
-
-BLE latest: remember we need physical access and the ignition key in
-order to power on the device.
-
-But if we don't pair then the wifi password can be passively eavesdropped
-
-And if we can't pair with MITM protection then - even though the
-connection is encrypted - a balaclava-in-the-middle with $50 of
-micro:bits can get the wifi password.
-
-So, bottom line: we need authentication and encryption, and in accordance with
-"don't roll your own crypto" advice we will do this with https://nacl.cr.yp.to/box.html
- / https://github.com/RustCrypto/nacl-compat/tree/master/crypto_box
-
-Given which, we probably don't need to pair in the first place.
-
-....
-
-could/should we use the same infrastructure for the client signing
-session keys? there is no crypto_sign implementation in nacl-compat,
-and no shared highlevel code in the signature generation, which makes
-me think "no".
-
-.....
-
-(1) use pynacl at build time to make keypairs for device and client
-
-keys/client.{key,pub}
-keys/eculocate.{key,pub}
-
-let alice_public_key = PublicKey::from(alice_public_key_bytes);
-let bob_secret_key = SecretKey::from([...])
-
-// Bob can compute the same `SalsaBox` as Alice by performing the
-// key agreement operation.
-let bob_box = SalsaBox::new(&alice_public_key, &bob_secret_key);
-bob_box.decrypt(&nonce, &ciphertext[..])?
