Category 5 parameter sets

[Moody, Dustin (Fed)]

All,

NIST has received a complaint regarding some of the text in our 2nd round report, NISTIR 8309.  In particular, the concern centers on NIST "strongly encouraging" the teams that didn't have category 5 parameters to consider adding them.  It was suggested that we should have sought public feedback for this encouragement.  So, we would like to ask the submission teams (and the pqc community more generally) their input on this matter.

 

We want to make clear that adding category 5 parameters is not required, and the decision is left up to the submission teams.  There are 15 submissions that were selected to advance to the 3rd round.  Of these 15, there were 3 that did not claim category 5 parameters:  BIKE, NTRUprime, and Dilithium.  In addition, depending on the model, NTRU may lack category 5 parameters.  We discussed each submission in more detail in the report.  We also want to make it clear that having category 5 parameters (or not having them) did not affect any decisions as to submissions advancing (or not) to the third round.  

 

NIST has not yet determined if it will standardize category 5 parameters.   We suggested that submitters consider adding such parameters for a variety of reasons.  As we've already stated on the forum, being able to add a parameter set that targets category 5 helps to demonstrate flexibility. We also believe there are use cases where users want very high security options (for instance, national security considerations), and consensus in the PQC community seems to be that it would be better for any new parameter sets to be added now rather than after round 3.  We've seen several examples in the PQC process where schemes have been attacked.  Having higher category parameters hedges against future breakthroughs in cryptanalysis and/or computing technology.  In particular, a reason for wanting category 5 parameters is that it facilitates being able to more closely compare submissions.  As almost all of the remaining submissions already had category 5 parameters, NIST wanted to encourage those who didn't have them to consider adding them.  If the suggestion presents a difficulty to BIKE, NTRUprime, Dilithium, or NTRU, we would like to understand.  The decision is always left to the submission teams.  

 

If teams need more time than August 10th to let us know a summary of expected changes, they can contact us to discuss.  We can be flexible.  

 

 

Dustin

[Kirk Fleming]

Dustin,

 

It's not clear what you are asking for the community's input on. Should NIST have encouraged BIKE, Dilithium, NTRU and NTRUprime to include category 5 parameters in their round 3 submissions? NIST have repeatedly said that it's not a requirement. In the original Call for Proposals submitters were "encouraged to also specify parameter sets that provide lower security levels", below category 1. Many teams were happy to ignore this.

 

BIKE, Dilithium and NTRU (in one cost model) do not have category 4 or 5 parameters so should be required to add parameters that "provide a substantially higher level of security, above category 3."  I think it is reasonable to suggest that these are category 5 parameters if it allows better comparison between schemes. Submitters can choose to ignore this if adding category 4 parameters makes more sense for their scheme.

 

NTRUprime does claim to have category 4 parameters. If the submitters believe that their current category 4 parameters adequately "demonstrate the ability of their cryptosystem to scale up beyond category 3" then they can ignore the suggestion for additional category 5 parameters.

 

I don't see why asking for public feedback would be necessary before making the suggestion and I don't see how complaining about it now helps.

 

Kirk

 

Sent: Monday, August 03, 2020 at 9:05 PM
From: "'Moody, Dustin (Fed)' via pqc-forum" <pqc-...@list.nist.gov>
To: "pqc-forum" <pqc-...@list.nist.gov>
Subject: [pqc-forum] Category 5 parameter sets

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DM6PR09MB59095A65B7C35E5538C0FCB3E54D0%40DM6PR09MB5909.namprd09.prod.outlook.com.

[Martin Strand]

Dear Dustin, all.

I've been reading the recent list traffic with interest. I'm currently
working at a governmental research institute, which means what we have
to think about how to protect classified information for decades.
Currently, AES-256 is approved for such uses. One could of course have
endless debates about whether that is too strong even in a 40-50 year
perspective (dev time, review, approval, and then 30 years after
end-of-life), but it's probably best to err on the safe side.

It would not make much sense to use a key agreement mechanism with
substantially lower security than that. Hence, I strongly support
NIST's encouragement of category 5 parameters. That would make it
easier to add the standard directly to the lists where AES-256
currently reside.

"Just use McEliece, then", I can hear someone say. For some
applications we would also like to be able to use this on small
devices while maintaining strong security. Standardization of cat. 5
schemes across the board would be very useful for us.

