# Tag Info

24

The best you can hope for is the following: You derive the password into a "big enough" (e.g. 128 bits) secret key $K$ with a Key Derivation Function like PBKDF2. There are some details to be aware of (see below). You use the secret key $K$ as seed for a Pseudorandom Number Generator. The PRNG is deterministic (same seed implies same output sequence) and ...

14

Both PBKDF2 and scrypt are key derivation functions (KDFs) that implement key stretching by being deliberately slow to compute and, in particular, by having an adjustable parameter to control the slowness. The difference is that scrypt is also designed to require a large (and adjustable) amount of memory to compute efficiently. The purpose of this is to ...

10

I'd use HKDF's "expand" step to generate multiple keys from one masterkey. Use PBKDF2 to derive that masterkey from the password and salt. i.e. replace the "extract" step of HKDF with PBKDF2. //Extract MasterKey = PBKDF2(salt, password, iterations) //Expand AES-Key = HMAC(MasterKey, "AES-Key" | 0x01) MAC-Key = HMAC(MasterKey, "MAC-Key" | 0x01) (where | ...

10

I suppose that what you are trying to do is password-based encryption of some data; you use PBKDF2 to derive the password into an encryption key, and then use the key with AES to encrypt the data. The AES encryption needs an IV, and the PBKDF2 function needs a salt. Both IV and salt should be generated anew for each encryption (even if reusing the same ...

10

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 ...

10

So in general, isn't this equivalent to what Bcrypt and PBKDF2 do in terms of password storage security? PBKDF2, yes, pretty much. The only real difference is that salt/password are used the other way around, with the password mixed in at every step. Bcrypt, however, is different. In your case an attacker only needs a small amount of memory compared to ...

9

You were doing fine up to the point where you wrote "JavaScript". Of course, JavaScript as a language is not fundamentally unusable for crypto (although, as a high-level scripting language, any crypto primitives implemented in JavaScript are likely to be rather slow and hard to secure against side channel attacks). However, when you write "JavaScript", I ...

9

For the purpose of key diversification (that is, assigning a unique key per device), a true master_key is customary; that is, one with plenty of entropy (like, 128 bits or more random bits). Edit: that's now stated in the question. With that caveat, yes, PBKDF2(password=master_key, salt=serial_number, rounds=1000, dkLen=16)is appropriate to generate one 128-...

8

If you want key diversification with a key as input, you are better off using a key based key derivation function (KBKDF) over a password based key derivation function (PBKDF). Difference is that KBKDF requires a key with high entropy. This also means that it does not require a salt nor an iteration count. It does however require context specific data for ...

7

A common approach is to encrypt the private key with a symmetric key derived from a pass phrase. This will be as secure as the chosen pass phrase. I'd suggest sticking with this approach; its conventionality makes it "simpler" than a solution that hasn't been studied well.

7

Identical passwords will still get unique PBKDF2 hashes given a unique salt, regardless of which mechanism you use. I don't think explicitly adding the salt improves the security of this scheme. The designer PBKDF2 have already considered and solved this problem. There is no need for you to try to duplicate their efforts. I think it's safer to use the ...

7

PBKDF2 uses the password as the PRF key. From the RFC: The first argument to the pseudorandom function PRF serves as HMAC's "key," and the second serves as HMAC's "text." In the case of PBKDF2, the "key" is thus the password and the "text" is the salt.

7

Hash algorithm strength is important, but it is not so important in key derivation functions. It is unlikely that even if SHA-1 is broken that it would influence the security of PBKDF2. You are better off using SHA-1, and increase the iteration count up to a level that is tweaked for your specific configuration. If you must, you could use Bouncy Castle to ...

7

Password hashes need first pre-image resistance and should not cause many collisions among typical passwords (preserve the entropy). This collision "attack" violates neither requirement and causes no practical security issues. While this issue can find trivial collisions, they're not between commonly chosen passwords. A SHA-1 hash (and thus the shorter of ...

6

You are correct that using a different salt for each file will slow down encryption and decryption, in proportion to the number of files. But it is not useful to do so. An adversary is not helped if she knows that the salt is common to several files hashed with the same password (under the assumption that she can recognize a correct password with fair ...

6

Summary: I don't know of any good reason why it has to be this way. In practice, I don't think it is necessary to inject the password into every iteration. As far as I know, I think the construction would still be secure (in practice) if you used the salt and password only in the input to the first iteration, and then just repeatedly hashed the result many ...

6

First, realize that PBKDF2 is PKCS #5 is RFC 2898, i.e. http://www.ietf.org/rfc/rfc2898.txt It's essentially an algorithm to securely hash a password as many times as you want, with whatever hash you want. OWASP recommends hashing the password at least 64,000 times in 2012, and doubling that every two years, per https://www.owasp.org/index.php/...

6

In a scenario such as yours, where there is only one password/passphrase, but it is used as key material for the encryption of multiple CBC encrypted files, you will (as you noted yourself) obviously not make it any harder for an attacker to compute your password, should you use a salt. However, using a salt would mean that the encryption of each file is ...

6

Firstly, How much time will it take to crack PBKDF2 while using a 9 character password? and how do I calculate the cost? I'm not specifying any specific system or platform. If a brute force attack is made using the best ever super computer around how much time will it take to crack it? Unless the underlying PRF is broken, brute force and dictionary attacks ...

6

PBKDF2 (as defined by RFC 2898) is a function of the form $$DK = \text{PBKDF2}(\text{PRF}, Password, Salt, c, dkLen)$$ In most practical use cases, the $\text{PRF}$ is $\text{HMAC}$ instantiated with a Merkle-Damgård hash function such as $\text{SHA-1}$. The time to compute $\text{PBKDF2}$ is roughly linear with the iteration parameter $c$, all other ...

5

Don't. Just don't. You are indeed perceptive enough to note that if the output of PBKDF2 is truly pseudo-random, then XORing it onto data is as secure as the password is. But don't. Really. It's not good hygiene. A KDF is a Key Derivation Function, not a cipher. It's not designed to be used as a cipher, so don't use it as one. Use it to derive keys that you ...

5

Password based key derivation functions generate a key suitable for ciphers from a given password. It relies only on the original password being kept secret. The purpose of the salt is simply to prevent the use of rainbow tables. A rainbow table would have to be made for each salt, and if (as is common practise), each user has their own salt, a rainbow ...

5

Yes, you can and use a slow hashing function when constructing the verifier. I would recommend using PBKDF2, as it is designed for this purpose. In fact, Wikipedia says: $v$ is the host's password verifier, $v = g^x$, $x = H(s,p)$. Using of functions like PBKDF2 instead of $H$ for password hashing is highly recommended. Thus, you could use $x=\text{... 5 That's a reasonable solution if you can't use a random salt. If you personalize your hash function for your application, then the salt is globally unique for each user. (e.g. use sitename||username as salt) The only salt reuse happening is that older passwords of the same user have the same salt. But that's a very minor issue. I disagree with Polynomial who ... 5 It's fine, as others have noted. However, by invoking PBKDF2 twice (first to check the password, then to derive the actual key), you're essentially doubling a legitimate user's workload, whereas an attacker still only needs to run it once for each guessed password. Thus, you're cutting the legitimate user's advantage in half, or, equivalently, wasting one ... 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 What I did in one of my password generators is that given a secret key$K$, public data$\text{Pub}$, I first generate a solid "master key"$K_m\$ via key-stretching the secret key using PBKDF2 (any other key derivation function would work, I just happened to have that lying around): $$K_m = PBKDF2(K, \text{salt, iterations, } \cdots)$$ And then derive ...

5

Use gpg --s2k-mode 3 --s2k-count N, where N is the number of iterations you want to use. The manual page says the default is 65536, and you can use any number between 1024 and 65011712. If you like to tweak the defaults, I suggest making this number as large as you can bear it, without introducing noticeable slowdown (e.g., ideal would be to make the ...

5

The threat model of password storage is that of server compromision, where the attacker gain access to the database and server code. The attacker can then run the code to test password candidates, possibly making modifications, porting to faster platform, etc. The attacker will not bother computing the fake hash and fake salt. So this scheme is twice as ...

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