MSC3903: X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients #3903

hughns · 2022-10-04T17:20:43Z

Clients:

…e channel between two Matrix clients

turt2live · 2022-10-04T17:34:34Z

proposals/3903-x25519-ecdhe.md

+This proposal introduces yet another key that Matrix client implementations need awareness of. It's also not clear to me
+where exactly this would fit in the spec documents.
+
+## Alternatives


it sounds like this is duplicating Olm sessions over to-device? Early on in this proposal there should be something to address that.

Yes, acknowledged.

Well, no. It's actually that you could achieve this with to-device messaging instead.

MSC3886 vs to-device messaging is one thing, and I appreciate you creating a comparison of the two. But I think we still need a comparison between this and Olm. I think a natural question is why can't we just do Olm over MSC3886?

I concur that the feasibility of Olm over MSC3886 should be assessed.

proposals/3903-x25519-ecdhe.md

notramo

This is horrible UX.

notramo · 2022-10-19T10:49:37Z

proposals/3903-x25519-ecdhe.md

+
+This means that for AES-GCM implementations that require the authentication tag to be explicitly processed (e.g. CryptoKit on iOS) that it can be sourced from the last 16 bytes of the base64-decoded `ciphertext`.
+
+**7.** The user should confirm that the established channel is secure by means of a checksum derived from the shared key.


This is CRAPPY, HORRIBLE UX! WHY? Why another visual comparison, another “I don't get what should I do now.” moment for users? Matrix already has too much visual comparison in its UX.

You already have a secure channel by means of QR code. Utilize it well, so users don't have to compare checksums.

The QR code is only secure in the sense that you can be sure that its contents were generated by the device that you're trying to communicate with. But it is not secret, as it is sometimes possible that someone else can scan the QR code as well. So unless you have another step (in this case, a visual comparison) to verify that the other public key was transmitted correctly, you cannot be sure that the channel is secure.

proposals/3903-x25519-ecdhe.md

turt2live · 2023-03-07T04:34:49Z

Like in #3886 (comment) , the author believes this is ready for FCP. The MSC appears to have conflicts with toDevice messaging though, so to get a slightly different review tone I'm putting this in technical review needed.

This doesn't mean the MSC isn't ready for FCP, just that the review given should be more useful to handle.

@matrix-org/spec-core-team please review this for technical design.

hughns · 2023-03-15T21:50:28Z

There has been more engagement in the topic of to-device messaging in #3886 so I have consolidated the notes and discussion onto that proposal so that they can be worked through more easily.

uhoreg · 2023-04-25T21:51:29Z

proposals/3903-x25519-ecdhe.md

+displayed on both devices for the user to visually verify.
+
+The checksum should be derived in a similar manner to step **4** above, however
+only 40 bit should be derived this time. The salt and info are the same as before.


The info should be different, otherwise the checksum will leak bits of the encryption key. You can prepend the info with checksum|.

Yep. As it stands, this looks like a gaping hole.

uhoreg · 2023-04-25T21:51:44Z

proposals/3903-x25519-ecdhe.md

+**1b.** The initiator derives the public key from `privateA` as
+`publicA = scalarMult(privateA, 9)`
+
+**1c.** The initiator shares it's key with the recipient via a trusted medium


Suggested change

**1c.** The initiator shares it's key with the recipient via a trusted medium

**1c.** The initiator shares its key with the recipient via a trusted medium

uhoreg · 2023-04-25T22:11:15Z

proposals/3903-x25519-ecdhe.md

+This proposal introduces yet another key that Matrix client implementations need awareness of. It's also not clear to me
+where exactly this would fit in the spec documents.
+
+## Alternatives


MSC3886 vs to-device messaging is one thing, and I appreciate you creating a comparison of the two. But I think we still need a comparison between this and Olm. I think a natural question is why can't we just do Olm over MSC3886?

uhoreg · 2023-04-25T22:40:44Z

proposals/3903-x25519-ecdhe.md

+## Security considerations
+
+Algorithm selection and implementation are crucial.
+


I don't think that this protects against replay attacks. That might be OK if the thing built on top of it can detect if a message is replayed (e.g. if messages have a definite order, so a replayed message would be flagged as being out of place), but I think it should be mentioned.

turt2live · 2023-06-20T01:07:09Z

proposals/3903-x25519-ecdhe.md

+This proposal introduces yet another key that Matrix client implementations need awareness of. It's also not clear to me
+where exactly this would fit in the spec documents.
+
+## Alternatives


turt2live · 2023-06-20T01:08:15Z

proposals/3903-x25519-ecdhe.md

+As Diffie-Hellman key agreement is a non-authenticated key-agreement protocol,
+this proposal makes use of a checksum for the user to authenticate the key agreement.
+
+**1a.** The initiator generates a ephemeral Curve25519 private key `privateA`.


nit: please use markdown's built-in numbering/bullet system

dkasak · 2023-11-29T11:50:03Z

proposals/3903-x25519-ecdhe.md

