enhance section on signature

Author: Lash-L

docs/technical_writeup.md

@@ -90,9 +90,9 @@ We need either the public key (stored on Roborock's servers) or the private key
 
 Remember step 4 of the onboarding flow - the vacuum hits the `/region` endpoint and passes a `signature` parameter. That signature is an RSA PKCS1v1.5 SHA-256 signature over the query string, signed with the vacuum's private key. We can't access the private key, but we don't need to. We just need the public key. With enough signature samples, we can actually determine the public key.
 
-Here's the math. An RSA signature is `sig = msg^d mod n`, and verification is `sig^e mod n == msg`. We know `e` (65537 is the standard RSA public exponent used by virtually every implementation - including here), we know the message (it's the query string), and we know the signature (it's right there in the request). What we don't know is `n` — the RSA modulus, which is the public key.
+Here's the math. RSA PKCS#1 v1.5 signing computes `sig = pad(SHA256(msg))^d mod n`, where `pad()` is the deterministic EMSA-PKCS1-v1.5 encoding (a fixed ASN.1 prefix + the hash, right-padded into a full block). Verification checks `sig^e mod n == pad(SHA256(msg))`. We know `e` (65537 is the standard RSA public exponent used by most implmenetations), we can compute `pad(SHA256(msg))` ourselves (it's deterministic given the query string), and we know the signature as it is included in the REST request. What we don't know is `n` — the RSA modulus, which is the public key.
 
-If we rearrange the verification equation: `sig^e - msg = k * n` for some integer `k`. That means `sig^e - msg` is a multiple of `n`. If we collect two different signed requests from the vacuum (different query strings, different signatures), we get two different multiples of `n`. The GCD of those two values gives us `n` — or `n` times some small cofactor that we can divide out.
+If we rearrange the verification equation: `sig^e - pad(SHA256(msg)) = k * n` for some integer `k`. That means the difference is a multiple of `n`. If we collect two different signed requests from the vacuum (different query strings, different signatures), we get two different multiples of `n`. The GCD of those two values gives us `n` - or `n` times some small cofactor that we can divide out. The padding being deterministic is what makes this work — if it included any randomness, we couldn't compute the padded value and the recovery would be impossible.
 
 So the approach is:
 1) During onboarding, we inject our server URL so the vacuum connects to us.

mkdocs.yml

@@ -5,25 +5,33 @@ theme:
   palette:
     - media: "(prefers-color-scheme: light)"
       scheme: default
-      primary: teal
-      accent: teal
+      primary: deep purple
+      accent: amber
       toggle:
         icon: material/brightness-7
         name: Switch to dark mode
     - media: "(prefers-color-scheme: dark)"
       scheme: slate
-      primary: teal
-      accent: teal
+      primary: deep purple
+      accent: amber
       toggle:
         icon: material/brightness-4
         name: Switch to light mode
+  font:
+    text: Inter
+    code: Roboto Mono
+  icon:
+    repo: fontawesome/brands/github
   features:
     - navigation.instant
     - navigation.tracking
     - navigation.sections
+    - navigation.expand
     - navigation.top
     - content.code.copy
     - toc.follow
+    - search.suggest
+    - search.highlight
 
 markdown_extensions:
   - admonition