MSC1703: encrypting recovery keys for online megolm backups #1703

dbkr · 2018-10-23T15:49:43Z

Rendered: https://github.com/matrix-org/matrix-doc/tree/dbkr/encrypted-recovery-keys/proposals/1687-encrypted-recovery-keys.md

This is an expanded version of MSC1687

ara4n · 2018-10-30T22:38:03Z

hm, this would be much easier to review if it were wordwrapped

proposals/1687-encrypted-recovery-keys.md

ara4n · 2018-10-30T23:13:37Z

So, it feels there are three actual options here:

1a. Generate the recovery key from the passphrase (vuln to dictionary attacks on the server)
1b. Generate the recovery key randomly, and then encrypt it with a key derived from the passphrase (the original plan)
3. Generate a backup encryption key from random; a passphrase-derived key (which is then XORed with the backup encryption key); and a recovery key from random (which is also then XORed with the backup encryption key). I'm not clear on how these interweave together, or the benefits they bring.

What are we actually proposing in practice? I'm a bit confused as to what option 3 buys us over option 1b?

rather than referring to option 2

splits option 2 up into two sub-options

dbkr · 2018-11-01T15:08:16Z

My suggestion here is to go with 1a (now just 1 in my renumbering). The summary is that I don't think there's any realistic way of mitigating the dictionary attack: option 2b. runs through a proposed mitigation and why it doesn't really work.

The kicker is that the user will get a new recovery key whenever they change their passphrase. Options 3 adds the ability to retain the same recovery key when you change your passphrase, so if we want that feature, option 1 won't suffice. It sounds like we don't though.

ara4n · 2018-11-01T17:46:25Z

proposals/1687-encrypted-recovery-keys.md

+### Option 2b
+
+A variant on option 2a is to regenerate K<sup>-1</sup> when the passphrase is
+changed, meaning the recovery does change when the passphrase is changed,


s/recovery/recovery key/

ara4n · 2018-11-01T17:47:23Z

proposals/1687-encrypted-recovery-keys.md

+### Option 3
+
+The backup encryption private key, K<sup>-1</sup>, and a private,
+passphrase-derived key, K<sup>-1</sup><sub>p</sub> are generated as above.The


ara4n · 2018-11-01T17:50:16Z

proposals/1687-encrypted-recovery-keys.md

+
+## Security considerations
+
+The proposal above is vulnerable to a malicious server admin performing a


surely only option 1 is vuln to dict attack?

