281–290 of 375 posts
Why not just add random "jitter" to the keystroke packets, but keeping just the 1 actual packet?
> In 2023, ssh added keystroke timing obfuscation. The idea is that the speed at which you type different letters betrays some information about which letters you’re typing. So ssh sends lots of “chaff” packets along with your keystrokes to make it hard for an attacker to determine when you’re actually entering keys. Why not just add random "jitter" to the keystroke packets, but keeping just the 1 actual packet?
Earlier quoted context omitted.
> several 56k baud modems These were almost definitely 8k baud.
Confusing baud and bit rates is consistent with actually being there, though.
> In 2023, ssh added keystroke timing obfuscation. The idea is that the speed at which you type different letters betrays some information about which letters you’re typing. So ssh sends lots of “chaff” packets along with your keystrokes to make it hard for an attacker to determine when you’re actually entering keys. Why not just add random "jitter" to the keystroke packets, but keeping just the 1 actual packet?
Jitter could be filtered out, I presume.
The 2023 timing obfuscation is a nice case study in security defaults vs edge cases. Most SSH users won't notice 100 packets per keystroke - it's noise in the bandwidth budget. But for high-frequency terminal apps, it becomes the dominant cost. At 2000 concurrent players updating 80x60 chars at 10fps, a custom protocol might be the right answer regardless of obfuscation settings.
Earlier quoted context omitted.
Jitter could be filtered out, I presume.
How? You can't average out the noise here because the attack involves discriminating the different types of events from one another based on the thing you'd be averaging.
Earlier quoted context omitted.
I assure you that if you rubber duck at another engineer that doesn't understand what you're doing, you will also be pummeled with information that may or may not be relevant. ;)
That isn't rubber duck debugging. It's just talking to someone about the problem. The entire point of rubber duck debugging is that the other side literally cannot respond - it's an inanimate object, or even a literal duck/animal.
The point or rubber duck debugging then is to realize the benefit of verbally describing the problem without needing to interrupt your colleague and waste his time in order to do so. It's born of the recognition that often, midway through wasting your colleague's time, you'll trail off with an "oh ..." and exit the conversation. You've ended up figuring out the problem before ever actually receiving any feedback.
To that end an LLM works perfectly well as long as you still need to walk through a full explanation of the problem (ie minimal relevant context). An added bonus being that the LLM offers at least some of the benefits of a live person who can point out errors or alert you to new information as you go.
Basically my quibble is that to me the entire point of rubber duck debugging is "doesn't waste a real person's time" but it comes with the noticeable drawback of "plastic duck is incapable of contributing any useful insights".
The 2023 timing obfuscation is a nice case study in security defaults vs edge cases. Most SSH users won't notice 100 packets per keystroke - it's noise in the bandwidth budget. But for high-frequency terminal apps, it becomes the dominant cost. At 2000 concurrent players updating 80x60 chars at 10fps, a custom protocol might be the right answer regardless of obfuscation settings.
Just think of the trees burnt in the name of security!
Earlier quoted context omitted.
A rubber ducky demands that you think about your own questions, rather than taking a mental back seat as you get pummeled with information that may or may not be relevant.
I'm not saying you should do this, but you can do this: https://gist.github.com/shmup/100a7529724cedfcda1276a65664dc...
The 2023 timing obfuscation is a nice case study in security defaults vs edge cases. Most SSH users won't notice 100 packets per keystroke - it's noise in the bandwidth budget. But for high-frequency terminal apps, it becomes the dominant cost. At 2000 concurrent players updating 80x60 chars at 10fps, a custom protocol might be the right answer regardless of obfuscation settings.
Just think of the trees burnt in the name of security!
In a perfect world, we could send all traffic completely unencrypted and never scan for a malicious payload, saving all that energy and hardware. But we do not live in that world and drawing the line with this minor, mostly unintrusive security feature seems strange.