Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Peter Gutmann]

Phillip Hallam-Baker  writes:

>Quantum Annoyance:

I thought a Quantum Annoyance was someone who keeps banging on about imaginary
attacks that don't exist as a means of avoiding having to deal with actual
attacks that have been happening for years without being addressed.

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Bas Westerbaan]

>
> That is not the only model of quantum computing. If it was, I would be
> saying this entire effort is a silly waste of time because the approach is
> fundamentally unscalable. They can throw lots of gates onto a chip but the
> entanglement collapses before they can be used.
>

The whole point of quantum error correction is that it preserves
entanglement. (QEC in practice is not a panacea, for instance, transmons
can escape in higher harmonics which are not corrected for.) For the claim,
"fundamentally unscalable" however you should bring some evidence.

Best,

 Bas


PS, for those that want to get into the topic, I recommend Nielsen &
Chuang.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Sofía Celi]

Dear, all,

Late to reply to some emails. I was just travelling ;)


 > I am now thinking in terms of 'Post Quantum Hardened" and "Post
Quantum
 > Qualified". Hardening a system so it doesn't completely break
under QCC
 > is a practical near term goal. Getting to a fully qualified
system is
 > going to be a root-and-canal job.

There is a notion of being 'quantum annoyant' to a quantum computer:
perhaps that might be an starting point for other schemes that do no
have a post-quantum counterpart as of right now. For others, a hybrid
approach should definitly be taken such that classical cryptography
still protects data.


I am using PQC to protect the data and Threshold-ECC to protect the data 
with separation of roles.


Unfortunately, Threshold-ECC does not have a propely assesed quantum 
secure version. There is some thoughts over here if interested: 
https://csrc.nist.gov/CSRC/media/Events/Second-PQC-Standardization-Conference/documents/accepted-papers/cozzo-luov-paper.pdf 



Thanks,

--
Sofía Celi
@claucece
Cryptographic research and implementation at many places, specially Brave.
Chair of hprc at IRTF and anti-fraud at W3C.
Reach me out at: cheren...@riseup.net
Website: https://sofiaceli.com/
3D0B D6E9 4D51 FBC2 CEF7  F004 C835 5EB9 42BF A1D6

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Sofía Celi]

Dear, all,

On 06/08/2022 07:15, Benjamin Kaduk wrote:

On Fri, Aug 05, 2022 at 07:16:06PM -0700, Rob Sayre wrote:

On Fri, Aug 5, 2022 at 5:16 PM Sofía Celi  wrote:


There is a notion of being 'quantum annoyant' to a quantum computer:



I've encountered the term "quantum annoyant" a few times. Is there a
precise definition that could be referenced? Maybe [0]?

I don't find the references I know of very satisfying, and I would
translate "annoyant" to "doesn't actually work".

thanks,
Rob

[0] 
https://urldefense.com/v3/__https://eprint.iacr.org/2021/696.pdf__;!!GjvTz_vk!S_lXpy5HvfAfDJmtXdME2kuOOLXGTGz07_pqClIgY8ppVcZYu7Cf2WQ0K7YjyyOypKFppMI6NE_C$


I think [0] is the reference (or at least very similar content) I've seen in 
previous discussions of this topic.

It's annoying to the attacker when they have to use their expensive and finicky
hardware once (or multiple times) for each individual message/exchange they
want to break, rather than being able to amortize the cost of running the
quantum computer across many protocol runs that are broken by that computer.
They'd have to be selective about what to decrypt (quickly), rather than just
getting "everything" -- while a QC does provide massive speedups, it does still
take some actual amount of time to run, and we can build protocols so that
the runtime of the QC is a practical constraint on the attacker's ability, even
if it is not necessarily a theoretical constraint on them.


Correct. Note that it doesn't mean that a QC will not break it at the 
end, but just that is is 'annoying' to perform such operations over and 
over. Edward Eaton and Douglas Stebila properly defined the "property" 
over here: https://eprint.iacr.org/2021/696.pdf It was first mentioned 
during the PAKE selection process at CFRG by Thomas: 
https://mailarchive.ietf.org/arch/msg/cfrg/dtf91cmavpzT47U3AVxrVGNB5UM/


Thanks,
--
Sofía Celi
@claucece
Cryptographic research and implementation at many places, specially Brave.
Chair of hprc at IRTF and anti-fraud at W3C.
Reach me out at: cheren...@riseup.net
Website: https://sofiaceli.com/
3D0B D6E9 4D51 FBC2 CEF7  F004 C835 5EB9 42BF A1D6

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Sofía Celi]

