Genbox

This is not an example of premature optimization. It is an example of guessing at the problem and missing the mark.

It is best explained by Donald Knuth himself. The full quote is:

> "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.".

Source: Structured Programming with go to Statements by Donald E. Knuth. http://web.archive.org/web/20130731202547/http://pplab.snu.a...

Thanks. That is quite horrifying.

I'm one of those security experts. I've broken more cryptosystems than I can count through security & code reviews. You would be surprised how many vendors have no idea on how cryptographic primitives work or when/how to use it. This is exactly what we mean when we say "don't roll your own crypto".

There is a communications problem within all of this. If I break a cryptosystem, I do not have permission by either party (customer/employer) to go and write a blog post about it. All in the name of "protecting our users". The same goes for my colleagues around the world, as such it gets very little attention.

As for threat actors misusing it, there is a value/effort calculation in their world where it is often easier to access content through other means. Crypto is hard - for everyone, even threat actors - so you won't often see them trying to tackle it.

Anyone know of any good population based studies that quantify the real amount of people with long COVID-19?

Their offices in Moscow (Capital of Russia. Largest city), Saint Petersburg (Second largest city in Russia) and Novosibirsk (Third largest city in Russia) were suspended indefinitely in March 2022[1]

[1] https://www.jetbrains.com/company/

"Small" here being 1900 full-time employees and ~250 interns in 10 different offices[1]

[1] https://www.jetbrains.com/lp/annualreport-2022/

> It looks like your fastest FNV[3] has some issues where it repeatedly increments `p` but reads relative to `uPtr` which is not being incremented.

That is entirely possible. Some hashes like the FNV-YoshimitsuTRIAD variant is not fit for real-world use and lack test-vectors to ensure that ports like mine is correct. I'm slowly but surely working my way through the C/C++/Rust/Go implementations out there and verifying them against my implementation to ensure it is correct. Luckily, a few authors provide extensive test vectors[1]

Thanks for the feedback, it is very much appreciated.

> FNV1a-YT also employs a good trick [...] While this is fine, I'm not sure if it's really FNV-1a anymore. It was made (by Sanmayce) to optimize for instruction-level pipelining, and use the fact that modern CPUs have multiple execution ports. But due to those changes, it is not compatible with FNV1a anymore.

The trick of reading in stripes is employed by many of the fastest hashes. It is kinda funny to see how one author prefers a switch case over for loops, where others prefer while loops. The differences can sometimes have a big impact on what optimizations the compiler decides to use.

[1] https://github.com/Genbox/FastHash/blob/master/src/FastHash....

The algorithm above is a 64bit to 32bit reduction method. It performs a 64bit mult and then discards the lower 32bit. I'm not sure if Daniel Lemire invented it as a alternative to modulo, as I've seen the method used before, but he certainly made it popular[1]

There is a 64bit version as well (2x64bit -> 64bit), that when compiled using 128bit multiplication is quite fast too.

The method made it's way into .NET runtime[2]. It is used in HashSet, Dictionary and ConcurrentDictionary today.

[1] https://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-...

[2] https://github.com/dotnet/runtime/blob/c22f7f8c73766830b3262...

> You can get higher quality and throughput for short strings from a hash that uses AES instructions or wyhash, or for long strings maybe from xxhash.

What would you consider a short string? The latency of AESENC is 5 if I remember correctly. In that time you can FNV-1a a "short" string.

For longer strings I agree that WyHash and xxHash is better. I have a benchmark of both further down on FastHash's github page[1]. Of course, that is only a measure of speed, but both are high quality as well[2].

From the top of my head, t1ha, falkhash, meowhash and metrohash are using AES-NI and none of them are particularly fast on short inputs, and at least two of them have severe issues, despite guarding against lots of vulnerabilities, which your construction does not.

You are right regarding bulk-keying with SIMD outperforming any kind of scalar hashing one-at-the-time. I've build a database that does just that (requires keys to be available in bulk - like when doing bulk inserts) using SIMD, and the latency becomes negligible.

[1] https://github.com/Genbox/FastHash

[2] https://github.com/rurban/smhasher

Yeah... and you know... a natural weather phenomenon. I thought this was about storm chasers or something.

At the moment I'm working on FastHash[1], a pet project of mine to port a few high-performance non-cryptographic hash functions to C#.

I'm also trying to build FastLinq, a value-by-reference Language Integrated Query (LINQ) optimized for high-performance scenarios. It is kind of a weird mix as LINQ in .NET is known for its high overhead.

Finally, I'm working on an Office setting synchronization application. I heard a podcast with Paul Thurrott complaining about the lack of sync solutions, so I thought I would do one for fun.

[1] https://github.com/Genbox/FastHash

I recently got in a fight with GitLab of all places. I setup SSO on my self-hosted instance so people could sign-up and report bugs in my applications.

I never even noticed that a bunch of accounts was created until GitLab wrote "we noticed you are X licenses over your limit. Will will charge your credit card on <todays date>". I didn't know it worked that way, and I honestly didn't think users with no permissions to do anything would count as a full license.

I nearly shit my pants. It was a lot of money. I contacted support and asked them to remove my payment details. They declined and forwarded me to a sales person.

I told the sales person about my issue, but she said I accepted their terms and conditions, so now I had to pay. But hey, if we had a quick call with some sales executives, then maybe we could resolve the matter...

Suffice to say, now I use one-time credit-cards for all online services. It is not the first time I've been hogtied by an online service with no recourse.

This is the good ol' Trusted System issue. I've roamed in this area before, both in terms of creating a chain of trust in crypto systems and also at a more philosophical context for voting systems. I'll decompose the issue into more abstract questions:

> Can we ever trust any system?

Yes, to an extent. There is no such thing as a system that can be trusted completely, but we don't need it to be in 99% of cases. One might say "you can trust crypto primitive XYZ. If you use it, it would take 1 billion years to break". That might be true, but side-channel attacks, leaks, statistical biases and whatnot will always be an issue.

To get as close as possible to trust in a system, it needs to be formally verified with proofs. That's the best we can do program/algorithm wise, but even if we trust the program, it cannot trust the system it resides on.

> How can we achieve trust then?

You know how bitcoin is based on a distributed consensus algorithm? It protects the whole system from collapsing due to a bad actor in the system. Even if thousands of people decides to cheat, it won't have any considerable effect.

Let's say you buy a hardware wallet from a reputable vendor - if they decide to cheat, you will be at their mercy. To combat this, you need a way to verify that what it does, it does so correctly, but also without side effects.

This is again something that needs to be formally verified. Any deviation from the spec will stand out like a sore thumb. To achieve this, we need to introduce a verifier.

The verifiers job is to check if the hardware wallet did it's job, but without being in the possession of the private key. There are lots of ways to do this, but a hot topic today is zero knowledge proofs, where the wallet would need to stand up to scrutiny.

The verifier would also need to check the results on the blockchain. Not just that the result generated is correct, but also that it is without side-effects.

> But then we have to trust the verifier!

Yep, and each time we introduce a verifier for the verifier, we will have made the system more trusted. Let's say we have N verifiers, whos best interest is that your wallet did the right thing.

In a transaction, it is not only in _your_ best interest that the transaction is correct (and without side-effects), but also the other party. We can extend this system to be a small group of people in _any_ transaction. If a small group of verifiers all agree with a certain level of consensus, then we can trust the system beyond a reasonable doubt.

This might sounds familiar to those who work with blockchains - and you would be right. It is eerily similar to how it works today. However, the blockchain covers only the cryptographic guarantees. The system needs to be extended to cover formal verification of the system as well.

> Example

Formal verification is a mostly academic exercise for most, so I'll give a small example for those of you who are unfamiliar with it.

Let's say person A and B make a transaction. Both have super secure hardware wallets and the crypto used it state-of-the-art. It should be secure right?

We can review the code of the system, but it is hard to identify mistakes. Who knows, maybe there will be a new area of vulnerabilities in a few years, and we never saw it coming.

Within the area of "correctness", we first need to make a formal specification. We create some testable properties about the system that needs to hold true, no matter the transaction or who is involved (these are called invariants).

So person A transfers 1 bitcoin to person B, they do so by signing a nonce with a private key. Person A checks the nonce and ensures it is indeed random (test 1). The signature is sent to person B, which then tests if the signature is no different than random data (test 2).

Howe test 1 and 2 are performed are incredibly important and very difficult to do, but not impossible.

If test 1 or 2 happens to be non-random, then we can just reject the transaction. We don't know if it was non-random by chance or on purpose, but since it does not live up to our criteria, we will reject it.

This means Person A will check what they got from person B and vice versa. However, why not have a bunch of random people participating in the block chain do the same checks?

If 0.1% of all in people in the blockchain checks the transaction between person A and B, and they all have a say if the transaction gets rejected, then we can trust the system beyond a reasonable doubt.

And no, this system is not perfect. We don't need it to be. We need it to be good enough so it becomes incredible hard to cheat. Also note that I've omitted a lot of details for brevity as well.

"phone home" is not really the right way to describe it. The attack proposed is that a hardware wallet (being a black box) can give the hardware wallet developers information about the private key.

Note that I have very little understanding of blockchain crypto, so I am unable to confirm/deny the information OP gave. However, the way I understand the attack is:

