19
No, you do not need to do escaping or sanitization on data that you pass in as the user input to these functions. They accept arbitrary byte sequences, so any arbitrary byte sequence you pass is acceptable, and there should be no security risks as a consequence of it. In general, cryptographic algorithms operate on arbitrary byte sequences (possibly of ...
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-...
17
SHA-512 is a cryptographically secure hash, PBKDF2 is what we call a Password Based Key Derivation Function. If the resulting secret isn't used as key but as hash value it's also called a password hash. Password hashes differ from secure hashes in the sense that they contain a salt and a work factor / iteration count.
Both cryptographic hashes and password ...
14
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 ...
13
Yes, it is. PBKDF2 derives a DK, a "derived key", which is indistinguishable from random. This is mainly because function within PBKDF2 is HMAC, and HMAC is a PRF. Let's see the definition from Wikipedia:
In cryptography, a pseudorandom function family, abbreviated PRF, is a collection of efficiently-computable functions which emulate a random oracle in ...
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$, ...
12
To paraphrase my answer to an earlier question, PBKDF2 is a generic high-level algorithm that internally calls a pseudorandom function (PRF) to process its input. The PBKDF2 spec does not mandate any particular PRF, so implementors are free to choose any PRF they want (as long as it meets the definition of a secure PRF, and can accept the input PBKDF2 gives ...
11
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 ...
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 ...
10
TL;DR: You want to use Argon2d here.
Even though Argon2 was standardized only somewhat recently, it is the result of the Password-Hashing Competition (2013-2015) and was a late re-design of Argon which also picked up ideas from a few other finalists. Since then there have been attacks on it, which caused the scheme to be tweaked to counter them better, this ...
9
That particular usage of SHA-1 uses HMAC, and then iterates that as part of PBKDF2 (which is actually defined for any PRF, not just HMAC-SHA1).
As of this date (2017-05-18) HMAC-SHA1 is unbroken in terms of collisions and other attacks, so PBKDF2-HMAC-SHA1 is still considered safe. The HMAC construction, along with the many iterations in PBKDF2, protects ...
8
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.
8
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 ...
8
I think you are overstating the complexity of PBKDF2, and also, not matching it feature-wise with your alternative. Let's dispatch the latter first: as gammatester's comment mentioned, PBKDF2 supports variable output size. If you built that into your proposal, it would become more complex.
Once we control for that, PBKDF2 is hardly more complex than your ...
8
You're right. Unless the software is doing something very peculiar, which should be very apparent when reading the code and documentation, and I can't imagine what it could be, the salt generation and the application of PBKDF2 are unnecessary.
If you have 32 bytes from a cryptographically secure random generator, you can use these 32 bytes as an AES-256 key....
answered May 12 '20 at 9:23
Gilles 'SO- stop being evil'
15.1k3 gold badges40 silver badges77 bronze badges
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
So, here's my question: is there a point where the salt size doesn't matter anymore in terms of security and where it might even decrease it?
The purpose of a salt is to prevent the attacker from targeting multiple users' passwords with the same try or caching common passwords' hashes in a table. You need enough salts that each user has a unique salt. After ...
7
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 ...
7
There's no practical limit to password or salt length you can use with PBKDF2.
Theoretical limit, however, is determined by the hash function used by PBKDF2: under the hood, it uses $HMAC(Password, Salt || Counter)$, which in turn will translates to a series of hash function calls:
$K_0 = H(Password)$ (assuming password is longer than hash block)
$HMAC =...
7
TL;DR: Yes, you can use PBKDF2 as a stream cipher. However, you should not use it for that and for its intended purpose (i.e. password-based key derivation) at the same time. Instead, if you need to do both, call it twice.
PBKDF2 is a password-based key derivation function — or, rather, a scheme for constructing such a function out of a variable-key-...
7
These hash functions are also used for the key derivation function. Both are roughly equally secure for a KDF in the sense of collision resistance etc., but SHA512 offers a bit more security as countermeasure for custom hardware attacks, since the memory requirements are a higher than for SHA256 and custom hardware to crack the passwords like FPGAs is more ...
7
All the parameters you've mentioned can be public. Furthermore, only the salt, IV and ciphertext cannot simply be guessed.
The IV is generally easy to retrieve once the key is known, so the making the IV secret doesn't make sense. In CBC mode and many other modes you may just not get the first plaintext block if the IV is completely absent, but the rest of ...
7
There's no point in using either an ASIC or a GPU to calculate a single password hash. That's true whether you use PBKDF2 or scrypt or Argon2 or whatever.
What massively parallel devices like GPUs or ASICs are good for is hashing millions or billions of passwords at the same time. That's useful if you're mining a cryptocurrency or trying to crack a hash ...
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
Of course you can - but as to whether or not it's a practical or advisable idea, I don't think so. It's not really prudent to implement crypto systems/protocols and assume that they'll be fine in 10 years.
Cryptography is a dynamic field that changes rapidly; algorithms get broken, hardware improves, governments try to undermine the field, and attacks only ...
6
You have two algorithms, $A$ and $B$, that claim to compute two (essentially) injective, hard-to-invert and costly-to-compute functions $F$ and $G$. Your fear is that either of the algorithms instead compute functions $F'$ and $G'$, that may be neither injective, hard-to-invert, nor costly-to-compute. This may happen because of programming mistakes or (these ...
6
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 ...
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 ...
6
No, you should not use a password directly as an HMAC key.
However, it is fine to use HMAC as part of a key derivation function, which generates keys from a password. However, do not mistake the output as naturally having higher entropy than whatever you put in. "password" has essentially 0-bits of entropy, and running it through a KDF will not magically ...
6
The only downside to SHA-2 over SHA-1 is that SHA-2 is a little slower.
In this case, that is of no practical consequence whatsoever because you're trying to make something slow to compute, and it is only a matter of raising the number of iterations to make it cost a certain number of bit operations in serial.
However, please consider using the modern ...
answered Jan 21 '18 at 21:29
Squeamish Ossifrage
44.1k3 gold badges92 silver badges188 bronze badges
Only top voted, non community-wiki answers of a minimum length are eligible