Dear, all,

On 06/08/2022 13:00, Rob Sayre wrote:
On Fri, Aug 5, 2022 at 10:15 PM Benjamin Kaduk > wrote:



It's annoying to the attacker when they have to use their expensive
and finicky
hardware once (or multiple times) for each individual
message/exchange they
want to break,


Well, I can agree with the term "expensive", but I'm not sure what you 
mean by "finicky". Are you saying they only work sometimes? It seems a 
bit hand-wavy to say that.


I've seen quantum computers before. They are room-sized, but not that 
big. I still find the term "quantum annoying" rather imprecise.


Maybe this is better (taken for the Eaton and Stebila paper in reference 
to PAKEs):


"""
If a scheme is quantum annoying, then being able to solve one discrete 
logarithm (in the case of DH, for example, sic) does not immediately 
provide the ability to compromise a system; instead, each discrete 
logarithm an adversary solves only allows them to eliminate a single 
possible password. Essentially, the adversary must guess a password, 
solve a discrete logarithm based on their guess, and then check to see 
if they were correct.

"""

It is difficult to asses how 'annoying' this will be for a quantum 
computer. For a strong noise-free quantum computer is probably not 
annoying but for something in between (which is what we might get in the 
upcomign years) it might be.


Thanks,

--
Sofía Celi
@claucece
Cryptographic research and implementation at many places, specially Brave.
Chair of hprc at IRTF and anti-fraud at W3C.
Reach me out at: cheren...@riseup.net
Website: https://sofiaceli.com/
3D0B D6E9 4D51 FBC2 CEF7  F004 C835 5EB9 42BF A1D6

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Phillip Hallam-Baker]

On Sun, Aug 7, 2022 at 3:52 AM Peter Gutmann 
wrote:

> Phillip Hallam-Baker  writes:
>
> >Quantum Annoyance:
>
> I thought a Quantum Annoyance was someone who keeps banging on about
> imaginary
> attacks that don't exist as a means of avoiding having to deal with actual
> attacks that have been happening for years without being addressed.
>

That is a little unfair but only a little.

What bothers me is that TLS is not a toy, it is the primary security
control used in most of the world's critical infrastructure. That is why
Quantum Cryptanalysis has to be take seriously.

But so does the fact that Rainbow fell to an attack discovered during the
competition. This is not mature crypto, it is not ready for prime time as a
sole control. I have seen references to a 'NIST' slide insisting that we
should not use hybrid schemes and I completely disagree with them. KGB
doctrine was always that every communication be secured by two independent
technologies using separate principles..

I suspect that this guidance is being misinterpreted and that what they
actually meant was that the PQC algorithms have to be fit for purpose as a
sole control.

First, do no harm: At this point it is very clear that the risk of a Laptop
on a Weekend breaking Kyber is rather higher than anyone building a QCC
capable computer in the next decade. So what is not going to happen is a
system in which a break of Kyber results in a break of TLS.


Critical infrastructure demands defense in depth. The lack of binding
between the ephemeral and the initial exchanges was always a design blunder
in TLS. Using an ephemeral should never weaken the security.

Incidentally, this particular design blunder is one of the reasons I am
sceptical of security proofs using formal methods. The problem with formal
methods is that you can only prove correctness with respect to a
specification and if the specification is wrong, all else fails. Unless you
start asking questions like 'what if this assumption fails', you end up
with systems with a single point of failure. And before folk start telling
me how great formal methods are, I was a practitioner once.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Phillip Hallam-Baker]

On Sun, Aug 7, 2022 at 11:53 AM Sofía Celi  wrote:

> Dear, all,
>
> Late to reply to some emails. I was just travelling ;)
>
> >  > I am now thinking in terms of 'Post Quantum Hardened" and "Post
> > Quantum
> >  > Qualified". Hardening a system so it doesn't completely break
> > under QCC
> >  > is a practical near term goal. Getting to a fully qualified
> > system is
> >  > going to be a root-and-canal job.
> >
> > There is a notion of being 'quantum annoyant' to a quantum computer:
> > perhaps that might be an starting point for other schemes that do no
> > have a post-quantum counterpart as of right now. For others, a hybrid
> > approach should definitly be taken such that classical cryptography
> > still protects data.
> >
> >
> > I am using PQC to protect the data and Threshold-ECC to protect the data
> > with separation of roles.
>
> Unfortunately, Threshold-ECC does not have a propely assesed quantum
> secure version. There is some thoughts over here if interested:
>
> https://csrc.nist.gov/CSRC/media/Events/Second-PQC-Standardization-Conference/documents/accepted-papers/cozzo-luov-paper.pdf


