3 ms·

How would you solve access permissions in DHT? What if a node in DHT holds data that it is not granted to read? This would imply encryption of the data to preve

by mr__y 7y ago

How would you solve access permissions in DHT? What if a node in DHT holds data that it is not granted to read? This would imply encryption of the data to prevent unauthorized reads - this does not really seem as a complicated problem - the data could be encrypted with only the nodes granted the read access having the decryption key(s). What seems harder to me is write permissions - if the data is encrypted/signed, only those nodes that have been granted permissions (and thus have copies of keys) would be able to overwrite/change that data. So the node that holds the data would not be able to overwrite it if it does not have r/w access to that piece of data. Nothing prevents from removing this data though. (I'm assuming the possibility of some nodes being malicious)

nybble41 7y ago
> What seems harder to me is write permissions The usual solution for this is that the data must be signed by a specific private key; possession of that key grants write permission. A generation count or timestamp is embedded in the signed data to ensure that newer data cannot be replaced with obsolete data. Malicious nodes can still block updates from being distributed, though, so you need more than one path to seed the data into the network.
zackmorris 7y ago
I'm not sure for DHT. But in Firebase the permissions are handled as user access rules written in Javascript, returning boolean true or false if the user has the ability to read/write the node and if the data being written passes a validation check: https://firebase.google.com/docs/rules https://firebase.google.com/docs/rules https://firebase.google.com/docs/rules/rules-language https://firebase.google.com/docs/rules/rules-language So Firebase permissions really have more to do with the identity layer than keeping the data secret. I think that probably everything should be encrypted anyway. This was a largely solved problem even in the 90s, and embedded devices are about as powerful as the 386 and 68030 computers popular then. We really need a distributed SSL identity layer though. Something like letsencrypt.org except the client's identity would come from the social proof of its peers instead of a central organization. Maybe this is already a solved problem in OpenSSL? I only understand symmetric key encryption, but not the man in the middle protections that SSL certificates provide. To me, p2p identity and encryption should have been a foundational pillar of the internet, not some controversial afterthought like we think of it today.

by mr__y 7y ago

nybble41 7y ago

> What seems harder to me is write permissions The usual solution for this is that the data must be signed by a specific private key; possession of that key grants write permission. A generation count or timestamp is embedded in the signed data to ensure that newer data cannot be replaced with obsolete data. Malicious nodes can still block updates from being distributed, though, so you need more than one path to seed the data into the network.

zackmorris 7y ago

I'm not sure for DHT. But in Firebase the permissions are handled as user access rules written in Javascript, returning boolean true or false if the user has the ability to read/write the node and if the data being written passes a validation check: https://firebase.google.com/docs/rules https://firebase.google.com/docs/rules https://firebase.google.com/docs/rules/rules-language https://firebase.google.com/docs/rules/rules-language So Firebase permissions really have more to do with the identity layer than keeping the data secret. I think that probably everything should be encrypted anyway. This was a largely solved problem even in the 90s, and embedded devices are about as powerful as the 386 and 68030 computers popular then. We really need a distributed SSL identity layer though. Something like letsencrypt.org except the client's identity would come from the social proof of its peers instead of a central organization. Maybe this is already a solved problem in OpenSSL? I only understand symmetric key encryption, but not the man in the middle protections that SSL certificates provide. To me, p2p identity and encryption should have been a foundational pillar of the internet, not some controversial afterthought like we think of it today.