From de1d9465dffc2c58b00e88e9b5aef58a8209b9c0 Mon Sep 17 00:00:00 2001 From: Tim Henkes Date: Thu, 26 Mar 2020 15:16:37 +0100 Subject: [PATCH] updated the note regarding libsignal and XEdDSA --- xep-0384.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0384.xml b/xep-0384.xml index 7d54077e..1e70b8c5 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. 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.
    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 libsignal by default does NOT use XEdDSA. libsignal includes XEdDSA though and has to be modified to use that to be compatible with OMEMO.
  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.