@TheGibson Absolutely can't be cracked. Let's get on with it.

@TheGibson We should be acting like the NSA has had quantum computing for years now. They have unlimited budgets and the smartest people in the world working there.

We should all be acting like RSA and every linear crypto algorithm can be cracked instantly.

@Ricardus @TheGibson eh, I work in quantum computing and I'm not really worried about this being a problem any time soon

@ngp @Ricardus I hope you're right... I do know that preparations for this have been ongoing for the last 4 yrs. at least... ultimately it will just be a change to resistant suites...

@thegibson OAEUX YWIZW ALTOI JIAXB ZFOAE UXYWI ZWALT

@thegibson Mmm.. I think we'll be OK with some sacrifices. There are a few signature schemes (like Lamport/Merkel) that would survive, and I think the original patents have run out on NTRU by now. TIL that NTRU is used by default by OpenSSH since v.9!

@seachaint @TheGibson I think the NTRU usage is transparent with any ed25519 key! It's "just" an extension of the c25519 key exchange, if I read the notes correctly.

@eqe @thegibson I don't know the details, but the change log makes it sound like the two methods are being used for redundancy rather than to complement one another. So yea, they're extending an existing key exchange with a quantum-resistent wrapper? But it's still a pubkey-based method so one assumes the new SSH "keypairs" would actually be pairs-of-keypairs?

@seachaint @TheGibson Wikipedia has a decent overview
en.wikipedia.org/wiki/NTRU
There are two areas of concern for quantum decryption, either the attacker can get the private key and impersonate, or the attacker can break the ECDH exchange to get the session key.

Based on the "record then decrypt" mentioned in the notes, openssh appears to be concerned about session key recovery. That appears to be the more feasible attack for practical QC, too.

The way you add a pqcrypto (post quantum cryptography) safety layer to an existing DH style exchange is, you keep the current exchange as is, and you also do a second exchange in parallel using the PQ-secure algorithm. Then you have 2 session keys, s1 protected using ed25519 and s2 protected using ntruencrypt, and you combine them into the final session key s. As long as the combiner is safe, and either s1 or s2 is protected, this gives dual security.

In short, I don't see any reason why this change would require new pubkeys.

@signal9 @thegibson Yep, the backdoor will be the come over and knock on my back door, and I ask them "How did you get past the attack chicken?"

@thegibson wasn't google proud of having computed 3+3 on a quantum computer a few years ago ?? Time flies pfew.

Sign in to participate in the conversation
hackers.town

A bunch of technomancers in the fediverse. This arcology is for all who wash up upon it's digital shore.