- User Since
- Aug 2 2016, 1:41 AM (163 w, 5 d)
Sep 27 2016
I went ahead and implemented the aforementioned 32-bit block cipher, and the implementation is available here. It's relatively performant, getting about a million encryptions per second; that should be enough, especially given that this is only used when a socket is first opened.
Sep 8 2016
I've now added Debian packaging support to the actual filter. Both packages install correctly and work well.
Sep 7 2016
A similar designed cipher is DJB's Salsa20/ChaCha20. Very fast and recently RFC'd. He's known for making crypto libs that are dead easy to use by software programmers to avoid fudged implementations.
Sep 2 2016
I've created some bash scripts to create a Debian package for kti/python-netfilterqueue. They're available in this GitHub repository, and I've uploaded a version of the package created on my Debian Jessie system here. There are still a few issues I'll be resolving in the coming days, including the lack of a source package, but it's overall completely functional.
Aug 30 2016
Should we reach out to Steven first and see if he can give us code?
Aug 28 2016
The network based ones are very dangerous because the artificial signals created on the machine leak in the network traffic which is immediately observable and collected by a network GPA.
Aug 26 2016
The first mitigation that comes to mind is to, similarly to T530, queue up all keyboard input events over a period of time (say, 30 milliseconds), and then process them all at once.
Aug 24 2016
The Debian package you mentioned is actually a completely different library serving the same purpose. I'll probably end up porting my code over to use that
Aug 22 2016
Could it be replaced with the Debian package python-nfqueue? Is it the same?
Aug 19 2016
Aug 10 2016
Would it be correct to say that the fix developed also defends against the earlier attack described by Steven Murdoch?
Aug 8 2016
We would like your feedback on the TCP ISN attack/mitigation info (or on the covert channel attack in general) on the wiki page.
Aug 6 2016
Can you please implement the same protections for IPv6/ICMP6 if its not too much work.
Aug 4 2016
After looking at the netem documentation I'm pretty sure there is something here we can use.
Aug 3 2016
I would also point out that, to disable c-states in a hypervised environment, we'd need the co-operation of either the hypervisor, or every single guest (I think; correct me if I'm wrong). My understanding is that, in most Whonix configurations, the hypervisor would be beyond Whonix's control; in a lot of configurations (such as Qubes), Whonix likely wouldn't even control the majority of guests (again, correct me if I'm wrong). Is there a way to get around this?