Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
What would you suggest to keep private key material in a safe place? There are rumors that even material stored as not extractable in Nitrokey Pro still can be extracted by side channels like electromagnetic emission. Would running all Internet communication end points on low powered Cortex A7 (immune to Spectre) single boards with a NitroKey like device help? May be need to add optical convertors here to avoid a long Ethernet antenna? Can Nitrokey Pro be used to keep SSHD private key on a server running OpenBSD? On Linux it seems to be possible: https://support.nitrokey.com/t/can-nitrokey-pro2-be-used-in-openbsd-with-ssh-and-gpg/2347/16 Please confirm if Nitrokey Pro can be used on OpenBSD current or 6.7 for keeping both client and server private keys ?
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
Some time ago Google bought 2000qbit version from D-wave and confirmed it is a quantum computer bla bla bla... but cluster consists of eight qbit blocks to build advertised capacity if I understand googles papers right. My question was about decrypting currently generated and accumulated encrypted traffic after five - ten years on quantim computers if they were available. And which crypto algo. I have to use right now to prevent decryption in post quantum computing era. Martin ‐‐‐ Original Message ‐‐‐ On Saturday, May 9, 2020 2:34 PM, wrote: > D-waves has too uncoupled qubits if I understand it correctly, it is nothing > to do about qubits quantity as we used to think about it. Like a "cluster" of > completely isolated hosts (which is already not a cluster or course).
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On Sat, May 9, 2020 at 1:05 PM Kevin Chadwick wrote: > Careful of what sources you trust! If a processor was storing the keys used, > non > volatile then people would have found out. Software encryption wouldn't save > you > either. If there is a back door it won't have anything to do with AES-NI that > can be analysed so easily. Indeed -- human based key compromise issues severely outweigh the risk of direct attacks on a tcp session with encrypted content. That said, the risk with encrypted material here is not attacks on individual sessions but opportunistic attacks on large bodies of sample material (with, of course, human assist which will often have economic basis and vectors). (That said, I would also keep in mind also that supposedly the computer industry has hit a performance wall because of Moore's Law issues. But, assuming that there's a thread of truth in the marketing, we also have reason to believe that 5G switches at speeds an order of magnitude faster than anything we see on computer busses. So it's not just about the size of the transistors. And, sure, there's real issues there, but I think we have to assume that some of what we're hearing about computational abilities and limits isn't completely factual.) Thanks, -- Raul
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 16:25, i...@aulix.com wrote: > Note: Since these MS / U.S. government keys are deeply sticking in Intel XEON > processor hardware, it doesn’t play a role, what other OS you install or boot > afterwards: Debian/UBUNTU Linux, OpenBSD, … If your software uses Intel > AES-NI hardware encryption, all encrypted packets ingoing, outgoing - then > automatically contain that U.S. government backdoor! Careful of what sources you trust! If a processor was storing the keys used, non volatile then people would have found out. Software encryption wouldn't save you either. If there is a back door it won't have anything to do with AES-NI that can be analysed so easily. I'm conscious of being far from OpenBSD relevance, so excluding myself from this thread now.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
Though I am a very noob in understanding crypto from a mathematical point of view (not just as an user of some ready program) IMHO following message can contain some truth about insecurity and intentional flaws of hardware crypto in X86 CPUs: https://support.nitrokey.com/t/spectre-or-meltdown-vulnerability/850 https://archive.fo/bF0gg Note: Since these MS / U.S. government keys are deeply sticking in Intel XEON processor hardware, it doesn’t play a role, what other OS you install or boot afterwards: Debian/UBUNTU Linux, OpenBSD, … If your software uses Intel AES-NI hardware encryption, all encrypted packets ingoing, outgoing - then automatically contain that U.S. government backdoor!
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 14:34, i...@aulix.com wrote: > D-waves has too uncoupled qubits if I understand it correctly, it is nothing > to do about qubits quantity as we used to think about it. Like a "cluster" of > completely isolated hosts (which is already not a cluster or course). I don't care for the details. D-waves tech has no hope of breaking any crypto in use today is what I have heard from reputable sources. Googles needs to go from 53 to an estimated more than 3000 for nistp-521 with each one being exponentially harder to manage. RSA 8192/4096 are the next best options but RSA takes exponentially longer to generate larger keys. Don't worry. The work is to be ready in case someone with enough funds makes a breakthrough. There is almost zero chance for many many years. You can always mix in a static symmetric key, if really needed or encrypt the data first with a static key? Wireguard offers mixing in a static key as an optional extra config option but wireguard has chosen not to support AES, so will be a lot slower on many modern processors and microchips that have AES hw support. The wireguard author seems to think the opposite about micro support, but he is wrong.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 14:31, i...@aulix.com wrote: > guessed by quantum provided session symmetric cipher is strong enough? Quantum does not break any in use today and AES-256 symmetric is expected to be quantum resistant in any case. I personally prefer AES-256 ctr over the more complex GCM. I am not a developer btw.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
D-waves has too uncoupled qubits if I understand it correctly, it is nothing to do about qubits quantity as we used to think about it. Like a "cluster" of completely isolated hosts (which is already not a cluster or course).
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
OpenSSH allows to use hybrid mode with many private keys of different type and even stored on different hardware like Nitrokey, Rutoken, etc. at the same time for a single session. E.g. 4 different private keys are required (say Nitrokey, Rutoken ECP2, Curve25519 and Postquantum one): AuthenicationMethods=publickey,publickey,publickey,publickey Will it prevent session analysis if only some part of keys (not all) were leaked or guessed by quantum provided session symmetric cipher is strong enough?
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
This one https://www.tomshardware.com/news/d-wave-5000-qubit-first-sale,40470.html is the most powerful 5000qbits quantum computer sells nowadays. Moreother, D-Wave opened online service to access 5000qbit remotely for solving 'special' tasks which can be accelerated using quantum architecture. In 2016 Google tested some encryption sub-layer in Chrome browser to test quantum resistant encryption algo. According to current online data collecting practices, after six years most of 'old' algorithms will possible to decrypt directly from storage by 'modern' quantum computers. Martin ‐‐‐ Original Message ‐‐‐ On Saturday, May 9, 2020 5:05 AM, wrote: > According to Damien Miller: > > > this is pretty much possible now, by enabling the experimental support > > for the XMSS PQ signature algorithm > > in the SSH
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 07:41, Martin wrote: > This one > https://www.tomshardware.com/news/d-wave-5000-qubit-first-sale,40470.html > is the most powerful 5000qbits quantum computer sells nowadays. D-waves definition of qubit is different and their machines will never be capable of breaking public key cryptography using Shor's algorithm. I assume they want free publicity that you are giving them.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 07:41, Martin wrote: > This one > https://www.tomshardware.com/news/d-wave-5000-qubit-first-sale,40470.html > is the most powerful 5000qbits quantum computer sells nowadays. > > Moreother, D-Wave opened online service to access 5000qbit remotely for > solving 'special' tasks which can be accelerated using quantum architecture. > > In 2016 Google tested some encryption sub-layer in Chrome browser to test > quantum resistant encryption algo. > > According to current online data collecting practices, after six years most > of 'old' algorithms will possible to decrypt directly from storage by > 'modern' quantum computers. That last sentence doesn't even make sense but is completely wrong. Decrypt according to? No Googles computer was an impressive jump to 53 qubits but every qubit is exponentially harder to keep stable. The pqcrypto project estimated far longer before an algorithm is broken by a computer and even then I believe they are talking about weaker keys. Not in our lifetime is often mentioned. It is quite possible and in my opinion probable that a nistp-521 key will never be broken by a quantum computer. I assume this is coming from the recent release of code by the PQCrypto project for OpenSSL. The PQCrypto project hasn't concluded yet. You should not use it yet especially without existing crypto too. There are some conservative algorithms that may not win the competition that are arguably useable under certain conditions but that is aside from the point. The one OpenSSH has developed is one of those.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 5/8/20 3:16 PM, Martin wrote: > Which 'quantum' resistant algorithms can be used right now to prevent data > decryption in future by 'quantum' computers (when they can do this) of > currently collected data flows? this is so dumb. worry about this when there are computers which can actually add two numbers quantoonly. aisha > > Martin >
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
According to Damien Miller: >this is pretty much possible now, by enabling the experimental support for the XMSS PQ signature algorithm in the SSH
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
https://www.technologyreview.com/2018/02/21/145300/serious-quantum-computers-are-finally-here-what-are-we-going-to-do-with-them/ https://www.microsoft.com/en-us/research/project/post-quantum-ssh/ https://openquantumsafe.org/ Why not to add post quantum algos to the SSH mainline to make them easily available at once in all up to date distros?
