periodontal

For an easy strategy, guess all zeros at first. Call resulting distance E1 and let S1 = E1 × E1.

Now guess with X = 1, rest still zero, obtaining S2. We can calculate X = (S1 - S2 + 1)/2.

Now guess (X, 1, all zeroes). Do the same calculation as above to obtain Y, except use S1 - X × X in place of S1.

You can repeat as needed for the other coordinate(s). However, the last coordinate requires no guessing since it's a known straight line distance from an extremal point. So you can calculate it directly (e.g., W = sqrt(S1-X×X-Y×Y-Z×Z) for 4D).

This guarantees you can solve any 4D in 5 guesses.

For the case you mention with rounding, I'm pretty sure it's still possible. If your probing guess for each coordinate uses the maximum value instead of 1 (e.g., 999 for 3 digits), it'll ensure that at least one guess is 500 away from the correct value, making at least one of them very sensitive to the exact distance. Then you do something like X=(S1 - S2 + 999×999)/(2×999). This likely breaks down in high enough dimensions (guessing 100+) due to distance being less sensitive on average to wild perturbations in any one coordinate. There might also be issues with intermediate rounding while calculating the distance if using doubles or similar.

This is probably due to the underlying filesystem being case insensitive on Mac. As a hack, you can create a symlink alias on a per repo basis.

ln -s HEAD .git/head

Basically, hash all your data items, keep track of the maximum number of leading 0 bits seen in a hash so far.

This is a decent proxy (but not without error) for how many distinct items you've seen so far since large numbers of leading zeros should be uncommon. Finding this means you probably saw a lot of other things to get to that point (intuitively, about N leading zeroes are expected after seeing 2^N items).

This is actually the same thing that a proof of work cryptocurrency does to control difficulty: change target number of leading zeros so miners have to do more/less work to find a match.

Of course, you could get "lucky" with a single counter and the resolution isn't great, so HLL first separates the values into buckets which are estimated separately and then combined to give a more robust estimate.

You might also try maximum instead of average. This is minimax and represents worst case scenarios for each guess.

This is mostly useful for optimal play against an opponent (which is not the case here). Imagine an adversarial version where the opponent doesn't have to commit to a word at the beginning but must reveal one matching all clues if you can't get it in 6 guesses (basically, they can change their word when you guess and you are trying to make that impossible).

You can get something somewhat similar with "always create merge commit" workflows (no fast forward) and changing your tooling to look at the first-parent-history by default. This view will have one commit per merge, but you can choose to follow the second+ parent history for a given commit to see what went into it.

For bash, add quotes: "${cmd[@]}"

Otherwise, you'll get word splitting. E.g.,

  cmd=(
   test
   "!= !="
   !=
   ""
  )
  "${cmd[@]}" && echo Success
  ${cmd[@]} || echo Failure

Of course, even your example units don't always behave like you want. For velocities, 150 megameters/second + 150 megameters/second ≈ 240 megameters/second.

If the extra initial scrutiny is perceived to streamline the process and avoid further hassles, many will hand it over without giving it a second thought.

For example, many people have voluntarily submitted fingerprints in order to enroll in TSA's PreCheck.

2147483647 + 1 is congruent to -2147483648 modulo 4294967296.

The same way we create and vet conventional cryptography: withstanding public scrutiny of experts until we are reasonably confident that there are no major issues. Most attacks are theoretical and require only novel analysis and a new bound on computational difficulty, not a proof of concept (i.e., algorithms are abandoned by cryptographers long before attacks become feasible).

Post quantum algorithms are simply algorithms designed and analyzed against a stronger threat model. Some of the attacks and techniques are still being developed, so no one knows if new quantum algorithms will be invented tomorrow that trivialize certain problems but the same danger is present to some extent for conventional cryptography today.

It's certainly possible to design such a system with external firmware and still allow for secure updates.

The enclave would store (in secured storage) a hash of the last used firmware. Hardware would have a hash update capability, but this destroys all other stored information (i.e., keys) if used when the enclave is not currently in an unlocked state.

On boot, hardware verifies firmware signature as usual but also compares the firmware hash (already calculated for the signature check) to the stored value. If there is a mismatch, update the stored hash. Since the enclave is currently locked, the hardware clears the keys.

Since it's in hardware, you're correct that it would have to be 100% right, but that's quite feasible for a simple update mechanism (indeed, the most complicated bits are reused pieces from the signature check which already has this requirement).

The reasoning there is far from conclusive. The argument is that the secure enclave has been updated in the past (to lengthen enforced delays) without wiping user keys.

However, without more information, this does not tell us whether it is possible in this case. The obvious implementation for a secure enclave resisting this sort of attack is to only allow key-preserving updates when already in unlocked state (which would be the case for any normal user update). All other cases should destroy the user keymat, even if the update is validly signed by Apple. This would be done by the hardware and/or previous firmware before it loaded the new firmware so you can't create an update that bypasses this step.

If this isn't how the secure enclave works now, I'll bet it will be in the next version (or update if possible).