OpenSSH 9.5 released with keystroke timing obfuscation(lwn.net)
lwn.net
OpenSSH 9.5 released with keystroke timing obfuscation
https://lwn.net/Articles/946497/
59 comments
Thanks! Macroexpanded:
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)
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)
More importantly (IMHO):
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).
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).
Last I checked, Azure didn't support Ed25519 keys, so manual fallback to RSA will now be required.
https://feedback.azure.com/d365community/idea/1dca6716-dc25-...
https://feedback.azure.com/d365community/idea/1dca6716-dc25-...
That wouldn’t surprise me at all. I recently had issues with an EC2 instance in AWS that I couldn’t auth to, with an Ed25519-based key.
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.
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.
Does Azure not support cloud-init? When AWS complained about Ed25519 keys, I just told AWS to not associate any keys at all and just put my key in the cloud-init config. The OS copies the contents from cloud-init to the appropriate authorized_keys file on first boot and it's none of AWS's business which key (or how many keys) I use to login into my instances.
That seems like specifically Azure DevOps, not the Azure platform generally? I assume any OS running inside Azure Compute, or any other managed services will support Ed25519 fine?
The API for creating Azure VMs doesn't support specifying an ED25519 key.
https://docs.microsoft.com/en-us/azure/virtual-machines/linu...
But once you've created the VM you can log in and replace that RSA key with an ED25519 one just like any standard Linux install, via ssh-copy-id or manually updating authorized_keys or whatever you want. So you just need a throwaway RSA key for the initial deployment.
https://docs.microsoft.com/en-us/azure/virtual-machines/linu...
But once you've created the VM you can log in and replace that RSA key with an ED25519 one just like any standard Linux install, via ssh-copy-id or manually updating authorized_keys or whatever you want. So you just need a throwaway RSA key for the initial deployment.
If Azure supports cloud-init, you can forego that throwaway RSA key.
Thanks for the information. That's pretty embarrassing that it's still not supported.
It's probably because FIPS 140-2 doesn't list it. I know machines booted with fips=1 and fips certified openssl, etc, openssh won't accept ed25519 keys for key auth.
> Curious to know if/when the OpenSSH folks will add Ed448
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.
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.
RSA 3072 has the 'comparable' security of AES 128:
* 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.
* 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.
You'd have an argument if you were just talking about the DH key used for PFS, but the ID key is a long term secret, so breaking it has a radically payoff surface.
Even when AES and ECC have similar security they have different behavior in terms of multi-target attacks and the curve for success probability vs computation invested are quite different.
You're also not limited to use AES 128 with ssh, ChaCha20-Poly1305 is a nice choice.
Even when AES and ECC have similar security they have different behavior in terms of multi-target attacks and the curve for success probability vs computation invested are quite different.
You're also not limited to use AES 128 with ssh, ChaCha20-Poly1305 is a nice choice.
Somehow I've never heard of Curve448 or the company Rambus. It's giving me (unfounded) Crypto AG vibes.
https://en.wikipedia.org/wiki/Crypto_AG
https://en.wikipedia.org/wiki/Crypto_AG
Strange, I didn't expect Rambus to be involved in cryptography, nor that they would give away the spec and implementation. I guess it was designed to be a smaller die-area solution for some of their silicon IP products, and opening it up just makes it more convenient for their customers to use. (And, hopefully, nobody is stupid enough to use some vendor's secret proprietary crypto in their chips).
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.
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.
Rambus bought Cryptography Research about 12 years ago:
https://www.rambus.com/rambus-completes-acquisition-of-crypt...
Rambus was pretty well known for using a submarine patent against RAM manufacturers back in late nineties https://www.edn.com/submarine-patents-could-torpedo-rambus/ followed by fifteen years of acting like a patent troll...
They may have good tech but have an history of being super shady.
They may have good tech but have an history of being super shady.
This comment is cringe enough that it is making the rounds on multiple Slacks. It's fine that you've never heard of Curve448. That just means you're not a cryptography engineer. Most people aren't! But if you're not one of those, be a little careful about connecting the dots to things like "Crypto AG". Saying "I've never heard of Curve448, it sounds sketchy" is a little like a systems programmer saying "I've never heard of Paxos before, it sounds sketchy". Most systems programmers are never going to do anything with Paxos. But all the competent ones can look it up in about 20 seconds and confirm that it isn't a conspiracy.
Damage control slacks?
No, Curve448 is as good as can be per the public knowledge, see https://safecurves.cr.yp.to/. What one could expect given Rambus history is undisclosed patents, possibly the most efficient hardware implementation. They have been known to get their tech standardized (not disclosing IP claims) and come back at adopters with patent violation suits.
Curve448 was published almost 10 years ago. What aspects of it could have been patented, and what patents does Rambus have covering those claims?
Cryptography Research patented quite a few DPA/SPA countermeasures, if there is a non obvious patent on Curve448 it will likely be one of those making it hard to make a non infringing, fast yet not vulnerable HW implementation... Given their business in licencing those countermeasure (https://www.rambus.com/security/dpa-countermeasures/licensed...), one can see their eagerness to get some curves in widely used standards as suspicious in that light.
I'm not really concerned but I also understand why one wouldn't implement anything Rambus related given their history of patent trolling...
I'm not really concerned but I also understand why one wouldn't implement anything Rambus related given their history of patent trolling...
Not sure about Crypto AG level shardy. But they are still shady. When I see Rambus I think "patent troll".
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.
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.
Same for me. I don't think Rambus was a pure troll because they actually did invent some things, but at the time I thought they saw what SCO did and wanted in on that action.
Rambus is an interesting company. I can't vouch for their crypto offerings, but they have been around since the 90's and at one point pioneered high-speed DRAM interfaces. Lots of what we see in DDR today is based on ideas and concepts they pushed forward in their proprietary interface. Early on, they definitely did innovative work.
IIRC, their interfaces were used in some Sony play-stations and also some Intel systems.
IIRC, their interfaces were used in some Sony play-stations and also some Intel systems.
That particular curve was chosen for specific technical reasons:
* https://en.wikipedia.org/wiki/Curve448
* https://en.wikipedia.org/wiki/Curve448
My fellow comments aren't actually getting to the point: The original release of the Pentium 4 used Rambus RAM, instead of the JEDEC standard of the time.
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.
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.
They bought Paul Kocher's Cryptography Research in 2021. Cryptography Research designed the Blu-Ray BD+ licensing system and owned a huge IP portfolio on differential power analysis, a technique Kocher, one of the godfathers of side channel cryptanalysis, invented. They also ran (run?) one of the industry's best cryptographic consultancies. If you're a major hardware vendor going to market with a new cryptographic coprocessor, you're very likely going to engage Rambus.
What are the pros/cons of Ed448?
> Ed25519 is one of the two digital signature algorithms today that use the EdDSA algorithm framework. The other is Ed448, which targets a higher security level (224-bit vs 128-bit) but is also slower and uses SHAKE256 (which is overkill and not great for performance).
* https://soatok.blog/2022/05/19/guidance-for-choosing-an-elli...
* https://soatok.blog/2022/05/19/guidance-for-choosing-an-elli...
I'm using RSA8192 with SSH and not seeing any noticable performance problems. ECC is generally faster than RSA, so just always using Ed448 or even larger should be a no-brainer.
Your personal RSA/ECC SSH keys are there for the initial key exchange, after which a session key is created (cycled after x bytes / y seconds).
But if you're handling hundreds or thousands of operations per second (e.g., a web site), then the delays add up.
But if you're handling hundreds or thousands of operations per second (e.g., a web site), then the delays add up.
If you are doing hundreds or thousands of SSH connections per second, you are doing something wrong. At least in 99.9% of cases.
Github might be different, but not the rest of the world.
Github might be different, but not the rest of the world.
The comments about Ed25519 versus Ed448 were meant for the general case of their use, and not (necessarily) strictly in the use for SSH.
However, the reason for Ed25519 use in OpenSSH is because the keys are much smaller, and easier to cut/paste/etc, for the same security factor. The fact that they are faster for signing is a bonus.
* https://lists.mindrot.org/pipermail/openssh-unix-dev/2023-Se...
RFC 8032 § 7.1. Test Vectors for Ed25519:
* https://goteleport.com/blog/comparing-ssh-keys/
All of the above correspond to roughly the security of AES 128. If you want AES 256 equivalence, double the size/length.
I'm in the habit of using ssh-copy-id(1), but there are a lot of places where you have to copy-paste in a web interface (and lots of instructions tell you to copy-paste into your remote ~/.ssh/authorized_keys file).
However, the reason for Ed25519 use in OpenSSH is because the keys are much smaller, and easier to cut/paste/etc, for the same security factor. The fact that they are faster for signing is a bonus.
* https://lists.mindrot.org/pipermail/openssh-unix-dev/2023-Se...
RFC 8032 § 7.1. Test Vectors for Ed25519:
SECRET KEY:
9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031cae7f60
PUBLIC KEY:
d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a
SECRET KEY:
6c82a562cb808d10d632be89c8513ebf6c929f34ddfa8c9f63c9960ef6e348a3
528c8a3fcc2f044e39a3fc5b94492f8f032e7549a20098f95b
PUBLIC KEY:
5fd7449b59b461fd2ce787ec616ad46a1da1342485a70e1f8a0ea75d80e96778
edf124769b46c7061bd6783df1e50f6cd1fa1abeafe8256180
-----BEGIN RSA PRIVATE KEY-----
MIIG4wIBAAKCAYEA1MSdsaPH2ShtjOo4c02+DbYcTdwUBLY+vNSXr2tV8/jGU059
Jak9CA7VSlKR/fik18D7Lq1beLjW56kV4Xvm3qmpxOc3eNGmj8dqtO0G3Lp1FAZz
xlu2SZsHmmVq9isZcN70apkwlDgIZ11NVIq/1iXzr0pIRMKkMNHTGBGBkYOrIcgd
H2elvIqfiit6Gts/zho4YCjgyn/r3Vgy/jCu6VbfwE9xVY/DB4srD5LrZMabRzN2
YwSTI+sRqpbt7I7nZ6o8CuyqHDLjbO9VzE0povBshTfoyog9XGcQHwTmWn4bdnsh
2I1x3gQpaqxdRs4vnKmXJ9GvC/sYla0GYXyDecpgjITqx3QA6aKx9+EVh/o6owYT
HXaToVkP7U5m8cqaloQFfA8HLsGDg9A0QaMtixnX7KtT/ZvKFMcazRJ1GX42Uaeu
O1opZKtjBHLtmaPadNeZdD77VytwY2UHeW5QSnfpos7IxUTATpd6KTWUV3snVQny
iltCI1BHJC01sWePAgMBAAECggGAEG1tz31ZvMaGTs72tNBX0C8zWD+ZvBNmHKY9
X+nlpQScK2pv9yxt7eVXSnm9k+JSt+XKfvwbh+KdlR1U9yfd12s6FF3VxppJReib
sIRsdzZeO8GTxsjl9iDmIWGbNI53VGOic2iIe6kn3PMzOUfNL/eWLP6LPePZUXuh
1MXlPxrvZ5hPx1D1Vu1NDBn3P4OWFY+osqP1Vy0xRNG+fim8F4ABnpODqJuE71wr
YvRxAELlUkYC6fo8chWAM6+bhxwxVaGiIKluikmVJtt0/aAcKR6fUogGfcumRGPp
HzFRDZBVdLmVwbpVrfCbULP7wYk2A5QMu2skAlZSYtyWJbBRXvgweEXepJaXC6FW
atD5ypi1kSX9K71BRM7DKrmY2/RsyR6Y8a2PdiOHB5MNYKoeH5o2k0htsV2zUspo
4nER4AB5a5fEysGg3yCST+m2q7UOBvcB0LblE/0sNuOGtCNPmtChdZxspsVRm2ID
XkKrljy+cdOsxZ0iVcvGhyJRhlCBAoHBAOn6KMfbB11uliVyouFfV5ZoiWPeIXbF
wkAnev+8kF/GmYU7bAFAhRg2qzwqTVlC2eeG+dHKgr9+xHjsTOIoLB/5jPgcIfY9
l0lZ9LmNwwvI3wg6XWnwQf9X97YZ1E1A3TpBU5XNzTo7hVtZgHDIf4ufB5sDhZ1S
nXf/+uBe7gJMMnizpq/tqr+0oPJd4uac1rTp2wsFx6MJjOR8kijZOnr3SdKNU3xo
shZWlRHy9qCjftxTIuOFSxdEZhJUm87w8QKBwQDoy2hYI0hMn3+lwu30lk4+LGSW
9ij7AzyTVcRR9FbYciTMQ24IrK020A9rDXkVkJ6FeTbCtT3UkFOlz3JZkEpvY/qd
Mf8hfd5IO68R1Z5lZpLCFAqcIRUE9l7En9nMiuqdDPZJfhUjhlajzhQotYEv1Fqq
WDmK0IaklSfGJt0LVsZSuINErHaC5HjJocL86Cqao9a1rxgJA7maCfirwABAafHc
6OhFuW5Pi6IXj9QbM7PgbGjIIXPDFfs7FkqF4H8CgcEAu0MACJSAXIL5oJcTTZVl
IHgiHc/WsJyuT3JJuwxL8Juem0dntcjRvQNkIQ8qQNqEVA1vPDz8UA9BaBaXohnM
1vp/nMPHWrEIuChK+YdAJ9poxskPoo4sBBV/qDsb84iKhulp4GeKbaTdorMLXTja
/AAXsjUrZzKL3VL+kzzm+OfLLVd7fSqWkkAa4F/MDg5QuRLBwRyrHw2xud0Jja/u
YiQw7Vc3Dkcs4TwCqw7t3Lt9+RCAx+ASrViM6PbWjNXBAoHAa0fiDEwmM3mFn+RX
ONJTuH9I0/EZLaRuNA/ga0xJAXKI1sF0YfcB1DLKCDGrTW7aPvR/cfeISP9CLTWO
owvF4dOXWP4Db3HMEEnBAl0Jo/1DQMFvqkfsod7QCZkJDCQwvrOMhI3gPADayJ5d
1+zdXidkqQADdJ9ojUxXig+66lDREKoLhIheDTAxIeq0K0zq5Vz/w7avQug+jmht
+uh+tTCdz4peEFPGLE5TIrybqPWIvbH4D9KqwIrOvoolSdENAoHAaa+n0ZXGovFy
Hjk02KSinY80b0VzOKKXCh3vc5+2WAS9Ar4no7Cobt5QhKA0GtYpLSCmUFRvsZ1P
Gemb/FH+yC5nLvKaDOpHktZONIARP8e9R1ku9o+9lOFAIU0MYHx0Ep0y4XWgMrTp
UuP3ai7zn++ag7Lu1QEm5pQAd2n+zMuKZbBISVA9fPbC9RkJX66E4zVbsEUnDDBD
9Rlu+3Dc0LwSjtAxXPDInmEh2mp3O/aZtMPVUPgDA4Ig7GbQC6W/
-----END RSA PRIVATE KEY-----
-----BEGIN PUBLIC KEY-----
MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEA1MSdsaPH2ShtjOo4c02+
DbYcTdwUBLY+vNSXr2tV8/jGU059Jak9CA7VSlKR/fik18D7Lq1beLjW56kV4Xvm
3qmpxOc3eNGmj8dqtO0G3Lp1FAZzxlu2SZsHmmVq9isZcN70apkwlDgIZ11NVIq/
1iXzr0pIRMKkMNHTGBGBkYOrIcgdH2elvIqfiit6Gts/zho4YCjgyn/r3Vgy/jCu
6VbfwE9xVY/DB4srD5LrZMabRzN2YwSTI+sRqpbt7I7nZ6o8CuyqHDLjbO9VzE0p
ovBshTfoyog9XGcQHwTmWn4bdnsh2I1x3gQpaqxdRs4vnKmXJ9GvC/sYla0GYXyD
ecpgjITqx3QA6aKx9+EVh/o6owYTHXaToVkP7U5m8cqaloQFfA8HLsGDg9A0QaMt
ixnX7KtT/ZvKFMcazRJ1GX42UaeuO1opZKtjBHLtmaPadNeZdD77VytwY2UHeW5Q
Snfpos7IxUTATpd6KTWUV3snVQnyiltCI1BHJC01sWePAgMBAAE=
-----END PUBLIC KEY-----
* https://goteleport.com/blog/comparing-ssh-keys/
All of the above correspond to roughly the security of AES 128. If you want AES 256 equivalence, double the size/length.
I'm in the habit of using ssh-copy-id(1), but there are a lot of places where you have to copy-paste in a web interface (and lots of instructions tell you to copy-paste into your remote ~/.ssh/authorized_keys file).
Is it a coincidence the generated keys start with the same first 3 letters (“MII…”)?
Nope. See https://www.thedigitalcatonline.com/blog/2018/04/25/rsa-keys... for example:
"Please note that, due to the structure of the underlying ASN.1 structure, RSA PEM bodies start always with the same characters: MIG for 1024 bit keys, MII for 2048 and 4096 bit ones."
"Please note that, due to the structure of the underlying ASN.1 structure, RSA PEM bodies start always with the same characters: MIG for 1024 bit keys, MII for 2048 and 4096 bit ones."
Length is then not an argument against always using Ed448 over Ed25519.
This is great news and has a much larger impact than the featured feature IMO.
If you use OpenSSH (wink), please consider donating to OpenBSD, aka the upstream developers: https://www.openbsd.org/donations.html
With the new default ObscureKeystrokeTiming setting, a single typed character now causes hundreds of packets on the wire instead of 3.
What are the downsides of this?
It's nice to see that they take this seriously. I praise their risk aversion.
The link that was (originally) submitted is to LWN just posting the release notes. The direct link(s) to the release notes is:
* https://www.openssh.com/txt/release-9.5
* https://www.openssh.com/releasenotes.html#9.5
* https://www.openssh.com/txt/release-9.5
* https://www.openssh.com/releasenotes.html#9.5
> This attempts to hide inter-keystroke timings by sending interactive traffic at fixed intervals (default: every 20ms) when there is only a small amount of data being sent. It also sends fake "chaff" keystrokes for a random interval after the last real keystroke. These are controlled by a new ssh_config ObscureKeystrokeTiming keyword.
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.
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.
It's 2023, you shouldn't be using the old rsa keys anyway.
Meh. RSA is only used to sign things in SSH and the keys used are generated in a conventional way and with the parameters you'd be told to pick (e.g. exponent 65537)
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.
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.
The release notes do not say why there is a need to obfuscate keystroke timings. I guess it is designed to mitigate some attack vector? Is it already being exploited in the wild or... let's say is purely of academic interest?
> mitigate some attack vector?
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.
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.
There is this cool thing I've noticed about software as it matures and this is a good example of that. When you're first starting out on a project, have no users, and its mostly feature incomplete there is little to no drive or reason to care about whole classes of security and performance issues... You're trying to just get the thing to work.
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.
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.
Keystroke timing attacks have been known for quite a while - heres a highly cited paper from over 20 years ago: https://www.usenix.org/conference/10th-usenix-security-sympo...
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.
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.
There was a recent research paper shared here where it was claimed using keystroke timing and some AI, researchers could predict the password with significant accuracy.
I'm very proud that we implemented server-side support for the keystroke timing obfuscation mechanism in golang.org/x/crypto/ssh already.
(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.
(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.
Why does the server side need support for that? Is it the ping/pong feature mentioned in the OpenSSH announcement?
[deleted]
https://news.ycombinator.com/item?id=37307708 (258 comments)