DHT Records: signatures

[jbenet]

Currently, DHT provider records are not signed, meaning anyone can sign someone else up for providing an object. That shouldn't happen: dht provide records must be signed, and only used if sig verify succeeds.

The {Get/Put}Value records we use (IPNS) already have their own notion of validity.

[whyrusleeping]

I dont know how i feel about this. I agree its needed for the security aspect, but signing every single provider would get really expensive. And we are already worried about CPU consumption. Id say leave this issue open, but not worry about it for a little while.

[btc]

I was curious about the cost of Sign/Verify. If I made a mistake with the computation, let me know.

2406924 ns/op is 2.4 ms/op

BenchmarkSign1B             1000           2406924 ns/op
BenchmarkSign10B            1000           2360527 ns/op
BenchmarkSign100B           1000           2354136 ns/op
BenchmarkSign1000B           500           2361775 ns/op
BenchmarkSign10000B          500           2415993 ns/op
BenchmarkSign100000B         500           2718051 ns/op
BenchmarkVerify1B          30000             52117 ns/op
BenchmarkVerify10B         30000             50968 ns/op
BenchmarkVerify100B        30000             51037 ns/op
BenchmarkVerify1000B       30000             56768 ns/op
BenchmarkVerify10000B      10000            105744 ns/op
BenchmarkVerify100000B      2000            628530 ns/op

see #528

[whyrusleeping]

hrm... i wonder how 2.4 ms will impact the time it takes to add a larger file

[btc]

hrm... i wonder how 2.4 ms will impact the time it takes to add a larger file

At steady state, with an average block size of 256KB, the 2.4ms operation caps sustained throughput at 102 MB/s. (Burst rate not affected)

[whyrusleeping]

okay, 102MB/s isnt terrible for now. We will have to look for different solutions in the future (should be fairly easy to parallelize)

[daviddias]

This is now included on the Record Spec https://github.com/ipfs/specs/tree/master/records

[Kubuxu]

I don't think it should be closed as it concerns whole DHT not only IPNS/RS.
See ipfs/specs#73

About the issue: I don't know if it feasible with RSA, keys and signatures are big and slow.
Using ed25519+curve25519 (ed for signing and curve for encryption) would give much better size and performance

[Winterhuman]

@whyrusleeping @daviddias This issue is closed, but, peer records and provider records don't seem to be signed; libp2p/go-libp2p-kad-dht#558 and libp2p/go-libp2p-kad-dht#559 are still open. Should this issue be reopened or has this been superseded by another issue?

[Winterhuman]

@Kubuxu Could this issue be reopened?

[Jorropo]

@Winterhuman we have other issues describing the problems, they are linked to this one. It doesn't need to be reoppened