| 9 Apr 2020 |
| 19:13:15 |  Mathijs | but I may be missing something clever :P |
| 19:13:17 |  uhoreg | In reply to @mathijs:matrix.vgorcum.com
would you want some kind of deterministic KDF from the password, or would you somehow want to transport the private key to a new device upon login? Some kind of deterministic KDF, probably similar to SSSS (and probably reusing as much of it as possible) |
| 19:14:07 | Mathijs | I see, that makes sense |
| 19:14:55 | Mathijs | what does SSSS actually use? |
| 19:17:54 | uhoreg | It uses PBKDF2 to generate an initial key and HKDF (with SHA-256 I think) to generate other keys. I considered argon instead of PBKDF2, but argon doesn't have as much support yet (in particular, webcrypto doesn't support it). |
| 19:23:00 | Mathijs | I see |
| 19:23:08 | Mathijs | thanks for taking the time to explain |
| 19:29:55 | Mathijs | actually: what is used for the salt in pbkdf2? |
| 19:30:07 | | * Mathijs should probably just read the msc |
| 19:31:35 | uhoreg | The salt is random, and stored in the SSSS key info |
| 19:32:17 | Mathijs | I see, so you fetch that from the server |
| 19:32:41 | uhoreg | In reply to * @mathijs:matrix.vgorcum.com
should probably just read the msc FYI, the MSC in the repo is a bit outdated. The latest version is in https://github.com/matrix-org/matrix-doc/pull/2472 |
| 19:32:58 | Mathijs | ty 👍️ |
| 19:33:49 | Mathijs | oh, yeah, I read you switched to a symmetric encryption method |
| 19:35:54 | Mathijs | have you had any thoughts about a salt for using this as a login method? |
| 19:36:11 | Mathijs | fetch a salt from the server when trying to login based on username? |
| 19:42:21 | Mathijs | downside is that you need an extra roundtrip when filling in the username |
| 19:42:38 | Mathijs | though I guess we also already do the well-known lookup, so what's another roundtrip |
| 20:07:26 | uhoreg | I've thought about it briefly, but haven't tried to figure out any details yet. |
| 10 Apr 2020 |
| 02:35:51 |  davo | What if you just did SRP instead of reinventing the wheel?
|
| 06:55:50 | Mathijs | maybe we could just do whatever bitwarden does |
| 07:06:58 | davo | well, this is what bitwarden does at a high level: https://help.bitwarden.com/article/password-salt-hash/ |
| 07:07:10 | davo | * well, this is what bitwarden does at a high level: https://help.bitwarden.com/article/password-salt-hash/ |
| 07:08:21 | davo | Protonmail do SRP though, as an example |
| 07:40:08 | davo | Why does /event/{eventId} return a 1-array pdus? https://matrix.org/docs/spec/server_server/r0.1.3#get-matrix-federation-v1-event-eventid |
| 08:02:30 | Mathijs | In reply to @david:vovo.id.au
well, this is what bitwarden does at a high level: https://help.bitwarden.com/article/password-salt-hash/ yeah, I read through it, but found the help articles to be generally too superficial |
| 08:02:44 | Mathijs | though that makes sense, I'm not the target audience |
| 09:49:47 | uhoreg | In reply to @david:vovo.id.au
What if you just did SRP instead of reinventing the wheel?
I've looked a bit at some PAKEs before. There's some criticism of SRP at https://blog.cryptographyengineering.com/2018/10/19/lets-talk-about-pake/ but some other PAKEs might be interesting to look at. There's also SCRAM, which was created by some XMPP people. It's certainly worth considering prior art. |
| 09:55:08 | uhoreg | One criterion that I have is that it should be reasonably easy for people to implement, which means, for example, not being too complicated, and reusing as much of what we're already using, so that people don't have to implement too many different cryptographic operations. |
| 09:57:42 | uhoreg | In reply to @david:vovo.id.au
Why does /event/{eventId} return a 1-array pdus? https://matrix.org/docs/spec/server_server/r0.1.3#get-matrix-federation-v1-event-eventid I don't know for sure, but I would guess that it's for symmetry with https://matrix.org/docs/spec/server_server/r0.1.3#put-matrix-federation-v1-send-txnid |
