Hostly, most cryptographic vulnerability today are because things are stuck in the NIST and FIPS regulation. Most vulnerable building blocks are still shipped to have their certification to begin with. Why there's still excitement to their work?
Cryptographic Right Answers: Post Quantum Edition
31–40 of 61 posts
Re: Cryptographic Right Answers: Post Quantum Edition
#32As I understand it, the only reason pqc is of "practical" concern is the issue of "store now, decrypt later". Is it possible to defend against this attack in a classical way? Some sort of time limit on decryption? Or an argument that it's impossible?
Strong pre-shared keys will continue to remain secure, even against a quantum computer.
Wireguard, for example, provides the ability to add a pre-shared key for endpoints, which it mixes in during key exchange. Wireguard sessions collected under such a configuration should remain safe when attacked by a future quantum computer, assuming that the shared keys remain secret.
Pre-shared keys are just inconvenient to handle safely.
Re: Cryptographic Right Answers: Post Quantum Edition
#33I've always found it a bit disquieting how many times people feel the need to update these "cryptographic right answers" blog posts. This is what, a fourth or fifth version since 2009? Meanwhile everything from ubuntu's apt-get to my connection to HN is secured with 2048-bit RSA - an algorithm invented in 1977 and in widespread use since at least 1995. Am I getting crypto advice that will keep my data safe for 30+ ye…
The “right answer” also depends on attack vector. If you are trying to protect against nation-state-level tampering or data leaks for two full generations, the enemy moves much quicker, and so you will need to advance much more quickly, to outpace what you think they might do to outpace you in the future. If you are only trying to prevent your ISP from seeing your traffic, which they are not trying particularly hard…
> If you are trying to protect against nation-state-level tampering or data leaks for two full generations, the enemy moves much quicker, and so you will need to advance much more quickly
It's supposed to protect my users' data for two full generations, but the advice is only good for 3 years?
Re: Cryptographic Right Answers: Post Quantum Edition
#34As I understand it, the only reason pqc is of "practical" concern is the issue of "store now, decrypt later". Is it possible to defend against this attack in a classical way? Some sort of time limit on decryption? Or an argument that it's impossible?
Strong pre-shared keys will continue to remain secure, even against a quantum computer. Wireguard, for example, provides the ability to add a pre-shared key for endpoints, which it mixes in during key exchange. Wireguard sessions collected under such a configuration should remain safe when attacked by a future quantum computer, assuming that the shared keys remain secret. Pre-shared keys are just inconvenient to hand…
> Pre-shared keys are just inconvenient to handle safely.
You can transfer PSKs safely and easily with OpenSSH 9.0 (released 2022-04-08) or later, which uses sntrup761x25519-sha512@openssh.com as the default key exchange method.
Re: Cryptographic Right Answers: Post Quantum Edition
#35>Avoid: HMAC-MD5, HMAC-SHA1 and such. The underlying hash function has to be safe. Interestingly enough, there is a proof out there that more or less states the opposite for HMAC-MD5 and HMAC-SHA1: * https://eprint.iacr.org/2006/043.pdf The issue here is that MD5 and SHA1 are broken for collisions. But no one could figure out an actual attack for HMACs based on them. The linked paper is an attempt to explain that.
[deleted]
Re: Cryptographic Right Answers: Post Quantum Edition
#36Hostly, most cryptographic vulnerability today are because things are stuck in the NIST and FIPS regulation. Most vulnerable building blocks are still shipped to have their certification to begin with. Why there's still excitement to their work?
[deleted]
Re: Cryptographic Right Answers: Post Quantum Edition
#37>Avoid: HMAC-MD5, HMAC-SHA1 and such. The underlying hash function has to be safe. Interestingly enough, there is a proof out there that more or less states the opposite for HMAC-MD5 and HMAC-SHA1: * https://eprint.iacr.org/2006/043.pdf The issue here is that MD5 and SHA1 are broken for collisions. But no one could figure out an actual attack for HMACs based on them. The linked paper is an attempt to explain that.
[deleted]
Re: Cryptographic Right Answers: Post Quantum Edition
#38Earlier quoted context omitted.
Strong pre-shared keys will continue to remain secure, even against a quantum computer. Wireguard, for example, provides the ability to add a pre-shared key for endpoints, which it mixes in during key exchange. Wireguard sessions collected under such a configuration should remain safe when attacked by a future quantum computer, assuming that the shared keys remain secret. Pre-shared keys are just inconvenient to hand…
> Pre-shared keys are just inconvenient to handle safely. You can transfer PSKs safely and easily with OpenSSH 9.0 (released 2022-04-08) or later, which uses sntrup761x25519-sha512@openssh.com as the default key exchange method.
If your threat model includes someone with a quantum computer intercepting all of your traffic and storing it to decrypt later, you probably don't want to share your keys over a non-PQC channel unless you can guarantee that they haven't started eavesdropping on your traffic yet.
Re: Cryptographic Right Answers: Post Quantum Edition
#39As I understand it, the only reason pqc is of "practical" concern is the issue of "store now, decrypt later". Is it possible to defend against this attack in a classical way? Some sort of time limit on decryption? Or an argument that it's impossible?
Have crypto agility, so that when you want to transition algorithms, the move will be as seamless as possible. You can start to use a blended or hybrid crypto today, where you simultaneously use both classical and pqc algorithms. For your classical algorithms, you should adjust your keys' security strength in accordance with your threat model. See CNSA 2.0 for a starter reference. For data in motion, you can use two VPNs, configured appropriately.
There are a number of things you can do today, more than I listed. I suggest you discuss with an appsec person who is familiar with your threat model.
Re: Cryptographic Right Answers: Post Quantum Edition
#40“Classical cryptography” used to refer to historical ciphers, Vigenère and the like, tapering off after the World War 2-era cipher machines and definitely not used to describe asymmetric algorithms. There should be a different term for pre- (non-?) quantum cryptography from the modern era. We already suffered the redefinition of “crypto”.
It's a reasonable point but this would probably be a losing battle; at this point terms like "classical security", "classical adversaries", etc. are common in the literature.
To me what's worse is "zk" used to describe applications of verifiable computation with no secrets involved, but that seems like a losing battle also.