Martin Strand

man. 3. aug. 2020 kl. 23:05 skrev 'Moody, Dustin (Fed)' via pqc-forum
<pqc-...@list.nist.gov>:

> --
> You received this message because you are subscribed to the Google Groups "pqc-forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
> To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DM6PR09MB59095A65B7C35E5538C0FCB3E54D0%40DM6PR09MB5909.namprd09.prod.outlook.com.

--
Martin Strand

[D. J. Bernstein]

Martin Strand writes:
> It would not make much sense to use a key agreement mechanism with
> substantially lower security than that. Hence, I strongly support
> NIST's encouragement of category 5 parameters. That would make it
> easier to add the standard directly to the lists where AES-256
> currently reside.

Given the degradation of lattice security levels---for example,

* asymptotic lattice security levels were 42% higher (this means 42%
more bits of security) against the best published attacks 10 years
ago than against the best published attacks today, and

* a "conservative lower bound" advertised in lattice submission
documents in 2019 turns out to be broken for all sufficiently large
lattice dimensions

---I presume that you see the risk that a lattice system claiming only
2^256 security today will be shown by public attacks within a few years
(a small fraction of the timeline you mention) to have substantially
lower security than that. This means, from what you say, that using the
system would not make much sense for your organization.

(https://cr.yp.to/talks.html#2020.07.20-1 includes a broader survey of
recent advances in lattice attacks.)

Is it correct to conclude that, to reduce the risk, your organization
would prefer a system targeting 2^384 security above a system targeting
only 2^256 security? (This would still be usable on small devices.) If
this isn't correct, why not? This is exactly the sort of information
that submitters need now if your use case is to be taken into account.

I should also note that NIST has repeatedly and consistently stated that
submitters should focus primarily on lower security levels, and now is
extremely late in the NISTPQC process for proposing changes to the
evaluation criteria. However, the real problem for submitters at this
point isn't any difficulty in targeting 2^256; it's the lack of
information regarding _how much further to go_. Your message is a
perfect example of how various arguments for 2^256 are, when combined
with the unfortunate reality of lattices losing security, actually
arguments for going some unspecified distance _beyond_ 2^256.

---Dan

P.S. As a side note, https://blog.cr.yp.to/20151120-batchattacks.html
might also be of interest to you.

[Perlner, Ray A. (Fed)]

* a "conservative lower bound" advertised in lattice submission
documents in 2019 turns out to be broken for all sufficiently large
lattice dimensions

Can you cite the specific paper you have in mind here?

Thanks,
Ray

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20200804170145.1188473.qmail%40cr.yp.to.

[D. J. Bernstein]

Perlner, Ray A. (Fed) writes:
> Can you cite the specific paper you have in mind here?

See my email dated 31 May 2020 23:13:38 +0200 for the full reasoning and
references. I'm not aware of any dispute.

---Dan

[D. J. Bernstein]

'Moody, Dustin (Fed)' via pqc-forum writes:
> a reason for wanting category 5 parameters is that it facilitates
> being able to more closely compare submissions

Can you please clarify what comparison procedure this is referring to,
and how category-5 parameters would help?

Let me hazard a guess. To compare, e.g., public-key sizes, NIST made
three tables showing

* public-key sizes across all category-1 parameter sets,
* public-key sizes across all category-3 parameter sets, and
* public-key sizes across all category-5 parameter sets,

but the third table is incomplete---e.g., it has only half of the
round-3 lattice candidates. This prompted NIST to now ask submissions to
complete this table. Is that what happened? If not, what _did_ happen?

---Dan

[Moody, Dustin (Fed)]

Dan, 

We think we've explained our position on this issue.  Submission teams can submit category 5 parameters if they wish, or not.  It's up to them. 

Dustin

---

From: pqc-...@list.nist.gov on behalf of D. J. Bernstein
Sent: Wednesday, August 5, 2020 7:19 AM
To: pqc-forum

Subject: Re: [pqc-forum] Category 5 parameter sets

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20200805111928.1237779.qmail%40cr.yp.to.

[Mike Gardiner]

I'd just like to add another voice behind Martin's comment.  

