# Tag Info

0

Your design is that the server has a key (which you call the salt, but would have to be secret here) and generates the client's public and secret values using e.g.: $$p = ID\\ s = H(k|p),$$ where $H$ is some hash function. This seems secure: if an attacker only has access to $p$ they have no chance of generating $s$ without knowing $k$. However, if $H$ is ...

3

The construction you are proposing is called the "envelope" or "sandwich" MAC, it predates HMAC, and it is in fact secure—provided the key and message are appropriately padded. That is, $$\text{SHA256}(k \parallel m \parallel 1 \parallel 0^{b - 1 - (|m| \bmod b)} \parallel k)$$ is secure, as long as $k$ is the underlying hash function's block length $b$ ...

1

You could do something fairly simple, such as $UserSecret = Random()$ $UserID = HMAC(ServerSecret, UserSecret)$ Send the user the two values. When he reconnects, he sends the two values back. If re-calculating $UserID$ with the user's $UserSecret$ gives the same $UserID$ then that proves (to a high degree of certainty) that it's the same person that was ...

1

With a KDF meeting its objectives, the only way the leak of the persisted key compromises the confidentiality of the other is correctly identified in the question: a password guess can be checked at the cost of one evaluation of the KDF based on the leaked key and its corresponding salt (and assuming the password's entropy is significantly less than the ...

Top 50 recent answers are included