On Sun, 29 Apr 2018, 19:04 Ari Trachtenberg, <trach...@bu.edu> wrote:
> > On Apr 29, 2018, at 12:20 PM, Moritz Wirth <m...@flanga.io> wrote: > > > 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. > And then the data is requested over HTTP unencrypted by the pgp-client or web interface > best, > -Ari > > > Sent from my iPhone > > Am 29.04.2018 um 17:08 schrieb robots.txt fan <robotsdot...@protonmail.com > >: > > 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 > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > > > > _______________________________________________ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > > > --- > Prof. Ari Trachtenberg ECE, Boston University > trach...@bu.edu http://people.bu.edu/trachten > > _______________________________________________ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel >
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel