Hot answers tagged

6

From looking at the source or 7zip that seems to be the case. The format has a place for a salt, as SEJPM's link shows. It is mixed into the homebrewn iterated SHA-256 hash before the key. The 7zip decoder even seems to support salts. However, the encoder never uses a salt. Oddly there is even code for generating a random 4-byte salt, but it is commented ...


5

You are right that if it costs Alice & Bob effort $N$ to agree on a key in this way, then it costs Eve only effort $N^2$ to find it. So the protocol is not secure in the standard sense, and probably not very useful. (Maybe in some highly constrained situation with very short-lived keys?) More generally, this purports to be a key agreement protocol whose ...


5

512 bits is overkill for even global uniqueness. 256 bits should be enough, with a good random number generator: even if every person on earth generated one every nanosecond, it would take a million million years to reach the birthday bound. However, I agree that global uniqueness is a good idea. If anyone anywhere uses the same salt and password hash (or ...


4

From a cryptographic standpoint a MAC would be perfect (e.g. HMAC-SHA256(strong secret key, email)). As long as no-one knows your secret key it is infeasible to find a token for another mail. One thing you will probably have to handle is: What happens when someone changes their email? What if someone resubmits the same form? Should the token be invalidated ...


4

There's absolutely zero need to have the token tied to the user's email address. Just add a column in the database for the token, generate the token randomly, and send it out to the user. If you want to go one step further, send the user the token, but only store $H(token)$ in the database, where $H$ is a sound cryptographic hash function of your choosing.


4

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


4

It is possible to reverse the birthday bound calculation. You can get an easily computable approximation using the expected number of collisions: If you had random $n$-bit salts, after $k$ values you would expect $2^{-n}\binom{k}{2}$ collisions. If the collisions are rare, they are mostly single collisions, so there are approximately $u = ...


4

Yes! I'd recommend at least 64 bits, but that's only because powers of two are convenient and space is cheap. Furthermore, usually a salt of the block size of the hash you're using is usually best, because salting at all will almost always involve an extra block, so why not fill it up given that there will be no performance impact? But once again, yes, ...


3

The answer is yes. There is no problem with sending the IV in the clear. So, this is fine. Likewise, the salt is not there to add entropy so this is also fine. Having said that, I understand from the code that the application is not using a uniformly distributed (and so high entropy) key. This is a problem and very bad, since it is easy to carry out a ...


2

In cryptography an Initialisation Vector or IV is an input of fixed size required to randomize the output of a cryptographic primitive. It is not meant to be secret, so there is not problem in make it available to the attacker after the encryption. The crucial point about the IV is its uniqueness and, for some mode of operation, its unpredictability. So, if ...


2

Can you help me understand what a cryptographic “salt” is? In the context of password creation, a "salt" is data (random or otherwise) added to a hash function in order to make the hashed output of a password harder to crack. When might I need to use it? Always. Why should or should I not use it? You should always use a salt value with your ...


2

First, good password hashing functions like PBKDF2 and scrypt usually take the password and salt as separate parameters, meaning the user does not have to worry about this. However, with some algorithms they do and in any case the theoretical question is important. Some of those methods you mention are clearly worse than others: Binary OR would be ...


2

Short answer: Yes, you're right.


1

No it isn't a good way of salting and it isn't the standard way either. There is no reason or benefit to store the salt before it is used. The point of salt is just to prevent parallel and precomputation attacks. Storing it ahead of time means in an undetected compromise the attacker would learn of 'future salts' which undermine the precomputation ...


1

It is secure. The IV only needs to be indistinguishable from random to an attacker, and it is as long as the salt is random. There is one remark: if you extract more key + iv bytes than the hash function in PBKDF2 returns then the PBKDF2 function is executed twice. An attacker however only has to find the key, not the IV, so an attacker doesn't have to do ...


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


1

Some research brought up this paper On the Security of Two MAC Algorithms (Preneel and Oorschot, 1995). The authors state that it's possible to significantly reduce the claimed security so that the security is about the same as collision resistance instead of preimage resistance. The details can be read there and in the references.


1

Your setup is secure. However it is largely "unneccessarily" secure. First the generation method: You're using the RNG-CSP which is (I guess) Microsoft's software interface to the Windows secure PRNG, so this is fine. Now for your tokens: You're restricting the character set, which reduces the possible entropy per byte, but is fine if you're in a ...



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