Well that's just sad.

I think it's understandable if you enjoy something to be feel a bit apprehensive about the idea of never getting to enjoy new parts of it. Lots of people would be very dissatisfied if GRR martin or rothfuss died before finishing their series.

If it ain't broke, don't fix it.

Not sure how I feel about my medical information being handled by PHP...

This won't make you feel any better...

Many healthcare systems are a COBOL-dialect all the way at the bottom. Some of these had PHP layers shimmed in, when the web became a thing.

I've seen php scripts that shell out to .bat's, that interface with the COBOL engine. It's a mad world.

For context, a large amount of healthtech software was written in the 80s (kind of like fintech, the difference is that there's no competitive advantage to having better technology in health).

It's a minor miracle that anything works at all.

I showed someone from the Allscripts innovation group what I could do in an Elixir repl once, and his jaw hit the floor. Then I showed him how we wrote parsers. He said we'd never make it because we turned around new features too fast for anyone to trust us.

Haha, among the most popular EMR you'll find a snarl of Perl, PHP, VB, Mumps/M, C#, old Java, cobol, and several proprietary languages. There is a small number of people who die in the US every year do to medical mistakes attributable to software bugs.

Would it make you feel better to know your PID is being stored in a database language where the only data type is strings, and there is an intrinsic command to interpret any string as code?

Please do not disparage the opinions of others in such a snarky way.

https://news.ycombinator.com/newsguidelines.html

So basically no features planned as of yet. The author just lists features they wish to see in future python versions. Clickbait title.

It's sad that someone with self-taught skills can earn their living?

So sad that someone can take an introductory course and then YEARS later be employed in the industry.

Which part?

why are three dogs surprising? should we expect a lot more

Isn't the image weird? 600 people in the search party, split across many directions and only 3 of them have rescue dogs. Given the importance of the event, and the effectiveness of rescue dogs (actually a dog found the mayor), one would have to assume that it's a typo.

Even a 30-man search and rescue party would generally have more than 3 dogs.

What?

A function that concatenates the results of two 64-bit hash functions _is_ a 128-bit hash function.

Just as a string of individual digits makes a larger number.

I mean, technically yes, but it it would be a 128-bit hash function with the security properties of a 64-bit hash function, so it offers little advantage over just using a 64bit hash (which I think was also the point you were trying to make, I think?).

However, that doesn't really address the original question on how much harder cracking 2x64bit hash would be than cracking a single 128bit hash would be.

My best guess there would be that it's really quantify as you start opening up more dimensions besides the number of bits. The gain would mostly come from protection against other properties from one of the algorithms like a potentially hidden backdoor or a undiscovered mathematical weakness. So as long as the strength of the individual hash function holds up, it probably makes sense to diversify between hash functions. E.g. SHA3-256 + BLAKE3-256, probably offers better long-term security properties than using SHA3-512.

So your point is that if you take the output of the _same_ 128bit hash function twice, split it into 64bit parts and then put it back together, you still have the full properties of the 128bit hash function? Well, no shit.

I have to admit that I'm not the greatest cryptography whiz, but I can't image that this holds up for _independent_ hash functions, where you should be able to more cheaply run a preimage attack against two 64bit hash functions than one 128bit hash function.

>I have to admit that I'm not the greatest cryptography whiz, but I can't image that this holds up for _independent_ hash functions, where you should be able to more cheaply run a preimage attack against two 64bit hash functions than one 128bit hash function.

performance is probably an issue. SHA256 has 256 bits and SHA1 has 160 bits (1.6x more bits), but SHA256 isn't 1.6x slower, it's only 38% slower. benchmarks used: https://www.cryptopp.com/benchmarks.html

Back to the original question of "how secure are 2x 64bit hashes compared to 1x 128 bit hash?", I can't imagine how it could be any more secure, considering that if it were more secure, you could just make your 128 bit hash function be the concatenation of the two 64 bit hash functions. It might be equally secure, but I'm not sure why you'd use it over a properly designed 128 bit hash function.

> where you should be able to more cheaply run a preimage attack against two 64bit hash functions than one 128bit hash function.

Try doing that in my example.

Your hash functions are contrustructed in a way such that the concatenation has the security properties of a 128 bit hash function (because your construction is equivalent md5). I am not sure that results holds for all concatenations of hash functions. Or for SHA concatenations.

I appreciate you making me think deeper about hash functions. Nice construction.

My guess: To paths to the same number string are the same number. ie: two 64 bit numbers is a 128 bit number in disguise.