Re: [Cfrg] Fwd: I-D Action: draft-yonezawa-pairing-friendly-curves-01.txt

[John Mattsson <[e-mail]>]

The US Suite B were, and the CNSA suite are, approved to protect information up to the TOP SECRET level. Such information is to my knowledge often protected for 50 years, in extraordinary case for 75 years, and after special permission for more than 75 years.

That NSA is not planning to require US governments to use of PQC before 2022/2024 would suggest that they do not expect quantum computers capable of breaking P-384 and RSA-3072 to be available to any foreign government before 2024 + 50/75 years... 

Looking how e.g. the PKI industry has acted in the past with e.g. RSA-1024 and SHA-1, my prediction is that many deployments  will continue to use non-PQC until someone has built or is very close to building a quantum computer capable of breaking current ECC and RSA....  

-----Original Message-----
From: Cfrg <[e-mail]> on behalf of "Blumenthal, Uri - 0553 - MITLL" <[e-mail]>
Date: Wednesday, 3 April 2019 at 18:45
To: Watson Ladd <[e-mail]>
Cc: cfrg <[e-mail]>
Subject: Re: [Cfrg] Fwd: I-D Action: draft-yonezawa-pairing-friendly-curves-01.txt

    On 4/3/19, 10:59 AM, "Watson Ladd" <[e-mail]> wrote:
        > On Wed, Apr 3, 2019 at 7:54 AM Blumenthal, Uri - 0553 - MITLL
        > <[e-mail]> wrote:
        >>
        >> In short, the problem is that one group of people accepts the risks for another group of people.
        >>
        >> As one of back officials said in a private discussion: "Your risk is always lower than our cost."
        >
        > If you don't like these protocols, don't use them. 
    
    This approach would work just fine for protocols and algorithms like PGP. This would absolutely not work for protocols like TLS. I leave it for you to figure why.
    
        > I really do not understand the issue here:
    
    I can see that. ;-)
    
        > ...pairings provide all sorts of efficiencies
        > and nice protocols that we cannot get other ways.
    
    That is true, and nobody is disputing it.
    
        > The argument that
        > now we need to stop doing some kinds of cryptography because in some
        > as of yet unknown timeframe quantum computers will break all the
        > schemes (ignoring the difference between authentication and
        > encryption) made as much sense in 1996 as it does today.
        > And yet today it is problem but was not in 1996?
    
    Some people tend to think that now, in 2019, the threat to crypto by quantum computers is much closer to reality than it was 23 years ago (to remind, DES was deployed with expectation of 15 years of life). 
    
    They think that since sensitive data tends to "maintain its value, the time for designing new non-quantum-resistant algorithms is coming to an end. Because when you factor in (no pun intended :) the time for commercial implementation and deployment, what's left for the actual use of the algorithm would be too short to justify the effort spent on it.
    
    Other people tend to think that there's no way quantum computers could become a threat in the near/foreseeable future (10-20-30 years, some say 50+, whatever).
    
    Yet others say "yeah, maybe - but due to the cost etc. of such devices, the risk applies mainly to high-level government communications, the majority of the population would still be safe for a long time even after these devices are actually made."
    
    Which camp got it right?
    
        > TLS 1.3 does not have any post-quantum ciphersuites. 
    
    For TLS the update is trivially simple - though you probably saw for yourself that even such a simple thing takes huge time and effort to deploy the fix/update to the majority. We'll probably see PQ ciphersuites after NIST PQC competition concludes. Google has been experimenting with PQ algorithms/protocols for a couple of years now, if not longer. 
    
    This still doesn't deal with the "golden oldies" - valuable data secured with the old stuff...
    
        > The answer here is a good security considerations section.
    
    For a nerd deciding what to play with - sure. For a consumer who uses whatever's provided to connect to his account at Amazon/Deutsche Bank/etc. - hardly.
    
    P.S. You used to express opinion that developers screw up implementations even when guiding documents are pretty decent. What made you change your mind? ;-)
    
    _______________________________________________
    Cfrg mailing list
    [e-mail]
    https://www.irtf.org/mailman/listinfo/cfrg