# Tag Info

8

Let's get terminology right. If you talk of "unknown s" then s is not a salt; when some piece of data is secret, we call it a key. And your "hash function" is then a MAC. In the context of "password hashing", such things are sometimes called "peppering" (as always, technical terminology is, at its core, a collection of bad puns). If your MAC is correct ...

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

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

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

4

For any value $x$ chosen randomly in a set of size $N$, and hash function $h$, publishing $h(x)$ allows for an exhaustive search on $x$ with average cost $N/2$. This is unavoidable. The problem with passwords is that, by virtue of fitting in the brain of a human, they tend to come for a set of potential passwords of relatively small size $N$. We try to cope ...

4

You cannot recover the password from the hash. That's not something that password hashes are designed for — quite the opposite: with a proper password hash, the only way to recover the password given the hash is to make a guess and verify it — and the better the hashing scheme, the more costly verifying guesses is. Passwords are used for authentication: a ...

3

The salt can be kept public. All that matters is that the salt is available for you to use when it comes to re-deriving your password from some input guess. In many ways, a salt performs the same function that an IV does for ciphers. You can read more about salt and password hashing here.

3

I'd assume the sample (since it isn't listed) is storing a salt per encryption, because that sample assumes that only the password is variable and has no concept of users. Using the salt per user is effective because the difficulty of using a rainbow table goes up per user (if the user table is compromised), and per your question additionally salting per ...

3

No, it should not be necessary to derive a unique key for each message, although it certainly shouldn't do any harm, either. CBC mode is provably secure (in the IND-CPA sense, or even IND-CCA2 if combined with a MAC) even if the same key is used for multiple messages, as long as the underlying block cipher is secure (a PRP) and the IVs are distinct and ...

3

First and foremost: it is a bad idea to invent a method to sign or encrypt with RSA (or any crypto). Standards like PKCS#1 or ISO/IEC 9796-2 are here for that purpose, and even these occasionally have more or less subtle flaws. Given comments, I'll assume that the question is about an RSA encryption scheme enciphering message $M$ into $(M||S)^e\bmod N$, and ...

3

Ask the server for the salt for a specific username. Compute the expensive salted hash on the client, send to server Server performs a cheap unsalted hash(or HMAC) on the hash received from the client and compares with the stored value Note that sending a hashed password doesn't mean you can use an insecure transport. You still need proper transport ...

3

Let's try to avoid random per-password salts. If the only requirement for salt is to be unique, which is the case for good password hashing schemes, you'll need: $globalSalt$ is a secret random 32-byte string. $userId_n$ is a unique user identifier. You can use, for example, $HMAC$-$SHA256(globalSalt, userId_i)$ to generate salt for each user $i$. Or, ...

3

This appears to be describing an attack that allows an active attacker to defeat a seemingly-secure protocol. In the normal setting where no one is attacking them, Alice and Bob share a password $W$; Alice derives a symmetric key $K$ from the password $W$ and encrypts her message with $K$, then sends it to Bob; now Bob can derive the same key (since he ...

2

First, separate the idea of "salt" from "hash". Salting is no more than a process applied to the message in a known way, such as appending the salt value to the end of the original data, yielding a "salted" message that differs from the original message. The hash algorithm is then performed using the salted message as input, yielding a digest value. A ...

2

Security against attacks using rainbow tables requires using a salt. In your first step $A_1 = MD5(P || S)$, you're already mixing in a salt. Provided that the salt is indeed globally unique (and randomly generating the salt is a correct way of achieving that), you already have protection against rainbow tables. In a nutshell, rainbow tables trade off a ...

2

Well, as others have said, you would not be able to do with a standard salted hash function. However, if you were use a specially designed hash function (that allows this specific comparison), then it would be possible. Here is a proof-of-concept idea, to show that it is possible: Suppose $N$ was a large composite number of unknown factorization Let our ...

1

No. A salt for a PBKDF is to prevent a bruteforce search to be able to target multiple passwords at once. You generally choose one salt for a password per user, and store it. So you do not keep generating salts, only when the password is set/changed. The role of an IV depends strongly on the mode. In some modes it is only required for semantic encryption ...

1

When using a salted, key-stretching KDF, like PBKDF2 or scrypt, you are in effect stretching both the salt and the password. That is to say, what you're calculating is $$\rm key = KDF(password, salt)$$ where changing either of $\rm password$ or $\rm salt$ requires the slow $\rm KDF$ function to be entirely recomputed. In fact, if changing the salt did ...

1

Short answer to the question is 'no', if the users of the service can choose their passwords. Details If PIN or password is used? There is no way to force people to select passwords that are secure. When password is long, at least some (lazy) users will make passwords that are long, but contain little entropy. When password or PIN gets longer people tend ...

1

You don't need a salt (it defaults to a zero length salt) if you generated the session keys using Diffie-Hellman. You should however use a different info (octet) string for each key in the expand part of the function. The idea is that the salt makes sure that the derived keys are different if the input keying material (IKM) repeats. If no salt is used ...

1

I am wondering whether this is completely impossible if you are willing to interpret Hash in a very broad sense and use pairing-based cryptography. Stephen mentioned in a comment that the entropy of the credit card is low, so we should not rely too much on it in any solution. What I am considering is the following. Assume for simplicity that we have access ...

1

No, you cannot do this. The entire purpose of a salted hash is to obscure the relationship between identical plaintexts and their hashes. Hashes' resistance to rainbow table attacks also relies on this feature. Let there be two plaintexts $P_a, P_b$, two salts $S_a$, $S_b$ such that $S_a \neq S_b$, and two salted hashes $C_a = H(P_a, S_a)$, $C_b = H(P_b, ... 1 In the first part of your question, you appear to be describing a password hashing scheme. A common (or, at least, commonly recommended) way to construct such schemes is based on a message authentication code (MAC). Specifically, let$\operatorname{MAC}_K(m)$be a message authentication code with key$K$and message$m$, and let$H(s,r) = d = (r, c)$, ... 1 If I understand the question correctly, you got an unknown value$s$, and known values$d$and$r$, such that, for some one way function$H$,$H(s,r) = d$. You want to find both a function$G:\{0,1\}^*\times\{0,1\}^*\to \{0,1\}^*$and a function$V:\{0,1\}^*\times\{0,1\}^*\to \{0,1\}$such that for any$x$,$V(G(d,r'),s) = V(d,s) = 1\$. Technically, at ...

1

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

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