Right now, there is little to no interest in applying threshold to data at
rest so it would be ludicrous to make threshold a requirement at this stage.

But data at rest is where about half the breaches occur (the other half
being data in use as in when a database or application has a file in
memory). And separation of roles is our most powerful tool for securing
data at rest. And threshold is the name for cryptographic tools that
enforce separation of roles.

The original reason I went away to do my own stuff is that it is really
difficult to get clarity on the underlying principles when one is focused
on maintenance of a highly constrained system like PKIX/WebPKI, TLS, etc.
So one of the original goals was to have something I could use for
'experiments' and then attempt to apply the same principles to the legacy
systems. Which is what I am doing here.


So no, Threshold PQC (TPQC) is not yet a thing. But now that the NIST
competition is winding down, it looks to me like there are going to be a
large number of out of work cryptographers unless they can find a new
problem to work on.

TPQC signatures are a really low priority for me. Multi signatures work
fine for almost any use case. What I really need are mechanisms for
generating keys from threshold shares and for key agreement split into
threshold shares.

A system that works for n=t=2 (two shares, both required) more than meets
the 80:20 rule.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Blumenthal, Uri - 0553 - MITLL]

> > I thought a Quantum Annoyance was someone who keeps banging on about 
> > imaginary
> > attacks that don't exist as a means of avoiding having to deal with actual
> > attacks that have been happening for years without being addressed.
>
> That is a little unfair but only a little.

I don't think Quantum "Annoyance" makes any sense at all. It's only annoying to 
implementers.

> What bothers me is that TLS is not a toy, it is the primary security control
> used in most of the world's critical infrastructure. That is why
> Quantum Cryptanalysis has to be taken seriously.

I concur.

> But so does the fact that Rainbow fell to an attack discovered during the 
> competition.

That was the point of the competition, n'est 'est pas?

> This is not mature crypto, it is not ready for prime time as a sole control.

I think you're throwing everything into one pile, mixing apples, oranges, etc.

How long till a crypto algorithm is considered "mature"? Is ECC "mature"? What 
about NTRU?

> I have seen references to a 'NIST' slide insisting that we should not use 
> hybrid schemes
> and I completely disagree with them.

I appreciate your point, and happen to disagree with it. SIKE failed - and so 
did many other PQ and Classic algorithms. So...? Can you *guarantee* that ECC 
(or RSA) won't fall to a brand-new LoW attack tomorrow, or
in two years? You'd say "it's not likely"? Sure, but IMHO it's comparably 
unlikely for NTRU or Kyber to fall
in a similar way.

> KGB doctrine was always that every communication be secured by two 
> independent technologies
> using separate principles..

I'm sorry to disappoint you, but the above is simply untrue.

> First, do no harm: At this point it is very clear that the risk of a 
> Laptop on a Weekend breaking Kyber is rather higher than anyone building
> a QCC capable computer in the next decade.

Probably. Otherwise, no comment.

> So, what is not going to happen is a system in which a break of Kyber results 
> in a break of TLS. 

I daresay, nothing - because, based on the available cryptanalytic results, I 
don't expect Kyber to break, at least at NIST Sec Level 5 (and I'm not 
interested in any other level).

> Critical infrastructure demands defense in depth. The lack of binding between 
> the
> ephemeral and the initial exchanges was always a design blunder in TLS.

Yes, absolutely.

> Using an ephemeral should never weaken the security.

Again, I concur.

> Incidentally, this particular design blunder is one of the reasons
> I am skeptical of security proofs using formal methods.

"Look at the formal proofs, but trust cryptanalysis". I could sign under this 
statement.



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Phillip Hallam-Baker]

On Sun, Aug 7, 2022 at 1:31 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> wrote:

>
> > KGB doctrine was always that every communication be secured by two
> independent technologies
> > using separate principles..
>
> I'm sorry to disappoint you, but the above is simply untrue.
>

Read Victor Sheymov's book 'Tower of Secrets'. He was a KGB officer and
(hopefully) you were not. He makes the point repeatedly throughout.
Victor Sheymov - Wikipedia 

The reason he gave for defecting was that cipher operators were dying
because of the use of radioactive sources inside the secure communications
enclosures to swamp R/F signals with noise.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Scott Fluhrer (sfluhrer)]

