commit 01a47046b606bcdf743d749ba34ceb758015dafa
parent 1d37b7d6163364d1688dfc4cf01507cb16b297a7
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Mon, 4 Aug 2025 13:34:40 +0200
update notes
Diffstat:
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/draft-schanzen-cake.xml b/draft-schanzen-cake.xml
@@ -687,25 +687,27 @@ sn_enc = mask[0..8] XOR sn_nbo
<name>Open Issues</name>
<t>
We must discuss EdDSA vs X25519 KEM usage. Maybe see Communicator draft for this.
+ Basically, since we also use the EdDSA peer ID key for signing (HELLOs), we offer
+ any attacker a signing oracle against our X25519 public keys.
+ This should be safe, but it is not clean.
+ To solve this, we would have to separate HELLO signing keys and PID KX keys.
+ This issue did not arise before, because we used signed semi-statix DH keys.
</t>
<t>
- We must discuss ChaCha20 vs XChaCha20.
- For XChaCha20 we can use fresh nonces when the key is re-used.
- With ChaCha20, we should increment the nonce.
- We could probably increment both. Incrementing may allow us to derive a starting nonce from
- the key schedule.
- We can get away with ChaCha20 (TLS, IETF) and its 32-bit internal counter because our
- messages are <= 2<sup>16</sup>-1 bytes and the counter cannot overflow.
- But, XChaCha20 is the generally recommended cipher for any use case by the libsodium author as well.
- The only downside seems to be that XChaCha20 is practically not specified anywhere (although it can be trivially defined in this document based on HChaCha) and only really implemented in libsodium.
- </t>
- <t>
- We must define which hash function is to be used for H. It should probably have 512 bit output.
- Candidates are Blake2b (Fast), SHA512 (safe).
+ The IETF ChaCha20 version is basically only recommended for use when a specification
+ or compatibility specifically requires it.
+ With ChaCha20, we would have to increment the nonce as it cannot be chosen securely at random
+ (not long enough).
+ XChaCha20 is the generally recommended cipher for any use case and we use it.
+ The only downside seems to be that XChaCha20 is practically not specified anywhere
+ (although it can be trivially defined in this document based on HChaCha) and only really implemented in libsodium.
</t>
<t>
We must define which KEM is to be used.
We may want to use our HPKE Elligator KEM <xref target="LSD0011"/>.
+ Using Elligator on this level may not be useful unless we also get rid of the plaintext message headers since
+ those definitely do not look random.
+ Ergo, the use of elligator probably makes more sense on the communicator level.
</t>
<t>
The Initiator/Responder selection logic may require a timed fallback: The designates Initiator may never initiate (NAT, already has sufficient connections, learns about responder later than responder about initiator etc.).
@@ -735,8 +737,8 @@ sn_enc = mask[0..8] XOR sn_nbo
Open tasks include:
</t>
<ol>
- <li>Explain how XChaCha20 works (see libsodium)</li>
- <li>Rekeying</li>
+ <li>Requesting key updates</li>
+ <li>Use KDF/Hash Function, SHA2 vs Blake2b</li>
<li>Services info transmission (currently empty/unused)</li>
<li>Integrate and test PILS PID changes (potentially requires in-band signalling of new PIDs in CORE, not really that much related to CAKE)</li>
</ol>
