3 ms·

> I mean, crypographically we’ve had solutions to those exact problems for 30 years. My point exactly - 1password.com addresses those problems (e.g. by adding

by manmal 4y ago

> I mean, crypographically we’ve had solutions to those exact problems for 30 years. My point exactly - 1password.com addresses those problems (e.g. by adding a random key to the master password, and via Secure Remote Password auth), while using just a master password (sans random key) in a dumbly file-hosted vault does not.

dijit 4y ago
When you talk about “master key”, are you aware about multi-key cryptography? me and my friend can have private keys to a ”vault” (or, file) that are solely our keys, even if they decrypt the same secret. No need for a “master password” to unseal the vault. Here is the gpg docs for it: https://www.gnupg.org/gph/en/manual.html#AEN111 https://www.gnupg.org/gph/en/manual.html#AEN111 section 5.1 of RFC 2440 explains how it works: https://www.ietf.org/rfc/rfc2440.txt https://www.ietf.org/rfc/rfc2440.txt
- manmal 4y ago
  If I got you right, then 1P does use this mechanism, and LP most likely too. The problem is - how do you store the private keys in a way that their loss is not catastrophic? Services like 1P and LP answer that question, with varying levels of sophistication. With 1P, it works roughly like this: - Every vault item is encrypted with the vault’s key (randomly generated number w/ 256 bit, AES) - For every user that has access to the vault, the user‘s public key is used to encrypt the vault key. I think this is what you meant by multi-key? Adding a team member to a vault means encrypting the vault key with the member‘s public key. - The user‘s private key in turn is encrypted with the „Account unlock key“, which is made up of: Master password + random secret [1] + salt. Neither of those is ever sent to the servers in plaintext, made possible by zero knowledge proofs. If you stored your ciphertext on a dumb file hoster: Sure you can increase entropy in the master password to match 1P‘s random secret. Or just store your private key directly, as I think you suggested. But this is not memorable, so where do you back this key up in case your hard drive fails? Aren’t we entering recursion at this point, requiring yet another round of encryption? There’s no end to this. At some point you need to have either a password you can commit to memory, or one that’s stored in sthg like a secure enclave. You could also print out the private key, like 1P is suggesting for its secret key. But exposure of the piece of paper is a total breach if it’s your private key, but not with 1P‘s secret key. 1: Random secret is stored on your device, and they ask you to print it out upon signup. It’s never shared in plaintext with the 1P server, same as the master password.

by manmal 4y ago

dijit 4y ago

When you talk about “master key”, are you aware about multi-key cryptography? me and my friend can have private keys to a ”vault” (or, file) that are solely our keys, even if they decrypt the same secret. No need for a “master password” to unseal the vault. Here is the gpg docs for it: https://www.gnupg.org/gph/en/manual.html#AEN111 https://www.gnupg.org/gph/en/manual.html#AEN111 section 5.1 of RFC 2440 explains how it works: https://www.ietf.org/rfc/rfc2440.txt https://www.ietf.org/rfc/rfc2440.txt

manmal 4y ago
If I got you right, then 1P does use this mechanism, and LP most likely too. The problem is - how do you store the private keys in a way that their loss is not catastrophic? Services like 1P and LP answer that question, with varying levels of sophistication. With 1P, it works roughly like this: - Every vault item is encrypted with the vault’s key (randomly generated number w/ 256 bit, AES) - For every user that has access to the vault, the user‘s public key is used to encrypt the vault key. I think this is what you meant by multi-key? Adding a team member to a vault means encrypting the vault key with the member‘s public key. - The user‘s private key in turn is encrypted with the „Account unlock key“, which is made up of: Master password + random secret [1] + salt. Neither of those is ever sent to the servers in plaintext, made possible by zero knowledge proofs. If you stored your ciphertext on a dumb file hoster: Sure you can increase entropy in the master password to match 1P‘s random secret. Or just store your private key directly, as I think you suggested. But this is not memorable, so where do you back this key up in case your hard drive fails? Aren’t we entering recursion at this point, requiring yet another round of encryption? There’s no end to this. At some point you need to have either a password you can commit to memory, or one that’s stored in sthg like a secure enclave. You could also print out the private key, like 1P is suggesting for its secret key. But exposure of the piece of paper is a total breach if it’s your private key, but not with 1P‘s secret key. 1: Random secret is stored on your device, and they ask you to print it out upon signup. It’s never shared in plaintext with the 1P server, same as the master password.