[Cryptography] composing EC & RSA encryption?

[Bill Cox]

On Sun, Oct 25, 2015 at 3:47 PM, Tony Arcieri <bascule at gmail.com> wrote:

> First, if your worry is QCs, then trying to combine ECC and RSA isn't
> going to help you as they'll both be obliterated by QCs.
>

We expect 256-bit ECC to fall to QCs before RSA-2048 or DH-2048.  If we use
one for long-term keys and the other for short-term keys, we'll see one
broken long before the other, hopefully with enough notice to upgrade away
from the broken system.

I know the Australian guys seem to think QCs with "1 million" cubits are
possibly as close as "five years" away, but I've seen these kinds of
predictions come and go so often that I am fairly comfortable ignoring
them.  What they accomplished was a 2-transistor QC.  That's really not
very impressive.  Wake me up again when they have a few hundred doing a
useful computation.

However, I think it would be prudent to start combining algorithms,
preferably very different ones.  The size of the keys is so vastly
different, I think it would be reasonable to start by simply combining ECC
and regular crypto (DH or RSA).  This might also fit the usage model of TLS
1.3 0-RTT.

However, the general idea of combining multiple algorithms isn't inherently
> bad. What you would *actually* want to do is combine e.g. ECC with an
> as-yet-unproven quantum algorithm, like Ring-LWE (possibly not a good idea
> due to patents, but let's go with it for now)
>
> In that case, you can do a key exchange with both algorithms, and feed the
> results of both into a KDF (e.g. concatenating the keys exchanged together
> as KDF inputs)
>
> This sort of scheme should be at least as strong as the strongest of the
> two.
>

I agree.  I'm not following what's going on in the TLS 1.3 effort.  Is
there an opportunity there?  I think there are already two keys, one for
long-term and one for short-term, but I think they use the same
cryptosystem for both, which would be a mistake, IMO.

Thanks,
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151026/44351ed3/attachment.html>