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

31–40 of 60 posts

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#31

Post by throw0101a »

isilofi wrote: post #26
throw0101a wrote: post #10

Earlier quoted context omitted.

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

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.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#32

Post by frabert »

throwaway9870 wrote: post #19
botanical wrote: post #7

Earlier quoted context omitted.

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

I think it was Nintendo who put Rambus DRAM in the N64

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#33

Post by [deleted] »

CodesInChaos wrote: post #30
FiloSottile wrote: post #20

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) d…

Why does the server side need support for that? Is it the ping/pong feature mentioned in the OpenSSH announcement?

[deleted]

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#35

Post by akulbe »

jshier wrote: post #14
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-...

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.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#36

Post by isilofi »

throw0101a wrote: post #31
isilofi wrote: post #26

Earlier quoted context omitted.

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.

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.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#37

Post by prussian »

jshier wrote: post #14
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-...

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.

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#38

Post by throw0101a »

isilofi wrote: post #36
throw0101a wrote: post #31

Earlier quoted context omitted.

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.

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.

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:

    SECRET KEY:
    9d61b19deffd5a60ba844af492ec2cc44449c5697b326919703bac031cae7f60
    
    PUBLIC KEY:
    d75a980182b10ab7d54bfed3c964073a0ee172f3daa62325af021a68f707511a
RFC 8032 § 7.4. Test Vectors for Ed448

    SECRET KEY:
    6c82a562cb808d10d632be89c8513ebf6c929f34ddfa8c9f63c9960ef6e348a3
    528c8a3fcc2f044e39a3fc5b94492f8f032e7549a20098f95b

    PUBLIC KEY:
    5fd7449b59b461fd2ce787ec616ad46a1da1342485a70e1f8a0ea75d80e96778
    edf124769b46c7061bd6783df1e50f6cd1fa1abeafe8256180
A comparable RSA 3072 key is much longer:

    -----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://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).

Re: OpenSSH 9.5 released with keystroke timing obfuscation

#39

Post by DiabloD3 »

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

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.

Post reply on HN