gnunet-handbook

commit 750c9059ef51891737ccb22bc71cb0ddd9b31161
parent 04872166c2fb01a8455c3629b844f74dad99a08a
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date:   Mon, 11 Mar 2024 13:23:57 +0100

update crypto plans

Diffstat:
M
developers/apis/cong.rst
 | 
11
+++++++----

1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/developers/apis/cong.rst b/developers/apis/cong.rst
@@ -28,13 +28,16 @@ Currently, we are using our own ECDHE key exchange that derives
 Each direction uses two 256-bit symmetric encryption keys derived through the ECDH exchange.
 Each payload is encrypted using AES(kA, Twofish(kB, payload)) both in CFB mode (!).
 
-For CONG, we should double-check the security of your ECDHE construction and then
-potentially move away from AES/Twofish, possible towards ChaCha20 or XSalsa20 (Needs discussion).
+For CONG, we should double-check the security of your ECDHE construction.
+We decided on 11/03/2024 to investigate XChaCha20-Poly1305:
 
 Proposal:
 
-  * Use X25519 for the KX with our Ed25519 keys: https://doc.libsodium.org/advanced/ed25519-curve25519
-  * Use XSalsa20 and kTx,kRx := KDF(X25519(),senderPK,receiverPK) for symmetric encryption
+  * Use X25519 for the KX with ephemeral Curve25519 keys.
+  * Use XChaCha20-Poly1305 and kTx,kRx := KDF(X25519(),senderPK,receiverPK) for symmetric encryption
+
+We will have to replace the use of ``GNUNET_CRYPTO_symmetric_encrypt`` and
+HMAC use in ``gnunet-service-core_kx.c`` including the respective keys and IVs.
 
 .. _Peer-IDs: