# Tag Info

3

I had to do the exact same thing for unique product identifier codes. In my case they needed to be random looking, not cryptographically secure, so I had more room to work with. I still went with a cryptographic method since that is what I was familiar with. In your case, you are looking for just under $2^{36}$ values, for which all values are unique, and ...

0

You don't need a hash function for this. Given that you're already using AES-128, and that your master key $N_s$ is 128 bits long, a perfectly good method for deriving the session keys $K_s$ would be to encrypt the random number $R_0$ (padded to a full AES block) using AES-128 (in ECB mode, i.e. using the raw block cipher) with $N_s$ as the key. Even if ...

0

First, Don't roll your own crypto. Second, you don't need to negotiate session keys for each transmission. As long as the network-secret is safe, all the connections using this secret are always safe. However, you mentioned forward secrecy. You can't get this with pre-shared keys. If the keys gets screwed every connection (now and in the future) can be ...

0

So, they both have a 16 byte shared secret, and you want to create a shared 16 byte (=128 bit) AES key...am I missing something here? Why not just use the secret as the key! Just plug it into CBC or CTR or GCM or something, and you'll be good. If you'll be running this for a large number of messages, then the scheme you described using HMAC would be ...

3

In the first section of this answer I'll assume that through better hardware or algorithmic improvements, it has become routinely feasible to exhibit a collision for SHA-1 by a method similar to that of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu's attack, or Marc Stevens's attack. Neither has ever been achieved publicly, but it is clearly feasible (the ...

3

When people say HMAC-MD5 or HMAC-SHA1 are still secure, they mean that they're still secure as PRF and MAC. The key assumption here is that the key is unknown to the attacker. $$\mathrm{HMAC} = \mathrm{hash}(k_2 | \mathrm{hash}(k_1 | m))$$ Potential attack 1: Find a universal collision, that's valid for many keys: Using HMAC the message doesn't get ...

0

I think I understand what you're asking now. ChaCha is essentially a block cipher with no key schedule. This has an advantage, less SRAM required for constrained devices, and even for desktops, less cache calls ( https://stackoverflow.com/questions/10274355/cycles-cost-for-l1-cache-hit-vs-register-on-x86 ). Part of the reason why ChaCha manages to be as ...

5

Collision attacks are attacks where success is obtained when two values obtained by some process are identical. The term is often used in the context of hashes, since collision-resistance is one of their desirable property. Birthday attacks are collision attacks that work by the effect of chance, with the colliding values obtained by some roughly random ...

3

TL;DR: You put less of a burden an any attacker trying to brute-force this. And please note: Implementing PBKDF2 shouldn't be much harder than implementing your approach. Now let's head over to the explanation why "your" scheme is really bad for password-hashing. The scheme you propose is that each try cost you exactly two hash-function evaluations. One ...

Top 50 recent answers are included