# Tag Info

19

You are correct in that the best strategy for an adversary would be to guess the password, as opposed to cryptanalysis of AES plaintext/ciphertexts. However, this does not make encryption pointless - password based key derivation is a challenge unto itself, separate from encryption, but one that does have practical solutions. We can strengthen this weak ...

17

Can you help me understand what a cryptographic “salt” is? In the context of password creation, a "salt" is data (random or otherwise) added to a hash function in order to make the hashed output of a password harder to crack. When might I need to use it? Always. Why should or should I not use it? You should always use a salt value with your hash ...

17

There are a number of considerations here, I'll try to lay them out one at a time for ease of following: What must the site do with the data? Oftentimes, we ask web sites to do things on our behalf when we are not actually visiting them. For example, I may want crypto.SE to email me when there are responses to this post. The site could not do that ...

16

Yes, scrypt achieves this. Scrypt has a variable-length output, so just generate as much output as you need. For instance, you can ask it for 256 bits of output, then use the first 128 bits for one key and the second 128 bits for the other key. While PBKDF2 also has a variable-length output, I do not recommend that you use it in the same way. It has a ...

14

If you are unsure, then always choose Argon2id. Only choose Argon2d if you need maximum security at the expense of side-channel risk, and only choose Argon2i if side-channel attacks are the primary threat. The number of passes just increases resistance to time-memory tradeoff attacks (TMTO). What you are probably remembering is that Argon2i is more ...

13

It sounds like you're using a password-based key derivation function that accepts an optional salt input to convert a passphrase into an encryption key, which you then use to encrypt messages with a block cipher mode (or possibly some other type of stream cipher) that takes an IV or a nonce, and you want to know whether it's necessary to provide a salt to ...

13

Assume you have an IND-CCA secure cryptosystem $E$ that runs a password through a slow KDF and implicitly handles salts and random IVs, a human-chosen password $p$, and messages $m_1$ through $m_n$ to encrypt. Is $E_p(m_1+m_2+\cdots+m_n)$ or $E_p(m_1)+E_p(m_2)+\cdots+E_p(m_n)$ better for this? Each invocation of $E$ is slow due to it running a KDF on $p$, ...

10

Am I right? Is it completely pointless to use passwords to AES encrypt files? No, certainly it isn't completely pointless to use password to AES encrypt files. However, problem lies within details. The attacker won't need to bruteforce my file with 128bit keys, he bruteforces it with passwords. This is true, 128bit key is often far bigger than what ...

10

