[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] Reconciling algorithm
From: |
Daniel Kahn Gillmor |
Subject: |
Re: [Sks-devel] Reconciling algorithm |
Date: |
Wed, 28 Apr 2010 22:16:33 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100411 Icedove/3.0.4 |
On 04/28/2010 06:29 PM, Jesus Cea wrote:
> This is not good. An undocumented *key* feature, written in a obscure
> programming language :).
>
> I know it is not very appropiate to post this in this mailing list but...
>
> I was wondering if there is any kind of demand of an alternative OpenPGP
> keyserver, with a different but documented syncronization technology,
> like Merkle trees. Implemented in Python.
There are already several alternative OpenPGP keyservers with different
(but documented) synchronization tech. In particular, all the systems
that sync'ed via e-mail (onak, pks, openpksd, etc. i'm sure someone
else has a better list than me).
They have been superseded by SKS, mainly because of the more effective
synchronization.
The algorithm *is* documented, but it's academic/mathematical
documentation, not bits-on-the-wire documentation. See the two papers
linked from the site here:
http://minskyprimus.net/sks/
I don't think a new synchronization technique is what we need; i *do*
think that an alternate implementation that interoperates with sks would
be a great thing, and i imagine would be a good way to really nail down
what's happening practically in the actual set reconciliation.
> I apology for the off-topic and the attack to sks :(.
I don't think it's an attack, or certainly not an off-base attack --
it's an acknowledgment of a real weakness, and SKS would itself be
better if it was resolved. Thanks for bringing it up.
--dkg
PS i don't read/write ocaml either, and i don't have the available
cycles to write such an alternate implementation myself. I'm just
saying that i think it's a good idea.
signature.asc
Description: OpenPGP digital signature