Supernetworks -- ill update. Our initial comment got moderated for too much self promotion so also apologies there and again for anyone who is offended
Thanks Tom. This whole comment thread is a bit of a dumpster fire of opinions however we have been working on the wifi security problem for a long time and we have a lot to say about it. Router manufacturers competing into involution that ship RCE (much of which is triggerable from a web page) have created a substantial risk to consumers, in this case with a lens on the US market. We tackle hardware & software and prioritized network isolation as the first thing to resolve. We have tons on our blog and page about network security and have open source software.
Yep, unfortunately fuzzy. For enterprise wifi deployments, one amusing thing to do when configuring 802.1X is to test ARP spoofing the upstream radius server after associating, and self-authenticate.
It might be interesting to go and apply some of the sneaky packet injection mechanisms in this paper actually to try to bypass ARP spoofing defenses.
Some 802.1x have inherent mitm attacks that have been called out since 2004 and never got the v2 (https://www.rfc-editor.org/rfc/rfc6677.html). EAP-TLS however is the best practice here + VLANs.
Hostapd now has support for multi pass SAE /WPA3 password as well. We have an implementation of dynamic VLAN+per device PSK with WPA3 (https://github.com/spr-networks/super) we've been using for a few years now.
Ironically one of the main pain points is Apple. keychain sync means all the apple devices on the same sync account should share a password for wireless. Secondly the MAC randomization timeouts require reassignment.
The trouble with SAE per device passwords is that the commit makes it difficult to evaluate more than one password per pairing without knowing the identity of a device (the MAC) a-priori, which is why it's harder to find this deployed in production. It's possible for an AP to cycle through a few attempts but not many, whereas in WPA2 an AP could rotate through all the passwords without a commit. The standard needs to adapt.
This attack exploits multi PSK networks precisely. If it's all one PSK the attacker can already throw up a rogue AP for WPA3 or just sniff/inject WPA2 outright. The back half of a secure multi PSK setup is deploying VLANs for segmentation, to block these attacks.
WiFi provides half-way measures with client isolation features that break down when the packets hit L3, or in some cases the broadcast key implementations are deficient allowing L2 attacks. The paper is about all of the fun ways they could pivot across networks, and they figured out how to enable full bidirectional MITM in a wider class of attacks than commonly known or previously published.
This is mostly accurate, to clarify the association IDs tie into what VLANs will be assigned and that does block all of the injection/MITM attacks. This also assumes that the VLAN segments are truly isolated from one another, as in they do not route traffic between each other by default including for broadcast and multicast traffic.
However client isolation should be a tool people have at their disposal. Consider the need for people to buy cloud IOT devices and throw them on a guest network (https://arstechnica.com/security/2024/09/massive-china-state...). It's also about keeping web-browsers away from these devices during regular use, because there are paths for malicious web pages to break into IOT devices.
EAP TLS provides strong authentication, is much better than the other enterprise authentication options, but will not block these lateral attacks from other authenticated devices. The second half of the deployment is putting each identity into a VLAN to defend against the L2/L3 disconnects that can occur.
I work on https://supernetworks.org/. We propose a solution to these flaws with per-device VLANs and encourage per-device passwords as well.
More practically the risk for these attacks is as follows. A simple password makes sense for easy setup on a guest network, that's treated as untrusted. These passwords can probably be cracked from sniffing a WPA2 key exchange -- who cares says the threat model, the network is untrusted. But this attack lets the insecure network pivot out into the secure one.
by complexity class that would be consensus, although the argument for building BPP systems is about the energy cost being orders of magnitude less and perhaps also some polynomial speedup
A direct equivalent, no, as stated in the introduction.
"Notably, while probabilistic computers can emulate quantum interference with polynomial resources, their convergence is in general believed to require
exponential time [10]. This challenge is known as the signproblem in Monte Carlo algorithms [11]."
"given that destroying the correlation between two entangled particles" i think this is the assumption that is easy to make without digging deeper into entanglement.
i am still in the process of reading this article (https://arxiv.org/pdf/2408.06418) however entanglement witnesses can be realized in several ways and are one of the underlying aspects of how quantum networking can be made reliable.
under the category of heralded entanglement, one realization uses photons striking photo detectors after they meet in a beamsplitter under the hong-ou-mandel effect scenario. for type 1 entanglement with HOM: if the photons at the two input modes are identical, they always bunch due to quantum interference, and if the photons resulted from emissions in the respective quantum nodes those nodes are now entangled, and the detection is the classical signal that the entangled link was created. the nodes can now transmit information unidirectionally into the entangled qubits. for type 2 entanglement with HOM it's a little bit more complicated although the underlying concept of indistinguishability is what results in the entanglement just the same.
heres one experiment from oxford, https://www.nature.com/articles/s41586-024-08404-x, where they achieved this with high fidelity although the particular details of the beam splitter experiment are not as well detailed.
the router sniffed plaintext http to grab HTTP User agents to put them into a curl bash command line string. Nice RCE from the browser.