This got lost in the list server I think, so I'm reposting it on behalf of
William Hugh Murray (whmurray@optonline.net).

Cheers,
-Scott

-----

-------- Original Message --------
Subject: [Fwd: Re: [CISSPStudy_1]x:[CISSPSTUDY@SECURITYFOCUS] Thisshould
startup adiscussion....]
Date: Wed, 28 Feb 2001 09:33:45 -0500
From: William Hugh Murray <whmurray@optonline.net>
Reply-To: whmurray@sprynet.com
To: "CISSPSTUDY@SECURITYFOCUS.COM" <CISSPSTUDY@SECURITYFOCUS.COM>

I am not sure that I can add much but you have left a large number of
question
marks. If I answer the questions, it may clarify for everyone.

Kevlar wrote:

> Isn't your encrypted data only as safe as your key?

Yes, as a general rule. However, the key does not imply the data.
Until I use
it, it does not have any value. Therefore, if I screw up while trying
to share
it, that is not as bad as screwing up while trying to share the data.

> Just because there's an
> enormous ammount of data to deal with dosn't mean we can't find a way to
> deal with it. In my opinion this

Rather than question you, I will assume that the referrent of the
pronoun is
Rabin's proposal.

> is security through obscurity, albiet
> cleverly disguised. Brute force attacks are ALWAYS possible so long as the
> key space is of finite length (and it always is).

That is part of the reason for this proposal. Like Shannon's OTP,
Rabin's
proposal shows a way to increase the amount of work toward infinity and
reduce the
probability of success toward zero.

> So this would work on a "closed" system?

If one has confidence that one has a closed system, one does not need
encryption.
One rarely, not to say never, enjoys such confidence.

> I'm reminded of the problem with
> symmetric encryption: If you can share a secret, why do you need
encryption?

See my point above. If one shares a meaningless secret, the process is
low risk.
If one has already safely shared a meaningless secret, that can lower
the future
risk of sharing a meaningful one.

> As I understand it, two parties agree to establish an algorithm for
> selecting (semi) random bits from a constant bit-stream by starting the
> collection at a specific time. Dosn't that qualify as sharing a secret?

Yes.

> So we encrypt the secret using public key encryption: Great... now if our
> PK encryption fails us, so does our "unbreakable" scheme.

Yes. However, the proposal assumes it away. It does not constrain the
way that
you share the secret in advance. Also, while it may be necessary to
obtain this
secret, according to the proposal, it is not sufficient.

> So the argument goes: "It would take a significant ammount of processing
> power to decrypt the secret, and by the time someone does, the bit-stream
> used for one-time-pad generation has long gone."

I do not understand that to be a part of the assumption. Rabin grants
you
unbounded computer power. Some time must have passed but necessarily a
long time.

> What about the increasing ammounts of processing power (ie. Quantum
> computing)?

See last point.

> What about one implementation of one algorithm vs. another
> speed wise? What about latency on the network? What if the bit-stream
> itself was compromised, or spoofed, or destroyed?

The proposition is that the adversary is sufficiently storage
constrained or the
bit stream so large, that none of this matters. Remember, so far this
is like the
OTP, the proof holds only as long as the assumptions hold. There is no
proof that
the assumptions can be met.

> The EFF to build a computer specifically for the purpose of breaking a
> specific type of encryption. As I remember it pulled it off in somewhere
> between 8 and 13 hours.
>
> So, let's assemble this into something useful...

Whoops! Who said anything about useful?

> The secret is encrypted and sent out. The message is encrypted using the
> one-time-pad from the stream modified by the secret. The encrypted message
> is sent accross the line, and the whole time a man-in-the-middle is
> recording everything.

That he recorded everything violates the assumption that he does not
have
sufficient storage to do so. Remember that Eve must record everything
while Alice
and Bob are merely using some and throwing it away and ignoring the
rest..

> Obviously you must start your stream processing sometime after the secret
> has been broadcasted, and we know when we can stop capturing the stream
> when the encrypted message has been sent because by that time the
> encryption has been preformed.
>
> So T=0 is when the secret is broadcasted, and T=n is when the encryped
> message is sent, and somewhere in between is the stream used to generate
> the one-time-pad.
>
> So we record the stream from T=0 to T=n. This is the main basis for the
> "unbreakable" argument.

As we both seem to understand it.

> They say it can't be done because of the sheer
> ammount of data that you would have to store.

No. They assume that it cannot be done. If it cannot, then the proof
holds. If
it can, then you may still be secure but you cannot prove it.

> But we all know better.

Perhaps. Provable or practical? You pick.

> Then it's just a matter of decrypting the secret.

Rabin argues that there are two things, necessary to read the message.
You must
discover the instant key for which the assumptions grant you unlimited
computing
power but some elapsed time. You must also remember the bit stream,
which, by
assumption, you cannot do.

> So in reality it's not more secure, it's just (alot) more obscure.

Ah, well. Reality. There is the rub. All that Rabin has said is that
if you are
computing power unbound but sufficiently storage bound, then not only
will his
system work but that he can prove it. All that you have said is that in
the real
world you do not believe that the necessary conditions can be met. That
is where
Shannon and I stand.

> It has (many) single points of failures, and makes asumptions about the
> attackers resources to support it's argument.

Rabin said provable, not practical. All "proofs" require assumptions.
His
assumptions are no more difficult to meet than those of Shannon.
Shannon does not
claim that you cannot find the message but only that if you find it, you
cannot
recognize it. That assumes not only that there is zero entropy in the
key but
near zero in the message. Notice that while the necessary conditions
for Shannons
proof can never be met, the existence of the proof tells us what we must
control
in order to achieve practical encryption.

Rabin's proof is useful in the same way. It tells us that if we add
lots of
entropy to the process very late, then either or both of the work or
storage
requirements of the adversary will also go up. As the speed of our bit
stream
goes up relative to the adversary's storage, our system approaches both
secure and
provable.

> Caveat Emptor... If it sounds to good to be true, it usually is.
>
> Just my 2 cents. Feel free to tell me why I'm wrong!

You are not wrong but then neither is Rabin. You just insist upon
different
assumptions and different outcomes.

It is interesting. With Shannon most people seem to be engaged in the
exercise of
trying to meet, or claiming to have met, the necessary conditions for
his proof.
With Rabin, we all seem to be engaged in the opposite exercise.

> -Kevlar

-Asbestos

-------------------------------------
Scott C. Sanchez, CISSP
Technology Project Manager
Information Security Department

Goldman Sachs & Co.
180 Maiden Lane, 29th Fl.
New York, NY 10038
Phone: 1-212-357-9070 (x7-9070)
-------------------------------------

             +--------------------------------------------+
             | You have received this email because you |
             | subscribed to the CISSPSTUDY mailing list. |
             | -- To unsubscribe, send an email to -- |
             | listserv@securityfocus.com |
             | with a message body of: |
             | UNSUBSCRIBE CISSPSTUDY |
             +--------------------------------------------+

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]