From b66df869c7ee83d9245f2e5bfb777e4244864b39 Mon Sep 17 00:00:00 2001 From: Tim Henkes Date: Thu, 26 Mar 2020 10:59:18 +0100 Subject: [PATCH] added note about libsignal's XEdDSA implementation not following the spec --- xep-0384.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0384.xml b/xep-0384.xml index 60801576..7d54077e 100644 --- a/xep-0384.xml +++ b/xep-0384.xml @@ -240,7 +240,7 @@ There are essentially two ways in which libraries can fulfill these requirements:
    -
  1. Libraries can use a Curve25519 key pair as their internal IdentityKey. In this case, the IdentityKey can be used for X25519 directly, and XEdDSA has to be used to produce EdDSA-compatible signatures.
    2. +
  2. Libraries can use a Curve25519 key pair as their internal IdentityKey. In this case, the IdentityKey can be used for X25519 directly, and XEdDSA has to be used to produce EdDSA-compatible signatures. Note that the XEdDSA implementation included in libsignal does NOT follow the specification and does NOT produce EdDSA-compatible signatures. Other implementations following the specification must be used instead.
  3. Libraries can use an Ed25519 key pair as their internal IdentityKey. In this case, the IdentityKey can create EdDSA-compatible signatures directly, and has to be converted first to perform X25519.
Note that this decision is purely local to each client and OMEMO library. The public key is ALWAYS transferred in its Ed25519 form and only valid EdDSA signatures are transferred. The choice between Curve25519 and Ed25519 affects the definition of the Sig(PK, M) and DH(PK1, PK2) functions as defined below.