|
|
|
|
@ -67,32 +67,35 @@ Messaging Algorithm Names
|
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Messaging algorithm names use the extensible naming scheme used throughout this
|
|
|
|
|
specification. Algorithm names that start with "m." are reserved for algorithms
|
|
|
|
|
specification. Algorithm names that start with `m.` are reserved for algorithms
|
|
|
|
|
defined by this specification. Implementations wanting to experiment with new
|
|
|
|
|
algorithms are encouraged to pick algorithm names that start with their
|
|
|
|
|
domain to reduce the risk of collisions.
|
|
|
|
|
|
|
|
|
|
The name "m.olm.v1.curve25519-aes-sha2" corresponds to version 1 of the Olm
|
|
|
|
|
Algorithm names should be short and meaningful, and should list the primitives
|
|
|
|
|
used by the algorithm so that it is easier to see if the algorithm is using a
|
|
|
|
|
broken primitive.
|
|
|
|
|
|
|
|
|
|
The name `m.olm.v1.curve25519-aes-sha2` corresponds to version 1 of the Olm
|
|
|
|
|
ratchet using Curve25519 for the initial key agreement, HKDF-SHA-256 for
|
|
|
|
|
ratchet key derivation, Curve25519 for the DH ratchet, HMAC-SHA-256 for the
|
|
|
|
|
hash ratchet, and HKDF-SHA-256, AES-256 in CBC mode, and 8 byte truncated
|
|
|
|
|
HMAC-SHA-256 for authenticated encryption.
|
|
|
|
|
|
|
|
|
|
Algorithm names should be short and meaningful. A name of "m.olm.v1" is too
|
|
|
|
|
short. However a name of
|
|
|
|
|
"m.olm.v1.ecdh-curve25519-hdkfsha256.hmacsha256.hkdfsha256-aes256-cbc-hmac64sha256"
|
|
|
|
|
is too long despite giving a more precise description of the algorithm.
|
|
|
|
|
|
|
|
|
|
Algorithm names should list the primitives used by the algorithm so that it
|
|
|
|
|
easier to see if the algorithm is using a broken primitive.
|
|
|
|
|
A name of `m.olm.v1` is too short: it gives no information about the primitives
|
|
|
|
|
in use, and is difficult to extend for different primitives. However a name of
|
|
|
|
|
`m.olm.v1.ecdh-curve25519-hdkfsha256.hmacsha256.hkdfsha256-aes256-cbc-hmac64sha256`
|
|
|
|
|
is too long despite giving a more precise description of the algorithm: it adds
|
|
|
|
|
to the data transfer overhead and sacrifices clarity for human readers without
|
|
|
|
|
adding any useful extra information.
|
|
|
|
|
|
|
|
|
|
Key Algorithms
|
|
|
|
|
~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
The name "ed25519" corresponds to the Ed25519 signature algorithm. The key is
|
|
|
|
|
The name `ed25519` corresponds to the Ed25519 signature algorithm. The key is
|
|
|
|
|
a Base64 encoded 32-byte Ed25519 public key.
|
|
|
|
|
|
|
|
|
|
The name "curve25519" corresponds to the Curve25519 ECDH algorithm. The key is
|
|
|
|
|
The name `curve25519` corresponds to the Curve25519 ECDH algorithm. The key is
|
|
|
|
|
a Base64 encoded 32-byte Curve25519 public key.
|
|
|
|
|
|
|
|
|
|
Client Behaviour
|
|
|
|
|
@ -149,7 +152,7 @@ Downloading Keys
|
|
|
|
|
~~~~~~~~~~~~~~~~
|
|
|
|
|
|
|
|
|
|
Keys are downloaded as a collection of signed JSON objects. There
|
|
|
|
|
will be a JSON object per device per user. If one of the user's
|
|
|
|
|
will be one JSON object per device per user. If one of the user's
|
|
|
|
|
devices doesn't support end-to-end encryption then their
|
|
|
|
|
homeserver must synthesise a JSON object without any device keys
|
|
|
|
|
for that device.
|
|
|
|
|
|
Richard van der Hoff
9 years ago