There's nothing shocking about the stance to always use a key which is considered to be as strong or stronger than any key material (or data classification level) it protects.  This is simply following along with using appropriate security to protect access to the asset under protection.  Standardizing systems which can't achieve this goal would take them out of consideration for some organizations and some use cases unless there were absolutely no choices which were able to meet that criteria.  I actually find it surprising that 2^128 seemed to be the most important security level for this competition.  That''s historically been pretty typical if you're talking about ephemeral security tunnels, but not for long term guarantees of confidentiality/integrity and today with hardware acceleration there isn't much of a penalty for opting into 256 bits of security over 128.  The legal concepts of due care / due diligence are also important here. It doesn't really matter what the data is, if it's classified as needing protection consistent with what is considered to be best practices in the industry and and I have a choice between something currently believed to offer 2^256 bits of security and something that is currently believed to offer 2^128 bits or even 2^192 bits of security then the choice is clear.  After all, something could be discovered to weaken either scheme at any point.  And going beyond 2^256 bits is currently not something considered to be necessary or desirable in industry.  The goal of security is to reduce risk to an acceptable level, by applying enough.  Going beyond what's needed adds costs that don't make sense.  Personally, like the idea of showing how easy it would be to turn things up to 11 and go beyond 2^256 but standards are for commodities; I certainly wouldn't expect extra credit to be handed out.  

I'm not qualified to judge Dan's assertion that the security levels of some schemes still in the competition are under assault to such a level that anything claiming 2^256 bits of security today can be expected to be significantly weakened by the time the ink on the standard dries.  If there is consensus that those schemes come with a short expiry date then that deserves it's own topic thread.  And discussion in that thread should be centred on if there is something which can be done to make those schemes fit for the competition.  But that topic is completely outside the discussion here on wither or not category 5 parameter sets would be useful in the competition.  

To me, it's perfectly reasonable that the competition process evolves as everything else does.  Wouldn't reasonable teams hold in their screams and prioritize adjusting the seams of their schemes in order to realize their standardization dreams and spread like memes?

 

-Mike
 

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-...@list.nist.gov.

[D. J. Bernstein]

Let me emphasize that, as far as I know, every submission can easily
scale parameters up to any requested target security level. The big
ongoing problem is a lack of clarity regarding what's being requested.
Clear explanations would make it easy to answer the following questions:

* Is pre-quantum Core-SVP 2^254 (e.g., kyber1024) viewed as lower
risk than pre-quantum Core-SVP 2^203 (e.g., saber)? If not, why
not?

* Is pre-quantum Core-SVP 2^283 (e.g., firesaber) viewed as lower
risk than pre-quantum Core-SVP 2^254? If not, why not?

* Does it add value to a submission to have a parameter set targeting
the 6th line in the attack-cost table from the NISTPQC call for
submissions? If not, why not? What about the 2^512 security level
that NIST required for SHA-3?

* Given that flexibility, hedging, etc., were all mentioned in the
call for proposals, and that the call for proposals asked merely
for a parameter set "above category 3", why did NIST's latest
report suddenly change to asking for "category 5"? Is there any
reason to believe that there won't be a subsequent request for even
higher levels? Everyone seems to agree that adding parameter sets
now is better than adding them later.

The following unquantified arguments (some from NIST) all seem to
indicate that adding higher and higher and higher levels now would add
value to submissions:

* "breakthroughs in cryptanalysis and/or computing technology";
* "something could be discovered";
* "schemes have been attacked";
* "significant progress in lattice cryptanalysis";
* "due care / due diligence";
* "it's probably best to err on the safe side";
* "long term guarantees of confidentiality/integrity";
* a larger parameter set "helps to demonstrate flexibility";
* some "users want very high security options";
* "national security".

