1 files changed, 45 insertions, 0 deletions
diff --git a/spec/rend-spec/vanity-onions.md b/spec/rend-spec/vanity-onions.md
new file mode 100644
index 0000000..f07d108
--- /dev/null
+++ b/spec/rend-spec/vanity-onions.md
@@ -0,0 +1,45 @@
+<a id="rend-spec-v3.txt-C"></a>
+
+# Appendix C: Recommendations for searching for vanity .onions \[VANITY\]
+
+EDITORIAL NOTE: The author thinks that it's silly to brute-force the
+keyspace for a key that, when base-32 encoded, spells out the name of
+your website. It also feels a bit dangerous to me. If you train your
+users to connect to
+
+llamanymityx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymle.onion
+
+I worry that you're making it easier for somebody to trick them into
+connecting to
+
+llamanymityb4sqi0ta0tsw6uovyhwlezkcrmczeuzdvfauuemle.onion
+
+Nevertheless, people are probably going to try to do this, so here's a
+decent algorithm to use.
+
+To search for a public key with some criterion X:
+
+Generate a random (sk,pk) pair.
+
+While pk does not satisfy X:
+
+```text
+            Add the number 8 to sk
+            Add the point 8*B to pk
+
+        Return sk, pk.
+```
+
+We add 8 and 8\*B, rather than 1 and B, so that sk is always a valid
+Curve25519 private key, with the lowest 3 bits equal to 0.
+
+This algorithm is safe \[source: djb, personal communication\] \[TODO:
+Make sure I understood correctly!\] so long as only the final (sk,pk)
+pair is used, and all previous values are discarded.
+
+To parallelize this algorithm, start with an independent (sk,pk) pair
+generated for each independent thread, and let each search proceed
+independently.
+
+See \[VANITY-REFS\] for a reference implementation of this vanity .onion
+search scheme.