"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.
Looks interesting, I see you've added a light React UI and a simple REST API on the Go service to query for status and control the Tailscale interface. I'll make a note for sure!
I myself didn't really have a need to disable the interface during the lifecycle of the container, so I went with the standard containerboot process provided by Tailscale. I also wanted the container to be "invisible" and not respond to any incoming connections, so that it feels like you're running Tailscale on the actual router.
Keeping things a bit more granular and flexible for this use case makes total sense.
"The requeue-once rule is enforced by only allowing requeueing to the futex previously passed to futex_wait_requeue_pi as uaddr2, so it's not possible to requeue from A to B, then from B to C - but it is possible to requeue from B to B.
When this happens, if (!q.rt_waiter) passes, so rt_mutex_finish_proxy_lock is never called. (Also, AFAIK, free_pi_state is never called, which is true even without this weird requeue; in the case where futex_requeue calls requeue_pi_wake_futex directly, pi_state will sit around until it gets cleaned up in exit_pi_state_list when the thread exits. This is not a vulnerability.) futex_wait_requeue_pi exits, and various pointers to rt_waiter become dangling.
"
Not at the moment; to achieve this, you typically put it behind something like dnsproxy [1][2].
I have done this on my router, along with a couple firewall rules to prevent plaintext DNS queries leaking out of the WAN port. dnsmasq is configured to talk to dnsproxy, and dnsproxy is configured to use DNS over TLS with 1.1.1.1 [3]
It can be actively exploited in the same way that TCP initial sequence numbers can be exploited: when something else goes horribly wrong in the protocol stack. Contra the claim across the thread that the fundamental fix to this problem is DNSSEC (which is never going to happen), the real fix for all this stuff is not to trust this layer of the TCP/IP stack for authentication in the first place: you do cryptography, at the transport layer (not in the name lookup) so that IP address spoofing doesn't matter in the first place.
"Riffling through other files, Mendax found mail confirming that the
attack had indeed come from inside MILNET. His eyes grew wide as he
read on. US military hackers had broken into MILNET systems, using
them for target practice, and no-one had bothered to tell the system
admin at the target site.
Mendax couldn't believe it. The US military was hacking its own
computers. This discovery led to another, more disturbing, thought. If
the US military was hacking its own computers for practice, what was
it doing to other countries' computers?
"
>This is not unlike the surprise in underground.txt
I thought that was originally a book?
I distinctly remember reading it during an in school suspension in the 2000s.
I tried to go back to my township library and read it again years later, but someone had stolen it around the time that Wikileaks truthfully revealed that the DNC had kneecapped Bernie in the primaries.
(Many folks don't seem to distinguish between the public airing of unpleasant truths that could not be aired without their own actions, and "disinformation" in the "covid is a hoax" vein. To them, anything contrary to their narrative is evil and bad, and if only those dastardly Russians would stop making them look bad my making them send several illegal emails they could stop voting like Republicans)
It is a book, "Underground: Hacking, madness and obsession on the electronic frontier". I seem to recall cross it hosted under mit.edu/~hacker/underground.txt or something like that
Thanks.
How the world evolved: "Also, if you're curious, view the WebMake source file (warning: this contains the entire book text and markup: 948k in total). "
I hate it. It destroys the original concept of hackers, with the original Jargon file, the best relase (1.5). Lisp and Forth hackers are the original thinkerers.
We designed SPR to address problems with wifi isolation. Every wifi device runs in an isolated subnet and individual VLAN. Mac spoofing is not possible since a device's MAC identity is combined with a device-specific PSK. You can check out the project here: https://www.supernetworks.org/
While we were not aware of these protocol flaws specifically, the project was inspired by fundamental weaknesses in secure wifi isolation. One of the attacks that's demonstrated in the scripts but not in the academic paper -- is that most routers will route UDP/IP packets between devices even when they are "isolated", so there are problems with most guest wifi networks even before mac stealer type attacks come into play.
So, a long time ago, I implemented a similar system on top of some enterprise access points -- broadcast storms were just killing our Wi-Fi. The problem was mDNS / bonjour didn't work in this setup, although there was a way to use a routable multicast address, we couldn't get printers working.
Eventually we hacked something up where the AP controller could do proxy ARP, and google cloud print.
In an enterprise setup you usually ALG those things and block BUM traffic except for things that register for a routed stream in which case you have the system convert multicast to unicast to that client (in transport, not destination). If those are not a checkbox on your gear of choice then you have to build it yourself as you did.
VLANs+Subnets play little role in the end on a Wi-Fi SSID. Clients get put in the same GTK and hear everything in the same BSSID. You don't want to go making BSSIDs per client either as that kills airtime. Most of the time you're better off with a flat wireless network with the above controls as it functions exactly the same as a divided network where you need the same controls anyways but now it's simpler. Different subnets per SSID (for when you need to support different authentication methods, not for when you need different services to co-exist) can make things simpler though.
This sounds like ‘we had problem with devices talking to each other so we blocked that, and then services that require devices to talk to each other didn’t work!’
reply