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

Due to the Leidenfrost effect, incidental contact of bare skin and LN2 is not usually a problem (it boils off locally and creates a gaseous N2 barrier). Other things superchilled by it will not be as forgiving, however.

http://cookingissues.com/primers/liquid-nitrogen-primer/#sec...

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

This is a specific example of an Exact cover problem: https://en.wikipedia.org/wiki/Exact_cover

If you haven't seen Knuth's Dancing Links implementation of Algorithm X, I highly recommend it. It's based on the observation that updating a doubly-linked list in-place preserves enough information to make backtracking easy.

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).

While theoretically possible, it'll be very difficult to realize physically. If you allow fractal constructions, purely unrectifiable sets can fit the bill. For example, here's an example in 2-dimensional space that casts a solid shadow when the light source is along one axis but not from any other: https://books.google.com/books?id=usjNBQAAQBAJ&lpg=PP1&dq=&p...

They destroyed it ostensibly so that they had a stronger guarantee that that GUID would never be generated again. That said, I suspect they understood it wasn't strictly necessary and were looking for an excuse to have some fun.

Note that even in the MAC-based generation algorithm, it is difficult (but not impossible) to accidentally generate the same one again even on the same hardware since there is a high resolution time component as well.

Random UUIDs have a different encoded version number so it's actually impossible for a modern one to collide with the one they generated.

Per-user voting history in many (most?) states. The fact that a ballot was received from a particular voter (but not what they voted for) is often releasable under public disclosure laws.

I agree that the oracle of hindsight can often lead us astray.

However, in 2007, it wasn't just known that you could implement a backdoor, but how to do so. This of course means that any constants generated after this point could not be given the benefit of the doubt since anyone could launch this attack (and I think you'll grant me that all major intelligence services knew how to create and use a similar backdoor after 2007). And while USG did not acknowledge a backdoor, there was real, public doubt about the constants: Schneier's article in Wired was titled (notwithstanding Betteridge) "Did NSA put a Secret Backdoor in New Encryption Standard?"

Those in the standard were of unknown status, but even 2007 Schneier had the appropriately conservative cryptographer response and recommended "not to use Dual_EC_DRBG under any circumstances."

The pieces were there in 2012 for anyone that noticed a new Dual EC dependency being added, but I agree that the knowledge was not well-known enough (though it saddens me that a VPN manufacturer didn't know to avoid it 5 years later).

I still hold to the statement that rekeying Dual EC in 2012 is not a smoking gun on the standard, but more suggestive of an opportunistic attacker using the known mechanism for how to embed such a backdoor. If detected, it's obvious it's a backdoor, but that's not an indictment on the standard's constants (in fact, if you could otherwise attribute the attack to NSA, it's a tiny bit of evidence that either there is no standard backdoor or that USG don't want to use it in this case).

Here's a statement that I think we might disagree on: I believe that no one in 2012 that knew why the provenance of the constants could be a problem would have allowed Dual EC in the codebase in any form. This is why I believe the incremental chance of detection from changing the constants was small and why it'd be worth it to avoid attribution.

That said, I've stated my positions and see no need to continuing pressing legitimate points of disagreement. I just wanted to understand your position.

The backdoor possibility was known in 2007 and the standard included a way to set your own constants (which no one used, true, but just because it was true for Dual EC in general).

I disagree that following the standard on that point and creating your own would be a smoking gun that the standard is malicious. Rather, it could be a smoking gun that this implementation was. If the tampering would likely be detected anyway, I'd argue it's better to avoid attribution.

Basically, Dual EC is never something you'll choose willingly, given alternatives (it's quite slow and has had a slight bias demonstrated). So no one* did in practice. This made the backdoor almost a non-issue (so no heartbleed-like panic to patch, etc.).

However, having it in the standard (since removed) is perfect for fallback-like attacks or surreptitious changes (in the best case, your target has already implemented and deployed your exploit code and all you have to do is throw the switch to enable it!). That's what this is demonstrating (though some of the details are still speculative).

* Exception being those paid or required to do so by NSA.

> This backdoor appears to swap out the public key, which is something NSA has no interest in doing.

While they wouldn't need to swap it out (since they can unlock standard Dual EC), that doesn't mean they wouldn't.

Assuming 1) that Dual EC was used here and 2) was inserted surreptitiously in a way that has a nonnegligible chance of discovery, it would make sense to rekey it since failing to do so would strongly attribute the attack to NSA (or someone willing to give up the passive backdoor opportunity in order to pin it on NSA).

The only case for NSA where using the old key would be best is if the use of standards-based Dual EC would pass scrutiny but a modified one would not. This depends on the details.

If switching Juniper to Dual EC required only calling a different function in Juniper's existing crypto library and/or detection was unlikely, standard Dual EC might be best. If the compromise added a full Dual EC implementation, then changing the constants is good (different magic constants don't significantly increase risk of detection for the large inserted code blob while significantly decreasing the risk of attribution).

See the last section (Afterword: removing the hat):

  First, in case this is not obvious to the reader, we do
  not actually endorse the attacker's perspective. Our goal
  in analyzing the security of systems is to prevent attacks.

One point this doesn't (appear to) consider is the type of vulnerability which is possible to embed. Forcing a curve parameter with the prefix 0xBADA55 is eminently feasible given the many available design choices (as this shows, though I'm not sure this was in dispute), but there's a long way between this and the type of vulnerability that the NSA would be most comfortable with.

Consider Dual_EC_DRBG: by all indications this was a "NOBUS" vulnerability (exploitable by "nobody but us") since the private key to unlock the backdoor had to be created at design time and wouldn't be recoverable by any other user of the system. With the NIST seed-hashing technique used to generate these curves, however, only a relatively small number of bits of structure can be forced in the result (assuming no preimage attack on SHA-1, which is still presumed difficult even now, let alone in 1999 when the curves were specified).

This more or less makes Jerry Solinas in the thought experiment resort to weakening the curve by forcing the choice into suitably large set of privately-known weak curves (which might only constitute 1 in a billion of the publicly acceptable curves). However, it's not possible for these attacks to insert enough structure for a Dual_EC style private key so they end up weak against all attackers (including other nation states) in theory if they can perform the same analysis. This (assuming that no one else has discovered the weak class of curves) is a very risky needle to thread when you are still recommending NIST-384 for use in protecting top secret information even now over 15 years later.

PFS will make it so connections need to be individually attacked but since most PFS is done with Diffie-Hellman variants (susceptible to Shor's algorithm), the group size also needs to be large enough to resist early quantum computers.

For defense against large quantum computers, different PFS schemes need to be used (fortunately not hard to construct from other post quantum primitives).

CRT is often given with a closed form for the satisfying solution, although requiring computing multiplicative inverses mod each of the n_i (your primes). Since all of these values are known at design time, they can be precomputed and the run time for encoding becomes a constant M multiplications, M-1 additions and one mod at the end where M is the number of items you are encoding.

https://en.wikipedia.org/wiki/Chinese_remainder_theorem#Gene...

For example, the 3, 5, 7 packing yields a closed form of 70a_1+21a_2+15a_3 (mod 105). Plugging in 2, 4, 3 like your example yields 59 directly.

The fastest way to encode these dense bitpackings is almost certainly with the Chinese remainder theorem.