https://news.ycombinator.com/item?id=37307708 (258 comments)
Keystroke timing obfuscation added to ssh(1) - https://news.ycombinator.com/item?id=37307708 - Aug 2023 (255 comments)
also:
Timing Analysis of Keystrokes and Timing Attacks on SSH (2001) [pdf] - https://news.ycombinator.com/item?id=18557916 - Nov 2018 (17 comments)
ssh-keygen(1): generate Ed25519 keys by default. Ed25519 public keys
are very convenient due to their small size. Ed25519 keys are
specified in RFC 8709 and OpenSSH has supported them since version 6.5
(January 2014).
Previously, if you didn't specify "-t", you got RSA keys; now you get Ed25519, and if you want RSA you have to ask for it.
NIST's publication of FIPS 186-5 in February (2023) added Ed25519 and Ed448 as approved (? allowed?) algorithms:
* https://csrc.nist.gov/publications/detail/fips/186/5/final
* https://en.wikipedia.org/wiki/EdDSA#Standardization_and_impl...
Partly one of the reasons given for the default switch:
* https://lists.mindrot.org/pipermail/openssh-unix-dev/2023-Se...
Curious to know if/when the OpenSSH folks will add Ed448 (RFC 8709, like Ed25519).
https://feedback.azure.com/d365community/idea/1dca6716-dc25-...
Turns out they didn’t even support it until ~2021.
These instances were created before then. It took quite a while to figure out what was going on.
Yeah, it's a little weird feeling to downgrade in best-estimate security level to go from 4096 bit RSA to ed25519. Ed448 avoids that concern.
* https://www.keylength.com/en/4/
Going to 4096 doesn't get you much given you have weaker links in the security chain. The next step up would be AES 192 and RSA 7680, and then AES 256 with RSA 15360.
I'd be interested to read a history of Rambus. They're a strange and somewhat controversial company. I lived through the controversy but I'm not certain I remember it correctly. From what I remember they patented some things related to DDR SDRAM, I'm not sure how much credit they deserve for developing those things or if they were just first to file. For part of the Pentium 4's lifecycle they convinced Intel to use Rambus' proprietary DRAM (RDRAM) which supposedly had some benefits but I just remember being overpriced. They shook down DDR manufacturers for patent licensing fees. Apparently the EU opened an antitrust investigation into them for getting their patents into the standard and then not licensing them freely enough. I'm not sure it's fair to call them a patent troll but I guess they're something similar to Fraunhofer or Synopsis.
They may have good tech but have an history of being super shady.
https://en.wikipedia.org/wiki/Rambus
> Rambus was accused of shredding key documents prior to court hearings, the judge agreed and dismissed Rambus' case against Infineon. T
> On January 9, 2009, a Delaware federal judge ruled that Rambus could not enforce patents against Micron Technology Inc., stating that Rambus had a "clear and convincing" show of bad faith, and ruled that Rambus' destruction of key related documents (spoliation of evidence) nullified its right to enforce its patents against Micron.[28]
> Rambus engaged in intentional deceptive conduct in the context of the standard-setting process for example by not disclosing the existence of the patents which it later claimed were relevant to the adopted standard. This type of behavior is known as a "patent ambush".
> Ronald Black, Rambus's CEO, said, "Somehow we got thrown into the patent troll bunch...This is just not the case."[43]
See, they are the good guys after all. It came right from their CEO. /s
If someone is acting like this then shows up with a "here is a cool curve you can use", not surprising people will be suspicious. It's like that neighbor who has been suing everyone in the neighborhood, and calling the cops on kids playing outside, all of the sudden shows with a plate of cookies. People will think twice before trying a cookie.
IIRC, their interfaces were used in some Sony play-stations and also some Intel systems.
This Pentium 4 was released in the year 2000.
So, yes, Rambus, the company, is a known quantity. Just weird they're into crypto now, because trying to wiggle into this already crowded patent landmine is certainty an... interesting choice.
* https://soatok.blog/2022/05/19/guidance-for-choosing-an-elli...
(I just clicked the Submit button! https://go.dev/cl/524775)
It's a small change, but it's a signal that we're much more on top of x/crypto/ssh maintenance, compared to a year ago when we had to scramble to implement rsa-sha2-256/512 support just hours before GitHub (rightfully) dropped SHA-1 support, potentially breaking every x/crypto/ssh client.
The main reason is that thanks to the funding of my clients (https://words.filippo.io/full-time-maintainer/) I was able to hire Nicola Murino, the maintainer of SFTPGo, to pick up maintenance of x/crypto/ssh. This is benefiting both my clients and the whole ecosystem, and is a little step in growing the professional maintainer model.
Pretty much, if anybody can listen in on your traffic and IO is unbuffered then they can extract information about the keys pressed based on the timing between consecutive presses. There's this old LWN article: https://lwn.net/Articles/298833/
It was also discussed a while back when it was first published on undeadly: https://news.ycombinator.com/item?id=37307708
In general though if you have buffered IO you are fine since a packet is sent only when 'enter' is pressed.
Let's ignore ongoing feature creep and development in projects for now (I'll address this in a second). As the core software becomes functional, gains users, has bugs fixed, the threat model of the software needs to change and grow. Generally software in this state gets progressively more stable and in that stability you can see the tiny ripples of very small edge cases.
For software where security is paramount and has an uncountable number of users protecting uncountable bytes of data like SSH, the tiny ripples of extremely esoteric attacks become a reasonable thing to address as a feature improvement. Do I need this feature for my personal threat model or even the threat model of my company? No probably not... But it doesn't hurt to have it either.
This feature raises the cost of attacking the software, and may dissuade different attacker from even trying. Most of practical security is more about making attacks expensive enough that they attacker will have to spend more than the value of what they would obtain if they were able to break into it and this change helps keep that high watermark well above those thresholds.
For software that does have ongoing feature creep this process is a lot slower but does seem to happen for opensource projects specifically that can survive their infancy sufficiently long enough to become foundational components like SSH and Curl. I've never seen this level stability from closed source software.
Recently there has been some work on using audio of keypresses to determine what's been typed: https://arxiv.org/pdf/2308.01074.pdf .
The statistical analysis described earlier works better when you have samples of a person's typing to try and learn whats been sent, but the acoustic work has raised some concerns that ML techniques can be used on just packet timings to determine what's been typed without a pre-determined signature. There's also concern that all that telemetry programs and sites send about you may be abused to build a signature of your typing patterns as well.
So does it send these phantom keystrokes only when there are real keystrokes?
On first reading I thought it sends periodic+random keystrokes and so {Client,Server}AliveInterval option(s) may not be required to keep the connection alive. Need to try and confirm the behaviour.
This version also changes ssh-keygen to generate ed25519 keys by default. Time to update scripts that generate keys without a '-t' arg.
I'd say at this point the risk of silly goofs in the curve code is similar to the risk from RSA given how well understood it is.