commit 6ea56b935a68fc71b1d4c12a1f9282c21c890646
parent c6a1302c8cd28c2778a58435453d88aab6ebf132
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 10 Jul 2024 15:22:33 +0200
move elligator discussions into security
Diffstat:
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/draft-gnunet-communicators.xml b/draft-gnunet-communicators.xml
@@ -296,24 +296,7 @@ Dec(REPR):
X := E * V - (1 - E)(A / 2)
return X
]]></artwork>
- <t>
- Note that both for a value REPR and its negative counterpart -REPR (in the finite field), the decoding function will result in the same
- x-coordinate. Moreover, for two different valid x-coordinates, the resulting representatives of the corresponding encoding calls are
- different. Conversely, this means that we can't decode both representatives back to their original x-coordinate. This is why the sender
- eventually makes multiple calls to ElligatorKeyCreate() in KeyGenElligator() in order to create a valid public key that can be used
- for a key exchange. Also note that this effectively reduces the entropy of our public keys by 1 bit, which is tolerable.
- </t>
- <t>
- In the original paper, Elligator's encoding function takes the sign of y-coordinate as an additional input parameter. Its value determines
- which of the two terms is used instead of our random selection. We also skip the calculation of the corresponding y-coordinate in the decoding function.
- We omitted the y-coordinate parts of both functions because Curve25519 points are solely represented by their x-coordinate in modern crypto systems due to
- known attacks. Nevertheless, the desired feature of Elligator is still ensured.
- </t>
- <t>
- Lastly, we emphasize that the resulting representative of the encoding function is strictly smaller than 2^254 - 9. Therefore, the most and second most
- significant bit are always zero, which is an obvious property an attacker could observe. We avoid this problem by randomly flipping
- both bits. These bits will be ignored by the target peer after reception.
- </t>
+
</section>
<section anchor="key_derivation" numbered="true" toc="default">
<name>Key Derivation</name>
@@ -1470,7 +1453,28 @@ SetupCipher(REC_ID, MSK):
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security and Privacy Considerations</name>
- </section>
+ <section anchor="security_elligator" numbered="true" toc="default">
+ <name>Elligator</name>
+ <t>
+ Note that both for a value REPR and its negative counterpart -REPR (in the finite field), the decoding function will result in the same
+ x-coordinate. Moreover, for two different valid x-coordinates, the resulting representatives of the corresponding encoding calls are
+ different. Conversely, this means that we can't decode both representatives back to their original x-coordinate. This is why the sender
+ eventually makes multiple calls to ElligatorKeyCreate() in KeyGenElligator() in order to create a valid public key that can be used
+ for a key exchange. Also note that this effectively reduces the entropy of our public keys by 1 bit, which is tolerable.
+ </t>
+ <t>
+ In the original paper, Elligator's encoding function takes the sign of y-coordinate as an additional input parameter. Its value determines
+ which of the two terms is used instead of our random selection. We also skip the calculation of the corresponding y-coordinate in the decoding function.
+ We omitted the y-coordinate parts of both functions because Curve25519 points are solely represented by their x-coordinate in modern crypto systems due to
+ known attacks. Nevertheless, the desired feature of Elligator is still ensured.
+ </t>
+ <t>
+ Lastly, we emphasize that the resulting representative of the encoding function is strictly smaller than 2^254 - 9. Therefore, the most and second most
+ significant bit are always zero, which is an obvious property an attacker could observe. We avoid this problem by randomly flipping
+ both bits. These bits will be ignored by the target peer after reception.
+ </t>
+ </section>
+ </section>
<section anchor="gana" numbered="true" toc="default">
<name>GANA Considerations</name>
</section>
