commit: fd6f703510b9f551894f15ef1ce0c987f5579ebc
parent f4e87fa1d0d7a55a4057a247cfa22297416a5095
Author: Haelwenn (lanodan) Monnier <contact@hacktivis.me>
Date: Sun, 18 Apr 2021 20:45:08 +0200
notes/computing-truths: Expand on Unique IDs
Diffstat:
1 file changed, 10 insertions(+), 0 deletions(-)
diff --git a/notes/computing-truths.txt b/notes/computing-truths.txt
@@ -23,6 +23,16 @@ I would love to be proved wrong or shown doubts on any of this, thanks a lot if
- Data decays eternally
- You need threat models for your security
- So called "Unique IDs" aren't always unique
+ - A lot of "Unique IDs" can be spoofed or badly generated/stored (quite common for MAC Addresses)
+ - In the case of UUIDs, they can be reasonably trusted but be careful on how you use them:
+ - "nil" UUID (entirely zero) is valid
+ - version 1 should be avoided in settings where time isn't linear (can easily jump backwards, always at the same date on boot, …)
+ - version 3 (MD5) and 5 (SHA-1) obviously shouldn't be used as security credentials
+ - version 4 is pure random and should be avoided when you have reliable time and can get a large sample size (Birthday problem)
+ - In decentralized settings consider FlakeIDs, 128-bits k-ordered IDs: 64-bits of milliseconds since UNIX epoch, 48-bits for the node-ID, 16-bits of random/sequence
+ Implementation: <https://git.pleroma.social/pleroma/elixir-libraries/flake_id>
+ Note on the node-ID: Consider generating a random ID at launch or installation; using another Unique ID like a MAC Address has uniqueness issues and privacy issues
+ It's also assumed that a node can reasonably assert if a FlakeID in it's own namespace was already used.
## Correctness
- Asserting correction is hard (I do not believe that languages like F* actually do solve this entirely)
