The last thing is about data protection - I am pretty sure the data in the reconciliation process is not encrypted (which would be useless for public data) but may also be required for data exchanges by GDPR - the same goes for retrieval over https (which is tbh not really supported)
I don’t remember whether sks uses a single-stage or two-stage process for reconciliation … in a single-stage
process, data is directly encoded as evaluations of a rational function, so only another peer with similar
data will be able to decode it.
In a two-stage process, the initial phase is done on hashes, and a second stage transfers the data corresponding
to differing hashes. It should be possible for the second stage can be sent over an encrypted tunnel without
too much effort.
best,
-Ari
Sent from my iPhone
Am 29.04.2018 um 17:08 schrieb robots.txt fan <address@hidden>:
Moritz Wirth wrote:
Given the fact that it is not possible to delete data from a keyserver
Of course this is possible. You can delete key by using the "sks drop <hash>" command. Now, if I understand it correctly the key will immediately be re-added because of gossiping keyservers. However, it would not be impossible to extend SKS to have a keyserver reject keys from a blacklist that each server admin would maintain, or possibly gossip. (If this does not exist already.)
I imagine this would be a useful instrument for more use-cases than this one. I imagine a server admin based in Germany would get in trouble if someone submitted a key with the user-id "The owner of this server denies the Holocaust", an action that is illegal in Germany. The server admin could get out of the trouble by adding the hash of that key to the blacklist.
I know I am suggesting censorship but it's not like SKS was ever meant to be a secure or reliable channel.
_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel
_______________________________________________
Sks-devel mailing list
address@hiddenhttps://lists.nongnu.org/mailman/listinfo/sks-devel
signature.asc