4 ms·

After EC DRBG who cares about what NIST does?

by artemonster 4y ago

e4m2 4y ago
Those who have to comply with their standards (e.g. FIPS 140-3), at the very least.
- cipherboy 4y ago
  OP does have a point though, especially with DJB's thoughts (and others) on the matter. https://nitter.net/hashbreaker?lang=en https://nitter.net/hashbreaker?lang=en For FIPS in particular, they've first gotta sunset the traditional algorithms for anyone to strictly need to care (and even then, parallel constructions of PQC+traditional could let other PQC algorithms in -- like the Chrome experiments -- from a FIPS perspective, you can treat the PQC like plaintext). And for them to be useful, adoption needs to occur in the IETF communities (PKIX, TLS, SSH, IKE, ...). You're probably looking at least 5 years on the adoption window to customers running the lastest updates. NIST's blessing might help some of the IETF conversations that now need to happen. But not listening to DJB, given his track record, likely will anger a subset of IETF contributors and might hinder adoption. It'll be interesting to see if IETF takes the more conservative approach advocates by DJB or if they continue on with NIST's blessing alone. But I'm just a watcher... :-) Edit: and for the record, FIPS never mandated Dual EC DRBG but it was still a mistake for NIST to rubber stamp.
  - Aachen 4y ago
    You've linked the entire profile, I guess you're referring to this tweet list? https://nitter.net/hashbreaker/status/1548359451752640520#m https://nitter.net/hashbreaker/status/1548359451752640520#m
    - cipherboy 4y ago
      Ah sorry, correct.
  - westurner 4y ago
    From https://news.ycombinator.com/item?id=31995535 https://news.ycombinator.com/item?id=31995535 : > (IDK what the TLS (and FIPS) PQ Algo versioning plans are: 1.4, 2.0?) Kyber, NTRU, {FIPS-140-3}?
    - cipherboy 4y ago
      Sorry, reading NIST is worse than reading tea leaves and I don't actively participate in the IETF TLS mailing lists enough to say any more than the next person :-) Just stating that the process (NIST to enterprise customer) takes time for complete PQC adoption across the entire stack.
      - westurner 4y ago
        It shouldn't take long to change software: how long does it take to add a dependency on an open implementation and add an optional config file const pending a standardized list of algos like TLS 1.3+ and FIPS, and fallback to non-PQ; like DNSSEC (edit: and WPA2+WPA3)? Do mining rig companies that specialize in ASICs and FPGAs yet offer competitively-priced TLS load balancers -- now with PQ -- or are they still more expensive than mainboards?
mort96 4y ago
Well, we know which algorithms to avoid now.
api 4y ago
I don't take that as seriously. EC DRBG was ham-fisted and ridiculous. The mere idea of using EC, a slow heavy algorithm, for a random number generator was absurd out of the starting gate and the trap door function aspect instantly made everyone suspicious. The obvious choice for a NIST primitive built PRNG is AES, SHA2, SHA3, or some combination thereof, and there is nothing to argue for ECC in that role at all. It looks more like a frantic attempt to get a back door into crypto in response to some post-9/11 mandate from a technically ignorant Congress than evidence for the hyper-competent super-intelligent NSA of Hollywood fiction. Congress: "Backdoor crypto but don't tell anyone!" NSA: "Won't work. Cryptographers will notice." Congress: "We just added it as a line item buried in a bill about regulating the crunchiness of pork rinds. It's now a legal mandate." NSA: "Okay, but people are gonna notice because math is math." Congress: "Here's a billion dollars. Now go make a different math. Call it freedom math." The rest of NIST's portfolio looks relatively sane. AES, SHA2, and SHA3 have received years and years of heavy duty cryptanalysis and have enormous implicit "bug bounties" on them by virtue of what one could steal if they could be effectively attacked. The NIST ECC curves are a frequent target of speculation about being backdoored but I've seen several cryptographers argue that if they are it means we really shouldn't use ECC at all. It would mean the NSA knows something very significant about ECC that is still after all these years (the NIST curves are two decades old) far beyond what the academic community knows. Are there better things today outside NIST? To some extent. ARX ciphers and hashes have become immensely popular. They have the really nice properties of being efficient without special hardware (unlike AES) and being fairly side channel resistant. AES is still massively faster (2-4X) with hardware support though. In terms of cryptographic strength ChaCha has some theoretical advantages due to the wide (512-bit) state vector but neither AES nor ChaCha have anything that even smells like a practical attack against common (correct) use cases. In practice they're probably about the same. Unless your cryptographic design is just broken or unless you are using a very weak cipher like single-DES or RC4, you are many many orders of magnitude more likely to be attacked via a bug in the implementation, a side channel, supply chain attacks, or some form of automated or targeted social engineering (phishing, spear phishing, social engineering, etc.). It's usually easier to con humans than break cryptography. Edit: what the Snowden documents mostly showed is that the NSA has a huge trove of zero day exploits and that they tend to hoard them. They're sort of like a multi billion dollar state backed hacking group and most of what they do is not unlike what organized crime hacking groups do. We also know that the NSA has relationships with industry. With so much reliance on cloud services and man-in-the-middle CDNs like Cloudflare the obvious way to compromise stuff would be to directly tap systems where they are not encrypted at all. You might have Wireguard with extra hipster super cryptography but who cares if the NSA can download everything from "your" cloud or push malware to your machine via any one of the dozens of package managers you implicitly trust?

