This particular piece has been shared near me several times, in the context of this recent AWS outage, the previous big AWS outage, non-AWS outages, and others. Every time, I feel like I'm in vague agreement with the author, and at the same time, none of it is the least bit actionable. Even if Cook is correct, so what? There's no concrete change I can make in my working.
The nice thing about Blum-Blum-Shub or Blum-Micali is that they come with a proof of security. Even then, they tend to be impractical, due to performance and side channels.
This one is missing the most important part, the proof. Indeed, a sibling comment notes that empirical results look pretty flawed.
The forms of Keccak that were initially standardized in SHA-3 were secure but significantly slower than possible.
This had the consequence that for many applications where speed is important the existing very efficient implementations of BLAKE2b-512 or of the faster but less secure BLAKE3 have been preferred, or SHA-256 or SHA-512, on the CPUs where these are implemented in hardware.
However, it is also possible to use Keccak in modes of operation where it is as fast or faster than any other comparable hash (e.g. by using parallelizable tree hashing, like the BLAKE derivatives). Previously these modes were less known, because they were not standardized and because the existing reference implementations were less polished than those of the BLAKE derivatives.
After being included in standards like this RFC, it can be hoped that these good secure hashes will become more widely available.
Recent ARM-based CPUs have instructions for the core functions of Keccak, while on AMD/Intel CPUs with SHA-512 Keccak is rather fast even without dedicated instructions. Therefore on such CPUs KangarooTwelve and TurboSHAKE can be very fast right now, when using an appropriate implementation.
For instance I use BLAKE2b-512 for file integrity checking, frequently (i.e. at least a few times per day) running it over hundreds of GB or over many TB of data. Now, when I have an AVX-512 capable CPU, i.e. a Zen 5, I should experiment with implementing an optimized KangarooTwelve, because it should be much faster on such a CPU.
If you want to try an optimized AVX-512 implementation of KangarooTwelve on the command line, you can `cargo install k12sum`. On my machine it's neck-and-neck with `b3sum --no-mmap` (which does not use threads).
Note that the tweaks to Blake2 and Blake3 weakened the cryptanalysis done for the SHA3 hashing contest such that it is not directly applicable. That doesn't mean they are not well respected and probably fine, it's just that we have less confidence in them than K12 and other sibling Keccak hashes.
I have noticed too late that I have incorrectly written "AMD/Intel CPUs with SHA-512", but I have meant AMD/Intel CPUs with AVX-512".
(There are a few recent Intel CPUs that have SHA-512, i.e. Lunar Lake and the desktop variant of Arrow Lake, i.e. Arrow Lake S, but this has nothing to do with Keccak.)
Anywhere you need a high assurance and high speed hash function. And because of the sponge design, it can be the heart of lots of cryptographic protocols.
This is useful when you use a secure hash function as a key derivation function for some communication protocol or file or disk encryption method. This is one of the most frequent use cases for a secure hash function.
In such cases, you hash some random value or a salted password or a shared secret value obtained by some kind of Diffie-Hellman exchange, and you must generate a variable number of secret keys, depending on the target protocol. You typically need to generate at least an encryption key and an authentication key, but frequently you need to generate even more keys, e.g. in a communication protocol you may use different keys for the 2 directions of communication, or you may change the keys after a certain amount of time or of transmitted data.
When you have just a hash function with fixed output size, e.g. SHA-512, you must transform it in a hash function with extensible output size, to get all the keys that you need.
Typically this is done by hashing repeatedly the secret value, but each time concatenated with some distinct data, e.g. the value of a counter. Like for any cryptographic operation, every detail of the implementation matters and it is easy to make mistakes.
If you already have available a hash function that has been designed to provide extensible output, then you can use it as it is and you do not have to bother with designing an ad-hoc method for extending the size of its output and with the analysis of its correctness.
This sounds like something I would use HKDF for. But, to your point, it's nice to be able to build the design with a fewer number of primitives, and likely more performant, too.
Maybe, but now they could IPO confidentially as a tech company with high revenue with a multi-billion dollar valuation, which sort of sounds like their end goal
That was the first thought I had, too. When the dot-com bubble burst, every VC was slapping companies together to try to forestall the black mark of having a “failure” and balance sheet write off that they would have to show the LPs (investors) in the next LP meeting. It got so bad that someone described it as “tying together two rocks and seeing if they will float.” Needless to say, most didn’t. So, this makes me wonder if we’re seeing the first signs of the bursting of the AI bubble which we all know we’re in the middle of. Maybe it’s legit and there is real “synergy” or whatever, but the fact that this is two companies within the same VC portfolio makes it suspect.
That happened at a company I was at 8 years ago. It acquired a company also owned by the major investor. Layoffs started with a month. They whole thing shut down within 6 months.
those are heavy accusations to toss around and that the title would like you to conclude, but doesnt pass the basic smell check of fivetran's founders still having control of the company. dbt was the hottest company in the data world 3 years ago and is valuable.
I've learned to be wary, too. Most desktop motherboard these days have several fan headers just above the memory slots. They also frequently use DIMM slots that only have one latching lever, usually at the top of the slot near the fan headers. So when you're trying to remove a memory module, if you use slightly too much force and your finger keeps moving after the latch opens up all the way, you get a deep puncture wound.
The headers on the keyboard look like they'd be easier to hit accidentally, but probably not with enough force to cause a serious injury. I'd still prefer having some covers over them.
As this is a tech forum, I expect that the name that stands out is Radio Shack, and I do agree that that story is tragic. For me, as a long time New Yorker, the other name that stands out is Modell's. They were, for quite a long time, a fixture in New York City and beyond. Even for us not sports inclined, we still knew Modell's as a reliable retailer of sneakers throughout the years. Arguably, their Covid era bankruptcy was already the end, and this was just private equity puppeting the corpse. Nevertheless, it's a sad and nostalgic story.
I thought you were going to say Pier 1 instead. Because I was scammed into buying wicker furniture circa 1994, I’m not surprised pier 1 is continuing buying a legacy of scams.
[1]: https://xkcd.com/1172/ [2]: https://xkcd.com/1053/