Re: Cryptography of GNU Name System

[Christian Grothoff]

Dear Soatok,

Thank you for reading our draft. As you are probably aware, one of the
goal of such a draft is to solicit feedback on the design to improve the
result, and we appreciate qualified constructive criticism, in
particular if it is brought to us in the spirit of improving the project.

I partially agree with your point on IND-CCA, alas fixing it is not as
simple as you may think: we want to ensure that the encryption is
deterministic to assist the DHT with caching of blocks. That said, this
additional constraint is not properly spelled out in the draft yet,
which is another shortcoming we need to address. Furthermore, while we
have had some internal discussions on how to possibly improve the
situation with respect to IND-CCA, it will take more time for us to
actually implement and document these.

That said, I would firmly reject your main point. We should not use a
NIST curve, as NIST is known to produce NSA-backdoored cryptographic
standards. ECDSA should work in principle with any 'safe' curve, both
our implementation of ECDSA and the curve of our choice are pretty
standard, and thus mathematically speaking the combination should also
be safe. Also, I asked Dan Bernstein and Tanja Lange in 2013 (!) if it
was safe to use Curve25519 with ECDSA, and they said it was, while
making several constructive suggestions for improving the first GNS
design. I believe they know better than random Internet trolls.

An argument can be made for using a completely *non-standard* *variant*
of EdDSA which should improve performance and may enable additional
code-reuse within GNUnet, alas one can argue that this would be less
canonical than what we do today. We are considering to write this up as
a second cryptographic instantiation as part of demonstrating how to
realize cipher agility within the GNU Name System. However, there is
still at least one problem in the spec with respect to cipher agility
which we need to address first.


Finally, I would remind you that all GNU package that I know are open to
constructive feedback and welcome *friendly* contributors. If GNU
packages do not accept contributions, it usually implies that the person
who discovered the issue was not able to convince the maintainers that
the issue is real. This is often because they fail to appreciate crucial
aspects (like GnuPG implementing the OpenPGP standard and having to
provide backwards-compatibility).

I do not know if you have actually tried to convince GNU packages to fix
specific issues before, but you may want to reconsider how you approach
GNU developers if you actually intend to help.


Happy hacking!

Christian

On 7/14/20 6:02 AM, Soatok Dreamseeker wrote:
> Please
> read: https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-cryptography 
> <https://soatok.blog/2020/07/08/gnu-a-heuristic-for-bad-cryptography/>
> 
> Kind regards,
> S. Dreamseeker

0x939E6BE1E29FC3CC.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature