> On 19 Jul 2020, at 19:10, Bernd Fix wrote:
>> There is one argument for making Tor’s solution part of semi-standard
>> libraries implementing Ed25519, which goes: If abused in foreseeable
>> ways, then BIP32-Ed25519 becomes, but cryptocurrency applications are
>> going to do HDKD
First of all: thanks for all the input. Happy for any constructive feedback.
The way I see it especially from what Jeff said is that (at least for the spec)
it is very important that it is more agile with respect to the crypto.
Just like grothoff said.
If there is no formal or informal consensus
Hi there,
FYI, regarding the status of the Debian package:
* Gnunet 0.13.1 has been packaged and is already on Debian unstable:
https://tracker.debian.org/pkg/gnunet
* The current maintainer is seeking for another maintainer to take
over: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964314
On 7/19/20 4:19 PM, Jeff Burdges wrote:
>
>
>> On 19 Jul 2020, at 14:08, Bernd Fix wrote:
>> Compared to the current GNS implementation this all boils down to
>> replacing ECDSA with a non-standard EdDSA - is it worth the
>> trouble?
>
> It depends on how niche ECDSA on Ed25519 is. It’s
> On 19 Jul 2020, at 14:08, Bernd Fix wrote:
> Compared to the current GNS implementation this all boils down to
> replacing ECDSA with a non-standard EdDSA - is it worth the trouble?
It depends on how niche ECDSA on Ed25519 is. It’s clearly more work to ship an
Ed25519 if your library
On 7/18/20 1:36 PM, Jeff Burdges wrote:
> I do think GNS should ideally switch to Tor’s HDKD solution using
> Ed25519 instead of doing ECDSA over Ed25519 of course.
The signature computation as described in the Tor document is slightly
*different* from the EdDSA standard. EdDSA signing requires
