[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Guix - GNUnet binary ditribution roadmap
Date: Fri, 14 Mar 2014 00:58:44 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

On 03/14/2014 12:08 AM, Ludovic Courtès wrote:
> Christian Grothoff <address@hidden> skribis:
>> Ludo, would you please consider moving to the GNU Name System?
> Guix uses the SPKI-like infrastructure for purposes unrelated to the
> project at hand (to sign/authenticate archives.)

Yes, so what? My point is that once you move to ECDSA/Curve25519
to sign/authenticate archives, you will have better crypto and
open the door for a potentially tight integration with GNS.

> However, it probably makes sense to rely more on GNS in whatever will be
> developed as part of this GSoC.
>> GNS is based on SDSI/SPKI (delegation certificates!), and has many
>> other advantages (not to mention uses Curve25519 instead of RSA).
>> GNUnet's identity management is based on Curve25519 ECDSA signatures,
>> and we are using libgcrypt for those.
> Guix uses libgcrypt too, essentially manipulating canonical sexps.  So
> it could be that integration would be fairly simple?

GNUnet doesn't use sexps in the wire format as it it both verbose and
not really the canonical way to represent Curve25519 points (for that,
there is a nice, compact 32-byte binary encoding).  But of course the
conversion is trivial and we do that in libgnunetutil in various

So sexps is really not the issue, the use of RSA vs. Curve25519 is
more what I am concerned about -- as that will increase the complexity
without good reason. (Yes, I can sign RSA keys with Curve25519 and
vice-versa, but that gives us the weaker of the two systems in terms
of security, and the implementation complexity would be higher than
just one of them on top of that.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]