commit: f9beb6a539de4bb87b934bd3e9a31eba4ccb23c6
parent 0d1fe6e052ab857a15a4e479526a535bfb46df16
Author: Haelwenn (lanodan) Monnier <contact@hacktivis.me>
Date: Sun, 18 Apr 2021 21:35:50 +0200
notes/computing-truths: turn Unique IDs into a heading
Diffstat:
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/notes/computing-truths.txt b/notes/computing-truths.txt
@@ -25,18 +25,20 @@ I would love to be proved wrong or shown doubts on any of this, thanks a lot if
- A version number isn't a good indicator of quality
- 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)
- - If you count all IDs sequentially it means that you end up with enumeration and a lack of plausible-deniability and can lead to uniqueness issues if you restore storage from an previous point in time, this should be strongly avoided in internet applications
- - 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.
+
+## Unique IDs
+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)
+- If you count all IDs sequentially it means that you end up with enumeration and a lack of plausible-deniability and can lead to uniqueness issues if you restore storage from an previous point in time, this should be strongly avoided in internet applications
+- 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)
