3 ms·

> Ken Thompson: "...i really dont think it is useful. it is like replacing ipv6 with ipv50"

mitxela 6d ago
256-bit addresses would be long enough proper cryptographic addressing. (128 is barely not enough due to how they're allocated) 512 would also for cryptographic addresses within cryptographic subnets (or 3 128-bit layers plus some extra bits), and 1024 would allow for up to 7 layers. It's not a completely silly idea. Yggdrasil subnet addresses only have 56 bits of cryptographic entropy; there's a limited workaround where you increase work by searching for one with a zero prefix, but the cost to clone one can't be more than 2^56 times the cost to create it, which isn't adequate in cryptography. Individual addresses can also be created with 112 bits of entropy, which is barely adequate. That's why I say 128 bits total isn't enough for cryptography plus subnetting.
- Dylan16807 6d ago
  Is there a significant reason to want those to use the same address space as the normal internet? Especially with the layering, I would think you could put this in a routing header? > Yggdrasil subnet addresses only have 56 bits of cryptographic entropy; there's a limited workaround where you increase work by searching for one with a zero prefix, but the cost to clone one can't be more than 2^56 times the cost to create it, which isn't adequate in cryptography. Individual addresses can also be created with 112 bits of entropy, which is barely adequate. If you make it cost a dollar to compute, and you account for that getting 1000x cheaper during the time it needs to stay secure, that's around 70 trillion dollars to attack? I would call that "adequate". And ten cents / 7 trillion too. (This does assume an algorithm that runs reasonably fast on normal hardware, so that "2^56 times the cost" mostly holds up in the face of dedicated cracking chips.)
  - mitxela 6d ago
    The other option is to start making more software AF-agnostic and not assume that an address is always an ipv4 or ipv6 address.

256-bit addresses would be long enough proper cryptographic addressing. (128 is barely not enough due to how they're allocated) 512 would also for cryptographic addresses within cryptographic subnets (or 3 128-bit layers plus some extra bits), and 1024 would allow for up to 7 layers. It's not a completely silly idea. Yggdrasil subnet addresses only have 56 bits of cryptographic entropy; there's a limited workaround where you increase work by searching for one with a zero prefix, but the cost to clone one can't be more than 2^56 times the cost to create it, which isn't adequate in cryptography. Individual addresses can also be created with 112 bits of entropy, which is barely adequate. That's why I say 128 bits total isn't enough for cryptography plus subnetting.

Dylan16807 6d ago
Is there a significant reason to want those to use the same address space as the normal internet? Especially with the layering, I would think you could put this in a routing header? > Yggdrasil subnet addresses only have 56 bits of cryptographic entropy; there's a limited workaround where you increase work by searching for one with a zero prefix, but the cost to clone one can't be more than 2^56 times the cost to create it, which isn't adequate in cryptography. Individual addresses can also be created with 112 bits of entropy, which is barely adequate. If you make it cost a dollar to compute, and you account for that getting 1000x cheaper during the time it needs to stay secure, that's around 70 trillion dollars to attack? I would call that "adequate". And ten cents / 7 trillion too. (This does assume an algorithm that runs reasonably fast on normal hardware, so that "2^56 times the cost" mostly holds up in the face of dedicated cracking chips.)
- mitxela 6d ago
  The other option is to start making more software AF-agnostic and not assume that an address is always an ipv4 or ipv6 address.