Tag Info

New answers tagged

3

With a hash function that is vulnerable to length extension attacks, like SHA-256, you can turn any random collision into a collision with that random string concatenated with some (partially) chosen data. In any use case where random initial data does not matter, you could use it to generate two documents which have the same hash value and thus the same ...


1

This won't seriously impact the security of the key. HMAC is pretty resilient and changing the last part of the hash won't allow attacks on the a hash such as SHA-256. Note that you only select 4 characters, of which the last one only encodes 4 bits (as it is at the end). That means you've got a check value the size of 2^22 encoded bits, i.e. a chance of 1 ...


0

In a protocol like SSL, if it gets broken tomorrow, we can “simply” turn off all the cipher-suites that use HMAC-SHA1. But what if it is used as MAC protection for encrypted data storage? This isn't as big a problem as it may seem at first. Even with old data it can still be possible to upgrade the MAC later if you find out about a possible attack, as ...


2

I would use HMAC-SHA256. While poncho's answer that both are secure is reasonable, there are several reasons I would prefer to use SHA-256 as the hash: Attacks only get better. SHA-1 collision resistance is already broken, so it's not impossible that other attacks will also be possible in the future. It allows you to depend on just one hash function, ...


0

I managed to find it out by reproducing the test vectors. TL;DR: The standard assumes that you use the low 4 bits of the last byte of the hash, regardless of its length. So replace 19 in the original DT definition with 31 for SHA-256 or 63 for SHA-512 and you are good to go. Finding this out wasn't completely straightforward, as the standard only has a ...


1

When you start chopping off bits of a SHA-256 hash, you obtain a NoSHA-256 :) hash that has none of the security properties of the original hash. I assume, however, that this is not really important in the context of your database. You can compute the probability to have a collision using the birthday paradox. If you only want 64 bits, you may prefer to ...


7

Assuming the hash function is good, and SHA256 is widely believed to be so, the probability of no collisions in $k$ samples into a range of size $n$ (e.g., obtained by selecting a subset of characters) is upper bounded by $exp(-k^2/2n).$ For you, say $k=2^{21}=2,097,152$ (couple million) and $n=2^{64}$ means that your probability of no collision is roughly ...


0

Yes, it's fine. However, you might as well use HKDF-Expand (with your counter as the context information 'info'), so that if you later need some session keys to be larger than 256 bits, the extension is already defined for you. So, $$sk_1 = HMAC(mk, 1 || 0x01)\\ sk_2 = HMAC(mk, 2 || 0x01)\\ ...$$ And if you need a 512-bit $sk_3$ that's: $$sk_3 = HMAC(mk, ...



Top 50 recent answers are included