Hardware wallet generates a private key. It keeps this key in internal storage. When a transaction is made, the wallet makes a signature. According to OP, there is a variable here (I'm guessing either multiple private keys, or the ability to choose a signature algorithm, or even embedding a timestamp in the transaction) which the hardware wallet can use to "leak" information.

Let's say the wallet decides to embed a timestamp. Whenever a bit in the private key is 0, the timestamp is even, and when a bit is 1, the timestamp is uneven.

After 4096 transactions, presumably the whole private key is now stored in the blockchain as even/uneven timestamps.

This is of course a very slow way of leaking the private key, but does illustrate the problem of having unverified devices be responsible for crypto results.

I was wondering when it would become the norm to call it "ducktape". It has been 3 hours and nobody has corrected it. Last week I found a 3-pack of "ducktape" in the builders market.

I'm not making fun of you or trying to be funny - it is simply an observation that I find interesting.

Discussion here: https://news.ycombinator.com/item?id=32148318

I started my company back when news about .NET Core was first coming out (2016).

I've been bitten by Microsoft before (relied on tech they eventually killed), but decided it was worth it because of the modernization they had planned. Things such as AOT compilation, strong cross-platform support, lightweight runtime etc. was a giant productivity booster for me and my small team of 4 people.

Microsoft eventually backpaddled on a a few of their promises, but I still believe it was the right choice. I had doubts back then, but I would not hesitate today.

It is a piece of art. Functional and well designed.

I find these issues all too common among programmers. Especially with regards to MD5 and SHA1. They see a headline saying "SHA1 is now fully broken!", but in reality it is a fluff-piece on either Shattered (Google) or Sha-mbles (Leurent, Peyrin), and broken is used for effect more than anything else.

While it is quite impressive when someone manages to reduce the attack complexity, by let's say, reducing the cost of a chosen-prefix collision from billions of GPU hours to millions, it does not make the algorithm completely useless from one day to the next. It has to be taken into context.

Your username is too fitting for this, so I had to check your submissions. There is a link to Cow Tools on Wikipedia. I did not know what that was.

"Cow Tools" is a cartoon from Gary Larson's The Far Side, published in October 1982. It depicts a cow standing in front of a table of bizarre, misshapen implements with the caption "Cow tools".

Thanks for the laugh.

The more I research Singularity, the more I like it. I deep dived into all the design docs years ago and the amount of rethinking existing OS infrastructure is astounding.

Joe Duffy has some great blog posts on Midori (OS based on Singularity) here: http://joeduffyblog.com/2015/11/03/blogging-about-midori/

I find that most people are primarily driven by a need. You need food? Pick some berries. You need warmth? Start a fire.

When it comes to technology - especially advanced technology like Imagen - people don't see the value because they don't have a need associated with it.

> nearly everyone writes code for Unix/Linux and then cross-compiles for Windows

That's a very bold statement that I suspect is far from true.

Of course Microsoft only include functionality they want. Just like any other platform only include what they want. It is entirely their prerogative. Just because they don't include anything and everything other people want, it does not make them less open source.

We are entirely free to fork the project, embed the change and compile our own binaries. You don't have to strongarm a change into upstream for that.

> NAT is not so widely needed as it is in IPv4.

If every device had a globally unique address, is there really a need for NAT?

Note: This article is about Type 1 Diabetes.

While S3 is not a CDN as such, it does have a feature called "Request payer" which means the requester pays for the request. It won't mitigate anything for public files, but it will mitigate DoS attacks through a third-party.

Microsoft developed the excellent Code Contracts[1] project. From the user's perpective, tt was a simple class called Contracts with a few methods such as Require(), Ensure() and Invariant()

Underneath the hood it used the Z3 Solver[2], which is both intuitive, flexible and fast. It validated the contracts while coding and highlighted in the Visual Studio IDE when a contract was broken.

You could write something like: Contracts.Requires(x > 5 && y > x);

Which would get translated to a compile time check as well. Unfortunately, Code Contracts has been dead for years now, and it was even removed entirely from .NET[3] due to being hard to maintain, and the verifier stopped working in newer versions of VS.

Luckily, C# developers now have a small taste of contracts due to nullability analysis[4], but even more exciting is that contracts is making its way into C# as a first-level standard[5].

[1] https://www.microsoft.com/en-us/research/project/code-contra...

[2] https://github.com/Z3Prover/z3

[3] https://github.com/dotnet/runtime/issues/20006

[4] https://docs.microsoft.com/en-us/dotnet/csharp/nullable-refe...

[5] https://github.com/dotnet/csharplang/issues/105

Are there only 6 parts to the story? It seems to stop short of actually determining if there is malware with the software. A VirusTotal result is in no way accurate.

The paper is not a study in itself, it is a specific medical case that was chosen due to the possible link between the SARS-CoV-2 vaccine and the acute hepatitis this person developed.

The hepatologists found SARS-CoV-2 specific T cells (determined via ELISA) in the liver of a 52-year-old male which had caused an autoimmune reaction in which the patient developed acute hepatitis. It was ruled out to be any of the known hepatitis viruses through serology and PCR testing.

The link between SARS2 and the hepatitis came from the high amount of SARS2 specific CD8 T-cells. However, they also found Epstein-Barr virus specific T-cells in the same areas, although the SARS2 specific T-cells were activated cytotoxic with a high correlation to the concentration of hepatitis.

I'd say that shows a strong correlation and it is possible this individual developed hepatitis from the Pfizer vaccine (BNT162b2 mRNA). There is nothing that suggest that this is in any way or form an expected side-effect from the vaccine itself.

Edit: Note that autoimmune diseases can come from almost anything. There will be a very few cases where the immune reaction to the vaccine itself will cause an autoimmune disease. However, most of the children that have developed hepatitis are under the age of 5 and therefore not eligible to receive the SARS-CoV-2 vaccine in the countries where the reports are from.

However, a lot of the children with hepatitis have had an SARS-CoV-2 infection, which is why that link is currently being investigated by hepatologists.