Isn't your encrypted data only as safe as your key? 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 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).

So this would work on a "closed" system? I'm reminded of the problem with
symmetric encryption: If you can share a secret, why do you need encryption?

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?

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

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."

What about the increasing ammounts of processing power (ie. Quantum
computing)? 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 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...

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.

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. They say it can't be done because of the sheer
ammount of data that you would have to store. But we all know better.

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

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

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

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!

-Kevlar

At 12:13 PM 2/26/2001 -0800, you wrote:
>Hey all,
>
>Ok, I figure that I'll take first whack at this. The primary implications I
>see are:
>
>1. Source- The source must be trusted and must be not be affected by time
>delay. The cryptographic is based on the ability of a computer not being able
>to hold all of the key in RAM at one particular time. This means that the key
>sequence must be received in a timely manner and must not have to be
>reassembled from out of order packets. You could have in internal encryption
>that draws from some close source of dependable data, such as timing from a
>master telco switch ( I have seen/done this{from the techie side}) in which
>case if the source were discovered and a data stream could be predicted the
>advantage would be lost.
>
>2. Remote Source- It also seems that since this would have to be centralized
>and since the key would be pulled from a central source that this method
would
>be particularly vulnerable to a Man-in-the-Middle attack. I do that sort of
>thing all the time to sniff passwords off of a switched network. This
would be
>a bit more complex... but not much more so because the key would captured
>along with the traffic. It also brings into question whether or not the
source
>itself could be spoofed. Kinda like nabbing someelse's PGP key and putting
>yours in their place...
>
>Anyway, I would definitely have to agree that this is nifty but it seems a
bit
>impractical, esp on the internet. On a closed system it could work. But then
>again, how closed is a closed system?
>
>Regards,
>
>{Wayne L. Kearns}<----asbestos coating for junior comments[;-)
>
>
>
>
>
>
>Dan Houser wrote:
>
>> OK CISSP holders & hopefuls... time to put on your thinking cap for fun
>> discussion of random stream one-time pad encryption:
>>
>> "[Dr. Michael Rabin, noted cryptographer and] computer science professor at
>> Harvard says he has found a way to send coded messages that cannot be
>> deciphered, even by an all-powerful adversary with unlimited computing
>> power. And, he says, he can prove it."
>>
>> I thought of 2 big implementation flaws with statements in the article
>> about implementing this encryption technology, besides Bruce Schneier's
>> enlightened "encryption is a pole in your front yard you hope people will
>> run into instead of around" statement (which is also true). Show me yours,
>> and I'll show you mine... :^)
>>
>> For full article: http://www.nytimes.com/2001/02/20/science/20CODE.html
>> (You will need to register to get this article from the NY Times, well
>> worth the trouble.... their daily technology update is superb)
>>
>> ddh, cissp, etc.
>>
>> +--------------------------------------------+
>> | 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 |
>> +--------------------------------------------+
>
> +--------------------------------------------+
> | 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 |
> +--------------------------------------------+
>

             +--------------------------------------------+
             | 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 ]