[Cryptography] Christmas challenge greetings

Michael Kjörling michael at kjorling.se
Sun Dec 26 13:45:28 EST 2021


On 21 Dec 2021 11:10 -0500, from phill at hallambaker.com (Phillip Hallam-Baker):
> 1) An IPv6 Address is 128 bits.
> 
> 2) IPv6 headers all have to and from addresses but from field is redundant
> most of the time so there are 256 bits of addressing.
> 
> 3) Curve25519 public keys fit in 255 bits.
> 
> So who can propose the most outrageous proposal that makes use of these
> three facts?

Since you asked for outrageous, try this one on for size. Since this
isn't an actual technical proposal, I'm glazing over a lot of the
details.

A "digital object", here, is basically anything that can be
represented in binary form inside a classical computer. It could be a
file, but it could also be ephemeral data.

1) For each digital object of interest, generate a unique 25519 key
pair at random such that no part of the key pair is in any way derived
from the digital object.

2) Somehow sign each digital object with the private key portion of
its corresponding key pair as generated in step 1; then throw away the
private key portion of the key pair.

3) Somehow set up IPv6 routing and data servicing such that accessing,
in a standardized manner (for example: any HTTP/1.1 GET request after
establishing a connection to TCP port 65534), the public key of the
key pair generated in step 1 as an IP address, returns the original
digital object along with its signature in some form of standardized
container.

Sort of like an unauthenticated, free-for-all, cryptography-backed
DOI, or somewhat similar to an IP-level NFT if you prefer that
nomenclature. Also somewhat similar to IPFS, but without the
distributed hash table and where the addresses have absolutely no
relationship to the content being addressed.

If in step 1 127-ish bits of the 256-bit 25519 public key are fixed by
the protocol, this could even be implemented without hacking the from
field, but returning the response data would probably pose a challenge
either way. Fixing a few more bits could segregate this to a portion
of the IPv6 address space, which might well alleviate that problem;
maybe 3ffe::/16 could be repurposed?

Step 1 above is largely trivial. Step 2 shouldn't be difficult to pull
off; GnuPG, for example, can already use Ed25519 keys for signing
arbitrary data and its output format is standardized in the form of an
RFC. The second half of step 3 (the request and response format) seems
largely unproblematic; something would need to be agreed upon, but
that's about it. It's the first half of step 3 (the actual routing and
connection part) that qualifies this as an outrageous proposal; if
something like this was to be done on a wide scale, even if the issue
of returning the response is solved, it would almost certainly _kill_
global IPv6 routing by routing table bloat.

I'm not sure exactly what this would be good for, but in the spirit of
some other developments in the computer and networking industries,
maybe someone can think of something to use it for once it's out
there, up and running. :-)

-- 
Michael Kjörling • https://michael.kjorling.semichael at kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”



More information about the cryptography mailing list