OpenSSH takes aim at 'capture now, decrypt later' quantum attacks
- Reference: 1649772010
- News link: https://www.theregister.co.uk/2022/04/12/openssh_9/
- Source link:
The popular open-source SSH implementation aims to provide secure communication in a potentially unsecure network environments. While version 9 is ostensibly focused on bug-fixing, there are some substantial changes lurking within that could catch the unwary, most notably, the switch from the legacy SCP/RCP protocol to SFTP by default.
The OpenSSH group warned the change was coming earlier this year, with a deprecation notice in February's version 8.9 release. Experimental support for transfers using the SFTP protocol as a replacement for the SCP/RCP protocol turned up in version 8.7 in August 2021 with the warning: "It is intended for SFTP to become the default transfer mode in the near future."
[2]
The future, it appears, has arrived (at least as far as OpenSSH is concerned) with the defaulting to SFTP, which introduces some potential incompatibilities: gone is the requirement for the "finicky and brittle quoting" used by the legacy SCP/RCP "and attempts to use it may cause transfers to fail," according to the OpenSSH group, which added there was no intention to introduce bug-compatibility for legacy SCP/RCP when using the SFTP protocol (although the -O flag can be used to force scp to use the legacy protocol.)
Hello from the future-ture-ture
However, a bigger nod to the future has come in the form of the use of the "hybrid Streamline NTRU Prime + x25519 key exchange method by default."
"The NTRU algorithm is believed to resist attacks enabled by future quantum computers," explained the team, "and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo."
[3]
[4]
It added: "We are making this change now (ie, ahead of cryptographically-relevant quantum computers) to prevent "capture now, decrypt later" attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available."
Why is IBM selling post-quantum crypto when it's still a pre-quantum company? [5]READ MORE
Nth degree Truncated polynomial Ring Units (NTRU) is a cryptosystem and a contender for securing communication should quantum computers ever turn up in the real world.
[6]Kiss goodbye to privacy forever when brain-implanted comms gear becomes the norm – guru Whit Diffie
[7]Tiny Kobalos malware seen backdooring SSH tools, menacing supercomputers, an ISP, and more – ESET
[8]YOU... SHA-1 NOT PASS! Microsoft magics away demonic hash algorithm from Windows updates, apps
[9]RAMBleed picks up Rowhammer, smashes DRAM until it leaks apps' crypto-keys, passwords, other secrets
OpenSSH clearly thinks they are on the way, as do other organizations; America's National Science Foundation [10]awarded a $715,000 grant to researchers to hunt out gaps in quantum computing security, although last year the US National Security Agency [11]said it "does not know when or even if a quantum computer of sufficient size and power to exploit public key cryptography (a CRQC) will exist."
The move by the OpenSSH team therefore may be a prudent one. After all, who knows what the future might hold? ®
Get our [12]Tech Resources
[1] https://www.openssh.com/releasenotes.html
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YlWiNF@L9ZRfD4p3BrPKGgAAAQA&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YlWiNF@L9ZRfD4p3BrPKGgAAAQA&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YlWiNF@L9ZRfD4p3BrPKGgAAAQA&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2022/04/11/opinion_column_ibm/
[6] https://www.theregister.com/2021/05/17/rsa_cryptography_privacy/
[7] https://www.theregister.com/2021/02/03/kobalos_malware/
[8] https://www.theregister.com/2020/07/29/microsoft_windows_sha_1/
[9] https://www.theregister.com/2019/06/11/rambleed_rowhammer_attack/
[10] https://www.theregister.com/2022/03/18/quantum_us_grant/
[11] https://www.theregister.com/2021/09/01/nsa_quantum_computing_faq/
[12] https://whitepapers.theregister.com/
"legacy" SCP protocol and SFTP
what I am not quite sure about is whether or not the scp command will still work as expected... (or is it JUST the protocol being used that's changing?)
Frequently I specify absolute paths to things to scp around and usually for good reason, such as copying things to an archive on another box.
Sure SFTP is fine too but it may not do exactly what I want. Or is it just the PROTOCOL that is changing>
Given the use of '-O' to keep any existing behaviors I hope nothing truly breaks.
And does this have any effect on rsync? Yeah I use THAT a lot, too.
Re: "legacy" SCP protocol and SFTP
> what I am not quite sure about is whether or not the scp command will still work as expected... (or is it JUST the protocol being used that's changing?)
I had the same thought, so followed the link in the article to the release notes, which say:
This release switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default.
Which I read as saying that the command to be used is still 'scp', just the underlying protocol behind it has changed. However , there are some syntax/usage changes in the file/path specifications due to the underlying protocol being SFTP rather than SCP - I read it that the sshd daemon has an sftp-server built (or bundled with) into it:
Legacy scp/rcp performs wildcard expansion of remote filenames (e.g. "scp host:* .") through the remote shell. This has the side effect of requiring double quoting of shell meta-characters in file names included on scp(1) command-lines, otherwise they could be interpreted as shell commands on the remote side.
This creates one area of potential incompatibility: scp(1) when using the SFTP protocol no longer requires this finicky and brittle quoting, and attempts to use it may cause transfers to fail. We consider the removal of the need for double-quoting shell characters in file names to be a benefit and do not intend to introduce bug-compatibility for legacy scp/rcp in scp(1) when using the SFTP protocol.
Another area of potential incompatibility relates to the use of remote paths relative to other user's home directories, for example - "scp host:~user/file /tmp". The SFTP protocol has no native way to expand a ~user path. However, sftp-server(8) in OpenSSH 8.7 and later support a protocol extension "expand-path@openssh.com" to support this.
When the NSA tells you not to worry...
So someone with a massive interest in being able to decrypt tells us that there's no need to use really, really good encryption?
Hmmmm