[Cryptography] Post Quantum Crypto

Philipp Gühring pg at futureware.at
Thu Nov 12 21:23:51 EST 2015


Hi,

> > I believed that handling 2 different certificates will be too complex
> > (errorprone) and therefore too costly for the users. 
> 
> On the other hand, this works now, 

Are you sure? I would expect quite a number of systems to not be able to
handle 2 different certificates for the same identity. And it would likely
leave us open to downgrade attacks against NTRU in case NTRU were found to
be weaker than RSA, if both certificates are equal. I am not sure, whether
we should propose that.
I think that there are lots of software-stacks out there that can only
manage one certificate for an identity. Has anyone done large-scale
interoperability tests for a 2-certificate scenario? Could I see the
results please?

> with existing code, and certificates
> (at least DV) are free.  While a hybrid certificate would require
> new CA software,

We will need new CA software to support NTRU anyway, to check
NTRU/PassSign signature on CSR´s, and to sign the certificates with the
new signing algorithms.

> new PKIX extensions, new TLS standards and a new
> SSL/TLS software stack. 

I think that we have to renew the whole stack anyway, whether we go the
one-certificate way, or the 2-certificate way.

> And what happens when NTRU is found wanting,
> a certificate with 3 public keys (always rotated concurrently)?

Then we just drop NTRU and replace it with a different algorithm. But the
migratability is already in place then.


> Support for multiple certificates is considerably simpler to deploy.

For the software developers who develop the crypto stacks, yes.
But for the millions of end-users?

> > And for commercial CAs you would have to buy 2 certificates instead
> of one... 
> 
>     0 + 0 = 0
> 
> > And then we would have to have twice as many root certificates, ...
> and
> > most root certificate list vendors already have limits on the number
> of
> > root certificates per certificate authority (3 if I remember
> correctly).

>     There is no such limit.

I am sorry, but this is wrong:

https://www.apple.com/certificateauthority/ca_program.html

"A maximum of three roots per CA provider can be accepted because each
additional root negatively impacts users by increasing download time."

And the problem for the CA is that it simply can´t decide to have
dedicated or different root certificates just for Apple, so this simple
rule automatically creates a lower bound for all root certificates for the
internet for all internet-relevant CA´s.
Well, perhaps you could create a new company to get around this
restriction, but it´s likely more economic to adhere to the restriction.
And perhaps you can negotiate exceptions with them. I haven´t tried that.
I decided to accept this restriction for my designs.

>     For a while, we'll likely end up with fewer roots, that would
>     be a feature, not a bug.

;-)
I really liked Mozillas response a few years ago on this topic, which went
something like this: "In the beginning there was just one CA, and
everybody was complaining. So we fixed it, and now there are hundreds of
CA´s, and again everybody is complaining"
I think the problem is that people aren´t happy with the structure of the
CA market, not just with the size.

I had a different question for this topic:
"Do you want to have a CA in your country that speaks your language and is
able to provide support locally?" 
If the answer is yes, you automatically have to accept up to 196 CA´s on
this planet, if you concede to others what you want yourself.
Now do you feel good about 196 CA´s in your browser? No? Ok, I am sorry,
but there are not enough CA´s to provide one with support in your country.

I think any number of CA`s are not good, because whoever you ask, it´s
either too many or too few.

 
> > It´s already hard for users to generate 1 keypair, get a certificate
> for
> > it, install the certificate correctly, asking them to do that twice
> will
> > make it less likely for them to succeed.
 
>     I would assume that for web services LE would help automate
>     provisioning both algorithms.

Yeah, LE wasn´t on my roadmap 2 years ago, if I remember correctly.
Yes, LE should automate provisioning both algorithms. I hope it does.

>   It should also be noted that
>     your 5 year estimate for scalable QC is rather more aggressive
>     than expert consensus.

Yes, that´s because I have been working on worst-case scenarios, not on
most-likely-timeframe scenarios. I didn´t tried to extrapolate the
academic situation, instead I tried to estimate based on a hypothetical
well-funded attacker, willing to invest considerable ressource to buy into
the abiltity.
There are likely a lot of economic incentives not to push the speed that
much. But given a well-funded and willing attacker ...

The other thing is that I also looked back in time. IBM prooved the
viability of Shor in 2001, but kept quiet since then. They later claimed
that they got into a technological dead end. But if that was just an
excuse, then it might be that quantum computers are already existing and
we just weren´t told yet.
So I also investigated the likelihood whether we will be told about it, or
not.


Best regards,
Philipp Gühring



More information about the cryptography mailing list