Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSH 9.5 released with keystroke timing obfuscation

lwn.net

Post reply on HN
Print view View original

11–20 of 60 posts

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#11

Post by tialaramex »

acquacow wrote: post #8
devsda wrote: post #4

> 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 f…

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.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#12

Post by throw0101a »

nullc wrote: post #6
throw0101a wrote: post #3

More importantly (IMHO): 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). * https://www.openssh.com/releasenotes.html#9.5 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…

> 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.

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.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#13

Post by throw0101a »

botanical wrote: post #7
throw0101a wrote: post #3

More importantly (IMHO): 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). * https://www.openssh.com/releasenotes.html#9.5 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…

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

That particular curve was chosen for specific technical reasons:

* https://en.wikipedia.org/wiki/Curve448

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#14

Post by jshier »

throw0101a wrote: post #3

More importantly (IMHO): 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). * https://www.openssh.com/releasenotes.html#9.5 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…

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-...

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#15

Post by ch0ic3 »

cabirum wrote: post #9

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.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#16

Post by mastax »

botanical wrote: post #7
throw0101a wrote: post #3

More importantly (IMHO): 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). * https://www.openssh.com/releasenotes.html#9.5 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…

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

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.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#18

Post by sophacles »

cabirum wrote: post #9

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?

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.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#19

Post by throwaway9870 »

botanical wrote: post #7
throw0101a wrote: post #3

More importantly (IMHO): 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). * https://www.openssh.com/releasenotes.html#9.5 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…

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

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.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#20

Post by FiloSottile »

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.

Post reply on HN