Hi,
reading a recent paper (https://eprint.iacr.org/2023/305) I wonder if
this has any impact on GNUnet - especially GNS, which uses ECDSA
signatures for PKEY-signed payloads. Do we need to phase out PKEYs and
replace them with EDKEYs in the future?
Cheers, Bernd.
Dear GNUnet community,
after a security audit for the new Go implementation of the R5N-DHT by
"Radically Open Security", I have incorporated the changes based on the
findings in the report. The new version is tagged "v0.1.40".
No flaws in the cryptographic handling (path signatures) have
Dear GNUnet community,
although not part of the NLnet project "GNS", I have completed a GUI for
the ZoneMaster implementation in Golang.
(https://git.gnunet.org/gnunet-go.git, tag v0.1.39))
The zonemaster-go unifies the Namestore, Identity and Zonemaster
services into a single application
Dear GNUnet community,
I am happy to announce the completion of milestones 4 (GNS Zonemaster)
for the "Go implementation of GNS" which is a NLnet-funded project
"GNS (2019-02-022)".
The source code is written for Go1.18+; it can be found in the GNUnet
Repository at
Dear GNUnet community,
I am happy to announce the completion of milestones 4 (integration
tests) for the "Go implementation of the R5N DHT" which is a
NLnet-funded project "R5N (2021-02-038)".
The source code is written for Go1.18+ (it makes use of generics in some
places); it can be found
On 8/18/22 13:20, Maxime Devos wrote:
Looking at the README.md, do I understand correctly that gnunet-go
listens at the usual /tmp/gnunet-system-runtime/... and that as such
applications written with the C implementation of the services in
mind can connect to the Go implementation? If so,
A new version (v0.1.32) of gnunet-go is availble at
https://git.gnunet.org/gnunet-go.git that should be ready for
integration tests. Some major and minor bugs have been fixed that have
escaped attention before. A lot of code refactoring happened too...
The new README includes a new section on
Dear GNUnet community,
I am happy to announce the completion of milestones 2 and 3 for the "Go
implementation of the R5N DHT" which is a NLnet-funded project "R5N
(2021-02-038)".
The source code is written for Go1.18+ (it makes use of generics in some
places); it can be found in the GNUnet
Dear GNUnet community,
the Go implementation for the second Milestone is nearing completion;
nearly all points for "2. Core data structures and processes" are
implemented.
The implementation follows the specification (lsd0004) as closely as
possible (the spec itself is work-in-progress),
Dear GNUnet community,
I am happy to announce the completion of the first milestone of the "Go
implementation of the R5N DHT" for the NLnet-funded project "R5N
(2021-02-038)". The implementation is not based on the current GNUnet
DHT/Transport protocol, but on a new protocol defined in
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
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
net e.V. and the GNU maintainers. Various members of the association
will work on different work packages; Bernd Fix will act as project lead
for the whole project. Various contributors are expected to assist with
the writing of the specification, improving the GNUnet C reference
implementation an
> (3) Install required dependencies:
> --
>
> $ go get -u golang.org/x/crypto/...
> $ go get -u golang.org/x/text/...
> $ go get -u github.com/bfix/gospel/...
> $ go get -u github.com/miekg/dns/...
Additional dependencies are used in Milestone #3:
go get -u
=
GNUnet-Go: Status report for Milestone #3
=
I am happy to announce the completion of the 3rd milestone for the
GNUnet-Go project. The objective was to implement the revocation service.
N.B.: This release is using
On 1/2/20 12:07 PM, Bernd Fix wrote:
> =
> GNUnet-Go: Status report for Milestone #2
> =
I just noticed that the link to the GNUnet-Go repository is missing (as
in my announcement for Milestone #1 in Septe
=
GNUnet-Go: Status report for Milestone #2
=
I am happy to announce the completion of the 2nd milestone for the
GNUnet-Go project. The objective was to implement recursive resolution
of GNS names and to handle
On 9/20/19 11:31 AM, Bernd Fix wrote:
> It was correctly noted that using Ctrl-C to interrupt the running
> service (if started as a foreground process) does not work in all cases.
> This is due to the intrinsics of the Go runtime (see
> https://github.com/golang/go/
Thanks to everyone for giving me feedback on this list or by private
email; your comments and suggestions are very much appreciated.
I have updated the repository for gnunet-go with the following changes:
* fixed busy loop in service implementation; CPU usage is now down to
nothing while running
On 9/19/19 5:23 PM, Christian Grothoff wrote:
>> (2) Install Go1.13 on you computer:
>> ---
>> Either install a binary version at https://golang.org/dl/ or compile
>> from sources after cloning the Git repository
>> https://github.com/golang/go. Make sure the
On 9/18/19 11:53 PM, Devan Carpenter wrote:
> Thank you for all the work you've put into this. This is really
> impressive to see, and I believe it's an important milestone not only
> for the Go implementation, but for the whole GNUnet project as well.
Thank you for your kind words, but where you
On 9/18/19 9:51 PM, N wrote:> great to read about the progress!
>
> As a NetBSD developer I'm curious: are there any code parts on your
> side which are Linux Go specific? I have some to solve on the gnunet
> side, so if at a later stage you might require help or testing on
> more platforms..
The
I forgot to mention that the gnunet-go repository may change frequently;
less frequently dependencies can change too. Make sure you pull and "go
get" from time to time to keep up to date...>Y<
___
GNUnet-developers mailing list
=
GNUnet-Go: Status report for Milestone #1
=
I am happy to announce the completion of the first milestone for the
GNUnet-Go project. The objective was to implement a simple
GNUnet-compatible GNS service in Go that
On 9/16/19 6:02 PM, Christian Grothoff wrote:
> It is not intended, but AFAIK also has no security implications.
> Nevertheless, we should probably plan to fix the swap when we next break
> compatibility.
Maybe not swapping, but adding a salt (as 2nd arg to hkdf) - that would
be in line to the
After running more and longer tests I noticed that about every 16th
ECDHE key exchanged failed (shared secret mimatch). The investigation
lead to a problem in the copied and re-used package source from
golang.org/x/crypto/ed25519. The interal scalar multiplication for a
point returns the wrong
Because my trip to Switzerland had to be cancelled at the last minute, I
will not be able to join you all at the GNUnet Hacker Meeting in
St.Imier - so no holiday for me this year.
Would it be possible for me to join you on Monday for the GNS sessions
via Jitsi or any other suitable teleconf
On 6/1/19 6:06 PM, Christian Grothoff wrote:
> Tuesday:
> * Focus: GNS
> - Ascension (rexxnor, presentation @ 11am)
> - GNS-Go project (Bernd, Schanzen)
> - GNUnet packaging for distros (all)
Is it possible to move this GNS day to Monday? It is more than likely
now that I have to be in
On 07/13/2018 04:50 PM, Christian Grothoff wrote:
> On 07/13/2018 06:39 PM, Bernd Fix wrote:
>> This constraint of course make things trickier, because that means we
>> are stuck in using Ed25519 for ECDHE. A possible solution (again: not
>> for GNUnet itself, but for impl
I think that most problems mentioned in my previous post originate in
the '#define CURVE "Ed25519"' statement at curve_ecc.c:37. All key
parameter definitions (EdDSA, ECDSA and ECDHE) use that value leading to
the described problems. I think that the curve key parameter needs to be
set
Devan Carpenter wrote:
> Thanks for the discovery and analysis of this, Bernd.
>
> I wonder if this would be feasible to try to make into the 0.11.0 release..?
>
> Bernd Fix transcribed 1.1K bytes:
>> The EdDSA signature implementation in GNUnet calls the 'gcry_pk_sig
The EdDSA signature implementation in GNUnet calls the 'gcry_pk_sign
(, msg, prv)' function not with the message itself, but with the
SHA512 hash value of the message.
Due to the intricities of EdDSA signing this is not necessary (hashing
is done in the sign function itself, as more than just the
In ./src/include/gnunet_signature.h (lines 146-169) the following
constants are defined:
> /**
> * Signature of a conversation ring.
> */
> #define GNUNET_SIGNATURE_PURPOSE_CONVERSATION_RING 20
>
> /**
> * Signature for the first round of distributed key generation.
> */
> #define
33 matches
Mail list logo
