updated the note regarding libsignal and XEdDSA

This commit is contained in:
Tim Henkes 2020-03-26 15:16:37 +01:00
parent b66df869c7
commit de1d9465df
1 changed files with 1 additions and 1 deletions

View File

@ -240,7 +240,7 @@
</ol>
There are essentially two ways in which libraries can fulfill these requirements:
<ol>
<li>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 <strong>NOT</strong> follow the specification and does <strong>NOT</strong> produce EdDSA-compatible signatures. Other implementations following the specification must be used instead.</li>
<li>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 <strong>NOT</strong> use XEdDSA. libsignal <emph>includes</emph> XEdDSA though and has to be modified to use that to be compatible with OMEMO.</li>
<li>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.</li>
</ol>
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 <tt>Sig(PK, M)</tt> and <tt>DH(PK1, PK2)</tt> functions as defined below.</dd></di>