Re: [Sks-devel] withdrawal of service: sks.spodhuis.org

[Human at FlowCrypt]

One more apology - there does seem to be recent activity when you look at the repo owner: https://github.com/hockeypuck

Though not loads of activity, still more code contributions than the SKS repo: https://bitbucket.org/skskeyserver/sks-keyserver/commits/all

It may be worth considering.

On Sat, Jul 14, 2018 at 12:19 PM, Human at FlowCrypt <address@hidden> wrote:

Sorry, I hadn't noticed that you linked specifically the conflux (reconciliation code). That is indeed a good start if someone wanted to take the time to understand it. 

On Sat, Jul 14, 2018, 20:16 Human at FlowCrypt <address@hidden> wrote:

Hockeypuck has not had any commits in years, if I saw correctly. 

It cannot process some of the keys (maybe for a good reason, but it will clog the recon mechanism nevertheless, I suppose). 

I think it was a great effort, but apparently not maintained. 

If the recon process could be updated with mechanism where some implementations could seamlessly choose not to import certain keys, I think hockeypuck would be a great alternative. It may need to be forked. 

On Sat, Jul 14, 2018, 19:33 Moritz Wirth <address@hidden> wrote:

Though I am not sure, https://github.com/hockeypuck/conflux may be worth a look.

If somebody has a short How-To for installing hockeypuck (and importing a keydump..), I am happy to test if it is more stable than sks :)

Best regards,

Moritz

Am 14.07.18 um 02:50 schrieb Tom at FlowCrypt:

I would have loved to write an alternative SKS implementation that addresses the issues we were seeing recently. However, this:

• Set Reconciliation with Nearly Optimal Communication Complexity
• Practical Set Reconciliation

is preventing me from doing so. I'm a software engineer, not a mathematician, and I have little willingness to attempt implementing an algorithm nobody understands.

I wish the title said "simple" and "resilient" rather than "with nearly optimal communication complexity", and the contents matched the title. 

The pool of engineers willing and able to get us out of this mess would be much larger.

On Fri, Jul 13, 2018 at 11:23 PM, Andrew Gallagher <address@hidden> wrote:

> On 13 Jul 2018, at 22:43, Moritz Wirth <address@hidden> wrote:
>
> FWIW, has anybody even started working on a fix for any of the bugs?

There has been a fair bit of discussion, but no consensus has been reached, apart from a general agreement that major changes to the recon model will be required, and that these will be necessarily backwards-incompatible. That’s generally where the discussion dries up.

I get the impression that everyone is holding fire until there is some sign that one particular form of breakage will be more broadly acceptable than the others.

A

_______________________________________________
Sks-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/sks-devel