Is IPNS susceptible to replay attacks?

Help Old FAQ
1

From @se3000 on Wed Nov 04 2015 15:29:44 GMT+0000 (UTC)

The way I understand it, IPNS is addressed by the hash of a nodeā€™s public key.

Iā€™m imagining some kind of valuable dynamic information being served over IPNS, and a malicious party who prefers an old version to a new version could intentionally choose to serve the old one instead of updating. Is that a possibility?

It seems like this risk can be mitigated by checking with more peers. Iā€™m wondering if thereā€™s any way to resolve the dispute, like time stampingā€¦ Or is there something Iā€™m missing, and this isnā€™t actually a risk?


Copied from original issue: https://github.com/ipfs/faq/issues/70

2

From @whyrusleeping on Wed Nov 04 2015 17:30:50 GMT+0000 (UTC)

What i describe here is the current implementation of IPNS, a more flexible implementation will come a little later.

Each record is tagged with a monotonically incrementing sequence number and an ā€˜end of lifeā€™ timestamp, and the entire record is signed. When resolving ipns records, the requesting node will fetch a good number of them (currently 16) from the dht. Once these records are gathered, any with invalid signatures are thrown out. Next, any with expired timestamps are thrown out. The sequence numbers of each remaining record are then compared, and the highest one is selected. Any node who sent the requester an ā€˜olderā€™ or ā€˜invalidā€™ record will have the latest record sent to them by the requester as a network correction.

While this isnt a guarantee that replay attacks are completely impossible, it does make it difficult to pull off.

3

From @jbenet on Thu Nov 05 2015 07:32:42 GMT+0000 (UTC)

cryptographic freshness, TTLs, and update commitments are all ways of dealing with this that will be supported by IPRS (what IPNS will soon layer over) ā€“ see https://github.com/ipfs/specs/tree/master/records

4

From @wigy-opensource-developer on Wed Oct 26 2016 14:00:37 GMT+0000 (UTC)

@jbenet Hi! I know you are in a great refactoring related to GitHub organizationsā€¦ Could you please point me to the new place of this broken link? https://github.com/ipfs/specs/tree/master/records

The closest I could find was https://github.com/libp2p/interface-record-store , but that also referred to the broken spec.

5

From @dignifiedquire on Wed Oct 26 2016 14:02:55 GMT+0000 (UTC)

@wigy-opensource-developer I think this is what you are looking for https://github.com/ipfs/specs/tree/master/iprs-interplanetary-record-system

6

From @wigy-opensource-developer on Wed Oct 26 2016 14:05:58 GMT+0000 (UTC)

Wow, that was fast. Thanks!

7

Hi,

While I think that the generation count is enough to solve problems with replay attacks, it would be awsome if the IPNS entry also included a ā€˜prevā€™ link as well. That way you could see the whole history of the IPNS entry by following the dag down the ā€˜prevā€™ links. Will this ever be possible? I think that would make validation much stronger, and it would also be an interesting ā€œwayback machineā€ like feature in its own right.

ipns/entryabc -> ipfs/efg

ipfs/efg
content-hash:foo
generation: 5
prev: ipfs/hij

ipfs/hij
content-hash:bar
generation 4
prev: ipfs/klm

ipfs/klm
content-hash:baz
generation 3

ipfs/nop
content-hash:bar
generation 2
prev: ipfs/qrs

ipfs/qrs
content-hash:baf
generation 1
prev: nil