/tech/ will never believe me, I certainly wouldn't, but I worked on the data capture side of PRISM (the fiber splitters they found in AT&T's room literally used to live in my desk drawer) and we did implement flow time correlation. This was way before tor and our results were being published publicly as part of an internet mapping project. I left before it was scaled up into a global spying apparatus so I have no idea what they did with that code but I know they had it as I wrote part of it. It was being used to estimate global VPN/IPSEC usage where we needed to know that a machine was relaying a flow rather than creating a flow despite all the headers having been munged.
Fun fact / story time / LARP corner: the hardest part of the project was a different type of time correlation - the fiber connections at the time were unidirectional and we didn't have machines fast enough to capture both directions at once so we had to splice the bidirectional stream together after capturing it, and clock drift at OC3/OC12 speeds would make a session gibberish within a few seconds. We solved this with two GPS units, one per tap, to get (mostly) driftless timing and we had to run wires at each site to the roof for the antennas (this was before having stuff on the roof was normal).
But today there are all sorts of easier ways to leak data. Anything that is "random", for example. How do you know if those TCP sequence numbers or diffie-hellman keys chosen by a hardware RNG aren't actually part of a payload being exfiltrated and could be reassembled by someone listening to your traffic? You don't.
But then again, today there are only a few ethernet chipset vendors and they could have been required to listen for and execute magic packets. You'd never know as they'd not be delivered to the kernel, and they could travel through your network even with your computers turned off thanks to those chips being powered to support wake-on-LAN magic packets (look into it if you don't realize how active those chips really are when 'off'). The code's already there for wake-on-LAN, it would take next to no effort.