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

Reply via email to