Tag Info

Hot answers tagged

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


5

Given that SHA-512 is used, there is no practical benefit to iterating hash = sha512(salt + hash) compared to iterating just hash = sha512(hash). For some parameters, it even weakens the scheme by a factor of nearly 2 against the attack that most matters: guessing the password. Let's first justify the weakening. Assume salt is 125 bytes. salt + hash is ...


5

Edit: I missed a detail in the original question when writing the below. I compared the effects of including the salt in each iteration to including the password, but the original question asked about including the salt versus only iterating on the previous hash output. Mea culpa. My link to Thomas Pornin's answer to a related question contains an ...


4

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


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


4

The usual answer is that a salt can be make public; if that was a problem, then the salt would not be called a "salt" but a "key". In some protocols, unauthenticated obtention of the salt is the norm, and is not considered to be a problem. E.g. with SRP, a password-authenticated key exchange, where any salting and hashing must necessarily occur client-side. ...


3

PBKDF2 is designed for low-entropy passwords. Assuming your key is generated by a CSPRNG, then running it through PBKDF2 is redundant. I don't, however, believe it could be weaker than the original key.


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

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

Usually the salt is stored with the hash. Let's say we have a table users with the field password. The hash is generally written concatenated with the salt (divided by a separator like :) So the final field value will be something like cbc0a790b2f28fc72ca43eb749028b9f:21022011 Note that the salt should always be in cleartext (or being reachable in some ...


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


2

The resume of that other answer could be: When you have a password hashed, it's hard (very hard) to find out what was the original password: you have to try all combinations, until you find the hash. That's brute-force. Someone can speed up a bit this process, by pre-computing many passwords: he'll store all those passwords / hashes, and will try to find ...


2

Thomas Pornin has already answered your question accurately, but I'd like to add a strong warning to the discussion. You should probably not be computing password hashes client-side. In the most naïve approach, completely eliminates most of the value in password hashing. By computing hashes on the client and simply comparing their equivalence server-side, ...


1

Problem statement You have a list of messages $(m_1, m_2, \dots, m_n)$, possibly with corresponding tags/descriptions $(t_1, t_2, \dots, t_n)$, that you want to store. You want to protect confidentiality of the messages (but not the tags/descriptions) against an adversary that compromises your storage. You have a single secret passphrase $pw$ at your ...


1

If the salt value is not secret and may be generated at random and stored with the password hash, a large salt value prevents precomputation attacks, including rainbow tables, by ensuring that each user's password is hashed uniquely. This means that two users with the same password will have different password hashes (assuming different salts are used). In ...


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