Subject: [OAUTH-WG] RSA vs PKI?

From: Brian Eaton <[email-masked]>
Date: Fri, 6 Nov 2009 09:20:53 -0800

[switching subject line to fork discussion]

Hey Igor -

On Thu, Nov 5, 2009 at 7:49 PM, Igor Faynberg
<[email-masked]> wrote:
> One question: Is RSA is really essential here? I  think not (why not use ECC
> or any other PKI algorithm instead?). So, I would agree with Brian so long
> as RSA is replaced with PKI.

Interesting point, and I'm not sure I fully understand what you are getting at.

The choice of RSA-SHA1 vs RSA-SHA256 vs ECC vs DSA-SHA1 vs <whatever
comes out next week> seems to be about cryptographic security.  What
algorithms do we want to use?  How are we going to migrate from older
algorithms to new algorithms as the old ones are broken?  What are the
efficiency vs security trade-offs?

PKI, on the other hand, doesn't seem to be about security in the
cryptographic sense.  It's more about key discovery, and trust.  How
do you find the consumer's public key?

Have I understood where you are headed?

Cheers,
Brian

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Fri, 6 Nov 2009 11:26:21 -0800

i think everyone here probably understands that defining a small set
of required crypto algorithms is a "good thing." otherwise you get
MOSS.

there _are_ issues with both ECC and RSA.

Certicom holds some patents on ECC, so it is not a completely
unencumbered technology.

On the other hand, the NSA has elected to pay for a federal government
wide license for these patents rather than specify RSA in Suite B.
(Suite B being a collection of algorithms the NSA has approved for
securing "sensitive but not classified" government information.) This
has led some people to wonder whether the NSA knows something the rest
of us don't regarding the efficacy of RSA.

Another check mark in the RSA column is the fact that it's quite easy
to find a commercial CA that supports RSA. It's much harder to find
commercial support for ECC and Rabin Williams (despite the latter
being defined as part of ISO9796)

Just my $0.02.

In the interest of full disclosure, i am a former employee of both
RSADSI and Certicom and maintain a small financial interest in
Certicom.

-cheers
-meadhbh

--
   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
         http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Fri, Nov 6, 2009 at 09:20, Brian Eaton <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Igor Faynberg <[email-masked]>
Date: Sun, 08 Nov 2009 21:16:23 -0500

(My mail, for some strange reason, has never delivered Brian's response 
to me, so I first saw it in Meadhbh's quotation.)

 I am afraid I added to the confusion. The only point of my posting was 
to check if we are open to cryptographic  algorithms other than RSA. 
(Brian, by PKI I meant the system in which signatures are obtained with 
private keys [and verified using the respective public keys]. So, I 
referred here strictly to the cryptographic side of PKI.)

I am not a strong advocate of ECC. (It is only from my observations of a 
push for  ECC in ITU-T that I started to think that it is becoming 
ubiquitous.)  I am aware of the two advantages of ECC over RSA: 1) It is 
much faster and 2) it is provably secure.

But I did not want to waste the OAuth bandwidth on this discussion.  I 
only wondered if  it has already been decided to lock ourselves into one 
specific algorithm.

With thanks,

Igor

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Nov 2009 22:13:06 -0500

I am pretty sure ECC is no more provably secure than discrete log problems.

The problem with RSA is that once you go past 2048 bits the work
factor drops pretty quickly. 1048 bit RSA is roughly equivalent to an
80 bit symmetric key work factor. RSA 2048 is about 120 and RSA 4096
is 150 (these are from memory, but the drop off in effectiveness is
pretty sharp).

Now RSA 2048 is almost certainly enough for most things, but when you
are a government agency you want the stuff you encrypt using RSA2048
on its last day of service life to be secure for another 20-30 years,
possibly more. So while RSA 2048 has at least another 30 years left in
it for authentication problems it is already reaching the end of its
service life for certain confidentiality applications.

I would suggest making RSA 2048 - SHA 256 the mandatory to implement
and chose an ECC alternative from suite B.

On Sun, Nov 8, 2009 at 9:16 PM, Igor Faynberg
<[email-masked]> wrote:
> (My mail, for some strange reason, has never delivered Brian's response to
> me, so I first saw it in Meadhbh's quotation.)
>
> I am afraid I added to the confusion. The only point of my posting was to
> check if we are open to cryptographic  algorithms other than RSA. (Brian, by
> PKI I meant the system in which signatures are obtained with private keys
> [and verified using the respective public keys]. So, I referred here
> strictly to the cryptographic side of PKI.)
>
> But I did not want to waste the OAuth bandwidth on this discussion.  I only
> wondered if  it has already been decided to lock ourselves into one specific
> algorithm.
>
> With thanks,
>
> Igor
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Brian Eaton <[email-masked]>
Date: Sun, 8 Nov 2009 19:32:09 -0800

> and chose an ECC alternative from suite B.

So the choice of RSA key length seems like something that different
applications could reasonably choose on their own, no?  Do we really
need to include 2048 bit RSA in the spec, or is specifying RSA in
general sufficient?

I suspect we do need to specify acceptable hash output lengths if
we're going to have decent interop.

(I'm seriously pushing the bounds of my crypto knowledge here, so do
let me know if any of the above is nonsense.)

Cheers,
Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 8 Nov 2009 23:01:23 -0500

No, don't leave the key size to chance, there is a lot of crypto
hardware out there that is quite restrictive in key sizes.

The only key sizes I am aware of being widely used are 1024 and 2048.
Beyond 2048 you really need to move to ECC. 1024 is considered barely
sufficient and not really suitable for new applications.

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 09 Nov 2009 09:36:21 -0500

I am very glad that we have key observations on the table.  I do not 
object to making RSA mandatory; I only wanted to have other public-key 
algorithms considered, which is exactly what has happened.

To piggy-back a note on ECC "provability," yes, its complexity indeed 
boils down to that of the discrete logarithm  problem in a finite group. 
But elliptic curves define funky  groups!  I've heard claims from 
various sources--with references to Victor Shoup's results,--that in 
certain types of groups  the average-case bound for the discrete 
logarithm problem equals the worst-case bound. It appears that certain 
elliptic curves produce just these types of fields--this is what I was 
told. Now, I have not read all the references--I have just started with 
Shoup's papers, and it may take me a couple of months or so before I 
fully understand both the math and the practical meaning of the claims. 
Once there, I will be happy to share what I learned.

Igor

---

From: Breno <[email-masked]>
Date: Fri, 13 Nov 2009 10:22:07 -0800

Basically, the U.S. Government currently requires 256-bit symmetric
encryption keys for the highest levels of security (documents whose
confidentiality over the next several decades is a matter of national
security).

The 256-bit security requirement in symmetric keys compares to 512-bit in
ECC but only to something like RSA-15,000. It is quite clear that nobody
will ever deploy RSA-15,000 because it would be incredibly inefficient
compared to ECC-512. So there is no point in estipulating RSA key sizes for
the highest security settings.

Generally, n bits of symmetic key security map to 2n bits of ECC security
(currently published cryptanalytic research). However, the reduction of RSA
security to symmetric security does not follow a linear relationship.

-- 
Breno de Medeiros