Is IPNS susceptible to replay attacks? #70
Comments
|
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. |
|
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 |
|
@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. |
|
@wigy-opensource-developer I think this is what you are looking for https://github.com/ipfs/specs/tree/master/iprs-interplanetary-record-system |
|
Wow, that was fast. Thanks! |
|
This issue has been moved to https://discuss.ipfs.io/t/is-ipns-susceptible-to-replay-attacks/456. |
se3000 commentedNov 4, 2015
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?
The text was updated successfully, but these errors were encountered: