Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt

["Kyle Hamilton" <[e-mail]>]

On 7/1/06, Eric Rescorla <[e-mail]> wrote:
> "Kyle Hamilton" <[e-mail]> writes:
>
> > On 7/1/06, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> >>
> >> Maybe the wording wasn't clear. Would an update to the security
> >> considerations text like the one below be more clear to you?
> >>
> >>          Security considerations about the use of the web of trust or
> >>          the key verification procedure are outside the scope of this
> >>          document and are considered issues to be handled by the
> >>          application layer protocols.
> >
> > Security considerations that have anything to do with identity key
> > verification and entity mapping (pre-shared keys, PKIX, web-of-trust),
> > and the corresponding authorization to use the application being
> > protected, are outside the scope of this document.  These are
> > considered issues to be handled by the application layer protocols, or
> > at the very least by the TLS implementation in accordance with
> > key-interpretation protocols that are separately described.
>
> I don't think any of the below material is really relevant
> here. It's just boilerplate that applies to any crypto
> protocol
>
> [...snip...]
>
> This is duplicative of RFC 1984.

Then reference RFC 1984 in the Security Considerations section.  I
don't particularly care where they're written, but these are
considerations which need to be taken into account by every TLS
implementor and administrator -- and just because you already know
about it does not mean that everyone else does.  If someone decides to
read up on how the TLS protocol works by reading the document (even if
they're not implementing the protocol per se but even using it) it
would be a good idea to put it in.

> > Certain algorithms have "weak keys", and implementations of those
> > algorithms should check generated keys against them and reject them as
> > candidates for usage.
>
> In particular, this advice does not match with current TLS practice,
> which is NOT to check for weak keys.

It is a security consideration, and I present it for consideration as
such.  Let's consider the (admittedly unlikely, but also admittedly
possible) case of DES with an all-zero key, or 3DES with an all-zero
key.  Surprise!  Identity operation!  Would you want /your/ medical or
financial data protected over a network that had implementations that
could possibly not encrypt it at all?

Regardless of whether it meshes with current TLS practice, these are
issues that need to be pointed out. I think it's absolutely barbaric
that TLS is a security protocol, yet legitimate security concerns are
being whitewashed because it doesn't mesh with "current practice".

> > The RSA asymmetric encryption system is known to be vulnerable to
> > advances in factoring large numbers.  In particular, the General
> > Number Field Seive is being advanced slowly but inexorably.  It is
> > recommended that implementations move away from RSA for identity keys.
>
> I don't agree with this recommendation.

Would you care to express why?  I've been looking at the research
that's been put into the GNFS up to now, and measured its progress
against Moore's Law.  The results are... scary.  If advancements in
mathematics continue apace, we'll have problems very soon.

Quoting from the abstract of
http://scholar.lib.vt.edu/theses/available/etd-32298-93111/unrestricted/etd.pdf
:
[...]One of the most prominent systems for securing electronic
information, known as RSA, relies upon the fact that it is
computationally difficult to factor a "large" integer into its
component prime integers. If an efficient algorithm is developed that
can factor any arbitrarily large integer in a "reasonable" amount of
time, the security value of the RSA system would be nullified.

The General Number Field Sieve algorithm is the fastest known method
for factoring large integers. Research and development of this
algorithm within the past five years has facilitated factorizations of
integers that were once speculated to require thousands of years of
supercomputer time to accomplish. While this method has many
unexplored features that merit further research, the complexity of the
algorithm prevents almost anyone but an expert from investigating its
behavior. We address this concern by first pulling together much of
the background information necessary to understand the concepts that
are central in the General Number Field Sieve. These concepts are
woven together into a cohesive presentation that details each theory
while clearly describing how a particular theory fits into the
algorithm. Formal proofs from existing literature are recast and
illuminated to clarify their inner-workings and the role they play in
the whole process. We also present a complete, detailed example of a
factorization achieved with the General Number Field Sieve in order to
concretize the concepts that are outlined.
[end quote]

Let's figure out the number of digits in any given keysize:

8 bit = 3 (max value "256")
16 bit = 5 (max value "16535")
32 bit = 10 (max value = "4294967296")
64 bit = 20 (max value = "18446744073709551616")
128 bit = 39
256 bit = 78
384 bit = 116
512 bit = 155
768 bit = 232
1024 bit = 309
2048 bit = 617
4096 bit = 1234

The largest RSA composite number ever known to be factored was 200
digits long.  (Source:
http://www.crypto-world.com/FactorAnnouncements.html )  This was
announced in May 2005, and took from "shortly before Christmas 2003"
to October 2004 (about 10 months), plus December 2004 to May 2005
(about 6 months).  This took about 170 Pentium 1GHz CPU-years, and
approximately (with their clusters) 80 machines working for those 16
months.  This means that 768 bit general RSA is in sight (if Moore's
Law continues to hold and advances in factoring mathematics continue
unabated, it should be less than 3 years from now before a 768-bit RSA
composite is factored).

The largest number ever factored by the special number sieve was 274
digits long.  This is larger than 768-bit RSA, and suggests that
1024-bit RSA composites that are of the special form could be
factorable at this point or in the fairly near future.

This is why I recommend exploring options other than RSA for identity
keys.  Why do you disagree with this recommendation?

-Kyle H

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls