# Tag Info

## Hot answers tagged pbkdf

29

Coming up with a specific number is hard. Realistically, all three options take you well out of the realm of ever having more than the absolute worst passwords brute-forced by an attacker. The primary gain of scrypt and Argon2 over bcrypt is a hit to parallelism due to the addition of memory requirements. GPUs with thousands of cores will need (but don't ...

18

This is called Client-Independent Update, according to the Catena paper. It is desirable to be able to compute a new password hash (with some higher security parameter) from the old one (with the old and weaker security parameter), without having to involve user interaction, i.e., without having to know the password. We call this feature a client-...

13

You're right: there is no need for key stretching if your key already has enough entropy to resist brute force attacks without it. A 128-bit keyspace should be plenty for that. AFAIK, there is no significant difference between HKDF and single-iteration PBKDF2 in practice. Both effectively achieve the goal of expanding the input key to a potentially longer ...

9

The password P in the Microsoft implementation is first encoded using UTF-8. The iteration count c defaults to the value 100, and the hash algorithm Hash to SHA-1. The output is identical to PBKDF1 up to the maximum output size of PBKDF1, which is the output size of the hash. After that the first-to-last hash is prefixed with a counter (as a string ...

6

Is there anything wrong with swapping SHA2 for Keccak for use in PBKDF2? There are 2 main issues. Performance and implementation. Performance The performance issue is from an attacker-defender scenario, where the attacker is able to provide FPGA or ASIC resources. In this scenario, Keccak is several times faster than SHA-2. I will use a Blake comparison ...

5

Yes, using a PBKDF and a SHA-256 hashing algorithm on the same password negates the usefulness of the PBKDF, by allowing to test a candidate password using a single hash; and (assuming unsalted password hash, which is not the case in the question) amortizing across multiple users/instances the computation of a rainbow table allowing to find the password ...

5

Are there any memory-hard PBKDF constructions that can be implemented using only common standard crypto primitives, like (generic) hash functions and/or block ciphers? Of course there is one, and it even got a "special recognition" at PHC: Catena. I won't go into the details of Catena here (the paper does it much better on its 50+ pages), but it comes ...

5

OpenSSL uses EVP_BytesToKey, an algorithm proprietary to OpenSSL, with a salt and an iteration count set to 1. The algorithm is secure; the iteration count of 1 of course is not secure (for passwords with an average strength). Implementations for other languages/runtimes can be found by searching for it by name. This page (on nabble.com) explains a bit ...

5

In case 3, one must consider that the knowledge of $salt_2$ and $k_2$ (or/and other ones) allows to test a guess of $pwd$ with about $c$ evaluations of $H$. The "brute force" attack becomes doing this with a dictionary of passwords with the most common first. Password crackers using GPUs or ASICs reach astonishingly high hash rates, and for $c$ in the ...

5

Is it a risk to replace the use of a pbkdf function with a multiplication of the form S=J**K, creating a big number and only use the bits we need to exchange the only message that conversation needs using a xor operation between S and the message? One concern I would have would be a possible bias in the bits of $S$; at the very least, the lsbit of $S$ would ...

4

Is it fine to do that? Yes, it should be fine, as long as you do not reuse the key/salt-pair for encrypting another piece of data. Or is there a more standard construct? Any authenticated encryption algorithm would work. E.g. AES-GCM with the PBKDF2-derived key. If you are going to use the same password for encrypting many such pieces of data there are ...

4

I don't think it is a good idea, for two main reasons. Firstly, you are basing your security on the obscurity of a parameter that was not designed initially for being secret, which is a risky practice. It is similar to hiding the salt. Secondly, following your example, you may in principle think that a random number of iterations between 10 and 100,000 is ...

4

For full explanation, see Is there a standard for OpenSSL-interoperable AES encryption? . Short answer: what openssl enc (without -K for raw) uses is not PBKDF2; it is almost PBKDF1, with iteration count 1. This imposes almost no cost on attacker trials, so unless your passwords are strong enough to be keys by themselves you should avoid it if you can. In ...

4

Can you explain what using PBKDF2 with 1 iteration is doing in the above? Is this the same as just doing something like a HMAC SHA256 hash? This is mostly HMAC-SHA256, but you can declare how many bits of derived key you want. I assume it is used this way for ease of implementation (it's easier to have one working implementation of PBKDF2 than many ...

4

The purpose of key stretching is to increase the strength of the resulting output keying material, compared with the input keying material. The input of the keying material is of course generally a password. If the strength of the keying material is already high enough then there is not need to stretch the keys. Note that the word "length" is in this case a ...

3

Yes and no, depending on what you mean by "storing passwords". If you mean "storing my own passwords in a password store", then "no", since this is clearly not the goal of a KDF. But if you mean "storing authentication data in a database to authenticate our users", then yes, since passwords stored in that way are ...

3

I don't think you get those "examples": they implement HKDF. The full name of HKDF is HMAC-based Extract-and-Expand Key Derivation Function. They do not use PBKDF2 because they don't implement a specific use case, they implement the algorithm. So it is perfectly fine to use: master = PBKDF2(SHA-256, iterations, salt, password, 32) authKey = HKDF(SHA-256, ...

3

If you have access to a PBKDF2 implementation, I'd just take a 8 byte output of PBKDF2. Whether that's a Little Endian or Big Endian value doesn't matter so long as you're consistent. Since PBKDF2 has good spread, a 64-bit capture from it gets a 50% chance of collision around the 5.1 billionth different input, still down at 1% around 600 million. (See the ...

3

Like I wrote in the comment, the method here is pretty similar. The differences: Rather than deriving each site password directly from the password, I recommended deriving a single master secret using a password hash and then deriving the site passwords from that using another KDF. You are truncating the PBKDF2 output to 64 bits. You define the method of ...

3

TL;DR: If an attacker can gain less than 50k-100k USD from breaking all the "passwords" you're fine, else you could be screwed. (for 10k iterations, using SHA-1 for PBKDF-2) How secure would be to use PBKDF2 without salt (or with the same salt for all) with a 16 digits passwords that are unique (there can't be two identical)? It would keep medium-...

3

Are there any security issues related to use the same SALT in PBKDF2 for all IDs? Yes, you can build a rainbow table or brute force the ID's. An attacker could build up a table with tokens. Once the table exists the attacker can try all possible ID's until one of them matches. That way the function is reversible and your requirement to keep the ID secure ...

3

Initialization Key hash function hashstring Configuration: E is Rijndael with a block size and key size of 256 bits Input: keystring Output: hash The keystring is padded up with bytes valued zero and split up in blocks of 256 bits $S_0$ to $S_n$; The key blocks $K_0$ to $K_n$ are generated, where $K_0$ consist of $S_0$. The following blocks - if any, most ...

3

If I got the code correctly, it works in the following way: Computes digest $D = SHA256(password + salt)$ Computes table T with $N=MEMSIZE /32$ elements: $T_{0}=D, T_{i}=SHA256(T_{i-1})$ Set $R=T_{N-1}$ Update $R$ by mixing it with $T_{0}$, $T_{1}$, ..., $T_{N-1}$, where "mixing" is a byte addition or subtraction depending on value of the byte After ...

3

There aren't many KDFs that will be faster on an AVR than PBKDF2. In your case, it's likely that the only thing you can do is find a hash which can be implemented efficiently on an ATmega2560, and implement it with as many optimizations as possible. A highly-optimized implementation of a hash algorithm is likely to improve speed significantly. That's really ...

3

Generally you should try and avoid deriving keys from passwords on embedded devices or passwords. There are a few strategies that could be used. First of all, you can try and design a system that doesn't use a password. Passwords are very tricky to secure, and password hashing algorithms (or, in this case, rather Password Based Key Derivation Function or ...

2

You should not use a Password Based Key Derivation Function (PBKDF) for this. Instead you need a Key Based Key Derivation Function (KBKDF). You could use for instance NIST SP 800-108 (PDF) or HKDF. Both specify means for key derivation using some kind of context which is used as input for the KDF (e.g. a label or sequence number). A salt is used in a ...

2

This kind of key management problem is a big reason why encryption is not more widely used for everyday data. I see a single easy way to do this, I think it is similar to the way disk encryption systems work, and it may not work for your uses. For each file, a random key $kf$ is generated. 2 copies of the key are encrypted, one with a key derived from the ...

2

An alternative which appeared after the password hashing competition is Balloon hashing. It can use any standard cryptographic hash function as it's only crypto primitive; all other operations are simple concatenations or XOR which can be done in almost any high level language. I've even implemented it in Microsoft T-SQL using the HASHBYTES() function with ...

2

Actually, the strength of the derived key is likely to be limited by the strength of the password; for example, if the user selects the password "password", well, that's likely be to within the first couple that an attacker checks. However, if we assume that the password is stronger than what most people select, then the next limiting factor is $n$. The ...

2

Based on your code, it seems that the seed value you're deriving from the password is 64 bits long. This implies that: due to the birthday paradox, you will likely see seed collisions after about 233 passwords, and with modern hardware, a reasonably motivated attacker could enumerate the entire 64-bit seed space, and thus break your encryption regardless of ...

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