This reminds me of the science fiction novel The Water Knife by Paolo Bacigalupi. From the Amazon description:
"In the near future, the Colorado River has dwindled to a trickle. Detective, assassin, and spy, Angel Velasquez “cuts” water for the Southern Nevada Water Authority, ensuring that its lush arcology developments can bloom in Las Vegas. When rumors of a game-changing water source surface in Phoenix, Angel is sent south, hunting for answers that seem to evaporate as the heat index soars and the landscape becomes more and more oppressive."
That work is great. A related paper on earlier work where traffic analysis on skype was being done and where the researchers were able to extract individual phonemes and then reconstruct speech that way. It's one of my favorite papers. It's titled "Phonotactic Reconstruction of Encrypted VoIP Conversations" and you can find it here:
http://www.cs.unc.edu/~fabian/papers/foniks-oak11.pdf
Voice is in a way the easy case, because we know the antidote. Constant Bitrate (CBR) mode of an audio codec consumes the same amount of bandwidth regardless of what is transmitted, which is inefficient but secure. As I understand it Signal's voice chat is Opus in CBR mode.
Other scenarios are trickier and may need custom work. For example Encrypted SNI currently requires a host to pick a maximum name length, the encrypted name may be any of those names configured on the host, and is padded to that length so that an adversary can't guess which name from the length.
Because we don't have a general solution, TLS 1.3 defines an zero overhead optional padding, you can add extra bytes of padding to any TLS message but neither TLS itself, nor the HTTPS binding defines a "good" way to use this padding to shield users from analysis of content based on size because there is no general solution known.
I am speculating that nice traffic analysis attacks can be done on mosh (which is a great tool btw) to, similar to the paper that is in this thread. It's been sort of on my "todo/research" list but haven't been able to sit down for a few days and mess around with it. And I'm sure that QUIC (HTTP/3) will open up some interesting avenues of attack here too.
Sure. But that's why my point was about mosh (https://mosh.org/). It just uses TCP+SSH for the authentication part and then it sets up an encrypted UDP-tunnel on the server-side with the mosh-client then just sending AES-256-GCM packets back and forth over UDP. To the best of my knowledge it doesn't batch anything.
And compression definitely doesn't always help as some of the attacks on TLS were only able to be done because of compression happening before encryption. Hence why we ended up with the HPACK in HTTP/2 to prevent exactly such type of attacks.
Mosh does include random chaff and (some) timing variation and batching in an effort to weakly frustrate these kinds of keystroke information leakages -- my understanding is that we are at least as strong as SSH in this area, but would love to see any analysis either way. (We have a "frame rate" with a minimum interval in both directions, and a SEND_MINDELAY collection interval. The current values are chosen for performance and minimizing tiny packets, but could be increased or randomized.)
If necessary (or maybe in some optional supersecure mode), Mosh can afford to do much more timing variation, or even a "line-at-a-time" mode, since the client can be more aggressive about showing the predictive local echo (with the ability to correct it later) while waiting to send batches of keystrokes and for the server's reply. Or we could just do a CBR mode.
Oh wow, thanks Keith, first of all for mosh! I've been using it daily for several years now. It's been great! Second of all for clarifying and correcting me regarding the algorithm-usage. I don't know where I got it from and I must have just misremembered; it's been a while since I spent a bit of time looking at the source code (and walking away very impressed).
No-one said anything about the president or the NSA being involved. There are tons of ways this can work. And it actually happens.
Just once you're flagged and are inside The Machine you get detained upon entry whilst they confiscate your devices, try to see where you've been etc. Lookup the wikipedia page of Laura Poitras who for years lived in Berlin due to USA government surveillance. And this started way before her involvement with Snowden as a filmmaker.
I've done some security contracting work for the folks in Walldorf over the years; I've seen first-hand some SAP FTE's getting insanely frustrated putting in their expenses in their own systems. Which was pretty hilarious to watch. And most folks there fully acknowledge that usability is not their strength traditionally.
Things like uptime, support-contracts, having someone on-site within three hours when your multi-millon-dollar-order-processing-SAP-cluster goes down etc are what matter to their customers more than usability (traditionally).
Things are changing and a lot of effort has been put into getting better at UI/UX though. But I haven't been involved with them for several years now so I don't know where they are at or what their current offerings are (I keep tabs a bit on HANA developments but that's it really).
Oh wow. So I read "The Bug" of hers just after it came out (14 years ago) and it's such a poignant read about someone being slowly driven mad because he can't find a very peculiar bug which unpredictably haunts the sales people demo'ing their product. It's a great read and I highly recommend it to anyone here. The technical accuracy is hilarious too but you don't need to be a programmer whatsoever to understand the novel. I won't spoil the reveal of the actual bug or the ending but it's very much worth it.
After reading it I loaned my hardcover copy out to a guy named Boris when I told him how much I liked it. Boris; I don't know where you are and what you're up to nowadays; but if you somehow end up reading this; I kinda want it back. Ping me.
It's not about how stupid Americans are but the insane vilification of anything that reeks like socialism. You (*see edit below) live in the richest country on the planet which is incapable of providing clean drinking water to all of its citizens. That's unfathomable to me.
Some context; I know the USA better than most Europeans, having lived and paid taxes there for three years, whilst working and traveling all over the USA. I would never call Americans stupid. I've met some stupid ones though obviously. But Americans as a whole are as interesting and diverse and awesome and loathsome and everything in between as any other countries' citizens.
The collective results of the media, political developments of the past few decades, the countries' legal makeup (local, state and federal law) and what not more together result in stupid situations. One of them being that the USA is incapable of providing clean and affordable drinking water to all of its citizens.
And if you have to resort to compare yourself to Venezuela you're losing anyway. It's a bit like the: "hey, at least we're not THAT bad". But you STILL cannot provide clean drinking water to your citizens. What's that saying again?
Never be the smartest guy in the room? Maybe compare yourself with countries doing better than the USA and then try to improve things?
And no, not everything is that bad and there are tons of things I like way better in the USA than in Europe. Things are hardly ever that black and white. But comparing yourself to Venezuela is one of the weaker arguments here.
EDIT: just realized that parent comment stated he's not American; doesn't take away from any of my points regarding the Steinbeck quote and the Venezuela comparison.
OP / author of the tool here too. Feel free to come up with any questions or suggestions regarding this. The tool has already proved its worth for me personally but I'm always open to reasoned input why I'm an idiot because I missed x or y or implementation z.
I've been a personal paying user of Fastmail for over 5 years now. It's been great. For my own company and for another business I started late last year I've also selected Fastmail as an email provider again. Just wanted to say thanks to you and the rest of the team. Keep doing what you're doing and I'll happily keep on shelling over some dollars your way.
So I've been in the position, a few years back, where I spent months doing comprehensive code reviews of these energy distribution management systems and what not more. It's all super scary legacy stuff and the code in general is horrendous (regardless of vendor). It's next to unmaintainable, it's next to un-upgradeable due to the risk of outages and there has been no oversight into it whatsoever.
All the comments regarding "who puts these things on the internet" are missing the point completely. It doesn't matter if this stuff is on the Internet or not. It only makes it somewhat easier to get access to these networks and start causing outages. However you've got thousands of miles of converter stations and transformers and power lines dotting the country. It's not that hard to go to the middle of nowhere and get access to the backend networks that carry for example the DNP3 traffic. Once you're on there you can carry out these type of attacks too.
The fact that an enemy can just use the Internet to penetrate the power companies' networks and pivot from there to their back end networks and actually touch equipment is the icing on the cake; it means they don't need to bother with recruiting and sending spies who can get physical access somehow.
Agreed, and most people don't realize that this stuff almost "can't" be upgraded because the initial vendor back in the late 80's or early 90's specified a specific tech stack in the contract and any upgrading or even application of OS patches would legimitately violate any warranties and liabilities the original vendor has for their work. This is super time-critical physical process code commonly running on operating systems like Win95 or Win3.1 that were never intended to be real time operating systems and whose behavior could change radically if a patch were installed.
The cost and complexity of designing and tuning the process control software, and the lack of the detailed design calculations involved in figuring out what it needed to be written to do 20 or 30 years ago makes replacing that old tech stack nearly equivalent to replacing the entire installation.
Big power plants, refineries, and chemical plants truly are the worst of all legacy nightmares.
