From 7926df7410f23abd322e4ed51e0d6d46e47ca5ae Mon Sep 17 00:00:00 2001 From: Daan Sprenkels Date: Sun, 25 Aug 2019 21:30:10 +0200 Subject: [PATCH] readme: Update description of key generation 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. --- README.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index d2e453d..330b11b 100644 --- a/README.md +++ b/README.md @@ -36,15 +36,16 @@ namespace. Ideas: ## Shorten keys and collisions -For the first version of the keys, we will use 3 bytes encoded as base64url, -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]/`. +First of all: A sexted is a value of 6 bits. -This domain contains `8388608` values. If the service is somewhat used, we will -get collisions early when we generate those keys at random. Instead, we will -use format-preserving-encryption to construct a counter that visits every value -in an unpredictable order. Daan will fix this. +For generating keys, we will initially generate a random value of 4 sextets, +where the first bit is set to `0`. If this collides with an existing key, we +will generate a new one made out of 5 sextexts, and set the prefix bits to +`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