(and possibly 3; I haven't grokked how it works yet)

ara4n · 2018-11-01T17:51:38Z

this is much clearer now; thanks. let's just say "for now let's just generate the key from the passphrase and go with option 1" as a conclusion on the MSC and give it a go.

uhoreg · 2018-11-02T19:58:57Z

Yup, option 1 seems to be sufficient, and is simpler.

turt2live · 2018-12-17T23:19:04Z

Option 1 does indeed look easiest, even with the potential risk documented later in the proposal. It's also the option that was proofed in riot-web, correct?

ara4n · 2018-12-17T23:27:38Z

yup

richvdh · 2018-12-27T17:38:33Z

[It's now the only MSC for encrypting recovery keys for online megolm backups]

richvdh

I haz comments...

richvdh · 2018-12-27T17:40:31Z

proposals/1687-encrypted-recovery-keys.md

@@ -0,0 +1,154 @@
+# Proposal for storing an encrypted recovery key on the server to aid recovery of megolm key backups


could the file be renamed so that it matches the MSC number?

richvdh · 2018-12-27T17:40:47Z

proposals/1687-encrypted-recovery-keys.md

+```json
+{
+    "private_key": {
+        salt: "MmMsAlty",


Suggested change

salt: "MmMsAlty",

"salt": "MmMsAlty",

richvdh · 2018-12-27T17:40:57Z

proposals/1687-encrypted-recovery-keys.md

+{
+    "private_key": {
+        salt: "MmMsAlty",
+        rounds: 100000


Suggested change

rounds: 100000

"rounds": 100000

richvdh · 2018-12-27T17:43:38Z

proposals/1687-encrypted-recovery-keys.md

+string, b is as follows:
+ * Prepend the two bytes 0x8B, 0x01 to the byte string b
+ * Compute a parity bit by XORing all bytes of the resulting string (ie. prefix
+   + `byte string`)


this explodes into a bullet list in the rendered version.

also why is byte string in backticks? perhaps you just mean b, but then you probably want to use backticks each time b is used.

richvdh · 2018-12-27T17:44:06Z

proposals/1687-encrypted-recovery-keys.md

+In all options below, the process for generating a recovery key from a byte
+string, b is as follows:
+ * Prepend the two bytes 0x8B, 0x01 to the byte string b
+ * Compute a parity bit by XORing all bytes of the resulting string (ie. prefix


Suggested change

* Compute a parity bit by XORing all bytes of the resulting string (ie. prefix

* Compute a parity byte by XORing all bytes of the resulting string (ie. prefix

richvdh · 2019-01-02T14:52:33Z

proposals/1687-encrypted-recovery-keys.md

+### Option 3
+
+The backup encryption private key, K<sup>-1</sup>, and a private,
+passphrase-derived key, K<sup>-1</sup><sub>p</sub> are generated as above.The


Suggested change

passphrase-derived key, K-1p are generated as above.The

passphrase-derived key, K-1p are generated as above. The

richvdh · 2019-01-02T15:03:03Z

proposals/1687-encrypted-recovery-keys.md

+
+The backup encryption private key, K<sup>-1</sup>, and a private,
+passphrase-derived key, K<sup>-1</sup><sub>p</sub> are generated as above.The
+passphrase key counterpart, K<sup>-1</sup><sub>p</sub>', is also generated as


there are a bunch of formulae here which are imprecisely and inconsistently described. How about giving each calculation its own line?

the passphrase key counterpart, K^-1_p', is calculated as:

K^-1_p' = K^-1 XOR K^-1_p

richvdh · 2019-01-02T15:24:57Z

proposals/1687-encrypted-recovery-keys.md

+K<sup>-1</sup><sub>r</sub>' is generated by XORing K<sup>-1</sup><sub>r</sub>
+with K<sup>-1</sup>. Both K<sup>-1</sup><sub>p</sub>' and
+K<sup>-1</sup><sub>r</sub>' are stored in the `private_key` in the backup under
+keys `passphrase_counterpart` and `recovery_key_counterpart` respectively.


how are all these keys actually used for encryption?

richvdh · 2019-01-02T15:25:17Z

proposals/1687-encrypted-recovery-keys.md

+
+## Security considerations
+
+The proposal above is vulnerable to a malicious server admin performing a


richvdh · 2019-01-02T15:25:43Z

proposals/1687-encrypted-recovery-keys.md

+
+## Security considerations
+
+The proposal above is vulnerable to a malicious server admin performing a


(and possibly 3; I haven't grokked how it works yet)

cedricvanrompay · 2019-04-29T15:53:43Z

Is there a reason why PBKDF2 is used instead of the state of the art Argon2 ?

Reference: https://password-hashing.net/

uhoreg · 2019-04-29T20:53:26Z

Mainly because there are more implementations of it. In particular, it's in WebCrypto.

cedricvanrompay · 2019-04-30T07:13:25Z

Mainly because there are more implementations of it. In particular, it's in WebCrypto.

OK. I think it would be nice to have an attribute specifying the key derivation algorithm though, to make it easier to switch to a different one.

I cannot find quantitative results on state-of-the-art PBKDF2 cracking but I keep reading that PBKDF2 is very weak against ASICs.

uhoreg · 2020-06-15T15:10:40Z

This proposal is obsoleted by #1946

ara4n and others added 3 commits September 26, 2018 10:50

Initial MSC for encrypting recovery keys for online megolm backups

7960290

use the right MSC number

8c3e04b

Fleshed out proposal for passphrased backups.

c53aaee

ara4n added proposal-in-review proposal A matrix spec change proposal labels Oct 29, 2018

ara4n reviewed Oct 30, 2018

View reviewed changes

proposals/1687-encrypted-recovery-keys.md Outdated Show resolved Hide resolved

ara4n reviewed Oct 30, 2018

View reviewed changes

proposals/1687-encrypted-recovery-keys.md Outdated Show resolved Hide resolved

ara4n reviewed Oct 30, 2018

View reviewed changes

proposals/1687-encrypted-recovery-keys.md Outdated Show resolved Hide resolved

ara4n reviewed Oct 30, 2018

View reviewed changes

proposals/1687-encrypted-recovery-keys.md Outdated Show resolved Hide resolved

dbkr added 5 commits October 31, 2018 10:49

missed a -1

8ab9ece

Clarify that a new K is generated

f66f0f5

Add definitions of the various K dirctly in option 3

3f282af

rather than referring to option 2

word wrap

80abfe2

Try & clarify mitigation against dict attacks

89e2556

splits option 2 up into two sub-options

ara4n reviewed Nov 1, 2018

View reviewed changes

This was referenced Nov 16, 2018

E2E: Mechanism for encrypting the key with the passphrase (design and impl) element-hq/element-web#7404

Closed

Passphrase Support for e2e backups matrix-org/matrix-js-sdk#786

Merged

richvdh changed the title ~~More detailed MSC for encrypting recovery keys for online megolm backups~~ MSC1703: More detailed MSC for encrypting recovery keys for online megolm backups Dec 12, 2018

This was referenced Dec 13, 2018

Passphrase Support for e2e backups element-hq/riot-meta#240

Closed

Passphrase Support for e2e backups element-hq/element-ios#2127

Closed

Passphrase Support for e2e backups element-hq/riot-android#2771

Closed

ara4n mentioned this pull request Dec 17, 2018

MSC1756: cross-signing devices using a master identity key #1756

Merged

turt2live mentioned this pull request Dec 17, 2018

Initial MSC for encrypting recovery keys for online megolm backups #1686

Closed

turt2live added the T-Core label Dec 17, 2018

richvdh mentioned this pull request Dec 27, 2018

MSC1687: Encrypting recovery keys for online megolm backups #1687

Closed

richvdh changed the title ~~MSC1703: More detailed MSC for encrypting recovery keys for online megolm backups~~ MSC1703: encrypting recovery keys for online megolm backups Dec 27, 2018

richvdh self-requested a review January 2, 2019 07:46

richvdh requested changes Jan 2, 2019

View reviewed changes

anoadragon453 removed the T-Core label Jan 4, 2019

dbkr added 2 commits January 21, 2019 13:39

Add note saying which we picked.

c26bd4f

Fix spec to match what got implemented

2ffb58c

uhoreg mentioned this pull request May 22, 2019

MSC1219: storing megolm keys serverside #1538

Merged

turt2live added the kind:core MSC which is critical to the protocol's success label Apr 20, 2020

uhoreg closed this Jun 15, 2020

turt2live added obsolete A proposal which has been overtaken by other proposals and removed proposal-in-review labels Jun 8, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSC1703: encrypting recovery keys for online megolm backups #1703

MSC1703: encrypting recovery keys for online megolm backups #1703

dbkr commented Oct 23, 2018 •

edited by richvdh

Loading

ara4n commented Oct 30, 2018

ara4n commented Oct 30, 2018

dbkr commented Nov 1, 2018

ara4n Nov 1, 2018

ara4n Nov 1, 2018

ara4n Nov 1, 2018

richvdh Jan 2, 2019

richvdh Jan 2, 2019

ara4n commented Nov 1, 2018

uhoreg commented Nov 2, 2018

turt2live commented Dec 17, 2018

ara4n commented Dec 17, 2018

richvdh commented Dec 27, 2018

richvdh left a comment

richvdh Dec 27, 2018

richvdh Oct 21, 2019

richvdh Dec 27, 2018

richvdh Dec 27, 2018

richvdh Dec 27, 2018

richvdh Dec 27, 2018

richvdh Jan 2, 2019

richvdh Jan 2, 2019

richvdh Jan 2, 2019

richvdh Jan 2, 2019

richvdh Jan 2, 2019

cedricvanrompay commented Apr 29, 2019

uhoreg commented Apr 29, 2019

cedricvanrompay commented Apr 30, 2019

uhoreg commented Jun 15, 2020


		## Security considerations

		The proposal above is vulnerable to a malicious server admin performing a

		@@ -0,0 +1,154 @@
		# Proposal for storing an encrypted recovery key on the server to aid recovery of megolm key backups

	* Compute a parity bit by XORing all bytes of the resulting string (ie. prefix
	* Compute a parity byte by XORing all bytes of the resulting string (ie. prefix

	passphrase-derived key, K<sup>-1</sup><sub>p</sub> are generated as above.The
	passphrase-derived key, K<sup>-1</sup><sub>p</sub> are generated as above. The

MSC1703: encrypting recovery keys for online megolm backups #1703

MSC1703: encrypting recovery keys for online megolm backups #1703

Conversation

dbkr commented Oct 23, 2018 • edited by richvdh Loading

ara4n commented Oct 30, 2018

ara4n commented Oct 30, 2018

dbkr commented Nov 1, 2018

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

ara4n commented Nov 1, 2018

uhoreg commented Nov 2, 2018

turt2live commented Dec 17, 2018

ara4n commented Dec 17, 2018

richvdh commented Dec 27, 2018

richvdh left a 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

cedricvanrompay commented Apr 29, 2019

uhoreg commented Apr 29, 2019

cedricvanrompay commented Apr 30, 2019

uhoreg commented Jun 15, 2020

dbkr commented Oct 23, 2018 •

edited by richvdh

Loading