XOF, nice.. but what is the point of expanding SHAKE256 to e.g. 4096 bits, if its security remains 256 bits ?
SHA-3 Standard [pdf]
61–70 of 91 posts
Re: SHA-3 Standard [pdf]
#62Earlier quoted context omitted.
SHA-2 is fine, and in fact the more conservative choice right now. SHA-3 didn't happen because SHA-2 was threatened. My current favorite conservative hash choice is SHA512/256, which is the SHA-2 that generates a 512-bit output but truncates it to 256. It gives you the same length extension protection that is the most important feature of SHA-3, and is available in most libraries already. I have never recommended to…
Unfortunately, the SHA cpu extensions that will soon be available in Skylake Xeon parts (and the crypto extensions in ARMv8-a) only support sha2-256 (and SHA256/224, and the ill-advised sha1... why is Intel adding instructions or microcode for a hash function that's being phased out?). So you have a choice between a faster-in-software-on-64bit sha-512/256 and a faster-in-hardware sha-256. Unless there's some way to g…
In that case HMAC-SHA-256 may be a good choice. It too is immune to length extension attacks, and the HMAC construct has proven itself to greatly augment the strength of the underlying hashing algorithm (e.g. MD5 is considered broken, but HMAC-MD5 is not). It's just twice as expensive as SHA-256, so I'm not sure if that's faster than SHA-512 on software versus HMAC-SHA-256 on hardware.
Re: SHA-3 Standard [pdf]
#63Earlier quoted context omitted.
SHA-2 is fine, and in fact the more conservative choice right now. SHA-3 didn't happen because SHA-2 was threatened. My current favorite conservative hash choice is SHA512/256, which is the SHA-2 that generates a 512-bit output but truncates it to 256. It gives you the same length extension protection that is the most important feature of SHA-3, and is available in most libraries already. I have never recommended to…
> SHA-2 is fine, and in fact the more conservative choice right now. SHA-3 didn't happen because SHA-2 was threatened. To extend on that, shortly after SHA-1 fell, there was the very real threat that the SHA-2 family would follow suit (they are conceptionally similar). This worry brought NIST to hold the SHA-3 competition. Fortunately, the SHA-1 attacks did not turn out to be transferrable, so far, and consequently t…
> If you need a really conservative choice, hash the message m as SHA512(m)||SHA3-512(m) (the concatenation of the individual hashes).
Although keep in mind that you'll leak information about the input if either hash leaks information about the input.
For example, the hash function `badhash(blocks) = crc(blocks) ++ goodhash(blocks)` is collision resistant... but you wouldn't want to use `badhash(pad(secret) ++ nonce)` as a precommitment scheme. All of the extra entropy in the nonce, which otherwise might have protected against brute force attacks on low-entropy secrets, is being given to the attacker via the crc.
Re: SHA-3 Standard [pdf]
#64Earlier quoted context omitted.
It's faster (in software).
One of the key points of hashes in cryptography is to be computationally expensive rather than faster. Faster means more password attacks per second. Granted faster is better for non-cryptographic purposes like data indexes, but even there I'd consider performance secondary to the hash size, etc
Most applications of hashes, to inputs that aren't passwords, are protected because their input space is so large that it can't be brute forced or because their input simply isn't secret. The speed of the hash function then becomes a feature instead of a weakness.
For example, suppose I give you the hash of a random 128 bit network packet payload, and you have hardware to evaluate the hash function I used a quintillion times per second. How long will it takes you to find that packet? Well, there's 2^256 possibilities and you go at a rate of 10^18 per second, so... 2^128/10^18s ~= 10 trillion years.
Key derivation functions (i.e. password hashes) are a specialized version of hash functions for private low-entropy inputs. They need to be slow to prevent quickly enumerating and evaluation all likely inputs. Paying that time cost would be unnecessary, wasteful, and bloated for inputs that are public or high-entropy.
For example, Git would suffer enormously if it used a key derivation function instead of a standard hash function. Useful operations like rebase and squash would go from taking milliseconds to taking minutes or hours.
Re: SHA-3 Standard [pdf]
#65Earlier quoted context omitted.
No: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another. Trying to make one that does both leads to something that sucks at both.
> No: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another. That's not true either. Hashes are recommended to be used as input to KDFs. "Modern password-based key derivation functions, such as PBKDF2 (specified in RFC 2898), use a cryptographic hash, such as SHA-2" Source: https://en.wikipedia.org/wiki/Key_derivation_function#Key_st... > Trying to make one that do…
The hilarious part here is Wikipedia calling PBKDF2 modern. It's a 2000 minimal update (to generate more bits, to be kind of UTF-8 aware) of a 1993 standard.
At the time of the RFC publication it was already obvious its security was way behind bcrypt that was used in OpenBSD since 2.1 (June 1997), which did its best to be ASIC hostile, which isn't the case for PBKDF2.
In retrospect, NIST choosing PBKDF2 over bcrypt in NIST SP800-132 could be seen as part of the effort to weaken standards for NSA profit.
Re: SHA-3 Standard [pdf]
#66Earlier quoted context omitted.
> SHA-2 is fine, and in fact the more conservative choice right now. SHA-3 didn't happen because SHA-2 was threatened. To extend on that, shortly after SHA-1 fell, there was the very real threat that the SHA-2 family would follow suit (they are conceptionally similar). This worry brought NIST to hold the SHA-3 competition. Fortunately, the SHA-1 attacks did not turn out to be transferrable, so far, and consequently t…
Concatenation of the hashes seems like an unjustified risk, that in certain circumstances will allow weaknesses from either algorithm to flow throw to the final hash. If you really want to combine the hashes, XOR seems like a safer bet to me (since the algorithms are unrelated there should be no potential cancellation of entropy).
Seems like XOR is better for approximating a random oracle, and appending is (negligibly) better for ensuring collision resistance. People often are not clear about which of these two very different properties they actually want out of a hash.
Re: SHA-3 Standard [pdf]
#67XOF, nice.. but what is the point of expanding SHAKE256 to e.g. 4096 bits, if its security remains 256 bits ?
To derive 4096 bits of pseudorandom data from an input. For example, you could derive 16 256-bit keys from one master secret.
Re: SHA-3 Standard [pdf]
#68Earlier quoted context omitted.
I think you are confusing hash functions with key derivation functions..
I'm not. Hash functions are used in cryptography for password storage (eg SHA2-512). Best practice would be to use a KDF with a hash salt, but in a lot of cases, SHA2 + salt + pepper is sufficient.
> SHA2 + salt + pepper is sufficient
Not even close. The attempts/sec you can run against SHA-2 vs. the attempts/sec you can run against bcrypt or scrypt are an order of magnitude apart.
You should not use anything less than a proven KDF (scrypt, bcrypt, PBKDF2-HMAC-SHA2 with a lot of rounds) for password storage.
Many of your posts conflate "cryptographic" with "password hashing", which is certainly not the case. Note that PBKDF2-HMAC-SHA2 does not (at all) mean that SHA-2 is useful for password hashing. As someone else pointed out, that's just an implementation detail.
Re: SHA-3 Standard [pdf]
#69Earlier quoted context omitted.
SHA-2 is fine, and in fact the more conservative choice right now. SHA-3 didn't happen because SHA-2 was threatened. My current favorite conservative hash choice is SHA512/256, which is the SHA-2 that generates a 512-bit output but truncates it to 256. It gives you the same length extension protection that is the most important feature of SHA-3, and is available in most libraries already. I have never recommended to…
++ on SHA-512/256. SHA-512 uses 64-bit operations where SHA-256 uses 32-bit, so on a beefy 64-bit chip, it's faster per byte hashed. So, compared to SHA-256, more rounds, twice the state size, same familiar/widely-implemented design, and faster -- what's not to love? See http://bench.cr.yp.to/results-hash.html for a comparison of hash-function speeds.
Thanks for the link. I was just about to ask the very ideation you answered. :)
Re: SHA-3 Standard [pdf]
#70"The KECCAK-p permutations were designed to be suitable as the main
components for a variety of cryptographic functions, including keyed
functions for authentication and/or encryption. The six SHA-3
functions can be considered as modes of operation (modes) of
the KECCAK-p[1600,24] permutation. In the future, additional modes
of this permutation or other KECCAK-p permutations may be
specified and approved in FIPS publications or in NIST
Special Publications. "
Aww. Is there any news on a standard (NIST, or just informal RFC) on an authenticated encryption mode for KECCAK? I remember seeing a presentation of KECCAK at passwords[1] -- and I thought that part looked the most fun ;-)