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
