aboutsummaryrefslogtreecommitdiff
path: root/spec/rend-spec/vanity-onions.md
blob: f07d108d1f641ea7fcb284506cc464c6bf002aa5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
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.