|
| px43 wrote:
| Good job SHA-1, you had a good run and didn't get too broken
| before retirement, which is quite an accomplishment for anyone
| these days.
|
| Does anyone in the field know if there's a SHA-4 competition
| around the corner, or is SHA-3 good enough? It would be
| interesting if one of the SHA-4 requirements was Zero Knowledge
| Proof friendlyness. MiMC and Poseidon are two of the big
| contenders in that area, and it would be really great to see a
| full NIST quality onslaught against them.
| iwillbenice wrote:
| pclmulqdq wrote:
| The NIST likes having two standardized "good" hash functions. I
| doubt we will have a SHA-4 until SHA-2 starts getting close to
| a break. The SHA-3 competition started once SHA-1 started
| showing some possible weaknesses. Also, if SHA-2 ends up
| getting retired, Blake3 will likely become SHA-4: Blake2 lost
| to Keccak because Blake2 was too similar to SHA-2.
| twiss wrote:
| NIST seems perfectly comfortable with having only one
| cryptographic primitive for a given category as long as
| there's high confidence in it. The reason we have two hash
| algorithms is that back when the SHA-3 competition was
| created, there was some uncertainty about the long-term
| security of SHA-2. That uncertainty has since subsided, I
| would say. But if SHA-2 does end up being considered
| insecure, as long as there's no reason to suspect that the
| same will happen to SHA-3, there's no reason to create a
| SHA-4 yet.
| miga wrote:
| There is Post-Quantum Cryptography competition, with three
| e-signature algorithms selected for standardization:
| https://csrc.nist.gov/projects/post-quantum-cryptography
|
| Given that NIST itself warns PQC algorithm may be unsafe after
| 2035, this should be considered SHA-4.
| bawolff wrote:
| Sha-2 is already quantum safe.
|
| Sha is not a digital signature algorithm. That is a different
| type of crypto primitive.
| adastra22 wrote:
| Hash functions aren't significantly impacted by quantum
| computers. You may need to use a longer construction (eg.
| SHA512 instead of SHA256), but that's it.
| bawolff wrote:
| Im not a cryptographer, im kind of curious - is it possible
| to combine a birthday attack with grover's algorithm to
| attack sha256 in 2^64 time?
| adastra22 wrote:
| You would get cube root speedup instead of sqrt for a
| collision (birthday attack), or sqrt instead of brute
| force for a preimage. So SHA256 is secure from preimage
| attacks even with a quantum computer, and gives 2^80
| protection against collisions. SHA-2/384 would be
| sufficient for 128-bit security against collisions.
| twiss wrote:
| Not only is SHA-3 good enough, for most applications SHA-2 is
| still good enough as well. So personally I would be surprised
| to see a new competition for a general-purpose hashing
| algorithm anytime soon.
| SilasX wrote:
| Isn't the entire Bitcoin mining incentive structure
| equivalent to a huge bug bounty on SHA-2 (256, specifically)?
|
| Edit: Never mind, grand-uncle comment beat me to it:
|
| https://news.ycombinator.com/item?id=34003485
| SAI_Peregrinus wrote:
| Agreed. Blake3 is super promising as cryptographic hash
| function family due to its software performance (not sure if
| anyone has tried making hardware designs for it), but SHA2
| hardware acceleration is extremely common and makes it good
| enough. And while SHA3 software performance is poor it's
| quite good in hardware, so as more chips accelerate it it'll
| become generally viable. So while Blake3 looks nice, there's
| not a whole ton of need for it right now, and I doubt it'll
| become SHA4 ever.
| aliqot wrote:
| Sha3 is performant, but I'll always give it the stink eye
| because of NIST selecting the winner, then modifying their
| solution before standardization without sufficient
| explanation. Read the room, this is cryptography; one does
| not simply add mystery padding and rush off to the printing
| press.
|
| https://www.schneier.com/blog/archives/2013/10/will_keccak_
| s...
|
| https://en.wikipedia.org/wiki/SHA-3#Padding
| Perseids wrote:
| It is fair to criticize NIST for enabling rumors about
| them weakening SHA3, but these are _rumors only_ ,
| nothing more. Please, everyone, stop spreading them. SHA3
| is the same Keccak that has gone through extensive
| scrutiny during the SHA3 competition, and, as far as
| anyone can tell, it is rock solid. Don't trust NIST,
| don't trust me, trust the _designers of Keccak_ , who
| tell you that NIST did not break it:
|
| > NIST's current proposal for SHA-3, namely the one
| presented by John Kelsey at CHES 2013 in August, is a
| subset of the Keccak family. More concretely, one can
| generate the test vectors for that proposal using the
| Keccak reference code (version 3.0 and later, January
| 2011). This alone shows that the proposal cannot contain
| internal changes to the algorithm.
|
| https://keccak.team/2013/yes_this_is_keccak.html
| dchest wrote:
| All good changes, giving us SHAKE functions and the rest
| of useful variants based on domain separation in padding.
| WhitneyLand wrote:
| How much did your opinion change after reading the 10/5
| update to Schneier's post?
|
| From your first link:
|
| _I misspoke when I wrote that NIST made "internal
| changes" to the algorithm. That was sloppy of me. The
| Keccak permutation remains unchanged. What NIST proposed
| was reducing the hash function's capacity in the name of
| performance. One of Keccak's nice features is that it's
| highly tunable.
|
| I do not believe that the NIST changes were suggested by
| the NSA. Nor do I believe that the changes make the
| algorithm easier to break by the NSA. I believe NIST made
| the changes in good faith, and the result is a better
| security/performance trade-off._
| a1369209993 wrote:
| Can't speak for aliqot, but I am now somewhat more
| confident that the NIST changes were suggested by the
| NSA, and slightly more confident (or at least less
| unconfident) that SHA-3 is insecure.
|
| I still think it's _probably_ fine, but I feel better
| about insisting on SHA-2+mitigations or blake3 instead
| now, even if the main problem with SHA-3 is its being
| deliberately designed to encourage specialized hardware
| accelleration (cf AES and things like Intel 's aes-ni).
|
| (To be clear, the fact that Schneier claims to "believe
| NIST made the changes in good faith" is weak but nonzero
| evidence that they did not. I don't see any _concrete_
| evidence for a backdoor, although you obviously shouldn
| 't trust _me_ either.)
| booi wrote:
| Nice try NSA, that's exactly what you want us to believe!
|
| jk I'm sure it's fine... probably
| yarg wrote:
| Skein always seemed interesting to me:
| https://en.wikipedia.org/wiki/Skein_(hash_function)
|
| But I've had a soft spot for Schneier since this (pre-
| Snowden) blog post on Dual_EC_DRBG: https://www.schneier.
| com/blog/archives/2007/11/the_strange_s....
| nicolashahn wrote:
| how else do you add a backdoor?
| Dylan16807 wrote:
| The original padding, as bits, was 100000...0001
|
| The new padding prepends either 01, 11, or 1111 depending
| on the variant of SHA-3. That way the different variants
| don't sometimes give the same [partial] hash.
|
| It was weird to toss that in at the last second but
| there's no room for a backdoor there.
| StreamBright wrote:
| > Blake3 is super promising as cryptographic hash function
| family due to its software performance
|
| I am shocked how fast it is. Just tried it on several
| files. It is blazing fast.
|
| brew install b3sum on mac.
| KMag wrote:
| As far as Blake3 in hardware for anything other than very
| low-power smart cards or similar:
|
| Blake3 was designed from the ground up to be highly
| optimized for vector instructions operating on four
| vectors, each of 4 32-bit words. If you already have the
| usual 4x32 vector operations, plus a vector permute (to
| transform the operations across the diagonal of your 4x4
| matrix into operations down columns) and the usual bypass
| network to reduce latency, I think it would rarely be worth
| the transistor budget to create dedicated Blake3 (or
| Blake2s/b) instructions.
|
| In contrast, SHA-3's state is conceptually five vectors
| each of five 32-bit words, which doesn't map as neatly onto
| most vector ISAs. As I remember, it has column and row
| operations rather than column and diagonal operations that
| parallelize better on vector hardware.
|
| SHA-2 is a Merkle-Damgard construction where the round
| function is a Davies-Meyer construction where the internal
| block cipher is a highly unbalanced Feistel cipher.
| Conceptually, you have a queue of 8 words (32-bit or
| 64-bit, depending on which variant). Each operation pops
| the first word from the queue, combines it in a nonlinear
| way with 6 of the other words, adds one word from the "key
| schedule" derived from the message, and pushes the result
| on the back of the queue. The one word that wasn't
| otherwise used is increased by the sum of the round key and
| a non-linear function of 3 of the other words. As you might
| imagine, this doesn't map very well onto general-purpose
| vector instructions. This cipher is wrapped in a step
| (Davies-Meyer construction) where you save a copy of the
| state, encrypt the state using the next block of the
| message, and then add the saved copy to the encrypted
| result (making it non-invertible, making meet-in-the middle
| attacks much more difficult). The key schedule uses a
| variation on a lagged Fibonacci generator to expand each
| message block into a larger number of round keys.
| als0 wrote:
| > It would be interesting if one of the SHA-4 requirements was
| Zero Knowledge Proof friendlyness
|
| What would this requirement look like and why would it be
| important for a hash function?
| greggarious wrote:
| Nice, though it's scary many open source projects still just list
| an MD5 sum for the binaries.
| [deleted]
| jimrandomh wrote:
| SHA-256 is used for Bitcoin mining, which serves as an enormous
| bug bounty for both full and partial breaks (if you can
| efficiently find inputs where the output has lots of leading
| zeroes that's a partial break, and lets you mine bitcoin more
| efficiently). That's worth a lot of trust. I don't see any
| particular reason to think SHA-3 is better (though I'm not an
| expert) and unless I hear some indication that a problem has been
| found with SHA-2, I'll probably stick with it forever.
| tromp wrote:
| > if you can efficiently find inputs where the output has lots
| of leading zeroes that's a partial break, and lets you mine
| bitcoin more efficiently
|
| Depends on the type of break. If the break only allows finding
| a hash with 128+k leading zeroes in 2^{128+k/2} time, that
| would still be quite useless for bitcoin mining.
|
| The break would have to cover the bitcoin regime of around 78
| leading 0s.
| mindcandy wrote:
| In my research into Ethereum, I learned that in the creation of
| SHA-3, they did a lot of hammering on SHA-256 to see if new
| weaknesses could be discovered and addressed. The conclusion
| was that SHA-256 is still solid as far as anyone can tell. The
| SHA-3 process moved forward anyway so they could have a backup-
| plan handy in case some problem with SHA-256 pops up out of
| nowhere.
| [deleted]
| pclmulqdq wrote:
| Bitcoin mining uses double SHA-256. It tends to be harder to
| break doubled hash functions, since you don't have tools like
| length-extension attacks on the second round of hashing. For
| example, HMAC-SHA-1 is still secure (despite SHA-1 being pretty
| much broken), and it also uses a two-round hashing
| construction.
| flatiron wrote:
| Even if it didn't sha as a hmac is still fine because the
| length it takes to break. You can't break sha1 in the time it
| takes for your packet to go through the hmac step.
| anderskaseorg wrote:
| SHA-256 is vulnerable to a length extension attack. This is
| well-known to cryptographers; it doesn't matter for some
| applications and can be worked around in others. But it still
| catches some developers unaware.
|
| https://en.wikipedia.org/wiki/Length_extension_attack
| adastra22 wrote:
| Bitcoin mining uses double SHA256 which is not subject to
| length extension attacks. (Not that it matters, because
| bitcoin block headers are fixed length.)
| tptacek wrote:
| There are increasingly few situations in which length
| extension really matters, because we know more about
| designing protocols than we did 20 years ago; even code that
| uses SHA3 or Blake2 tends to still use HMAC. Further, there
| are standard variants of SHA2 that don't have length
| extension (they're truncated and don't disclose their full
| state). It's better to not have length extension properties
| than to have them, but it's not really a big part of the
| desiderata.
| flatiron wrote:
| I'm always confused when people slam sha on hmac. Is there
| a realtime sha back door I'm missing? Even sha 1 takes
| days/months to break.
| [deleted]
| phh wrote:
| I didn't expect such attacks to exist, thanks for bringing
| that up. However that Wikipedia page seem to say sha-256 is
| ok since it's truncated?
| Dylan16807 wrote:
| SHA-256 is not truncated. "SHA-512/256" is truncated. It
| means you do SHA-512 (with a different starting state) and
| then throw out half.
| CBLT wrote:
| Sha-224 and Sha-384 are the truncated versions of Sha-256
| and Sha-512 respectively.
|
| My boring hash function of choice is Sha-384. The Sha-512
| computation is faster on Intel hardware, and ASICS to crack
| it are far more expensive than Sha-256 because of bitcoin.
|
| If you're hashing passwords or something, use a "harder"
| hash like Argon2 or Scrypt.
| adrian_b wrote:
| SHA-512 is faster only on Skylake derivatives up to Comet
| Lake and on older Intel Core CPUs.
|
| On Intel Atom starting with Apollo Lake (2016) and on
| Intel Core starting with Ice Lake (2019) and on all AMD
| Zen CPUs (2017), SHA-256 is implemented in hardware and
| it is much faster than SHA-512.
| AtNightWeCode wrote:
| It is often worked around. But from what I understand the
| length extension issue was raised during the design but
| ignored. Hashing is not encryption but some of the
| recommended encryption standards are so complicated that it
| is a risk just by itself.
|
| SHA-384 is a truncated SHA-512. From the claims of sec people
| it does not offer more security when it comes to length
| attacks. But from how the algo works I would assume that it
| does.
|
| Nist is also plain wrong about their calculations. Cause how
| long it takes to calculate a specific hash depends on the
| hardware available, not what theory books says. It may in
| practice be faster to calculate a hash with more bits.
| miga wrote:
| That is date after which purchase of _new_ software with SHA-1
| will be forbidden, which seems late given that it takes only two
| months on GPU to find signature collision with a chosen prefix.
|
| Sounds like the deprecation schedule is too slow and unsafe.
| null0ranje wrote:
| > NIST is announcing that SHA-1 should be phased out by Dec. 31,
| 2030
|
| Looks like it'll limp along for a while yet
| dang wrote:
| We've updated the title with a representative sentence from the
| article which makes this clearer.
| dreamcompiler wrote:
| SHA-1 is still perfectly fine for some applications like
| detecting duplicate files on a storage medium (and it's less
| likely to produce a false positive than MD5) but it's been a bad
| idea for anything security related for a decade.
|
| The biggest issue is that git still uses it, which presents a
| problem if you want to protect a repo from active integrity
| attacks.
| EGreg wrote:
| Actually SHA1-HMAC is fine still. Although I had this question:
| https://crypto.stackexchange.com/questions/102990/what-is-mo...
| oconnore wrote:
| Since I'm on a roll with truncated hashes: SHA2-512/384, and
| SHA2-512/256 are not vulnerable to a Merkle-Damgard length
| extension attack.
|
| Thus, a construct like hash(key + message) can be used
| similar to SHA3 [1]
|
| [1]: https://keccak.team/keccak_strengths.html
| classichasclass wrote:
| This is worth emphasizing since HOTP (and thus TOTP) are
| based on it.
| [deleted]
| amluto wrote:
| > SHA-1 is still perfectly fine for some applications like
| detecting duplicate files on a storage medium
|
| If by "perfectly fine" you mean "subject to attacks that
| generate somewhat targeted collisions that are practical enough
| that people do them for amusement and excuses to write blog
| posts and cute Twitter threads", then maybe I agree.
|
| Snark aside, SHA-1 is _not fine_ for deduplication in any
| context where an attacker could control any inputs. Do not use
| it for new designs. Try to get rid of it in old designs.
| orev wrote:
| By "perfectly fine" they mean detecting duplicate image or
| document files on your local storage, which it's still
| perfectly fine for, and a frequent mode of usage for these
| types of tools.
|
| Not every tool needs to be completely resilient to an entire
| Internets' worth of attacks.
| dagenix wrote:
| Why would you pick SHA1 which has significant attacks you
| need to consider as opposed to something like SHA2 that
| doesn't?
| dreamcompiler wrote:
| Because SHA1 is faster and that matters if you're hashing
| several TB of files?
|
| But I don't know for sure that's the case.
| amluto wrote:
| First the preamble:
|
| DO NOT USE SHA-1 UNLESS IT'S FOR COMPATIBILITY. NO
| EXCUSES.
|
| With that out of the way: SHA-1 is not even particularly
| fast. BLAKE2-family functions are faster. Quite a few
| modern hash functions are also parallelizable, and SHA-1
| is not. If for some reason you need something faster than
| a fast modern hash, there are non-cryptographic hashes
| and checksums that are extraordinarily fast.
|
| If you have several TB of files, and for some reason you
| use SHA-1 to dedupe them, and you later forget you did
| that and download one of the many pairs of amusing SHA-1
| collisions, you will lose data. Stop making excuses.
| VLM wrote:
| > there are non-cryptographic hashes and checksums that
| are extraordinarily fast.
|
| Is it still true that CRC32 is only about twice as fast
| as SHA1?
|
| Yeah I know the XX hashes are like 30 times faster than
| SHA1.
|
| A lot depends on instruction set and processor choice.
|
| Maybe another way to put it is I've always been impressed
| that on small systems SHA1 is enormously longer but only
| twice as slow as CRC32.
|
| For a lot of interoperable-maxing non-security non-crypto
| tasks, CRC32 is not a bad choice, if its good enough for
| Ethernet, zmodem, and mpeg streams its good enough for my
| telemetry packets LOL. (IIRC iSCSI uses some variant
| different formulae)
| adrian_b wrote:
| CRC32 is fine for kilobyte-sized data packets.
|
| For files, it is useless. Even if that was expected, I
| have computed CRC32 for all the files on an SSD. Of
| course, I have found thousands of collisions.
| jcrawfordor wrote:
| Deduplication is the kind of application where CRC is a
| decent approach and CRC has no resistance to attack
| whatsoever. SHA1 adds the advantage of lower natural
| collision probability while still being extremely fast.
| It's important to understand that not all applications of
| hashing are cryptographic or security applications, but
| that the high degree of optimization put into
| cryptographic algorithms often makes them a convenient
| choice in these situations.
|
| These types of applications are usually using a
| cryptographic hash as one of a set of comparison
| functions that often start with file size as an
| optimization and might even include perceptual methods
| that are intentionally likely to produce collisions. Some
| will perform a byte-by-byte comparison as a final test,
| although just from a performance perspective this
| probably isn't worth the marginal improvement even for
| hash functions in which collisions are known to occur but
| vanishingly rare in organic data sets (this would include
| for example MD5 or even CRC at long bit lengths, but the
| lack of mixing in CRC makes organic collisions much more
| common with structured data).
|
| SHA2 is significantly slower than SHA1 on many real
| platforms, so given that intentional collisions are not
| really part of the problem space few users would opt for
| the "upgrade" to SHA2. SHA1 itself isn't really a great
| choice because there are faster options with similar
| resistance to accidental collisions and worse resistance
| to intentional ones, but they're a lot less commonly
| known than the major cryptographic algorithms. Much of
| the literature on them is in the context of data
| structures and caching so the bit-lengths tend to be
| relatively small in that more collision-tolerant
| application and it's not always super clear how well they
| will perform at longer bit lengths (when capable).
|
| Another way to consider this is from a threat modeling
| perspective: in a common file deduplication operation,
| when files come from non-trusted sources, someone might
| be able to exploit a second-preimage attack to generate a
| file that the deduplication tool will errantly consider a
| duplicate with another file, possibly resulting in one of
| the two being deleted if the tool takes automatic action.
| SHA1 actually remains highly resistant to preimage and
| second preimage attacks, so it's not likely that this is
| even feasible. SHA1 does have known collision attacks but
| these are unlikely to have any ramifications on a file
| deduplication system since both files would have to be
| generated by the adversary - that is, they can't modify
| the organic data set that they did not produce. I'm sure
| you could come up with an attack scenario that's feasible
| with SHA1 but I don't think it's one that would occur in
| reality. In any case, these types of tools are not
| generally being presented as resistant to malicious
| inputs.
|
| If you're working in this problem space, a good thing to
| consider is hashing only subsets of the file contents,
| from multiple offsets to avoid collisions induced by
| structured parts of the format. This avoids the need to
| read in the entire file for the initial hash-matching
| heuristic. Some commercial tools initially perform
| comparisons on only the beginning of the file (e.g. first
| MB) but for some types of files this is going to be a lot
| more collision prone than if you incorporate samples from
| regular intervals, e.g. skipping over every so many
| storage blocks.
| adrian_b wrote:
| SHA-1 is implemented in hardware in all modern CPUs and
| it is much faster than any alternatives (not all
| libraries use the hardware instructions, so many popular
| programs compute SHA-1 much more slowly than possible;
| OpenSSL is among the few that use the hardware).
|
| When hashing hundreds of GB or many TB of data, the hash
| speed is important.
|
| When there are no active attackers and even against
| certain kinds of active attacks, SHA-1 remains secure.
|
| For example, if hashes of the files from a file system
| are stored separately, in a secure place inaccessible for
| attackers (or in the case of a file transfer the hashes
| are transferred separately, through a secure channel), an
| attacker cannot make a file modification that would not
| be detected by recomputing the hashes.
|
| Even if SHA-1 remains secure against preimage attacks, it
| should normally be used only when there are no attackers,
| e.g. for detecting hardware errors a.k.a. bit rotting, or
| for detecting duplicate data in storage that could not be
| accessed by an attacker.
|
| While BLAKE 3 (not BLAKE 2) can be much faster than
| SHA-1, all the extra speed is obtained by consuming
| proportionally more CPU resources (extra threads and
| SIMD). When the hashing is done in background, there is
| no gain by using BLAKE 3 instead of SHA-1, because the
| foreground tasks will be delayed by the time gained for
| hashing.
|
| Only when a computer does only hashing, BLAKE 3 is the
| best choice, because the hash will be computed in a
| minimal time, by fully using all the CPU cores.
| dylan604 wrote:
| who is attacking you in this situation though? you're
| scanning the files on your local system and storing their
| hashes. you then look for duplicate hashes, and compare
| the files that created them. if the files are truly
| duplicates, you can now decide what to do about that. if
| they are not truly the same, then you claim to have found
| another case of collisions, write your blog
| post/twitthread and move on, but does that constitute
| being attacked?
|
| sometimes, i really feel like people in crypto just can't
| detach themselves enough to see that just because they
| have a hammer, not everything in the world is a nail.
| lokar wrote:
| If you are going to follow up with a full comparison you
| can use something much cheaper then sha-1
| bawolff wrote:
| I dont think this is what most people think of when they
| say deduplication. There are quite a few systems which
| will just scan for duplicates and then automatically
| delete one of the duplicates. In such a system sha1 would
| be inappropriate.
|
| If you are just using sha1 as a heuristic you dont fully
| trust, i suppose sha1 is fine. It seems a bit of an odd
| choice though as something like MurmurHash would be much
| faster for such a use case.
| adrian_b wrote:
| SHA-1 cannot be trusted only when there is a possibility
| that _both_ files whose hashes are compared have been
| created by an attacker.
|
| While such a scenario may be plausible for a public file
| repository, so SHA-1 is a bad choice for a version
| control system like GIT, there are a lot of applications
| where this is impossible, so it is fine to use SHA-1.
| dagenix wrote:
| Why would you pick a function that is known to have
| issues when there are other functions that do the same
| thing but don't have known issues?
|
| Your comparison is flawed. It's more like if you have a
| nail and next to it a workbench with two hammers - a good
| hammer and a not as good hammer. This isn't a hard
| choice. But for reasons that are unclear to me, people in
| this thread are insisting on picking the less good hammer
| and rationalizing why for this specific nail it isn't all
| that much worse. Just pick the better hammer!
| oefrha wrote:
| Because people already have two decades of SHA-1 hashes
| in their database and a rewrite + rescan is completely
| pointless? Hell, I have such a system using md5. So you
| produced a hash collision, cool, now fool my follow-on
| byte-by-byte comparison.
|
| Edit: Before anyone lecture me on SHA-1 being slow, yes,
| I use BLAKE2 for new projects.
| dylan604 wrote:
| thanks for the reply that did not answer the question
| asked.
| dagenix wrote:
| Your question is irrelevant. If you don't care about
| security, SHA1 is a bad choice because there are faster
| hash functions out there. If you do care about security,
| SHA1 is a bad choice because it has known flaws and there
| exist other algorithms that don't. The only valid reason
| to use SHA1 is if there is a historical requirement to
| use it that you can't reasonably change.
|
| Any analysis about how hard it is for an attacker to get
| a file on your local file system via a cloned got repo,
| cached file, email attachment, image download, shared
| drive, etc is just a distraction.
| adrian_b wrote:
| You would be right, except that there are no faster hash
| functions (on all modern Intel, AMD and ARM CPUs, which
| have hardware SHA-1).
|
| BLAKE 3 is faster only in wall clock time, on an
| otherwise idle computer, because it fully uses all CPU
| cores, but it does not do less work.
|
| BLAKE 3 is preferable only when the computer does nothing
| else but hashing.
| VLM wrote:
| Its worship of the new. Nothing worth anything existed
| last week, so reimplementing an entire infrastructure is
| zero cost.
| ShowalkKama wrote:
| because it's shorter, dealing with long hashes is
| annoying (I use md5, not sha1)
| bawolff wrote:
| You could just discard half the sha256 hash. Using the
| first 16 bytes of sha256 is a lot more secure than using
| just md5, in which case you might as well just use crc32.
| bawolff wrote:
| Ask the webkit source code repo how using sha-1 for that
| purpose went.
|
| It depends what you are doing, but deduplication where a
| collision means you loose data, seems like an inapropriate
| place for sha-1.
| bornfreddy wrote:
| Webkit incident: https://itwire.com/business-it-
| news/security/fallout-webkit-...
| Pet_Ant wrote:
| > where an attacker could control any inputs
|
| I believe the GP's point hinges on the word "attacker". If
| you aren't in a hostile space, like just your won file server
| and you are monitoring your own backups it's fine. I still
| use MD5s to version my own config files. For personal use in
| non-hostile environments these hashes are still perfectly
| fine.
| 0xbadcafebee wrote:
| If you're _only_ using the hash for non-cryptographic
| applications, there are much faster hashes:
| https://github.com/Cyan4973/xxHash
|
| SHA1 and MD5 are the most widely accessible, though, and I
| agree it's fine to use them if you don't care about security.
| dragontamer wrote:
| I feel like the properties of CRC make them superior for that
| task in most cases though. (CRC8, CRC16, CRC32 and CRC64, maybe
| CRC128 if anyone ever bothered going that far)
|
| In particular, CRC guarantees detection on all bursts of the
| given length. CRC32 protects vs all bursts of length 32 bits.
| AlotOfReading wrote:
| There are only a few examples of anything larger than CRC64
| being characterized and they're not very useful.
|
| For the sake of the next person who has to maintain your code
| though, please choose algorithms that adequately communicate
| your intentions. Choose CRCs only if you need to detect
| random errors in a noisy channel with a small number of bits
| and use a length appropriate to the intended usage (i.e.
| almost certainly not CRC64).
| dragontamer wrote:
| And when you choose SHA1, does it mean you understood that
| it's no longer secure? Or is it chosen because it was
| secure 20 years ago but the code is old and needs to be
| updated?
|
| CRC says that you never intended security from the start.
| It's timeless, aimed to prevent burst errors and random
| errors.
|
| --------
|
| BTW, what is the guaranteed Hamming distance between SHA1?
| How good is SHA1 vs burst errors? What about random errors?
|
| Because the Hamming distances of CRC have been calculated
| and analyzed. We actually can determine, to an exact level,
| how good CRC codes are.
| benlivengood wrote:
| https://eprint.iacr.org/2019/078 is a good overview of
| the statistical properties of SHA hashes.
|
| Basically after ~10 rounds the output is always
| indistinguishable from randomness which means hamming
| distance is what you'd expect (about half the bits
| differ) between the hashes of any two bitstreams.
| dragontamer wrote:
| CRC does better than random vs burst errors. And vs
| random errors is indistinguishable from any other
| methodology.
|
| If you are only worried about random errors, might as
| well use chksum.
| AlotOfReading wrote:
| You shouldn't choose SHA-1, that's the point of this
| announcement. Seeing it indicates both that there was the
| potential for malicious input and that the code is old.
| The appropriate mitigation is to move to a secure hash,
| not CRCs. You may not know the bounds and distances
| exactly, but you know them probabilistically. Bit errors
| _almost always_ map to a different hash.
|
| The same is true of CRCs over a large enough input as an
| aside.
| dagenix wrote:
| If you are choosing between a CRC and SHA1, you probably
| need to reconsider your understanding of the problem you
| are trying to solve. Those algorithms solve different use
| cases.
| dragontamer wrote:
| If you are choosing SHA1, now that it is retired, you
| probably should think harder about the problem in
| general.
|
| CRC should be better for any error detection code issue.
| Faster to calculate, more studied guaranteed detection
| modes, and so forth.
|
| SHA1 has no error detection studies. It's designed as a
| cryptographic hash, to look random. As it so happens, it
| is more efficient to use other algorithms and do better
| than random if you have a better idea of how your error
| looks like.
|
| Real world errors are either random or bursty. CRC is
| designed for these cases. CRC detects the longest burst
| possible for it's bitsize.
| IncRnd wrote:
| > I feel like the properties of CRC make them superior for
| that task in most cases though.
|
| THIS IS FALSE. Please do not ever do this. Why not? For
| example, by controlling any four contiguous bytes in a file,
| the resultant 32bit CRC can be forced to take on any value. A
| CRC is meant to detect errors due to noise - not changes due
| to a malicious actor.
|
| Program design should not be done based upon one's feelings.
| CRCs absolutely do not have the required properties to detect
| duplication or to preserve integrity of a stored file that an
| attacker can modify.
| dragontamer wrote:
| > THIS IS FALSE. Please do not ever do this. Why not? For
| example, by controlling any four contiguous bytes in a
| file, the resultant 32bit CRC can be forced to take on any
| value.
|
| And SHA1 is now broken like this, with collisions and so
| forth. Perhaps it's not as simple as just 4 bytes, but the
| ability to create collisions is forcing this retirement.
|
| If adversarial collisions are an issue, then MD5 and SHA1
| are fully obsolete now. If you don't care for an adversary,
| might as well use the cheaper, faster CRC check.
|
| ------
|
| CRC is now more valid use case than SHA1. That's the point
| of this announcement.
| IncRnd wrote:
| > CRC is now more valid use case than SHA1. That's the
| point of this announcement.
|
| No. That isn't the point of this announcement. This
| announcement codifies a transition time for SHA-1 use in
| SBU and has nothing to do with a CRC.
| Dylan16807 wrote:
| The point of the announcement is to give a timeline to
| start treating SHA1 as having no real security.
|
| This is relevant to when you'd choose CRC, because it
| also has no real security.
| LinuxBender wrote:
| _SHA-1 is still perfectly fine for some applications like
| detecting duplicate files on a storage medium_
|
| Absolutely agree, especially when speed is a workable trade-off
| and accepting real world hash collisions are unlikely and
| perhaps an acceptable risk. For financial data, especially
| files not belonging to me I would have md5+sha1+sha256
| checksums and maybe even GPG sign a manifest of the checksums
| ... because why not. For my own files md5 has always been
| sufficient. I have yet to run into a real world collision.
|
| FWIW anyone using `rsync --checksum` is still using md5. Not
| that long ago _I think 2014_ it was using md4. I would be
| surprised if rsync started using anything beyond md5 any time
| soon. I would love to see all the checksum algorithms become
| CPU instruction sets. Optimizations:
| no SIMD-roll, no asm-roll, no openssl-crypto, asm-MD5
| Checksum list: md5 md4 none Compress list:
| zstd lz4 zlibx zlib none Daemon auth list:
| md5 md4
| tptacek wrote:
| You're never going to _accidentally_ run into an MD5
| collision.
| dwheeler wrote:
| Git no longer uses SHA-1. It instead uses a variant called
| SHA-1DC that detects some known problems, and in those cases
| returns a different answer. More info: . Git switched to SHA-1DC in
| its version 2.13 release in 2017. It's a decent stopgap but not
| a grrat long term solution.
|
| There is also work to support SHA-256, though that seems to
| have stalled: https://lwn.net/Articles/898522/
|
| The fundamental problem is that get developers assumed that
| hash algorithms would never be changed, and that was a
| ridiculous assumption. It's much wiser to implement crypto
| agility.
| hejaodbsidndbd wrote:
| It's not called SHA-1DC. It's called "some blob of C whose
| behaviour is never described anywhere".
| xena wrote:
| If there's a readily-avaliable blob of C code that does the
| operation, then by definition it must be described
| somewhere. Maybe you should get ChatGPT to describe what it
| does.
| hejaodbsidndbd wrote:
| derbOac wrote:
| Why isn't Git using something else? Why go to the trouble of
| implementing something like that?
|
| I don't mean that as some ridiculing criticism, I just am
| genuinely puzzled.
| chungy wrote:
| Changing out the hashing algorithm in Git is a very
| difficult thing to do.
| cerved wrote:
| not within the git project so much as all the other code
| that depends on it
| duskwuff wrote:
| > Why isn't Git using something else?
|
| Because switching to a different hash algorithm would break
| compatibility with all existing Git clients and
| repositories.
| woodruffw wrote:
| > The fundamental problem is that get developers assumed that
| hash algorithms would never be changed, and that was a
| ridiculous assumption. It's much wiser to implement crypto
| agility.
|
| Cryptographic agility makes this problem worse, not better:
| instead of having a "flag day" (or release) where `git`'s
| digest choice reflects the State of the Art, agility ensures
| that every future version of `git` can be downgraded to a
| broken digest.
| est31 wrote:
| That's the general anti-agility argument wielded against
| git, but note that git's use cases require it to process
| historic data.
|
| E.g. you will want to be able to read some sha-1-only repo
| from disk that was last touched a decade ago. That's a
| different thing than some protocol which requires both
| parties to be on-line, say wireguard, in which instance
| it's easier to switch both to a new version that uses a
| different cryptographic algorithm.
|
| Git has such protocols as well, and maybe it can deprecate
| sha-1 support there eventually, but even there it has to
| support both sha-1 and sha-2 for a while because not
| everyone is using the latest and greatest version of git,
| and no sysadmin wants the absolute horror of flag days.
| miga wrote:
| It would be safer to forbid broken hashes after certain
| date, and consider only those earlier hashes that have
| been counter-signed by new algorithms.
| Dylan16807 wrote:
| Assuming reasonable logic around hashes, like "a SHA-2
| commit can't be a parent of a SHA-1 commit", there wouldn't
| much in the way of downgrade attacks available.
| bornfreddy wrote:
| Wow, smart! This would keep all the old history intact
| and at the same time force lots of people to upgrade
| through social pressure. I'd probably be angry as hell
| when that happened to me, but it would also work.
| AgentME wrote:
| SHA-1 was already known to be broken at the time Git chose
| it, but they chose it anyway. Choosing a non-broken algorithm
| like SHA-2 was an easy choice they could have made that would
| still hold up today. Implementing a crypto agility system is
| not without major trade-offs (consider how common downgrade
| attacks have been across protocols!).
| fishywang wrote:
| >SHA-1 was already known to be broken at the time Git chose
| it
|
| Please pardon my ignorance but could you elaborate on what
| time (e.g. the year) are you referring to?
| LarryMullins wrote:
| Since about 2005, collision attacks against SHA-1 have
| been known. In 2005 Linus dismissed these concerns as
| impractical, writing: > The basic
| attack goes like this: > > - I construct
| two .c files with identical hashes. Ok,
| I have a better plan. - you learn to fly
| by flapping your arms fast enough - you then
| learn to pee burning gasoline - then, you fly
| around New York, setting everybody you see on fire, until
| people make you emperor. Sounds like a
| good plan, no? But perhaps slightly
| impractical. Now, let's go back to your
| plan. Why do you think your plan is any better
| than mine?
|
| https://git.vger.kernel.narkive.com/9lgv36un/zooko-zooko-
| com...
| nighthawk454 wrote:
| I didn't know either. From Wikipedia [1], SHA-1 has been
| considered insecure to some degree since 2005. Following
| the citations, apparently it's been known since at least
| August 2004 [2] but maybe not demonstrated in SHA-1 until
| early 2005.
|
| git's first release was in 2005, so I guess technically
| SHA-1 issues could've been known or suspected during
| development time.
|
| More generously, it could've been somewhat simultaneous.
| It sounds like it was considered a state-sponsored level
| attack at the time, if collisions were even going to be
| possible. Don't know if the git devs knew this and
| intentionally chose it anyway, or just didn't know.
|
| [1] https://en.wikipedia.org/wiki/SHA-1
|
| [2] https://www.schneier.com/blog/archives/2005/02/crypta
| nalysis...
|
| EDIT: sibling comment has evidence that Linus did in fact
| know about it and considered it an impractical vector at
| the time
|
| https://git.vger.kernel.narkive.com/9lgv36un/zooko-zooko-
| com...
| VLM wrote:
| "We recommend that anyone relying on SHA-1 for security migrate
| to SHA-2 or SHA-3 as soon as possible." --Chris Celi, NIST
| computer scientist
|
| The emphasis being on "for security"
|
| I've also used SHA-1 over the years for binning and verifying
| file transfer success, none of those are security related.
|
| Sometimes, if you make a great big pile of different systems,
| what's held in common across them can be weird, SHA-1 popped
| out of the list so we used it.
|
| I'm well aware its possible to write or automate the writing of
| dedicated specialized "perfect" hashing algos to match the
| incoming data, to bin the data more perfectlyier, but sometimes
| its nice if wildly separate systems all bin incoming data the
| same highly predictable way thats "good enough" and "fast
| enough".
| jraph wrote:
| > I've also used SHA-1 over the years for binning and
| verifying file transfer success, none of those are security
| related.
|
| It could. If you want to verify that the file has not been
| tempered by someone, it is security related.
| kiratp wrote:
| As an industry we need to get over this pattern of scoping down
| usage of something that has failed it's prime directive. People
| still use MD5 in secure related things because it's been
| allowed to stick around without huge deprecation warnings in
| libraries and tools.
|
| SHA1 (and MD5) need to be treated the same way you would treat
| O(n^2) sorting in a code review for a PR written by a newbie.
| bawolff wrote:
| But sha-1 is now both slow and insecure.
|
| If you dont care about security, use a faster hash. If you care
| about security use sha256 (which is about the same speed
| anyways).
|
| The only valid reason to still use it in non-security critical
| roles is backwards compat.
| oconnore wrote:
| If you need a shorter hash just truncate a modern hash
| algorithm down to 160 or 128 bits. Obviously the standard
| lengths were chosen for a reason, but SHA2-256/160 or
| SHA2-256/128 are better hash functions than SHA1 or MD5,
| respectively. Blake2b/160 is even faster than SHA1!
|
| (I suspect this would be a good compromise for git, since so
| much tooling assumes a 160 bit hash, and yet we don't want to
| continue using SHA1)
| kzrdude wrote:
| Git has already implemented a solution based on SHA-2 with
| 256 bit output so that's unlikely to be changed for the time
| being. (But it has not really been launched in earnest, only
| as a preview feature.)
| danbruc wrote:
| Just as a note, the primary reason for the truncated variants
| is not to get a shorter hash but to prevent extension
| attacks. For variants without truncation, the final hash is
| the entire internal state, therefore an attacker can
| calculated the hash of any message that starts with the
| original message and then has additional content without
| knowing the original message. Truncating the hash denies
| access to the complete internal state and makes this
| impossible.
| cesarb wrote:
| Another way to prevent extension attacks is to make the
| internal state different whenever the current block is the
| last block, as done for instance in BLAKE3 (which has as an
| additional input on each block a set of flags, and one of
| the flags says "this is the last block").
| GTP wrote:
| Or use Keccak (which is the permutation that was chosen for
| SHA3), which lets you pick the length that you need.
| umvi wrote:
| What kind of attack against a git repo can be realistically
| carried out today?
| kadoban wrote:
| Given a git repo with signed commits I can give you the same
| repo with some file(s) changed with the signatures intact.
|
| Pretty sure you can anyway, I haven't thought deeply about
| the git file formats involved and such.
|
| Note that this attack isn't _that_ serious. There's not a lot
| of cases where this would make sense.
| AnssiH wrote:
| I don't think so, unless you utilize some not-yet-public
| vulnerability.
|
| As far as I know, with current public SHA-1
| vulnerabilities, you can create two new objects with the
| same hash (collision attack), but cannot create a second
| object that has the same hash as some already existing
| object (preimage attack).
| [deleted]
| hannob wrote:
| > SHA-1 is still perfectly fine for some applications like
| detecting duplicate files on a storage medium
|
| That's what the developers of subversion thought, but they
| didn't anticipate that once colliding files were available
| people would commit them to SVN repos as test cases. And then
| everything broke:
| https://www.bleepingcomputer.com/news/security/sha1-collisio...
| TheRealPomax wrote:
| That changes the parameters quite a bit though. For local
| digests, like image deduplication of your own content, on
| your own computers, sha-1 is still perfectly fine. Heck, even
| MD5 is still workable (although more prone to collide).
| Nowhere in that process is the internet, or "users" or
| anything else like that involved =)
|
| You use digests to quickly detect potential collisions, then
| you verify each collision report, then you delete the actual
| duplicates. Human involvement still very much required
| because you're curating your own data.
| dylan604 wrote:
| If we're talking specifically image deduplication, then a
| hash comparison is only going to find you exact matches.
| what about the image deduplication of trying to find alt
| versions of things like scaling, different codecs, etc?
|
| if you want to dedupe images, some sort of phashing would
| be much better so that the actual image is considered vs
| just the specific bits to generate the image.
| TheRealPomax wrote:
| Depends on the images. For photographs, a digest is
| enough. For "random images downloaded from the web", or
| when you're deduplicating lots of user's data, sure, you
| want data appropriate digests, like SIFT prints. But then
| we're back to "you had to bring network content back into
| this" =)
| dreamcompiler wrote:
| Very true but if the hash matches the images are
| guaranteed to match too. That's my first pass when
| deduping my drives. My second pass is looking for
| "logically equivalent" images.
| charlieyu1 wrote:
| At least 20 years too late
| upofadown wrote:
| I wonder what NIST does for a case where SHA-1 is not used for
| any cryptographic properties? I recently ran into that for
| OpenPGP. The authenticated encryption mode uses SHA-1 because it
| was otherwise used in the standard but because of how things work
| only a non-cryptographically secure hash is required.
|
| I have somewhat jovially suggested that the OpenPGP standard
| should just rename it if it turns out that the name becomes a
| problem...
| kzrdude wrote:
| Yes, they say "Modules that still use SHA-1 after 2030 will not
| be permitted for purchase by the federal government" so I
| wonder... does that mean products that can read 2022-era git
| repos (using sha-1) are they no longer allowed by that date,
| and so on? There must be exceptions by use case!
| klabb3 wrote:
| Use is quite vague in this context, at least having a
| distinction between read/write would be more clear.
| [deleted]
| woodruffw wrote:
| I'm not sure I understand what you mean by PGP not requiring
| SHA-1's cryptographic properties. Do you mean that PGP's
| authenticated encryption mode only requires preimage
| resistance?
| upofadown wrote:
| Not even that. It only requires that the hash is not
| reversible.
| woodruffw wrote:
| Can you elaborate? This doesn't match my understanding of
| how "authenticated" encryption works in PGP (by which I
| assume you mean MDC, which is closer to integrity-without-
| identity than authentication).
| upofadown wrote:
| For most PGP use, the MDC only serves as an integrity
| check [1]. That is the same for the proposed modes as
| well. In the case of symmetrical encryption it does in
| fact serve to authenticate the encrypted material based
| on the passphrase.
|
| It does not use the popular combination of an encryption
| function acting more or less independently of a MAC
| (message authentication code). It uses a different
| method[2]. This seems to cause much confusion.
|
| [1]
| https://articles.59.ca/doku.php?id=pgpfan:authenticated
|
| [2] https://articles.59.ca/doku.php?id=pgpfan:mdc
| Spooky23 wrote:
| If you're in a regulated industry and required to run FIPS
| validated modules in FIPS mode, usually you lose access to
| system implementations of the removed algorithm.
| twiss wrote:
| FWIW, the "crypto refresh" of the OpenPGP standard specifies
| the use of AEAD for authenticated encryption, replacing the
| SHA-1 "modification detection code". Even if the latter isn't
| broken, the former is more modern and more performant, and so
| retconning the use of SHA-1 for optics shouldn't be necessary
| once everyone moves to that :)
| upofadown wrote:
| Even assuming that anything real comes out of the "crypto
| refresh" (it seems to be going the way of the last effort) it
| would still be irresponsible to promote the use of an
| entirely incompatible encryption mode for no real reason. The
| existing standard has been in use for over 20 years now. Even
| if there were some sort of security weakness discovered it
| would make more sense to try to resolve that issue in some
| sort of backwards compatible way. Since there is no weakness
| then the best course of action seems pretty clear and is
| really easy to do. The crypto refresh is currently attempting
| to add no less than three new authenticated encryption modes
| in addition to the existing one for a total of four. Each and
| every mode is entirely incompatible with the others. This
| strikes me as sort of nuts...
| [deleted]
| twiss wrote:
| Only one of them, OCB, is mandatory to implement. The other
| two are optional, but there may be performance or
| compliance reasons to use one of them. E.g., people who
| care about FIPS compliance may want to use GCM.
|
| In any case, since there are feature flags and algorithm
| preferences to signal support for these, all of this is in
| fact backwards compatible. There's little risk that someone
| will accidentally use an AEAD mode to encrypt a message for
| a recipient that doesn't support it, since the recipient
| needs to signal support for it in their public key.
|
| And, offering performance and security benefits for those
| that care to upgrade their implementations and keys is
| still a worthy goal, IMHO.
| upofadown wrote:
| >The other two are optional,...
|
| That just makes things worse. The OpenPGP standard covers
| the offline, static encryption case. You have an
| encrypted file or message. If your implementation has
| implemented the encryption method then you can decrypt
| it. If it doesn't than you can't. Contrast this with an
| online, dynamic method like TLS where you can negotiate a
| method at the time of encryption and decryption.
|
| >In any case, since there are feature flags and algorithm
| preferences to signal support for these, all of this is
| in fact backwards compatible.
|
| The OpenPGP preferences are not applicable to symmetric
| encryption. In that case the implementation has to guess
| what method will be supported by the decrypting
| implementation. In most cases it would make sense to use
| the most widely implemented method. That is always going
| to be the one that has been used since forever.
|
| The OpenPGP preferences are included in the public key at
| key generation time. They reflect the capabilities of
| that implementation. The public key then has a life of
| it's own. It is quite normal to use that key to encrypt
| material for other implementations. Having optional
| methods, again, makes things much worse here. This is not
| a theoretical problem. I have already been involved in a
| difficult usability issue caused by an implementation
| producing one of these new incompatible encryption modes.
| The file was created on the same implementation as the
| public key. So the implementation saw that the reciepient
| supported all the same methods that it did. But the
| actual implementation that did the decryption did not
| support that mode. This sort of interoperability problem,
| even if it only happens from time to time, seriously
| impacts usability. That is the ultimate issue. Why are we
| making things harder for the users of these systems for
| no real reason?
| twiss wrote:
| > The OpenPGP preferences are not applicable to symmetric
| encryption. In that case the implementation has to guess
| what method will be supported by the decrypting
| implementation. In most cases it would make sense to use
| the most widely implemented method. That is always going
| to be the one that has been used since forever.
|
| I agree, if you don't know the capabilities of the
| implementation decrypting the message then it makes sense
| to be conservative, and wait until these AEAD is widely
| implemented before using it.
|
| > I have already been involved in a difficult usability
| issue caused by an implementation producing one of these
| new incompatible encryption modes.
|
| I also think that generating AEAD encrypted OpenPGP
| messages today is irresponsible, since the crypto refresh
| is still a draft, not an RFC yet. Even if the decrypting
| implementation _can_ read the message today, the draft
| could still change (although now that it 's in Working
| Group Last Call it's unlikely), and then you'd have an
| even bigger problem.
|
| But I think that's the fault of the implementation, not
| of the (proposed) standard. If we eventually want to have
| the security and performance benefits of AEAD, we have to
| specify it today (well, or yesterday, but that's a bit
| hard to change now ^.^).
| upofadown wrote:
| >If we eventually want to have the security and
| performance benefits of AEAD,...
|
| The thing is, there doesn't seem to be any security
| weaknesses with the existing AE method. I have looked
| hard. There also doesn't seem to be any need for the AD
| (associated data) part.
|
| OCB seems to be the fastest out of all of them. If the
| proposal was just to add on OCB as an enhanced
| performance mode then I might be OK with that. Why make
| the people encrypting multi-TB files wait? I am mostly
| grumpy with the idea that we have to drop an existing
| well established standard for stuff like messaging and
| less extreme file sizes.
| zachruss92 wrote:
| It's about time haha. Once they found real world conflicts it
| needed to be phased out for anything security related. At least
| it isn't very hard to move from SHA-1 to SHA-256.
| px43 wrote:
| AKA, SHA-2 :-)
| SAI_Peregrinus wrote:
| SHA-2 is an entire family of hash functions: SHA-228,
| SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256.
| snhly wrote:
| Other than legacy stuff, I think the main reason programmers
| still use it is the fact that '1' is easier for them to call to
| mind than '256', or whatever else. So when you're throwing a
| script together really quickly, you'll prefer to type SHA1
| instead of anything else. At least that's how my brain works.
| jodrellblank wrote:
| Who named it "Secure Hash Algorithm" :|
|
| Now the name will be annoyingly and misleadingly wrong _forever_
| , in a way that was totally predictable.
| GTP wrote:
| That was the name of the standard, for which they had to pick a
| "Secure Hash Algorithm". And it's normal to have to update
| standards over time, regardless of the name. Which name would
| you have suggested for a standard defining a secure hash
| function? Usually it's better to not use fantasy names for
| standards, and "A Hash Function That Is Secure Now But Maybe
| Not Anymore In 10 Years" it's a bit too verbose in my opinion.
| dolni wrote:
| Change "Secure" for "FIPS" and you have a decent name. FHA-1
| -- FIPS hash algorithm, version 1.
| lapetitejort wrote:
| The same concept applies to telescopes. Every year a
| "Ridiculously Huge Telescope" gets announced. If I named them
| I'd start small: "Decently Sized Telescope"; "Mildly Safe
| Hashing Algorithm".
| Dylan16807 wrote:
| Huge Telescope 1. Huge Telescope 2. Huge Telescope 3.
|
| If we do the same thing as the hash names, I think it's
| fine. "SHA-1", specifically with the "1", doesn't cause
| problems.
| jagger27 wrote:
| Cryptographers have a long history of doing this. Many of them
| broken. DES and WEP are two that immediately spring to mind.
| kzrdude wrote:
| Fortunately it's still true for Fast Fourier Transform. Would
| be fun to break that one.
| woodruffw wrote:
| Well, the safest part of any seatbelt is the part that goes
| over the chest, not the seat :-)
|
| Standards evolve, and SHA has grown new generations to replace
| ones that have become insecure. See also "Secure Sockets
| Layer."
| icare_1er wrote:
| Well, in that case, we should remove "Secure" from any protocol
| name like HTTPS, FTPS, SSH and pretty much everything, because
| by definition, whatever is secure at a given time probably wont
| be anymore 10years later.
| jodrellblank wrote:
| No because those S's don't mandate any particular algorithm;
| HTTPS has changed from SSL to TLS, and SSH often throws up
| mismatched cipher or version errors when connecting to older
| servers, so they could still be secure 10 years later.
|
| I would however be fine with removing "unlimited" from the
| name of services which are limited, 'Simple' from protocols
| which don't need subjective comments about their complexity,
| 'Ultimate' and 'Supreme' from the names of things which are
| neither the last nor best, etc.
| yrro wrote:
| I wonder if Windows' Kerberos implementation will ever support
| the aes128-cts-hmac-sha256-128/aes256-cts-hmac-sha384-192
| encryption types. It's been stuck on aes128-cts-hmac-
| sha1-96/aes256-cts-hmac-sha1-96 since Vista...
| ComplexSystems wrote:
| Any estimate on how long SHA 2 will last?
| woodruffw wrote:
| SHA-2 uses the same construction as SHA-1, but my understanding
| is that there are no practical collision (much less preimage)
| attacks against full-round SHA-2.
| tptacek wrote:
| Indefinitely. It's fine. The message expansion in SHA2 is
| totally different from that of SHA1 (hash message expansion is
| analogous to cipher key scheduling), and forecloses on the SHA1
| attacks. JP Aumasson, part of the BLAKE team, has suggested
| SHA2 might never be broken; that's hyperbolic but gives a sense
| of how little research is on the horizon to threaten it.
|
| The big issues with SHA2 are MD structure/length extension
| (which HMAC addresses, and you can also use the truncated
| versions; length extension matters pretty much exclusively if
| you're designing entire new protocols) and speed.
|
| I'd reach for Blake2 right now instead of SHA2 (or SHA3) in a
| new design, but I wouldn't waste time replacing SHA2 in
| anything that already exists, or put a lot of effort into
| adding a dependency to a system that already had SHA2 just to
| get Blake2.
| miga wrote:
| Then why does NIST warn that we might need PQC algorithms by
| 2035?
|
| Or is this claim ignoring progress of quantum computing?
| luhn wrote:
| Quantum computing threatens factorization and elliptic
| curves, i.e. RSA and ECDSA. Hash functions are considered
| relatively safe. The NIST's PQC standardization is focused
| on public key cryptography--I can't find any initiatives
| from them working with post-quantum hashing.
| dchest wrote:
| Here's one:
|
| "neither us nor our children will see a SHA-256 collision (let
| alone a SHA-512 collision)" -- JP Aumasson
| https://twitter.com/veorq/status/652100309599264768
___________________________________________________________________
(page generated 2022-12-15 23:00 UTC) |