EDIT: okay, looks like the official documentation lists it, but many places I looked didn't. Maybe it wasn't being detected in cpuinfo?

A VBMI2 example implementation can be found in the function named divide_with_lookup_16b: https://godbolt.org/z/xdE1dx5Pj

PMULLD is probably just doing 2x PMULUDQ and discarding the high bits.

(I tried commenting on his blog but it's awaiting moderation - I don't know if that's ever checked, or just sits in the queue forever)

Yes.

> Or should your one-liner be a library?

Definitely not.

Particularly if I can write the one-liner faster than it takes one to search, check, include and install the library.

const tryNew = (f, ...a) => {

  try {

   return new f(...a);

  } catch(x) {

   return undefined;

  }

 };

I don't get why JS devs like to whinge about the smallest things. And we get stuff like leftPad because of huge aversion to writing utility functions.

Since users could be trying to compile it on GCC 9.4.0, and as the functionality dependent on the header isn't critical to the application, if the build detects the header is broken, it just disables the functionality and emits a warning.

Back to xz: If security isn't your top priority, it seems reasonable to just ignore the failure of an optional feature and just move along. Of course, in hindsight, it's easy to point fingers, but without that, it doesn't sound completely unreasonable to me.

If I were trying to phish someone, I wouldn't attack the public key crypto part, so how domains come into play during authentication doesn't matter. I'd just grab the "unencrypted" session token at the end of the exchange.

Even if you somehow protected the session token (sounds dubious), there's still plenty a phisher could do, since it has full MITM capability.

There's also the issue of how many sites actually use it, as well as how it handles the loss of or inability to access private keys etc. I generally see stuff like 'recovery keys' being a solution, but now you're just back to a password, just with extra steps.

Sure, you can probably come up with some non-HTTPS scheme that can address this, but I don't see any site actually doing this, so you're back to the unrealistic scenario.

Except that phishing doesn't require the private key - it just needs to echo back the generated token. And even if that isn't possible, what stops it obtaining the session token that's sent back?

For a typical person, maybe, but for a tech-minded individual who understands security, data entropy and what /dev/random is?

And I don't see how MFA stops phishing - it can get you to enter a token like it can get you to enter a password.

I'm also looking at this from the perspective of an individual, not a service provider, so the activities of the greater percentage of users is of little interest to me.

> There are plenty of scenarios where MFA is more secure than just a strong password.

And how realistic are they? Or are they just highly specific scenarios where all the stars must align, and are almost never going to happen?

Assuming n is an integer:

  * 5n bytes received = 4n bytes data
  * 5n+1 bytes received is [invalid]
  * 5n+2 bytes received = 4n+1 bytes data
  * 5n+3 bytes received = 4n+2 bytes data
  * 5n+4 bytes received = 4n+3 bytes data

Unfortunately for Z85, they made the highly questionable decision to use big-endian, which means it can't take base64's route. You could probably define an incomplete group at the end to be right-aligned or similar, but you may as well be sensible and just go little-endian.

Why oh why??!

If it were little endian, you could probably skip the "must be multiple of 5 chars/4 bytes" requirement, not to mention that 99.9999% of processors out there are running in little-endian mode.

There is nothing "envious" about network byte order.

PMULUDQ is in SSE2, though I haven't checked if that's usable for the problem here. There's also PMULLD in SSE4.1 if you only need a 32-bit result. But for summing digits, perhaps SSE2's PMADDWD could be sufficient?

I'm doubtful of this in general. Some older processors did have a very slow BSF/BSR implementation, so it may be the case there, but I wouldn't generally stick with that assumption these days. (and it's most certainly not the case on AMD Zen, given all its ALUs can do these bit ops)

AVX doesn't have lzcnt prior to AVX-512 CD, so it could make more sense there, though I'd imagine that abusing float conversion (convert to float, extract exponent) would still be faster.