> -Original Message-
> From: TLS  On Behalf Of Blumenthal, Uri - 0553 -
> MITLL
> Sent: Sunday, August 7, 2022 1:32 PM
> To: Phillip Hallam-Baker 
> Cc: TLS@ietf.org
> Subject: Re: [TLS] Before we PQC... Re: PQC key exchange sizes
> 
> > > I thought a Quantum Annoyance was someone who keeps banging on
> about
> > > imaginary attacks that don't exist as a means of avoiding having to
> > > deal with actual attacks that have been happening for years without
> being addressed.
> >
> > That is a little unfair but only a little.
> 
> I don't think Quantum "Annoyance" makes any sense at all. It's only
> annoying to implementers.

Actually, we came up with the concept while evaluating PAKEs for the CFRG, and 
in the that context, it makes sense.  For some PAKEs, if we assume that the 
adversary has the ability to compute one discrete log, all that would gain him 
is the ability to check of one particular password was being used for a 
recorded exchange (and hence if computing a discrete log is costly, which is 
likely to be the case for the first generation of Quantum Computers), you're 
still "mostly safe".

In contrast, with other PAKEs, computing one discrete log would allow you to 
break any implementation of that PAKE parameter set globally - that is about is 
'un-annoying' as you can possibly get.

We say this disparity, and the term 'Quantum Annoyance' was coined to express 
it.

Now, with key exchanges, it is somewhat less applicable.  However, if computing 
a few thousand discrete logs allows you to put together a usable factor base, 
well, perhaps that would indicate that 'finite field DH with a common modulus' 
is less 'quantum annoying' (in the above sense) than (say) ECC...

> 
> > I have seen references to a 'NIST' slide insisting that we should not
> > use hybrid schemes and I completely disagree with them.

(The above comment was by PHP)

Hmmm, I had thought I tracked just about everything NIST said about 
postquantum, and I don't recall that.  In any case, I don't believe that anyone 
is taking that advice; initially, just about everyone is suggesting to combine 
postquantum with classical (ECC or RSA).  And, since this is the TLS working 
group, I would point out that the current TLS postquantum draft does do hybrid.

> 
> > First, do no harm: At this point it is very clear that the risk of a
> > Laptop on a Weekend breaking Kyber is rather higher than anyone
> > building a QCC capable computer in the next decade.
> > So, what is not going to happen is a system in which a break of Kyber
> > results in a break of TLS.

Again, that's why we're planning on hybrid; to break the privacy of TLS, you 
would need to break both Kyber (or NTRU; I'll spout off on that if you're 
interested) and (say) X25519.  Hence, what we are proposing is no less secure 
than what we are currently doing now.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Rob Sayre]

On Sun, Aug 7, 2022 at 1:59 PM Scott Fluhrer (sfluhrer)  wrote:

>
> Actually, we came up with the concept while evaluating PAKEs for the CFRG,
> and in the that context, it makes sense.


The problem is that the term "Quantum Annoyance" is an equivocation.


>  you're still "mostly safe".
>

Like this phrase.

I don't really have a strong opinion on these matters, but it seems like
too much hand waving to me.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

[Stephen Farrell]

Hiya,

On 07/08/2022 21:58, Scott Fluhrer (sfluhrer) wrote:

Hence, what we are proposing is no less secure than what we are currently doing 
now.


Well, except there'll be a whole pile of new code, which
is a fine way to be less secure.

Now for key establishment that's not too bad perhaps, but
when I hear some of the certificate proposals (in lamps,
not really this wg), I just shudder.

S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Technical Errata Reported] RFC8446 (7073)

[Martin Thomson]

This is correct, though I would have extended this to say ", except for 
post-handshake authentication, which uses keys derived from the current 
[sender]_application_traffic_secret_N." or similar.

On Sat, Aug 6, 2022, at 23:03, RFC Errata System wrote:
> The following errata report has been submitted for RFC8446,
> "The Transport Layer Security (TLS) Protocol Version 1.3".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7073
>
> --
> Type: Technical
> Reported by: Ben Smyth 
>
> Section: 4.4
>
> Original Text
> -
> These messages are encrypted under keys derived from the 
> [sender]_handshake_traffic_secret.
>
> Corrected Text
> --
> These messages are encrypted under keys derived from the 
> [sender]_handshake_traffic_secret, except for post-handshake 
> authentication
>
> Notes
> -
> There's an exception
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
>
> --
> RFC8446 (draft-ietf-tls-tls13-28)
> --
> Title   : The Transport Layer Security (TLS) Protocol Version 1.3
> Publication Date: August 2018
> Author(s)   : E. Rescorla
> Category: PROPOSED STANDARD
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls