similar to: Defeating Timing Attacks

Nicolas, The timing attack described in the paper by Dawn Song et al. works by examining the timing of keystrokes. Currently OpenSSH sends a packet every time you press a key, thus it is possible to capture the approximate inter-keystroke timing of a user (they found minimal overhead in time from a key press to packet sent). Our patch causes a packet to be sent every 50 ms regardless of whether

Hi folks. FYI: There's a discussion[0] about keystroke timing attacks against SSH going on on the cryptography mailing list. Would be interesting to hear the opinion of some OpenSSH folks what SSH/OpenSSH is doing against this and what could maybe be don in addition. Especially since the main idea behind the attack is obviously not limited to the initial authentication phase when a password

Hello, In response to the timing analysis attacks presented by Dawn Song et. al. in her paper http://paris.cs.berkeley.edu/~dawnsong/ssh-timing.html we at Silicon Defense developed a patch for openssh to avoid such measures. Timing Analysis Evasion changes were developed by C. Jason Coit and Roel Jonkman of Silicon Defense. These changes cause SSH to send packets unless request not to,

Hello, In response to the timing analysis attacks presented by Dawn Song et. al. in her paper http://paris.cs.berkeley.edu/~dawnsong/ssh-timing.html we at Silicon Defense developed a patch for openssh to avoid such measures. Timing Analysis Evasion changes were developed by C. Jason Coit and Roel Jonkman of Silicon Defense. These changes cause SSH to send packets unless request not to,

Hi All. Attached is a patch against OpenBSD, based in part on the owl-always-auth patch. The idea is that the only way out of auth_passwd for the failure case is the "return 0" at the bottom. I don't know if this is a good way to do it or not, it's presented for discussion. Also, I don't think 3.6.1p2 is quite right WRT these timing issues (eg, you get a fast failure

Hello, i have a question regarding SCTP support of OpenSSH. (I have searched the list, and it seems to show up periodically every two years, and since it's that time again i dare to ask...) It can't be described better than what i've placed in a bug report yesterday, so please let me (mostly) copy & paste that: Hello. I don't know how you do it, i never managed a(n

Dear colleagues, I have a question about this commit: https://github.com/openssh/openssh-portable/commit/e9d910b0289c820852f7afa67f584cef1c05fe95#diff-a25e40214ca9c9f78abce22f23bf2abdb2a24384c6610d60bbb314aed534eb48R216 The function ensure_minimum_time_since effectively doubles the time spent in the input_userauth_request (mostly presumably in PAM). So if PAM processing is really slow, it will

Dear colleagues, May I ask you to explain whether I am wrong in my conclusions? On Wed, Apr 12, 2023 at 11:55?AM Dmitry Belyavskiy <dbelyavs at redhat.com> wrote: > > Dear colleagues, > > I have a question about this commit: > >

Hi all, Over the past 10 years, there has been some discussion and several patches concerning keystroke timing being revealed by the timing of openssh packet network transmission. The issue is that keystroke timing is correlated with the plaintext, and openssh users expect their communications to be kept entirely secret. Despite some excellent ideas and patches, such as Jason Coit's

On 25.04.24 17:15, openssh-unix-dev-request at mindrot.org digested: > Subject: how to block brute force attacks on reverse tunnels? > From: Steve Newcomb <srn at coolheads.com> > Date: 25.04.24, 17:14 > > For many years I've been running ssh reverse tunnels on portable Linux, > OpenWRT, Android etc. hosts so they can be accessed from a server whose > IP is stable

For many years I've been running ssh reverse tunnels on portable Linux, OpenWRT, Android etc. hosts so they can be accessed from a server whose IP is stable (I call such a server a "nexus host"). Increasingly there's a problem with brute force attacks on the nexus host's tunnel ports. The attack is forwarded to the portable tunneling host, where it fails, but it chews up

Dear Peter, I'm trying to balance the original problem statement (protection from users enumeration) and avoid doubling time here if the process has already taken a long time to provide faster auth method iteration. I believe that a better solution is to set some arbitrary (probably configurable) timeout and, in case when we spend more time than that value, avoid doubling it. On Wed, Jun 28,

Dmitry Belyavskiy wrote: > May I ask you to explain whether I am wrong in my conclusions? I guess it's not clear what problem you are trying to solve. //Peter

[I know this is the 'port' list, but I can't find a better place to post this, and with the garbage going on @slashdot I figured I'd get this out. This belongs on sci.crypt or a general OpenSSH mailing list] First, a quick rehash of stuff everyone here already knows, OpenSSH can use two major forms of authentication: 1. Password 2. RSA keys The RSA method is good because it

We had an incident recently where an openssh client and server were replaced with trojanned versions (it has SKYNET ASCII-art in the binary, if anyone's seen it. Anyone seen the source code ?). The trojan ssh & sshd both logged host/user/password, and probably had a login backdoor. Someone asked me what was their exposure if they used public/private keys instead of passwords. My

Somebody please forward this, if this is not an appropiate place to ask the OpenSSH developers for a new feature. As many of us have seen, any sshd left open on the internet eventually becomes the target of password guessing attacks. I am aware of tools for scanning the security logs, and manipulating iptables to block ongoing attacks, but I am not aware of a way to configure sshd itself to

OpenSSH 3.6.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or

OpenSSH 3.6.1 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or

OpenSSH 3.6 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or

OpenSSH 3.6 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or