21–30 of 30 posts
Earlier quoted context omitted.
This only matters if there's an existing protocol that uses truncated SHA-2 you need to interoperate with (and your premise is there is not). There is no functional advantage to having a different IV for SHA-2 5-2/256.
Yup, this looks like it's a cross-domain protection.
Earlier quoted context omitted.
The word "safe" isn't doing us any favors here. What we're really talking about is the "security margin" of the different hashes. Every hash we're talking about on this thread has a margin far beyond any plausible or foreseeable attacks. None are unsafe.
This is a serious issue, and I think it's a problem of cryptography education. On the one hand, we (rightly, in my opinion) teach people who haven't studied cryptography that they shouldn't try to implement it on their own. This is good, because cryptography is mostly applied math (hard) and careful software implementation (also hard), and mixing these two hard things without shooting yourself in the foot is very har…
I might be hugely mistaken, but isn't the current situation that almost all of the "essentially safe" hash functions are good enough for almost all uses? I understand that the amount of choice can lead to analysis paralysis, but sensible solution generally is just pick one (possibly the one that has a reasonable implementation most readily available) and move on. Sure, the almost randomly picked algorithm might not ideal on all possible metrics, but perfect is the enemy of good.
Earlier quoted context omitted.
> The best all-purpose cryptographic hash is probably truncated SHA-2 512 Could you elaborate on that please? Why would you consider it as the "best all-purpose cryptographic hash"?
On 64-bit processors SHA-512 truncated to 256 bits is faster than SHA-256, and has the advantage of being safe against length-extension attacks (which are a major gotcha of SHA-512 and the rest of SHA2). Out of SHA3, K12, SHA2 and Blake, SHA-512 is one of the fastest (some variants of Blake2 are faster), and it's the one with the longest track record, while the Blake-family and SHA3 are fairly new. It's also widely s…
Unless you are doing hash trees, in which case SHA-512 is slower than SHA-256, and length extension is not possible.
Point is there isn't and shouldn't be a blanket solution.
Earlier quoted context omitted.
This is a serious issue, and I think it's a problem of cryptography education. On the one hand, we (rightly, in my opinion) teach people who haven't studied cryptography that they shouldn't try to implement it on their own. This is good, because cryptography is mostly applied math (hard) and careful software implementation (also hard), and mixing these two hard things without shooting yourself in the foot is very har…
> It's easy to find sound recommendations for which algorithms are well-studied and essentially safe; it's less easy to find guides that compare and contrast algorithms along nuanced axes like computational cost, interoperability, security margin or adaptability. I might be hugely mistaken, but isn't the current situation that almost all of the "essentially safe" hash functions are good enough for almost all uses? I…
In general if you provide people with a list of possibilities and say, "Yeah, any of these is fine", they're not going to literally choose one at random. They're going to search a bit and read about differences between the algorithms, and unless they spend a lot of time reading about the respective properties of each algorithm they might eventually say something like, "Argon2 is safer than bcrypt."
"Safer" is a misnomer. There are meaningful reasons to choose one algorithm over another, but these generally boil down to performance impact, implementation time and how easy it is to shoot yourself in the foot with implementation.
This matters because people seek understanding, and if you don't provide a satisfiable amount they might draw erroneous conclusions that have a meaningful non-security impact. For example, you most likely don't need to be using AES256. People like to, because 256 > 128. But seriously - you probably don't need to. The impulse to just use the bigger number leads to decision making based on signaling more than real security, and has a meaningful reduction in things like usability and performance.
To rephrase my point here - "safe" is safe enough, and there should probably be better education on the peripheral implementation metrics for cryptographic algorithms, because you're far more likely to run up your AWS bill or inadvertently screw up your security by e.g. choosing a complex cryptographic algorithm with a huge security margin versus a simple one with a "good enough" security margin. If we're not able to provide more education about what to actually look for when discriminating between algorithms, then we need to find a way to decouple certain metrics from the perception of "safety", like key size.
For a real world example of this, look at the advertising with things like "bank-grade" or "military-grade" security which are heavily associated with phrases like "128-bit" or "256-bit." Sometimes a developer will see that AES128 is used and think to themselves, "I'll use 256 and be even safer!", all the while the public is slowly taught to associate safety with ever larger bit sizes. Then when a legitimately superior ECC algorithm comes out that uses 224 bit keys, people cling to RSA because they can use a 2048 bit key size and 2048 > 224.
K12 is not a "faster SHA-3". K12 is K12, M14 is M14. K12 is related to SHA-3, but if you're throwing standards out the door (and I think you should), you can use any of the hash core algorithms, whether or not they're related to Keccak. The best all-purpose cryptographic hash is probably truncated SHA-2 512, and the hipster modern hash is probably still Blake2.
Earlier quoted context omitted.
> It's easy to find sound recommendations for which algorithms are well-studied and essentially safe; it's less easy to find guides that compare and contrast algorithms along nuanced axes like computational cost, interoperability, security margin or adaptability. I might be hugely mistaken, but isn't the current situation that almost all of the "essentially safe" hash functions are good enough for almost all uses? I…
Yes, this is precisely my point. "Safe" is a binary property in cryptography. But developers don't have much to go on, so even if they follow best practices they often interpret differentiating metrics as variances in "safety", when in actuality those things are only relevant for computational cost, implementation difficulty, adaptability and interoperability. In general if you provide people with a list of possibili…
K12 is not a "faster SHA-3". K12 is K12, M14 is M14. K12 is related to SHA-3, but if you're throwing standards out the door (and I think you should), you can use any of the hash core algorithms, whether or not they're related to Keccak. The best all-purpose cryptographic hash is probably truncated SHA-2 512, and the hipster modern hash is probably still Blake2.
K12 is not a "faster SHA-3". K12 is K12, M14 is M14. K12 is related to SHA-3, but if you're throwing standards out the door (and I think you should), you can use any of the hash core algorithms, whether or not they're related to Keccak. The best all-purpose cryptographic hash is probably truncated SHA-2 512, and the hipster modern hash is probably still Blake2.
Isn't swordfish good also? Because it's slow
K12 is not a "faster SHA-3". K12 is K12, M14 is M14. K12 is related to SHA-3, but if you're throwing standards out the door (and I think you should), you can use any of the hash core algorithms, whether or not they're related to Keccak. The best all-purpose cryptographic hash is probably truncated SHA-2 512, and the hipster modern hash is probably still Blake2.
Isn't swordfish good also? Because it's slow
K12 is not a "faster SHA-3". K12 is K12, M14 is M14. K12 is related to SHA-3, but if you're throwing standards out the door (and I think you should), you can use any of the hash core algorithms, whether or not they're related to Keccak. The best all-purpose cryptographic hash is probably truncated SHA-2 512, and the hipster modern hash is probably still Blake2.