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

[Henry Baker]

At 03:15 PM 5/15/2021, Danny O'Brien wrote:
>On Fri, May 14, 2021 at 5:55 PM Henry Baker <hbaker1 at pipeline.com> wrote:
>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!
>
>I think the topic you may want to dive into (if you haven't already) is distributed hash-tables (https://en.wikipedia.org/wiki/Distributed_hash_table ). The binding isn't kept in a single node, but distributed across the network as a DHT (though of course that node has to be the origin point of the propagation). The DHT is the main underlying tech of IPFS, and the first thing any IPFS service reaches for as a solution, so it's generally a useful starting point.
>
>As you've spotted this isn't ideal for IPNS. I don't know what the real-world characteristics are of IPFS's DHT wrt eventual consistency, etc, but I know that the IPFS folks have been working on an alternative setup that allows quicker, network-wide updates for IPNS values for some time. Last time I looked, they were working on a separate publish-subscribe service over the network so that rather than messing around with re-checking a value after a certain time, interested parties could subscribe to an update service that would ping you when the value was re-bound. That was a few years ago, though, so my knowledge might be out of date.
>
>The other way to do this is to piggy-back of DNS's own working distribution system, which IPNS supports via dnslink. https://simpleaswater.com/dnslink/ . That gives you human-readable names and a timely well-known caching model, at the cost of leaning on a semi-centralised external service.
>
>---
>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.

Hi Danny, et al:

After going through a bit of an IPNS tutorial, I finally intuited the following understanding:

Mutable names are *public keys* of a public/private key pair. They appear to be bound to a particular 'Peer ID'; the first (local) name bound with any PeerID is 'self', any others have purely local *nicknames*.

As best as I can tell, any *binding* resulting from an 'ipfs name publish <public-key>' operation is *broadcast* to the IPFS universe in a way that the key-pair *attests* to this binding.

So anyone receiving the news of a new binding to such a public-key can prove to himself/herself that the binding is valid by checking that the binding is *signed* by the *owner* of this public-key, namely the PeerID which published the binding, and therefore must know its private key.

It is up to the network and the receiver to try to determine if the binding he/she has received is the *latest* binding to this public-key; after all, networks can delay some messages so that they appear out of order.

IPFS allows the owner of a PeerID to *generate new* public-keys which can be used for additional bindings.

IPFS also allows the owner of a PeerID to *remove* public-keys which it no longer wishes to be associated with.

I.e., these public-keys are 'pinned' to this PeerID in much the same way that immutable objects can be pinned to a PeerID. However, this pinning of public-key mutable bindings is much more public than the pinning of immutable objects.

I noticed that 'publishing' a new binding takes > one minute; I'm curious about what is taking all of this time.

It's not clear how the IPFS network does the mapping of public-key -> PeerID which currently owns that public-key. In particular, IPFS allows the *export* and *import* of a public/private key pair; what happens when two different PeerID's claim the same public-key ??

I'm going to submit a more ambitious post to cryptography which outlines my theoretical model of 'object identity' aka 'mutability' aka 'public/private key pair' aka 'locality' aka 'transaction' aka 'arbitration'.