> I think this is a pretty small point to get hung up on. The rest of her article is perfectly reasonable.
The above isn't the only place that betrays her lack of understanding, though.
For instance, she confidently writes "Ion traps are used for example by IonQ and Honeywell. They must “only” be cooled to a few Kelvin above absolute zero," but this is just wrong; trapped-ion qubits do not, a priori, require cryogenic cooling. Yes, lowering the temperature can be useful for incidental reasons, as it improves the vacuum quality and reduces some technical excess noise sources, but this is simply an engineering choice. Many of the high-profile results in trapped-ion quantum information processing were in fact achieved in room-temperature systems. And even if one does opt for cryogenic cooling, the ~tens of Kelvin regime of interest here is incomparably easier to reach than the tens of milli-Kelvin required for superconducting qubits and other solid-state spin platforms (where those elaborate dilution refrigerator "chandeliers" are actually required to keep the qubits intact). In fact, in ratiometric terms, the temperatures of interest are actually closer to room temperature than to that millikelvin regime!
Like many physicists, I'd naturally be inclined to agree with Sabine Hossenfelder as far as her distaste of marketing hype is concerned, but in making authoritative-sounding statements without having the knowledge to back them up, and misrepresenting what one would hope she knows are the actual scientific facts in the service of a punchy script, she is hardly doing any better than those private-sector hype evangelists she ridicules. Beware of Gell-Mann Amnesia…
Essentially, yes; all of quantum key distribution (QKD) is generating a secret key which can then e.g. be used as a one-time pad. The novelty here is that we can do it with much fewer assumptions on how the quantum devices behave than in conventional QKD.
> My naive security architect view is, I get the impression the people doing quantum engineering and those working as cryptographers have a very narrow overlap.
You probably aren't wrong, but also note that popular science articles are probably not the best basis for judging this. :) A number of people working on QKD have done serious work on classical cryptosystems as well, although the overlap of that set with people working "in the trenches" of practical IT security is of course yet another topic.
> To do the data exchange, it's not encrypted to a key per se […]
I'm not sure whether this is what you are wondering about, but the actual data exchange is completely separate from the key distribution. Particularly for the entanglement-based protocols like used in device-independent scenarios, there isn't really any data exchange between the parties during the key distribution stage at all (apart from the classical post-processing steps such as error correction after the fact). Rather, the quantum resource provides random, but correlated bit strings at the two nodes. Only after the QKD protocol has finished is there actual data exchange using the secret key material, probably using the key as a one-time pad to keep the information-theoretic security guarantees.
Thus, trying to think about these protocols in terms of data transfer doesn't strike me as particularly natural; in fact, if the entangled state shared between Alice and Bob is maximally entangled, the raw bits obtained from the quantum devices are always going to be completely random.
The security proofs are indeed based on careful entropy considerations. You mentioned implementation details of classical cryptosystems. These primitives – S-boxes, etc. – motivate why we should reasonably expect cryptanalysis on such algorithms to be hard in practice, even though we know that they can't be secure considering information theory only. In the QKD case, however, we can make information-theoretic security statements without any reference to computational power. Thus, a security analysis will look at quite a different set of things: on one hand, whether the entropy accounting is correct, and on the other hand, whether the practical implementation actually corresponds to what that accounting assumes.
> QKD is no replacement for asymmetric cryptography since it requires exchanging a secret key before the communication can take place.
Your general point about QKD "promises" vs. practical IT security is well taken, particularly as I am much more of a general quantum physicist and spare-time compiler/infosec geek than a QKD person myself.
However, note that asymmetric cryptography doesn't really solve the authentication problem you mention either. If you don't want to place your trust in some sort of PKI, you are back to Alice and Bob having to meet first to exchange some sort of key material (e.g. their public keys) to later avoid impersonation. Given an authenticated channel, both QKD and classical public-key cryptography can construct a secure channel for messages of arbitrary length, but the latter only for computationally bounded attackers. Of course, this is not to say that a trusted PKI can't be a sensible assumption in practice.
> Would it be accurate to say it is scaled back to the level achieved by classical (non-quantum) cryptography?
Not quite. Classical cryptography of course requires the additional assumption that the computational capacity of the attacker is limited (at least if the amount of key material available is less than the length of the messages to be exchanged). QKD does not need any such computational assumptions. Looking at this purely from a theoretical perspective, I hope you'll agree that the ability to create new shared randomness "out of thin air" by drawing on quantum correlations, and to do so an information-theoretically secure fashion, is a pretty neat trick.
Now, if you asked me how likely it is _in practice_ that $THREE_LETTER_AGENCY has broken your cryptosystem to the point where they can feasibly attack it/have backdoored it, compared to the likelihood that they've bugged your devices in a supply chain attack or found any number of other ways to compromise the practical implementation, I suspect my answer wouldn't be much different to yours. Nevertheless, I still think it is interesting to explore additions to the cryptographer's toolbox that, in a very practical sense, have a rather different profile of assumptions and tradeoffs.
> I always read perfect secrecy as a term of art with some technical meaning.
That's indeed the case, but I fear the subtle technical definition here is usually one of the first things to go in the cycle of press releases and news articles, entirely too quickly giving rise to headlines that speak of “unhackable cryptography" or things like that. I've slightly edited my above post to clarify this, thanks.
> Do you think there will be entanglement based replacements for these [other protocols]?
One thing to note is that QKD is fundamentally a primitive to create shared, private randomness, not a communication channel – of course, the output can be used as the key for one-time pad encryption, but you might as well use it some different way.
For applications beyond that, I am really not an expert, but from what I know, people are looking into a variety of protocols, such as for leader election. There was a review article a few years back by Wehner et al., "Quantum internet: A vision for the road ahead" (https://www.science.org/doi/10.1126/science.aam9288), which highlights some proposals.
As for applications like signing, one aspect to consider is that quantum entanglement will, at least for another decade or two, always be much shorter-lived than classical data at rest. Thus, most practical quantum protocols will boil down to creating and making use of entanglement in a short amount of time, e.g. to initially establish some sort of shared secret, make a coordinated decision, etc.
First author of one of the preprints mentioned in the article here (theory in Paris/Geneva/Zürich/Lausanne, experiment in Oxford) – happy to answer any questions! I obviously speak only for myself, not for any of my colleagues, and as a matter of course, I should also mention that publication in a peer-reviewed journal is still pending for these results.
One point to mention — which I feel quite strongly about, and I think my collaborators do as well – is that sweeping generalisations like "perfect security" are really not the point, and, if anything, have mostly done the field a disservice. Such statements do make for catchy headlines, and while there is a solid technical meaning attached to them (information-theoretic security), to a wider audience they might suggest that QKD replaces the need for careful security engineering, which is definitely not the case: if your processing nodes, say, leak out the generated key material via a classical side channel, no amount of theoretical security guarantees will save you!
Rather, device-independent quantum key distribution allows you to scale back the assumptions on your implementation to a well-motivated, minimal set. To me, this is already intriguing enough without the need for hyperbole!
There isn't anything special about functions; the original article does not describe this correctly. Rather, the big conceptual difference is the point at which the expression is evaluated – once for the whole program (`=`), vs. at each call site (`=>`).
I presume this got accepted because it fixes a well-known gotcha with default parameters in Python due to early evaluation, where, for instance, the dictionary instance in `def fun(args={}): …` would be shared between all invocations, leading to all sorts of fun bugs. This is especially pernicious as most Python programmers will know other languages as well, where this tends to be handled much more sensibly (e.g. in C++, D, …) and default arguments are evaluated at each call site.
Physicist here too. What exactly do you disagree with? The parent comment is sound – thermal imaging cameras typically under-read on shiny metal surfaces. Their emissivity/absorptivity at relevant wavelengths is low, and reflectivity is high. Thus, their own Planck spectrum is (approximately) scaled down by their emissivity, and consequently the radiation in the measured MIR band is mostly what is reflected, which tends to come from the room-temperature environment.
A polished piece of metal makes a shitty black body. This is also why shiny metal (foil) is used to curb unwanted radiated heat transfer everywhere from thermos flasks and cryostats to space probes. (The lower emissivity further improves the efficiency of multi-layer insulation.)
Reproducible in Firefox 67 on macOS as well. "DOWNLOAD" is only in one line for very wide windows, and for my default half-screen-wide window size (960 px), the main body title renders as
There seems to be something very strange going on with the way you are building LDC.
On the machine I am typing this message from [1], building DMD using DMD in optimized mode takes 58s, plus another 2s for druntime and 7s for Phobos (the two parts of the D standard library, for those not familiar).
A release build of LDC using LDC (CMake/Ninja), on the other hand, takes about 90s, which includes several versions of the runtime (only one is built for DMD by default), the JIT support libraries and a few ancillary tools. This is with debug info enabled, disabling it speeds up the build a bit further.
Since these are different codebases and the LDC build makes better use of the available cores, these are obviously not directly comparable if what you are talking about is compiler performance. However, a release build of DMD using LDC on the same machine takes about 45 seconds – i.e., it is faster and produces a faster binary.
Take these numbers with a grain of salt, obviously, as this was hardly a controlled benchmark. Your statement just conflicts with my experience working on both compilers, and the timings hopefully illustrate why.
---
[1] A 2015 MacBook Pro (i7-4980), so hardly anything out of the ordinary.
Nope, not photoshopped. It's a single exposure; the apparatus is illuminated using flashes.
The latter made lighting the shot in a controlled fashion a bit easier than if I had used continuous sources – you'd be looking at using a torch with a bunch of filters or a computer monitor on the lowest brightness otherwise.
Photographer here. The amount of attention this has received has caught me a bit off guard – this is really just a somewhat pretty picture of what is a standard technique in physics by now.
I'm putting together a short post with answers to some of the most commonly asked questions, but in the meantime, check out this great comment by a well-informed Redditor:
There are some advantages to having access to a human-readable representation for the symbol name, for example because not every piece of binary tooling out there necessarily also supports reading debug info for the target platform in question.
However, another benefit of this is simply that even if you can hash a huge string down to a fixed length, you still need to construct your huge string in the first place during compilation.
With D generally being quick to compile, by the time your symbol names were in the megabytes, all the string creation and manipulation could take up an appreciable fraction of the total compile time. (No kidding – I was quite surprised to see this show up on the profiles as well.)
> it'd be the same amount of effort without as-fast-as-possible.
While the first part is perhaps somewhat subjective, the second is just wrong. D allows you to get to the same bare-metal, no-holds-barred level of performance that C++ does – I wonder where that misconception would come from.
Note that this is not just an academic possibility, but there are real-world use(r)s of D in exactly that domain, for example the folks at Weka.IO for their distributed file system. Of course, their sub-millisecond latencies don't leave much room for careless use of the garbage collector. But being careful about memory allocations for that sort of application is just as sensible a thing to do in D as it is in C++.
> D is arguably in the same bucket as Swift, and partly as Go. I don't think it's very useful to compare and contrast it against Rust.
It is easy to claim how things "arguably" are, but without providing any justification that is not a very meaningful statement to make.
D very much matches your definition of "low-level, zero-overhead (no GC) etc nature and powerful metaprogramming facilities" – the GC can be avoided easily enough. It can certainly claim to be a "better C++" in this sense. For instance, Weka.IO (a storage startup founded on D) heavily relies on D to offer exactly that, in order to implement a distributed file system with sub-100µs latency.
The fact that you can also write Python-esque code during prototyping (playing fast and loose with the GC, etc.) doesn't detract from the core identity of the language as a tool for systems programming with zero-cost abstractions.
D can interface with Objective-C just fine. The Apple-provided tooling will indeed be more convenient for the developer, but the result the end user sees will be a "high quality & native app" just the same.
The above isn't the only place that betrays her lack of understanding, though.
For instance, she confidently writes "Ion traps are used for example by IonQ and Honeywell. They must “only” be cooled to a few Kelvin above absolute zero," but this is just wrong; trapped-ion qubits do not, a priori, require cryogenic cooling. Yes, lowering the temperature can be useful for incidental reasons, as it improves the vacuum quality and reduces some technical excess noise sources, but this is simply an engineering choice. Many of the high-profile results in trapped-ion quantum information processing were in fact achieved in room-temperature systems. And even if one does opt for cryogenic cooling, the ~tens of Kelvin regime of interest here is incomparably easier to reach than the tens of milli-Kelvin required for superconducting qubits and other solid-state spin platforms (where those elaborate dilution refrigerator "chandeliers" are actually required to keep the qubits intact). In fact, in ratiometric terms, the temperatures of interest are actually closer to room temperature than to that millikelvin regime!
Like many physicists, I'd naturally be inclined to agree with Sabine Hossenfelder as far as her distaste of marketing hype is concerned, but in making authoritative-sounding statements without having the knowledge to back them up, and misrepresenting what one would hope she knows are the actual scientific facts in the service of a punchy script, she is hardly doing any better than those private-sector hype evangelists she ridicules. Beware of Gell-Mann Amnesia…