Hot answers tagged

22

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


17

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

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

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

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


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

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


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

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


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


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


2

So the advantage of the keyfile in addition to the password is that it is basically a form of two factor authentication: You have a password (something you know), and a token (something you have). The problem is that your salt must be available in order to derive your password based secret, which would mean your token (the salt) is not really separable from ...


2

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 really hard to recover. And "yes", companies ...


2

Client-side encryption can prevent a passive eavesdropper on the server's memory—like Heartbleed—from seeing the client's secrets. But, if you might be concerned about any more serious compromise of the server, who delivers to the client the JavaScript code that performs encryption?


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