Let's take AES-CBC for example—a typical cryptosystem that requires a randomized IV. Suppose I can predict the IV in advance. Then I can start by asking for the encryption of $\mathit{iv}_0$, which is $\operatorname{AES}_k(\mathit{iv}_0 \oplus \mathit{iv}_0) = \operatorname{AES}_k(0)$, and proceed by asking to be challenged on the messages $m_0 = \mathit{... 9 The first protocol for password authenticated key exchange that appeared in the crypto community was the Bellovin-Merritt scheme (see also this survey page 4). This protocol is very simple, and might actually suit your need: is is exactly a Diffie-Hellman key exchange, in which the flows are encrypted with a block cipher (using the common password as the key ... 9 HMAC is still very efficient. It's used in PBKDF2 not for the lower efficiency (that's handled by iterating it many times) because of the fact that it takes two inputs. That lets the password and other data be combined in a safe manner, invlunerable to some of the issues that just using SHA256 alone could create. PBKDF2 isn't doing H(H(H(...H(Pwd + salt))..... 8 AES supports three key lengths. They are 128, 192 and 256 bits long. You chose to use the 256 bit algorithm that operates in CBC mode. It's a correct choice. Now all you need is: key - 256 bits long initialization vector - 128 bits long You can generate them using the command I found here: openssl enc -aes-256-cbc -k secret -P -md sha1 where the "secret"... 8 Suppose you use 128 characters out of an alphabet (this is a large alphabet). To create a key you'd need about 37 fully random characters to create an AES key of 256 bit strength. Even you would create such a password, you'd have trouble encoding it over the required number of bits. You could either use a 44 character base 64 string or 64 character hex ... 8 The short answer is, it depends on how you choose your passwords, and on how the software derives the encryption key from the password. As you've correctly noted, AES is almost never the weakest link in your encryption system. So far, nobody's found (or, at least, published) any way to break AES itself significantly faster than by trying all the possible ... 8 Should the secret data be encrypted with Alice's raw password? As a general rule of thumb: A password should only ever be fed into a password hashing scheme (PHS) such as Argon2, scrypt or bcrypt, never into anything else! There are multiple reasons for this: Passwords need special processing in the form of complexity parameters. Passwords need external (... 7 Generate key-pair Generate random salt, hash password with proper password hash (scrypt or PBKDF2) to derive a master key. Use HKDF to derive one login key and one encryption key from master key Encrypt private key with encryption key from previous step Upload it to server, download only possible by proving possession of login key (either send over SSL, or ... 7 I'm going to attempt to answer a part of your question that has so far been neglected: when I might need to use it and why I should/should not use it. The short answer is that, as an amateur, you should not be using cryptography at a level that requires dealing with salts directly. For instance, the bcrypt password hashing algorithm uses salts ... 7 There is a terminology gap in your question. Lets assume that you want to encrypt message$m$, and for that purpose you'll be using the encryption function$E$such that the encrypted message will be$E(m)$. Now you ask whether your message will be more secure if you encrypt it for example as$E(E(E(m)))$. Well if this encryption is stronger than$E(m)$, ... 7 It will happen immediately, because you just posted your password to the internet, where the adversary is watching. On the other hand, if you can describe the procedure you used to generate it, we can quantify the adversary's probability, knowing only the procedure and not the specific outcome, of guessing the password in one trial. From there one can ... 6 Here are some hints on how it's done on Mega: The password provided is passed through a KDF to derive a key, that is used to en-/decrypt the master key (later provided by the server through an API call). To bring it down to the crucial bits: The KDF applies$2^{16}$rounds of AES-128 with it. The details can be found in the function prepare_key() of the ... 6 No, in general you cannot. WinRAR uses AES (128 or 256 depending on version) for encryption, which does not allow key recovery even with know plaintext and ciphertext. It also uses key stretching to derive the encryption key from a password. The algorithm used in newer versions is PBKDF2 with a version dependent iteration count. So a key-guessing attack is ... 6 Both the AES key size and the RSA key size matter, because it's no use adding security beyond the weakest link. Here the weakest link is 2048-bit RSA, which is considered roughly equivalent in security to 100-128-bit symmetric keys (depending on who you ask). So having a password with much more than 100 bits of entropy would be fairly useless. In practice, ... 6 Generate a random IV (with a cryptographically secure random generator of course) and prepend the IV to the ciphertext. Some modes of encryption don't require a random IV, but you can never go wrong with a random IV as long as your RNG works fine. An IV does not need to be secret (it's a matter of terminology — if it had to be secret it woulnd't be called ... 6 Building upon Geoffroy Couteau's answer, there are possible fixes to the issues addressed there. The Bellovin-Merrit (from section 3: EKE using exponential key exchange) scheme is roughly like this: - Alice and Bob agree on a safe prime modulus and a generator of the group (which has a problem of leaking its Legendre symbol) - Alice and Bob do a normal DH ... 6 Yes. That's the entire idea of key stretching, you can get away with a password that offers less strength against attacks. You add more operations to a brute force/dictionary attack to protect the keys. The disadvantage is that you need to do the same number of operations during key derivation. Passwords commonly don't have 64 bits or 80 bits of entropy ... 6 As mentioned in the comments, using two different algorithms with independent password does not "double" your security. Like in 3DES there would be a space time tradeoff for an attacker using a Meet-in-the-Middle-Attack (not to be confused with the term Man-in-the-Middle-Attack) However e. g. in the following scenarios you actually gain security: One of ... 6 One approach that you might consider is a puzzle; this is something where the decryptor must do some searching to find the result. Here is one simple example: suppose the encryptor takes the password, and selects$N\$ random bits; he concatenates the two and SHA-256 hashes the result. He then takes the first 128 bits of the hash, places that in the ...

5

Both scrypt and pbkdf2 have variable length outputs, and each bit of the output is effectively independent on every other bit. So, one obvious way would be just to ask for enough output for both keys. For example, if the two keys are each 128 bits, then ask scrypt (or pbkdf2) for 256 bits of output; use the first 128 bits as the first key, and the second ...

5

Short answer: Use bcrypt. Long answer: First, "hashing a password with the password" is an undefined statement. Regardless, you are well into "inventing your own crypto" territory. Assuming you mean something along the lines of SHA-256(password + password), this is a phenomenally bad password digesting scheme. Being unsalted, your approach is vulnerable to ...

Only top voted, non community-wiki answers of a minimum length are eligible