In the opposite direction, there's an unquantified counterargument
regarding costs ("Going beyond what's needed adds costs that don't make
sense"). However, this doesn't claim that having bigger _options_
available _for applications that can afford them_ is a bad thing.

As for quantified arguments, the type of threat modeling shown in

https://blog.cr.yp.to/20151120-batchattacks.html

can justify going beyond 2^128 security (to stop multi-target attacks)
but doesn't justify going beyond 2^192 security. Some comments here have
suggested that users of classified data are rejecting 2^192 as too weak,
but this isn't backed by references, and it's contradicted by NSA's
published recommendations of AES-256, P-384, RSA-3072, DSA-3072, and
DH-3072 for material classified TOP SECRET:

https://web.archive.org/web/20150815072948/https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml

None of NSA's recommended public-key components are above 2^192 security
(and, out of those components, only P-384 can plausibly claim 2^192
security). As for AES-256, there's ample evidence of people using
AES-256 _because the extra computation is cheap_, not even bothering to
implement AES-192. NSA's Kevin Igoe said in

https://mailarchive.ietf.org/arch/msg/cfrg/lyP6VTm2h1asZSCNn7ogNywD5TU/

that NSA recommended AES-256 instead of AES-192 exactly because of the
extra availability of AES-256 hardware. How has this mutated into some
people believing that AES-192 is too weak?

Sure, it's possible that some cryptographic providers have deployed
15000-bit RSA after rejecting NSA's RSA-3072 recommendation as being too
weak for "cryptographic parity" with AES-256. But where's the evidence
regarding the existence and volume of such deployments? Are these part
of the "majority of use cases" that NIST refers to?

If someone wants a 2^256 lattice system for "cryptographic parity" with
AES-256, but then realizes that known _quantum_ attacks take far fewer
operations against AES-256 than against the lattice system, then doesn't
post-quantum "cryptographic parity" require moving from AES-256 up to a
larger cipher? If not, why not?

Obviously NSA's public recommendations, and previous comments from NIST
personnel such as "we'd expect security strengths 2 on up to be secure
for 50 years or more", shouldn't be taken as gospel. Perhaps moving up
to 2^256 is a reduction in risk that should play an important role in
NISTPQC. But there has been so little public justification for this
change that it's weird to see NIST suddenly adopting this change---and
it's unclear whether NIST now believes that options beyond 2^256 have
further security value or should be treated as irrelevant.

NIST has made a comment that seems to be trying to deter submissions
from providing _more_ parameter sets, although this isn't the same issue
as providing _larger_ parameter sets: "NIST believes that too many
parameter sets make evaluation and analysis more difficult." The
following questions remain unanswered:

How many is "too many"? How did flexibility, which was portrayed as
purely positive in the call for proposals, turn into a bad thing for
NIST? The call for proposals explicitly allowed multiple parameter sets
_per category_, never suggesting that this would be penalized!

There's also a comment from NIST that "a reason for wanting category 5

parameters is that it facilitates being able to more closely compare

submissions". I asked for clarification:

Can you please clarify what comparison procedure this is referring
to, and how category-5 parameters would help?

Let me hazard a guess. To compare, e.g., public-key sizes, NIST made
three tables showing

* public-key sizes across all category-1 parameter sets,
* public-key sizes across all category-3 parameter sets, and
* public-key sizes across all category-5 parameter sets,

but the third table is incomplete---e.g., it has only half of the
round-3 lattice candidates. This prompted NIST to now ask submissions to
complete this table. Is that what happened? If not, what _did_ happen?

NIST replied "We think we've explained our position on this issue". The
question remains unanswered. What we're seeing in NISTPQC is not the
transparency that NIST promised after Dual EC.

Consider again pre-quantum Core-SVP 2^283 (firesaber) vs. pre-quantum
Core-SVP 2^254 (kyber1024). Should Kyber be adding a larger parameter
set to "facilitate" comparisons with firesaber? What's the comparison
mechanism that would benefit from this? If Kyber _shouldn't_ be doing
this, why not?

---Dan

[Kevin Chadwick]

On 2020-08-12 20:51, D. J. Bernstein wrote:
> None of NSA's recommended public-key components are above 2^192 security
> (and, out of those components, only P-384 can plausibly claim 2^192
> security). As for AES-256, there's ample evidence of people using
> AES-256 _because the extra computation is cheap_, not even bothering to
> implement AES-192. NSA's Kevin Igoe said in

You all know this and likely not very helpful, but from an implementers point of
view.

NIST specs tend to focus on minimum levels for performance while remaining
secure. A nonce of atleast 8 bytes, CMAC ^92 etc..

I always use 16 bytes or more, but I guess this advice may be difficult to
formulate for Lattice?

A couple of Bruce Schneier's blog posts are contradictory or rather evolutional
in a way on AES as new round weaknesses were developed.

AES-256 has an inferior shuffle compared to AES-128. AES-256 is better for PQ. A
suggestion of double encrypting with AES-256 became the suggestion to improve
the shuffle and harden it with more rounds.

"https://www.schneier.com/blog/archives/2009/07/another_new_aes.html"

I triple encrypt because it is that cheap in hw, compared to TX.

It's quite likely that large firms have the "Our trusted expert says use
AES-256" so that's what we use mentality. The above post also mentions AES-256
enhanced cipher, in the later comments.

[Mike Gardiner]

This discussion is bogged down by statements which may be technically correct but don't really change the fact that having category 5 parameters would be useful. 

I don't have any insight into how NIST is going to choose.  But as someone mostly concerned with the final product, I'm saying I'd like to see category 5 parameters in that standard and I'm not going to be alone on that.  I'd like to see it discussed before the end of the competition because any tweaks after give me the heebie jeebies. Those trust issues also have me really wondering about the NSA endorsement of stateful hash based schemes given how easy they are to misuse. 

The fact that AES256 gets cut down significantly by a quantum computer doesn't change the want for schemes that have good/better/best parameters in line with what we use in industry today.   As for RSA.. we're kind of stuck with it at this point regardless of the actual security level.  2048 isn't too weak, and 4096 is the largest that's practical so I'm anxious for a standardized alternative that can get widely implemented/supported.  ECC fumbled for a variety of reasons unrelated to how secure it actually is.  The statements around transitioning to SuiteB not being very important due to an impending quantum computer hurt it just the fact it got conflated with the EC_DRBG mess by many not technical people just as the cryptographer position that there's too much unanswered by the parameters.  So we have a whole bunch of national vanity curves and options many can't use because while they may be defacto, they aren't certified. 

[Donald Costello]

You have no idea how far back you push the teaching of  Cryptology. Your work is very important but not only is it too hard to follow the ins and outs of your arguments, I no longer care how many angels are on the head of a pin 

Get Outlook for iOS

---

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> on behalf of Mike Gardiner <gard...@gmail.com>
Sent: Thursday, August 13, 2020 4:47:45 PM
To: pqc-forum <pqc-...@list.nist.gov>

Subject: Re: [pqc-forum] Category 5 parameter sets

This discussion is bogged down by statements which may be technically correct but don't really change the fact that having category 5 parameters would be useful. 

I don't have any insight into how NIST is going to choose.  But as someone mostly concerned with the final product, I'm saying I'd like to see category 5 parameters in that standard and I'm not going to be alone on that.  I'd like to see it discussed before the end of the competition because any tweaks after give me the heebie jeebies. Those trust issues also have me really wondering about the NSA endorsement of stateful hash based schemes given how easy they are to misuse. 

The fact that AES256 gets cut down significantly by a quantum computer doesn't change the want for schemes that have good/better/best parameters in line with what we use in industry today.   As for RSA.. we're kind of stuck with it at this point regardless of the actual security level.  2048 isn't too weak, and 4096 is the largest that's practical so I'm anxious for a standardized alternative that can get widely implemented/supported.  ECC fumbled for a variety of reasons unrelated to how secure it actually is.  The statements around transitioning to SuiteB not being very important due to an impending quantum computer hurt it just the fact it got conflated with the EC_DRBG mess by many not technical people just as the cryptographer position that there's too much unanswered by the parameters.  So we have a whole bunch of national vanity curves and options many can't use because while they may be defacto, they aren't certified. 

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/f323a8dc-7538-436f-af57-63a536477a2fo%40list.nist.gov.

[Scott Fluhrer (sfluhrer)]

I respectively disagree that “Category 5” parameters would be useful; in fact, I can see a scenario where they are actually harmful.

 

Suppose NIST does approve a “category 5” parameter set for some approved postquantum algorithm.  In that case, some moderately clueless customers will demand that it be used rather than a more reasonable parameter set (after all, NIST approved it, hence NIST must think it’s required for security).  We (as equipment manufacturers) will implement it, and the customers see that it doesn’t perform very well…, and so stick with RSA/ECC “which performs better”, even though a lower category parameter set would have performed just fine.

 

Furthermore, I would have to ask you: can you think of a plausible scenario (apart from a cryptographical advance) where a category 5 parameter set would be secure, but a category 3 parameter set would not be?  I can’t think of one.  As for the cavaet of “apart from a cryptographical advance”, well, if we posit such an advance, what assurance would we get that the advance is enough to endanger category 3, but not category 5.

 

IMHO, category 5 helps in only a moderately unlikely scenario, while at the same time would actively discourage some customers (the “moderately clueless ones” I referenced earlier) from using any postquantum algorithm.

 

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of Mike Gardiner
Sent: Thursday, August 13, 2020 5:48 PM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [pqc-forum] Category 5 parameter sets

 

This discussion is bogged down by statements which may be technically correct but don't really change the fact that having category 5 parameters would be useful. 

 

I don't have any insight into how NIST is going to choose.  But as someone mostly concerned with the final product, I'm saying I'd like to see category 5 parameters in that standard and I'm not going to be alone on that.  I'd like to see it discussed before the end of the competition because any tweaks after give me the heebie jeebies. Those trust issues also have me really wondering about the NSA endorsement of stateful hash based schemes given how easy they are to misuse. 

 

The fact that AES256 gets cut down significantly by a quantum computer doesn't change the want for schemes that have good/better/best parameters in line with what we use in industry today.   As for RSA.. we're kind of stuck with it at this point regardless of the actual security level.  2048 isn't too weak, and 4096 is the largest that's practical so I'm anxious for a standardized alternative that can get widely implemented/supported.  ECC fumbled for a variety of reasons unrelated to how secure it actually is.  The statements around transitioning to SuiteB not being very important due to an impending quantum computer hurt it just the fact it got conflated with the EC_DRBG mess by many not technical people just as the cryptographer position that there's too much unanswered by the parameters.  So we have a whole bunch of national vanity curves and options many can't use because while they may be defacto, they aren't certified. 

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/f323a8dc-7538-436f-af57-63a536477a2fo%40list.nist.gov.

[Mike Gardiner]

Scott, I like the cut of your jib. I'm not totally sure your questions are fair given the assumption that a cryptographic break/advance is off the table.. but you're at least not claiming I'm pushing cryptography back to the dark ages or something.  

You suggest that category 5 parameters would be harmful because they are slower than category 3, which might cause someone to choose ECC/RSA instead for performance reasons.  I think some people would make that choice, and I don't think they would have to be considered to be clueless to do so.  I'm going to assume you mean prime521 or RSA 4096 as the alternative choices.  Given you said the choice was between a post quantum scheme and ECC/RSA I'll also assume you mean a data integrity or identity use case.  So I'm thinking about signing legal documents, software and firmware.  As well as client/server identity, or root/intermediate CAs.    I suppose you could have intended ECC to include ECDH and ECIES, and RSA to include RSA encryption.. but I don't think so? 

We will have to assume that there is no viable quantum adversary on the date the choice is made.  Choosing algorithms which are broken certainly happens but when we are assuming the choice was made partially because it's in the strongest category wouldn't add up. I"ll also assume that the quantum schemes are certified at the time the choice is being made. 

The only way that scenario leads to harm is if the data needs to be protected beyond the point where the scheme is useful.

If the key in question is an identity for a web server/service then the useful life is at most 12 months thanks to apple and google forcing the CA/Browser forum.

If the key in question is a software signing key then the range is generally 1-2 years.  For firmware I've seen the validity period being longer.  I can't name any names but I think 30 years is the longest I've seen.. but the device in question probably wouldn't be in the field that long. 

If the key in question is an email signing key, then in an enterprise setting we're probably talking about 1 year, maybe 2. 

If the key in question is a document signing key then we're probably talking about 1 to 2 years.  Trust for longer than the certificate validity period is thanks to an attached timestamp signature.. I don't really like this practice so I'm going to say we ignore it much like how you said we are ignoring cryptographic advance. 

If the key in question is a public CA.  I think 20 years is the current norm for a root and 10 for an intermediate. 

If the key in question is a private CA/Intermediate.. then all bets are off.  But this has me quite curious as to what parameters are default / allowed when using the AWS and Google managed CA services.    

So, would slow category 5 parameters be harmful in the above cases?  In the public CA case.. where we're generally dealing with intelligent people who realize RSA/ECC keys can't be trusted for 20 more years.  The majority of those other cases expect the key to be useful for on average 2 years and RSA/ECC can probably be expected to be good for that period of time so harm is doubtful unless the choice is made close to when the quantum break happens.

Other than performance issues RSA and ECC are going to be popular choices for a while because of how well supported they are. Historically adoption of new algorithms have been slow.  Maybe that won't be the case now in the world of cloud services, that remains to be seen.  If you are building your own software to protect your own data then you have some flexibility to use novel algorithms.  TLS and SSH libraries can be updated fairly easily but getting a quantum resistant CA/intermedate option through the CA/Browser forum and then trusted in all major browsers will be something else. 

Interoperability between vendors that build different components is going to be important for an ability to roll out new key types  Apple could switch their code signing requirements for iOS easily.  But windows and java code signing would be trickier.  You've got to get the CAs on board and update old versions of operating systems/jvms to trust and understand the new algorithms.  For anyone who needs certification, assuming the standard is available in 2024, then we're probably looking at 2025 at least until the CMVP has figured out how to certify modules with those algorithms. It's possible that it would take only a few months after that to get the first FIPS approved module out if it's software.  If we're talking hardware (level 3)  I think it's more realistic to think 2026 because customers who care enough to want FIPS certified quantum resistant algorithms probably want assurance that the module uses quantum resistant algorithms to protect the keys which would mean it's a sub-3 evaluation and we're talking a year.

Now, you also asked for an example where you would want to choose category 5 rather than 3.  And very cheekily said cryptographic advance doesn't count.  Which makes it really hard to give an example.  in the purely theoretical sense we're talking about math that should be impossible to crack even considering the advance of computational power for an incredible amount of time. So under the conditions that there isn't an advance there is absolutely no need to choose category 5 over 3.  You've got me.

Category 3 in the data protection world is kind of wierd though.  You would think that it would follow along with the product/marketing world and given the choice between good/better/best you would expect most people to choose the middle option.  It's better than the minimum without going overboard.  I've never seen anyone choose that way though.  Usually they are optimizing for speed or security.  If speed is the most important criteria then the answer is always category 1.  Otherwise the conversation tends to start with category 5 and only move back to 3 if there is a performance issue. Now that's just my experience though.  Maybe it's an outlier. 

I'd like to turn that question around on you though.  Assume you're trying to protect private health information.  And you've got a requirement that that data must be protected from disclosure for the life of the patient. Given the history of modern cryptography, do you expect any choice out there to realistically protect data of children born today for their entire lives?  How long were we able to put faith in our standardized algorithms this century?  How confident are you that AES192 with your mode of choice would be up to the task given we know it will be at least weakened by half on the arrival of a sufficiently large quantum computer?  How confident are you that we've got it all figured out this time and there is no way that any advancement (mathematical, computational or other) could happen which would weaken the category 3 choices being discussed here today to the level that they would possibly be broken in a 100 year span?  What choice do you expect a CISSP would make? 

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-...@list.nist.gov.

[Donald Costello]

You do go on ! You go on and on for 14 paragraphs about ideas that are so confusing noone can even categorize the issues.

You probably think of your self as analytic . I am sorry to offend you , you are probably a nice fellow, but you just don’t get it.

It is very difficult to understand not to mention teach Quantum Computing.  At least there are books and even videos about the subject. All we have about your subject is what you and your clique have to say.

It is at best Pseudo -Science!

Get Outlook for iOS

---

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> on behalf of Mike Gardiner <gard...@gmail.com>

Sent: Thursday, August 13, 2020 10:08:38 PM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: gard...@gmail.com <gard...@gmail.com>

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/87e82b40-2249-4216-a739-6c2279de9276o%40list.nist.gov.

[Bas Westerbaan]

 

How confident are you that AES192 with your mode of choice would be up to the task given we know it will be at least weakened by half on the arrival of a sufficiently large quantum computer?

 The "symmetric cryptography bit-strength is cut in half by quantum computers" statement is only true for noiseless (viz. impractical) quantum computers.  In practice, I wouldn't be surprised if it took at least another 50 years before a practical (noisy) quantum computer breaks AES128 after a quantum computer has broken its first RSA2048 keypair.