After EC DRBG who cares about what NIST does?

e4m2 4y ago

Those who have to comply with their standards (e.g. FIPS 140-3), at the very least.

cipherboy 4y ago
OP does have a point though, especially with DJB's thoughts (and others) on the matter. https://nitter.net/hashbreaker?lang=en https://nitter.net/hashbreaker?lang=en For FIPS in particular, they've first gotta sunset the traditional algorithms for anyone to strictly need to care (and even then, parallel constructions of PQC+traditional could let other PQC algorithms in -- like the Chrome experiments -- from a FIPS perspective, you can treat the PQC like plaintext). And for them to be useful, adoption needs to occur in the IETF communities (PKIX, TLS, SSH, IKE, ...). You're probably looking at least 5 years on the adoption window to customers running the lastest updates. NIST's blessing might help some of the IETF conversations that now need to happen. But not listening to DJB, given his track record, likely will anger a subset of IETF contributors and might hinder adoption. It'll be interesting to see if IETF takes the more conservative approach advocates by DJB or if they continue on with NIST's blessing alone. But I'm just a watcher... :-) Edit: and for the record, FIPS never mandated Dual EC DRBG but it was still a mistake for NIST to rubber stamp.
- Aachen 4y ago
  You've linked the entire profile, I guess you're referring to this tweet list? https://nitter.net/hashbreaker/status/1548359451752640520#m https://nitter.net/hashbreaker/status/1548359451752640520#m
  - cipherboy 4y ago
    Ah sorry, correct.
- westurner 4y ago
  From https://news.ycombinator.com/item?id=31995535 https://news.ycombinator.com/item?id=31995535 : > (IDK what the TLS (and FIPS) PQ Algo versioning plans are: 1.4, 2.0?) Kyber, NTRU, {FIPS-140-3}?
  - cipherboy 4y ago
    Sorry, reading NIST is worse than reading tea leaves and I don't actively participate in the IETF TLS mailing lists enough to say any more than the next person :-) Just stating that the process (NIST to enterprise customer) takes time for complete PQC adoption across the entire stack.
    - westurner 4y ago
      It shouldn't take long to change software: how long does it take to add a dependency on an open implementation and add an optional config file const pending a standardized list of algos like TLS 1.3+ and FIPS, and fallback to non-PQ; like DNSSEC (edit: and WPA2+WPA3)? Do mining rig companies that specialize in ASICs and FPGAs yet offer competitively-priced TLS load balancers -- now with PQ -- or are they still more expensive than mainboards?

mort96 4y ago

Well, we know which algorithms to avoid now.

api 4y ago

I don't take that as seriously. EC DRBG was ham-fisted and ridiculous. The mere idea of using EC, a slow heavy algorithm, for a random number generator was absurd out of the starting gate and the trap door function aspect instantly made everyone suspicious. The obvious choice for a NIST primitive built PRNG is AES, SHA2, SHA3, or some combination thereof, and there is nothing to argue for ECC in that role at all. It looks more like a frantic attempt to get a back door into crypto in response to some post-9/11 mandate from a technically ignorant Congress than evidence for the hyper-competent super-intelligent NSA of Hollywood fiction. Congress: "Backdoor crypto but don't tell anyone!" NSA: "Won't work. Cryptographers will notice." Congress: "We just added it as a line item buried in a bill about regulating the crunchiness of pork rinds. It's now a legal mandate." NSA: "Okay, but people are gonna notice because math is math." Congress: "Here's a billion dollars. Now go make a different math. Call it freedom math." The rest of NIST's portfolio looks relatively sane. AES, SHA2, and SHA3 have received years and years of heavy duty cryptanalysis and have enormous implicit "bug bounties" on them by virtue of what one could steal if they could be effectively attacked. The NIST ECC curves are a frequent target of speculation about being backdoored but I've seen several cryptographers argue that if they are it means we really shouldn't use ECC at all. It would mean the NSA knows something very significant about ECC that is still after all these years (the NIST curves are two decades old) far beyond what the academic community knows. Are there better things today outside NIST? To some extent. ARX ciphers and hashes have become immensely popular. They have the really nice properties of being efficient without special hardware (unlike AES) and being fairly side channel resistant. AES is still massively faster (2-4X) with hardware support though. In terms of cryptographic strength ChaCha has some theoretical advantages due to the wide (512-bit) state vector but neither AES nor ChaCha have anything that even smells like a practical attack against common (correct) use cases. In practice they're probably about the same. Unless your cryptographic design is just broken or unless you are using a very weak cipher like single-DES or RC4, you are many many orders of magnitude more likely to be attacked via a bug in the implementation, a side channel, supply chain attacks, or some form of automated or targeted social engineering (phishing, spear phishing, social engineering, etc.). It's usually easier to con humans than break cryptography. Edit: what the Snowden documents mostly showed is that the NSA has a huge trove of zero day exploits and that they tend to hoard them. They're sort of like a multi billion dollar state backed hacking group and most of what they do is not unlike what organized crime hacking groups do. We also know that the NSA has relationships with industry. With so much reliance on cloud services and man-in-the-middle CDNs like Cloudflare the obvious way to compromise stuff would be to directly tap systems where they are not encrypted at all. You might have Wireguard with extra hipster super cryptography but who cares if the NSA can download everything from "your" cloud or push malware to your machine via any one of the dozens of package managers you implicitly trust?