electricdusk/rushlink
3
3
Fork 3
Code Issues 21 Pull Requests 2 Releases Activity

readme: Update description of key generation

Browse Source 
In a recent commit, I updated the key generation to Lucus' solution, in which
we don't have to do any format-preserving encryption, but where the
probability of collisions is amortized away (basically by doing exponential
backoff) by adding a character every time we get a collision.
This commit is contained in:
Daan Sprenkels 2019-08-25 21:30:10 +02:00
parent 061bb23625
commit 7926df7410
1 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
README.md
View File

@ -36,15 +36,16 @@ namespace. Ideas:
## Shorten keys and collisions ## Shorten keys and collisions
For the first version of the keys, we will use 3 bytes encoded as base64url, First of all: A sexted is a value of 6 bits.
as described in [RFC4648, par. 5]. To allow for truncate-resistant upgrading
of the URL key format, the first bit is set to `0`. That means the first base64
character will always be in `/[A-Za-f]/`.
This domain contains `8388608` values. If the service is somewhat used, we will For generating keys, we will initially generate a random value of 4 sextets,
get collisions early when we generate those keys at random. Instead, we will where the first bit is set to `0`. If this collides with an existing key, we
use format-preserving-encryption to construct a counter that visits every value will generate a new one made out of 5 sextexts, and set the prefix bits to
in an unpredictable order. Daan will fix this. `0b10`. We will keep doing this until we don't have any collisions anymore.
To get proper-looking keys, we format the key to characters using the
base64url alphabet described in ([RFC4648, par. 5]). The encoded value will
be saved in the database.
[RFC4648, par. 5]: https://tools.ietf.org/html/rfc4648#section-5 [RFC4648, par. 5]: https://tools.ietf.org/html/rfc4648#section-5