+In [MSC3906](https://github.com/matrix-org/matrix-spec-proposals/pull/3906) a
+proposal is made to allow a user to login on a new device using an existing
+device by means of scanning a QR code.
+
+[MSC3886](https://github.com/matrix-org/matrix-spec-proposals/pull/3886) already
+proposes a simple unsecured rendezvous protocol.
+
+In this proposal we build a secure layer on top of MSC3886 to allow for trusted
+out-of-bands communication between two Matrix clients.


The reference to MSC3906 should be clarified by stating what kind of relationship it has with this MSC.

Suggested change

In [MSC3906](https://github.com/matrix-org/matrix-spec-proposals/pull/3906) a

proposal is made to allow a user to login on a new device using an existing

device by means of scanning a QR code.

[MSC3886](https://github.com/matrix-org/matrix-spec-proposals/pull/3886) already

proposes a simple unsecured rendezvous protocol.

In this proposal we build a secure layer on top of MSC3886 to allow for trusted

out-of-bands communication between two Matrix clients.

In [MSC3906](https://github.com/matrix-org/matrix-spec-proposals/pull/3906) a

proposal is made to allow a user to login on a new device using an existing

device by means of scanning a QR code, followed by exchanging some messages over

a secure channel.

[MSC3886](https://github.com/matrix-org/matrix-spec-proposals/pull/3886) already

proposes a simple unsecured rendezvous protocol.

In this proposal we build a secure layer on top of MSC3886 to allow for trusted

out-of-bands communication between two Matrix clients, which satisfies the

requirements of MSC3906.

dkasak · 2023-11-29T11:51:47Z

proposals/3903-x25519-ecdhe.md

+The proposal is to use X25519 to agree a shared secret that is then used to
+perform AES.


Suggested change

The proposal is to use X25519 to agree a shared secret that is then used to

perform AES.

The proposal is to use X25519 to agree on a shared secret that is then used to

perform AES.

dkasak · 2023-11-29T11:53:16Z

proposals/3903-x25519-ecdhe.md

+As Diffie-Hellman key agreement is a non-authenticated key-agreement protocol,
+this proposal makes use of a checksum for the user to authenticate the key agreement.
+
+**1a.** The initiator generates a ephemeral Curve25519 private key `privateA`.


Suggested change

**1a.** The initiator generates a ephemeral Curve25519 private key `privateA`.

**1a.** The initiator generates an ephemeral Curve25519 private key `privateA`.

dkasak · 2023-11-29T11:58:09Z

proposals/3903-x25519-ecdhe.md

+of the curve).
+
+**2.** The recipient similarly generates a private key `privateB`, derives the
+public key `publicB` and shares is using the same structure of payload:


Suggested change

public key `publicB` and shares is using the same structure of payload:

public key `publicB` and shares it using the same structure of payload:

dkasak · 2023-11-29T13:07:42Z

proposals/3903-x25519-ecdhe.md

@@ -0,0 +1,157 @@
+# MSC3903: X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients


This entire MSC is essentially re-specifying ECIES (some more resources: [1], [2]).

MIT-licensed ECIES implementations in Rust, Python, TypeScript and Golang available here.

dkasak · 2023-11-29T13:16:53Z

proposals/3903-x25519-ecdhe.md

+secure by means of a checksum that is shown on both devices.
+
+If the checksum shown is not the same on both defives then it means that the
+devices have not directly exchanged keys with one another and are subject to a man-in-the-middle.


Suggested change

devices have not directly exchanged keys with one another and are subject to a man-in-the-middle.

devices have not directly exchanged keys with one another and are subject to a

man-in-the-middle attack.

dkasak · 2023-11-29T13:47:04Z

proposals/3903-x25519-ecdhe.md

+displayed on both devices for the user to visually verify.
+
+The checksum should be derived in a similar manner to step **4** above, however
+only 40 bit should be derived this time. The salt and info are the same as before.


Yep. As it stands, this looks like a gaping hole.

hughns · 2024-04-09T11:55:57Z

It is proposed that MSC4108 supersedes this MSC.

hughns · 2024-04-30T18:16:25Z

Closing this PR as #4108 is now ready for review.

X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secur…

35a5290

…e channel between two Matrix clients

hughns changed the title ~~X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secur…~~ X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients Oct 4, 2022

MSC3903

6574c3e

hughns changed the title ~~X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients~~ MSC3903: X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients Oct 4, 2022

hughns marked this pull request as ready for review October 4, 2022 17:26

turt2live added proposal A matrix spec change proposal client-server Client-Server API kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Oct 4, 2022

turt2live reviewed Oct 4, 2022

View reviewed changes

proposals/3903-x25519-ecdhe.md Outdated Show resolved Hide resolved

hughns added 2 commits October 4, 2022 18:54

Add notes about related/dependencies

35f3455

Add notes on to-device messaging as an alternative

3f1149d

hughns mentioned this pull request Oct 4, 2022

MSC3886: Simple client rendezvous capability #3886

Closed

9 tasks

turt2live added the hacktoberfest-accepted label Oct 5, 2022

poljar reviewed Oct 6, 2022

View reviewed changes

proposals/3903-x25519-ecdhe.md Outdated Show resolved Hide resolved

proposals/3903-x25519-ecdhe.md Outdated Show resolved Hide resolved

proposals/3903-x25519-ecdhe.md Outdated Show resolved Hide resolved

hughns added 3 commits October 6, 2022 10:20

Add detail about AES-GCM authentication tag

d50c96c

Whitespace and move note to correct point

73777be

MSCyyyy => MSC3906

ecc30a2

hughns mentioned this pull request Oct 13, 2022

Support sign in + E2EE set up using QR code implementing MSC3886, MSC3903 and MSC3906 matrix-org/matrix-js-sdk#2747

Merged

3 tasks

Unstable alg prefix

c184022

uhoreg reviewed Oct 17, 2022

View reviewed changes

proposals/3903-x25519-ecdhe.md Outdated Show resolved Hide resolved

notramo suggested changes Oct 19, 2022

View reviewed changes

hughns added 2 commits February 13, 2023 10:43

Use unpadded base64 encoding for consistency with rest of Matrix spec

8c67a12

Spelling

79905f7

turt2live assigned hughns Feb 28, 2023

turt2live requested a review from a team February 28, 2023 02:34

turt2live self-requested a review February 28, 2023 02:34

hughns and others added 5 commits March 1, 2023 14:22

Incorporate feedback from review

451ef4c

Clarification over authentication of key exchange and trust model

eb424f4

Fudge keys to attempt to parse spell check

7c0b50f

Line length

ef5d88d

Spelling

035b202

Migrate discussion on send-to-device messaging to MSC3886

8995ccd

uhoreg reviewed Apr 25, 2023

View reviewed changes

turt2live removed their request for review June 6, 2023 19:48

turt2live reviewed Jun 20, 2023

View reviewed changes

dkasak reviewed Nov 29, 2023

View reviewed changes

dkasak requested changes Dec 4, 2023

View reviewed changes

hughns closed this Apr 30, 2024

turt2live added the obsolete A proposal which has been overtaken by other proposals label Apr 30, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSC3903: X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients #3903

MSC3903: X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients #3903

hughns commented Oct 4, 2022 •

edited

Loading

turt2live Oct 4, 2022

hughns Oct 4, 2022

hughns Oct 4, 2022

uhoreg Apr 25, 2023

turt2live Jun 20, 2023

hughns Oct 18, 2023 •

edited

Loading

notramo left a comment

notramo Oct 19, 2022

uhoreg Oct 19, 2022

turt2live commented Mar 7, 2023

hughns commented Mar 15, 2023

uhoreg Apr 25, 2023

dkasak Nov 29, 2023

uhoreg Apr 25, 2023

uhoreg Apr 25, 2023

uhoreg Apr 25, 2023

turt2live Jun 20, 2023

turt2live Jun 20, 2023

dkasak Nov 29, 2023

dkasak Nov 29, 2023

dkasak Nov 29, 2023

dkasak Nov 29, 2023

dkasak Nov 29, 2023

dkasak Nov 29, 2023

dkasak Nov 29, 2023

hughns commented Apr 9, 2024

hughns commented Apr 30, 2024


		This means that for AES-GCM implementations that require the authentication tag to be explicitly processed (e.g. CryptoKit on iOS) that it can be sourced from the last 16 bytes of the base64-decoded `ciphertext`.

		7. The user should confirm that the established channel is secure by means of a checksum derived from the shared key.

	1c. The initiator shares it's key with the recipient via a trusted medium
	1c. The initiator shares its key with the recipient via a trusted medium

		## Security considerations

		Algorithm selection and implementation are crucial.

		The proposal is to use X25519 to agree a shared secret that is then used to
		perform AES.

	1a. The initiator generates a ephemeral Curve25519 private key `privateA`.
	1a. The initiator generates an ephemeral Curve25519 private key `privateA`.

	public key `publicB` and shares is using the same structure of payload:
	public key `publicB` and shares it using the same structure of payload:

		@@ -0,0 +1,157 @@
		# MSC3903: X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients

	devices have not directly exchanged keys with one another and are subject to a man-in-the-middle.
	devices have not directly exchanged keys with one another and are subject to a
	man-in-the-middle attack.

MSC3903: X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients #3903

MSC3903: X25519 Elliptic-curve Diffie-Hellman ephemeral for establishing secure channel between two Matrix clients #3903

Conversation

hughns commented Oct 4, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hughns Oct 18, 2023 • edited Loading

Choose a reason for hiding this comment

notramo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

turt2live commented Mar 7, 2023

hughns commented Mar 15, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hughns commented Apr 9, 2024

hughns commented Apr 30, 2024

hughns commented Oct 4, 2022 •

edited

Loading

hughns Oct 18, 2023 •

edited

Loading