[Cryptography] IPFS: what's PKI got to do with it?

[Henry Baker]

At 04:57 PM 5/14/2021, Danny O'Brien wrote:
>On Fri, May 14, 2021 at 4:31 PM Henry Baker <hbaker1 at pipeline.com> wrote:
>I've read the papers on IPFS, and understand that
>somehow a *mutable* binding gets 'published' to the
>cloud, and has to be refreshed every 24 hours or so.
>
>But what I can't determine from the papers is where
>public key encryption fits in.
>
>Somehow, a PKE pair is involved in *mutable* bindings,
>but none of the papers seem to describe this process
>in an intelligible way.
>
>I understand fully well how the *immutable* bindings
>work; I'm only interested in understanding how the
>*mutable* bindings work.
>
>This intuition might help: if you're going to make a binding that's mutable, you're going to need to be able to store it at some permanent location (so that others can find it, and can repeatedly check it for changes). You also need to prohibit most other actors on the network from being able to mutate it. 
>
>Every IPFS node has a keypair. When you want to create a mutable IPNS entry, you sign it with your node's private key  and throw it into the IPFS DHT with a hash of your public key as the value that others can look up to find your entry. That means that there's always a fixed location for a given mutable binding (your public key hash), and only those who have the private key can change it (because IPFS clients will reject any update to that entry that isn't signed by the private key of that public key.)
>
>What may be throwing you is that each keypair only gives you one usable entry in the IPNS DHT. If you want to store more than one file, you have to point that location to a directory and use that to address the other individual files. It acts as a mutable root, pointing to the top of a collection of immutable links. To change one element, you point your mutable root to the root of another immutable collection that represents the same tree, but with that one item changed.
>
>Hope that helps!
>
>d.

Hi Danny:

Yes, your description was extremely helpful-- perhaps it should be incorporated into the documentation.

Perhaps I know too much: I'm aware of all of the various caching schemes for multiprocessor systems and the need to keep them all consistent, with all sorts of cleverness that entails.

Then there's the Bitcoin block-chain, with its *competition*/*lottery*/*proof-of-work* required to update the *global state* to make sure that it remains consistent.

Keeping a mutable binding within a single node is downright primitive, by comparison!

However, there must be more to this; what about the *24 hour clock*? Apparently, IPFS defaults to bindings lasting for only 24 hours, after which they must be renewed. This sounds a lot more like the "TTL" timers in networking packets.

I was hypothesizing that perhaps the "binding owner" node could broadcast signed messages to indicate changes in that node's binding; these signed messages would have a TTL of at most 24 hours. Then the public key becomes the mechanism to avoid *fake news* of the node's value.