3 ms·

I'm not a crypto researcher in any way, but if someone had access to the vault, wouldn't the fact that there are multiple stored (encrypted) representations of

by pbnjay 13y ago

I'm not a crypto researcher in any way, but if someone had access to the vault, wouldn't the fact that there are multiple stored (encrypted) representations of the same data encryption key present an attack point? This image for example: http://blog.cloudflare.com/static/images/cryptography2.png http://blog.cloudflare.com/static/images/cryptography2.png stores identical plaintexts under different encryptions.

peterwwillis 13y ago
I'm not a crypto research either, but this paragraph explains basically what keeps the data secure against vault capture: > Red October is backed by a database of accounts stored on > disk in a portable password vault. The server never stores > the account password there, only a salted hash of the > password for each account. For each user, the server > creates an RSA key pair and encrypts the private key with > a key derived from the password and a randomly generated > salt using a secure derivation function. Breaking this down: 1. Create database 2. Create user 3. Store salted/hashed user password 4. Create pub/priv keypair for user 5. Encrypt keypair using password and a new salt If you get the vault, you need the user's password to decrypt their keypair. Trying to crack their password is really hard (they use scrypt). Trying to crack an encrypted keypair is really hard because they also use scrypt (i assume?). Even if it is cracked, all the other encrypted keypairs have a different salt, so even one cracked still leaves all the others to be cracked again. So even if the same plaintext data is encrypted by multiple people, it'll be substantially different each time because of all the different keypairs and salts.
- pbnjay 13y ago
  Presumably any attacker only cares about the encrypted data, not the user's credentials. The data is encrypted with a single data-key - so the attack would focus on cracking that key. The attacker knows that identical processes are used to encrypt that data-key. Even with multiple keys and nested encryptions, it seems that at the very least that the reduced entropy of search space around the data-key can be used to optimize a brute-force search. This would be further compounded if at least one user's key-encryption-key were known. I'm probably missing something important, but if I've learned anything from the cryptopals challenges its that you don't want to reduce your entropy in any way. Would a simple solution be to add a random salt at each level of the nested key encryptions?
btruitt 13y ago
Quoting a colleague of mine that I asked this of today: "No data is leaked provided the encryption scheme is IND-CPA. AES CBC with a random IV is believed to meet that security definition (within a bound of ~2^64 separate encryptions with the same key and assuming the AES PRP is itself secure)." http://en.wikipedia.org/wiki/Ciphertext_indistinguishability http://en.wikipedia.org/wiki/Ciphertext_indistinguishability
- pbnjay 13y ago
  Great to hear, Thanks! I'm really interested in this for an upcoming project, so I'm just trying to understand the implications of some of these design decisions.

by pbnjay 13y ago

peterwwillis 13y ago

I'm not a crypto research either, but this paragraph explains basically what keeps the data secure against vault capture: > Red October is backed by a database of accounts stored on > disk in a portable password vault. The server never stores > the account password there, only a salted hash of the > password for each account. For each user, the server > creates an RSA key pair and encrypts the private key with > a key derived from the password and a randomly generated > salt using a secure derivation function. Breaking this down: 1. Create database 2. Create user 3. Store salted/hashed user password 4. Create pub/priv keypair for user 5. Encrypt keypair using password and a new salt If you get the vault, you need the user's password to decrypt their keypair. Trying to crack their password is really hard (they use scrypt). Trying to crack an encrypted keypair is really hard because they also use scrypt (i assume?). Even if it is cracked, all the other encrypted keypairs have a different salt, so even one cracked still leaves all the others to be cracked again. So even if the same plaintext data is encrypted by multiple people, it'll be substantially different each time because of all the different keypairs and salts.

pbnjay 13y ago
Presumably any attacker only cares about the encrypted data, not the user's credentials. The data is encrypted with a single data-key - so the attack would focus on cracking that key. The attacker knows that identical processes are used to encrypt that data-key. Even with multiple keys and nested encryptions, it seems that at the very least that the reduced entropy of search space around the data-key can be used to optimize a brute-force search. This would be further compounded if at least one user's key-encryption-key were known. I'm probably missing something important, but if I've learned anything from the cryptopals challenges its that you don't want to reduce your entropy in any way. Would a simple solution be to add a random salt at each level of the nested key encryptions?

btruitt 13y ago

Quoting a colleague of mine that I asked this of today: "No data is leaked provided the encryption scheme is IND-CPA. AES CBC with a random IV is believed to meet that security definition (within a bound of ~2^64 separate encryptions with the same key and assuming the AES PRP is itself secure)." http://en.wikipedia.org/wiki/Ciphertext_indistinguishability http://en.wikipedia.org/wiki/Ciphertext_indistinguishability

pbnjay 13y ago
Great to hear, Thanks! I'm really interested in this for an upcoming project, so I'm just trying to understand the implications of some of these design decisions.