[HN Gopher] OpenSSH 9.5 released with keystroke timing obfuscation
___________________________________________________________________
OpenSSH 9.5 released with keystroke timing obfuscation
Author : surteen
Score : 210 points
Date : 2023-10-04 13:50 UTC (9 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| cabirum wrote:
| 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?
| ch0ic3 wrote:
| > 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.
| sophacles wrote:
| 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.
| habibur wrote:
| 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.
| TrueDuality wrote:
| 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.
| devsda wrote:
| > 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.
| acquacow wrote:
| It's 2023, you shouldn't be using the old rsa keys anyway.
| tialaramex wrote:
| 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.
| throw0101a wrote:
| 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
| Tempest1981 wrote:
| More from last month:
|
| https://news.ycombinator.com/item?id=37307708 (258 comments)
| dang wrote:
| 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)
| throw0101a wrote:
| 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 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).
| sigg3 wrote:
| This is great news and has a much larger impact than the
| featured feature IMO.
| pnpnp wrote:
| What are the pros/cons of Ed448?
| throw0101a wrote:
| > _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...
| isilofi wrote:
| 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.
| throw0101a wrote:
| 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.
| isilofi wrote:
| 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.
| throw0101a wrote:
| 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 SS 7.1. Test Vectors for Ed25519:
| SECRET KEY: 9d61b19deffd5a60ba844af492ec2cc44449c
| 5697b326919703bac031cae7f60 PUBLIC KEY:
| d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f
| 707511a
|
| RFC 8032 SS 7.4. Test Vectors for Ed448
| SECRET KEY: 6c82a562cb808d10d632be89c8513ebf6c929
| f34ddfa8c9f63c9960ef6e348a3
| 528c8a3fcc2f044e39a3fc5b94492f8f032e7549a20098f95b
| PUBLIC KEY: 5fd7449b59b461fd2ce787ec616ad46a1da13
| 42485a70e1f8a0ea75d80e96778
| edf124769b46c7061bd6783df1e50f6cd1fa1abeafe8256180
|
| A comparable RSA 3072 key is much longer:
| -----BEGIN RSA PRIVATE KEY----- MIIG4wIBAAKCAYEA1
| MSdsaPH2ShtjOo4c02+DbYcTdwUBLY+vNSXr2tV8/jGU059 J
| ak9CA7VSlKR/fik18D7Lq1beLjW56kV4Xvm3qmpxOc3eNGmj8dqtO0G3L
| p1FAZz xlu2SZsHmmVq9isZcN70apkwlDgIZ11NVIq/1iXzr0
| pIRMKkMNHTGBGBkYOrIcgd H2elvIqfiit6Gts/zho4YCjgyn
| /r3Vgy/jCu6VbfwE9xVY/DB4srD5LrZMabRzN2 YwSTI+sRqp
| bt7I7nZ6o8CuyqHDLjbO9VzE0povBshTfoyog9XGcQHwTmWn4bdnsh
| 2I1x3gQpaqxdRs4vnKmXJ9GvC/sYla0GYXyDecpgjITqx3QA6aKx9+EVh
| /o6owYT HXaToVkP7U5m8cqaloQFfA8HLsGDg9A0QaMtixnX7
| KtT/ZvKFMcazRJ1GX42Uaeu O1opZKtjBHLtmaPadNeZdD77V
| ytwY2UHeW5QSnfpos7IxUTATpd6KTWUV3snVQny iltCI1BHJ
| C01sWePAgMBAAECggGAEG1tz31ZvMaGTs72tNBX0C8zWD+ZvBNmHKY9
| X+nlpQScK2pv9yxt7eVXSnm9k+JSt+XKfvwbh+KdlR1U9yfd12s6FF3Vx
| ppJReib sIRsdzZeO8GTxsjl9iDmIWGbNI53VGOic2iIe6kn3
| PMzOUfNL/eWLP6LPePZUXuh 1MXlPxrvZ5hPx1D1Vu1NDBn3P
| 4OWFY+osqP1Vy0xRNG+fim8F4ABnpODqJuE71wr YvRxAELlU
| kYC6fo8chWAM6+bhxwxVaGiIKluikmVJtt0/aAcKR6fUogGfcumRGPp
| HzFRDZBVdLmVwbpVrfCbULP7wYk2A5QMu2skAlZSYtyWJbBRXvgweEXep
| JaXC6FW atD5ypi1kSX9K71BRM7DKrmY2/RsyR6Y8a2PdiOHB
| 5MNYKoeH5o2k0htsV2zUspo 4nER4AB5a5fEysGg3yCST+m2q
| 7UOBvcB0LblE/0sNuOGtCNPmtChdZxspsVRm2ID XkKrljy+c
| dOsxZ0iVcvGhyJRhlCBAoHBAOn6KMfbB11uliVyouFfV5ZoiWPeIXbF
| wkAnev+8kF/GmYU7bAFAhRg2qzwqTVlC2eeG+dHKgr9+xHjsTOIoLB/5j
| PgcIfY9 l0lZ9LmNwwvI3wg6XWnwQf9X97YZ1E1A3TpBU5XNz
| To7hVtZgHDIf4ufB5sDhZ1S nXf/+uBe7gJMMnizpq/tqr+0o
| PJd4uac1rTp2wsFx6MJjOR8kijZOnr3SdKNU3xo shZWlRHy9
| qCjftxTIuOFSxdEZhJUm87w8QKBwQDoy2hYI0hMn3+lwu30lk4+LGSW
| 9ij7AzyTVcRR9FbYciTMQ24IrK020A9rDXkVkJ6FeTbCtT3UkFOlz3JZk
| EpvY/qd Mf8hfd5IO68R1Z5lZpLCFAqcIRUE9l7En9nMiuqdD
| PZJfhUjhlajzhQotYEv1Fqq WDmK0IaklSfGJt0LVsZSuINEr
| HaC5HjJocL86Cqao9a1rxgJA7maCfirwABAafHc 6OhFuW5Pi
| 6IXj9QbM7PgbGjIIXPDFfs7FkqF4H8CgcEAu0MACJSAXIL5oJcTTZVl
| IHgiHc/WsJyuT3JJuwxL8Juem0dntcjRvQNkIQ8qQNqEVA1vPDz8UA9Ba
| BaXohnM 1vp/nMPHWrEIuChK+YdAJ9poxskPoo4sBBV/qDsb8
| 4iKhulp4GeKbaTdorMLXTja /AAXsjUrZzKL3VL+kzzm+OfLL
| Vd7fSqWkkAa4F/MDg5QuRLBwRyrHw2xud0Jja/u YiQw7Vc3D
| kcs4TwCqw7t3Lt9+RCAx+ASrViM6PbWjNXBAoHAa0fiDEwmM3mFn+RX
| ONJTuH9I0/EZLaRuNA/ga0xJAXKI1sF0YfcB1DLKCDGrTW7aPvR/cfeIS
| P9CLTWO owvF4dOXWP4Db3HMEEnBAl0Jo/1DQMFvqkfsod7QC
| ZkJDCQwvrOMhI3gPADayJ5d 1+zdXidkqQADdJ9ojUxXig+66
| lDREKoLhIheDTAxIeq0K0zq5Vz/w7avQug+jmht +uh+tTCdz
| 4peEFPGLE5TIrybqPWIvbH4D9KqwIrOvoolSdENAoHAaa+n0ZXGovFy
| Hjk02KSinY80b0VzOKKXCh3vc5+2WAS9Ar4no7Cobt5QhKA0GtYpLSCmU
| FRvsZ1P Gemb/FH+yC5nLvKaDOpHktZONIARP8e9R1ku9o+9l
| OFAIU0MYHx0Ep0y4XWgMrTp UuP3ai7zn++ag7Lu1QEm5pQAd
| 2n+zMuKZbBISVA9fPbC9RkJX66E4zVbsEUnDDBD
| 9Rlu+3Dc0LwSjtAxXPDInmEh2mp3O/aZtMPVUPgDA4Ig7GbQC6W/
| -----END RSA PRIVATE KEY----- -----BEGIN
| PUBLIC KEY----- MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AM
| IIBigKCAYEA1MSdsaPH2ShtjOo4c02+ DbYcTdwUBLY+vNSXr
| 2tV8/jGU059Jak9CA7VSlKR/fik18D7Lq1beLjW56kV4Xvm 3
| qmpxOc3eNGmj8dqtO0G3Lp1FAZzxlu2SZsHmmVq9isZcN70apkwlDgIZ1
| 1NVIq/ 1iXzr0pIRMKkMNHTGBGBkYOrIcgdH2elvIqfiit6Gt
| s/zho4YCjgyn/r3Vgy/jCu 6VbfwE9xVY/DB4srD5LrZMabRz
| N2YwSTI+sRqpbt7I7nZ6o8CuyqHDLjbO9VzE0p ovBshTfoyo
| g9XGcQHwTmWn4bdnsh2I1x3gQpaqxdRs4vnKmXJ9GvC/sYla0GYXyD
| ecpgjITqx3QA6aKx9+EVh/o6owYTHXaToVkP7U5m8cqaloQFfA8HLsGDg
| 9A0QaMt ixnX7KtT/ZvKFMcazRJ1GX42UaeuO1opZKtjBHLtm
| aPadNeZdD77VytwY2UHeW5Q
| Snfpos7IxUTATpd6KTWUV3snVQnyiltCI1BHJC01sWePAgMBAAE=
| -----END PUBLIC KEY-----
|
| * https://www.scottbrady91.com/openssl/creating-rsa-keys-
| using...
|
| * 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).
| tiffanyh wrote:
| Is it a coincidence the generated keys start with the
| same first 3 letters ("MII...")?
| kstrauser wrote:
| 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."
| tiffanyh wrote:
| Seems like this would be susceptible to an Inference
| Attack.
| nullc wrote:
| > 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.
| throw0101a wrote:
| 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.
| nullc wrote:
| 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.
| jshier wrote:
| 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-...
| prussian wrote:
| 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.
| milliams wrote:
| 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?
| Arnavion wrote:
| 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.
| milliams wrote:
| Thanks for the information. That's pretty embarrassing
| that it's still not supported.
| akulbe wrote:
| 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.
| botanical wrote:
| 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
| throwaway9870 wrote:
| 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.
| frabert wrote:
| I think it was Nintendo who put Rambus DRAM in the N64
| snuxoll wrote:
| The N64 did use Rambus RDRAM, but the PS3 also used
| Rambus XDR memory.
| tptacek wrote:
| 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.
| rdtsc wrote:
| 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.
| kstrauser wrote:
| 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.
| mastax wrote:
| 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.
| sweis wrote:
| Rambus bought Cryptography Research about 12 years ago:
| https://www.rambus.com/rambus-completes-acquisition-of-
| crypt...
| brohee wrote:
| 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.
| throw0101a wrote:
| That particular curve was chosen for specific technical
| reasons:
|
| * https://en.wikipedia.org/wiki/Curve448
| DiabloD3 wrote:
| 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.
| tptacek wrote:
| 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.
| enbugger wrote:
| What are the downsides of this?
| rollcat wrote:
| If you use OpenSSH (wink), please consider donating to OpenBSD,
| aka the upstream developers:
| https://www.openbsd.org/donations.html
| guerrilla wrote:
| It's nice to see that they take this seriously. I praise their
| risk aversion.
| FiloSottile wrote:
| 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.
| CodesInChaos wrote:
| Why does the server side need support for that? Is it the
| ping/pong feature mentioned in the OpenSSH announcement?
| [deleted]
| jsanford wrote:
| With the new default ObscureKeystrokeTiming setting, a single
| typed character now causes hundreds of packets on the wire
| instead of 3.
___________________________________________________________________
(page generated 2023-10-04 23:02 UTC)