Cryptography-Digest Digest #178, Volume #14 Wed, 18 Apr 01 19:13:01 EDT
Contents:
Re: Reusing A One Time Pad ("M.S. Bob")
Re: A practical idea to reinforce passwords ("Mark G Wolf")
Re: I took the $5000 Goldman Challenge (Dror Baron)
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: Reusing A One Time Pad ("Tom St Denis")
Re: Current best complexity for factoring? (Terry Boon)
Re: Current best complexity for factoring? ("Tom St Denis")
Re: I took the $5000 Goldman Challenge ("Dale King")
Crypto question ("Shah Karim")
Re: I took the $5000 Goldman Challenge ("Tom Gutman")
Re: Crypto question (Ben Cantrick)
Re: Crypto question ("Carsten Alexander")
Re: GSM Encryption and Authentication (David Wagner)
Re: Crypto question ("Mark G Wolf")
Re: Reusing A One Time Pad ("M.S. Bob")
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: A practical idea to reinforce passwords (Bill Unruh)
Re: There Is No Unbreakable Crypto (Bill Unruh)
Re: Reusing A One Time Pad (Bill Unruh)
----------------------------------------------------------------------------
From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 21:05:23 +0100
Mark G Wolf wrote:
>
> I don't wish to seem rude and will admit that I'm not the smartest person in
> the world, but you know what I would find extremely helpful in life... an
If you want to understand more about why reusing an "one-time pad" is a
bad idea, I suggest you read the real life accounts about Venona
<http://www.nsa.gov/docs/venona/>. The summary is: when the soviet spies
ended up reusing their pads due to shortages or using duplicated pads
due to printing errors, the US SIS managed to decipher the messages they
encrypted. I believe some of those spies died.
On your question of how bad, that is up in the air. At a start read
Shannon's works, and about analysis of LFSR and stream ciphers.
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 15:13:41 -0500
> ]Sounds like a pretty good idea to me. In fact it's something I've been
> ]thinking about quite a bit lately. The idea that the intended recipient
or
> ]user actually has to do some brute force work to decrypt messages to
enhance
> ]security. In fact I'm often surprised it's not mentioned more often.
Gee,
>
> I do not see how it enhances security. If the far side does not know
> your key, then he has to brute force the whole thing anyway. If he does,
> it is no harder for him than you. Ie, what advantage does your not
> knowing what your own key is (in part) give you?
I was thinking more in general. As far as the password thing goes, it
depends on the login process. For instance it could be a kind of Kerberos
interaction between your password and smartcard. In that case you're kind
of sending a message to yourself. You can use a simple to remember password
which gets padded by the server so that if someone should get at your card
temporarily they couldn't compromise the card as easily. The whole point is
that server doesn't know your logon without both getting your password and
smartcard. You can make your password easier to remember at the expense of
a longer logon process.
There's that Trinity thing again. Hey you think them Catholics know
something the others don't.
------------------------------
Crossposted-To: comp.compression
From: Dror Baron <[EMAIL PROTECTED]>
Subject: Re: I took the $5000 Goldman Challenge
Date: Wed, 18 Apr 2001 15:15:06 -0500
On 18 Apr 2001, SCOTT19U.ZIP_GUY wrote:
> I think the problem with King is like if he was taught Eucliden
> Geomtry in school. So everything is formulated towards that. THen
> when he get comfronted with something more suited to Projective
> Geometry he would get lost. Its hard to mix the two geometres so
> I try to be of the type uses which ever one fits the problem.
> One has to be flexable.
Dude, I rest my case. That's like cheating whichever
way works best for any given problem.
Dror
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 15:28:19 -0500
> If you want to understand more about why reusing an "one-time pad" is a
> bad idea, I suggest you read the real life accounts about Venona
> <http://www.nsa.gov/docs/venona/>. The summary is: when the soviet spies
> ended up reusing their pads due to shortages or using duplicated pads
> due to printing errors, the US SIS managed to decipher the messages they
That was then, when spies didn't have relatively powerful computers with
very sophisticated software internetworked together sitting on their desks
like we do now. The problem they had was really one of management more than
anything else, which computers can take care of nicely nowadays.
> encrypted. I believe some of those spies died.
Your not from the NSA are you? And if you were you wouldn't kill me would
you. Hey you think Microsoft has all kinds of backdoors in their code?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 20:39:46 GMT
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9bktes$2kq4$[EMAIL PROTECTED]...
> > If you want to understand more about why reusing an "one-time pad" is a
> > bad idea, I suggest you read the real life accounts about Venona
> > <http://www.nsa.gov/docs/venona/>. The summary is: when the soviet spies
> > ended up reusing their pads due to shortages or using duplicated pads
> > due to printing errors, the US SIS managed to decipher the messages they
>
> That was then, when spies didn't have relatively powerful computers with
> very sophisticated software internetworked together sitting on their desks
> like we do now. The problem they had was really one of management more
than
> anything else, which computers can take care of nicely nowadays.
Which is why (if you cared to learn) modern crypto is about key stream
generators and block ciphers instead of OTPs. The big problem with OTPs
whether you care to admit it or not is that you must supply a huge stream of
bits securely. That means you can't use some nice protocol like DH to
exchange a key (since that's not provably random or decorrelated). You have
to at best walk up to the guy or gal and physically give them the big key.
Modern crypto is about short 128-bit (etc) keys that can be exchanged using
PK crypto (DH, ElGamal, ECC, RSA, whatever...). They are workable solutions
that do not rely on huge pads for security.
> > encrypted. I believe some of those spies died.
>
> Your not from the NSA are you? And if you were you wouldn't kill me would
> you. Hey you think Microsoft has all kinds of backdoors in their code?
This is just complete crap and is OT.
Tom
------------------------------
From: [EMAIL PROTECTED] (Terry Boon)
Subject: Re: Current best complexity for factoring?
Date: Wed, 18 Apr 2001 20:35:21 GMT
Reply-To: [EMAIL PROTECTED]
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
On Wed, 11 Apr 2001 06:37:36 GMT, Samuel Paik <[EMAIL PROTECTED]> wrote:
>Claus Näveke wrote:
>> How are these primes generated? I thought they are too big for doing
>> math-operations with them...
>
>The second question first. Use multi-word computations--limit is only
>memory and time.
>
>Generally, pick random odd n-bit number (this means the high order
>bit and low order bit are set to 1 and the rest of the bits are chosen
>randomly). Test for probabilistic primality. If not prime, increment by 2
>and go to test, otherwise, accept as prime.
I've seen this method suggested elsewhere as well...
Does this not bias the "random" selection of a prime towards primes
which come after a long run of composites?
(And, furthermore, is this effect significant? I wonder if I've got a
pmf for the spacing between primes somewhere in my bookshelf...)
I suspect that the answers to these two questions are "Yes" and "No"
respectively.
- --
Terry Boon, Hertfordshire, UK
[EMAIL PROTECTED]
=====BEGIN PGP SIGNATURE=====
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5
iD8DBQE63ftpB+GG7A6DEUARAi13AJ4osqMvrFyGH4O8BI+G4UpiEtUUWACfdOqh
LmzEwl6vjEbu0ErBu5C6PoA=
=uux2
=====END PGP SIGNATURE=====
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Current best complexity for factoring?
Date: Wed, 18 Apr 2001 21:03:43 GMT
"Terry Boon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 11 Apr 2001 06:37:36 GMT, Samuel Paik <[EMAIL PROTECTED]> wrote:
> >Claus Näveke wrote:
> >> How are these primes generated? I thought they are too big for doing
> >> math-operations with them...
> >
> >The second question first. Use multi-word computations--limit is only
> >memory and time.
> >
> >Generally, pick random odd n-bit number (this means the high order
> >bit and low order bit are set to 1 and the rest of the bits are chosen
> >randomly). Test for probabilistic primality. If not prime, increment by
2
> >and go to test, otherwise, accept as prime.
>
> I've seen this method suggested elsewhere as well...
>
> Does this not bias the "random" selection of a prime towards primes
> which come after a long run of composites?
Why would it do that?
Try N=9, 9 is not prime but 11 is... or 21, or etc..
> (And, furthermore, is this effect significant? I wonder if I've got a
> pmf for the spacing between primes somewhere in my bookshelf...)
>
> I suspect that the answers to these two questions are "Yes" and "No"
> respectively.
I think the answer is no and no.
There is no truly random way to pick primes... only ones based on secure
prngs...
Tom
------------------------------
From: "Dale King" <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: I took the $5000 Goldman Challenge
Date: Wed, 18 Apr 2001 16:06:36 -0500
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] wrote in <9bkoag$adl$[EMAIL PROTECTED]>:
>
> >Dale King <[EMAIL PROTECTED]> wrote:
> >
> >> I agree with what you meant, but your terminology and understanding of
> >> information theory is a bit wrong. There really isn't such a thing as
> >> random and non-random data. There are random and non-random data
> >> sources.
> >
> >Actually, that's not true. That's the Shannon Information Theory view
> >of things, but it's not the whole picture.
> >
> >While Kolmogorov complexity is usually mentioned here in the context
> >of data compression, the original work was done to define precisely
> >what is meant by "random data" (*NOT* random sources). Kolmogorov
> >complexity in fact gives a very nice theory and definitions for what
> >we mean by "random data" versus "non-random data"...
> >
>
> I think the problem with King is like if he was taught Eucliden
> Geomtry in school. So everything is formulated towards that. THen
> when he get comfronted with something more suited to Projective
> Geometry he would get lost. Its hard to mix the two geometres so
> I try to be of the type uses which ever one fits the problem.
> One has to be flexable.
You don't need to go beyond euclidian geometry to show that something is
untrue according to euclidian geometry. Kolmogorov did not disprove or
replace Shannon. Your claims are incorrect according to Shannon, going to
Komogorov won't make them right any more than going to projective geometry
will allow you to disprove the pythagorean theorem.
And I do know a bit more than Euclidean geometry. I do have a Master's
degree in computer science, so quit treating me like a kid that doesn't know
Shannon from Kolmogorov.
> The word random is a nasty word whose meaning is very vague
Which is why I responded as I did to try to clear up the difference.
Kolmogorov is concerned with how to represent one given file, compression is
based on information theory which tries to compress data from a source.
> many times people think of it in the Shannon sense and yet they
> are using it in the K complexity sense but the fact is they are
> not the same. And I think it leads to strange results.
> Example supose one is using a OTP should one check to see if
> the string is K complex enough. I feel most would say yes.
> They may even eye the data to see if if looks random. They
> may than apply the OTP to the data and then do another check
> to see if it "looks" random. But if Shannon is correct should
> one check at all since any sequence is as likely as any other
> to be the output of a "uniformly random source". Also
> if you make the set of possible OTPs smaller then when one
> decrypts you are reducing the set of possible messages to
> choose from. What is one really to do or make of this?
But my point was that if you had a source that produced only strings that
had a high K complexity it is possible to write a compressor that compressed
the data from that source. The entropy is basically decreased because while
any particular file seems random as it has a high K complexity, the source
is not random because it will not produce messages with low K complexity.
And also Kolmogorov included the size of the program, but in the compression
case we are not counting the size of the decompressor.
That is basically what I thought the OP was trying to say, but didn't quite
word it correctly.
--
Dale King
------------------------------
From: "Shah Karim" <[EMAIL PROTECTED]>
Subject: Crypto question
Date: Wed, 18 Apr 2001 16:18:18 -0500
OK I am a crypto newbie, and while doing some reading on public key
cryptography and digital signatures, I ran into something which puzzles me :
Given:
1) In public key cryptography there are 2 keys, private key and public key,
and only the public key is published. So anyone can send a message to an
intended recipient using that recipient's public key to encrypt that
message. However, only the intended recipient can decode that message
because they have the private key.
2) In sending a digital signature, the sender computes a message digest from
the message to be sent, using for example a one-way hash function. This
digest is encrypted using the sender's *private* key, yielding a digital
signature. This signature, along with the original message to be sent, is
encrypted using the intended recipient's public key and sent.
3) The recipient uses his private key to extract the message and the
encrypted digital signature. Now to verify the signature, the recipient
decrypts it using the sender's *public* key, yielding the original message
digest. He also takes the received message and computes the digest using the
same one-way hash function. Lastly he compares the two digests to make sure
that they match, ensuring the message has not been tampered with in
transmission.
The problem I have is where the receiver decodes the sender's digital
certificate: How can the receiver decode something that is encoded with the
sender's *private* key? To put it another way, Alice encodes a message using
her *private* key and sends it to Bob. How can Bob decode that message using
Alice's *public* key? Is this normal? My understanding is that Alice can
only encode messages using Bob's public key, and Bob then will decode that
message using his private key.
Can anyone explain/ comment on this? Thanks.
------------------------------
From: "Tom Gutman" <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: I took the $5000 Goldman Challenge
Date: Wed, 18 Apr 2001 14:58:18 -0700
Reply-To: "Tom Gutman" <[EMAIL PROTECTED]>
"Dror Baron" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On 18 Apr 2001, SCOTT19U.ZIP_GUY wrote:
>
> > I think the problem with King is like if he was taught
Eucliden
> > Geomtry in school. So everything is formulated towards that.
THen
> > when he get comfronted with something more suited to Projective
> > Geometry he would get lost. Its hard to mix the two geometres so
> > I try to be of the type uses which ever one fits the problem.
> > One has to be flexable.
>
> Dude, I rest my case. That's like cheating whichever
> way works best for any given problem.
>
That's kind of weird! So you think it's like cheating for me to
decide whether I should use a hammer or a screwdriver after
examining the fastener?
--
Tom Gutman
------------------------------
From: [EMAIL PROTECTED] (Ben Cantrick)
Subject: Re: Crypto question
Date: 18 Apr 2001 16:10:32 -0600
In article <9bl0dm$[EMAIL PROTECTED]>,
Shah Karim <[EMAIL PROTECTED]> wrote:
>The problem I have is where the receiver decodes the sender's digital
>certificate: How can the receiver decode something that is encoded with the
>sender's *private* key? To put it another way, Alice encodes a message using
>her *private* key and sends it to Bob. How can Bob decode that message using
>Alice's *public* key? Is this normal? My understanding is that Alice can
>only encode messages using Bob's public key, and Bob then will decode that
>message using his private key.
>
>Can anyone explain/ comment on this? Thanks.
As mind-boggling as it sounds, this "encrypt with private key/decrypt
with public key" is a known feature of the RSA public key encryption
system.
You can encrypt with either the public key OR the private key, and then
only the other key of the pair can decrypt the message.
It's hard to accept at first, but remember - they're both keys. And what
is encrypted with one can (only) be decrypted with the other. That's how
the cryptosystem was designed, and that's how it works.
The mathematics neither knows nor cares if it's using a "public" or
"private" key. "Public" and "private" are distinctions made mostly for
human convenience.
If you're interested in the actual math, try section 1 of Route's
excellent PGP Hack FAQ: http://www.stack.nl/~galactus/remailers/attack-2.html
-Ben
--
Ben Cantrick ([EMAIL PROTECTED]) | Yes, the AnimEigo BGC dubs still suck.
BGC Nukem: http://www.dim.com/~mackys/bgcnukem.html
The Spamdogs: http://www.dim.com/~mackys/spamdogs
"If I had a penny for my thoughts I'd be a millionaire." -Mike D
------------------------------
From: "Carsten Alexander" <[EMAIL PROTECTED]>
Subject: Re: Crypto question
Date: Thu, 19 Apr 2001 00:12:24 +0200
> sender's *private* key? To put it another way, Alice encodes a message
using
> her *private* key and sends it to Bob. How can Bob decode that message
using
> Alice's *public* key? Is this normal? My understanding is that Alice can
> only encode messages using Bob's public key, and Bob then will decode that
> message using his private key.
Well, it may be somehow confusing, but the private key is called "private"
not because it's a special key with a special structure. It's called
"private" because the key is kept (at least is to keep) secret. Actually
both keys depend on each other. But that dependency can not be deduced
without some special information, which is also kept secret (or is destroyed
after the keypair was generated. Both keys can be used for encryption and
decryption in the same way but with another intention.
Someone can encrypt a message using your public key and only can decrypt it,
because your private key is kept secret. You can also encrypt a message
using your own private key and that message can only be decrypted by using
your public key. Since your private key is kept secret, you and only you can
encrypt it. If this encrypted message can be decrypted by using your public
key, it's the evidence that you encrypted that message.
Got the big picture?
--
Carsten Alexander
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: GSM Encryption and Authentication
Date: 18 Apr 2001 22:16:02 GMT
"A8" is a name that's a placeholder for an authentication algorithm.
The authentication algorithm can be freely chosen by the provider.
The GSM standard provides (provided?) an example algorithm called
COMP128 that most providers used by default. Then weaknesses were
found in COMP128. Today, I don't know how many providers still use
COMP128 or a derivative. Yes, hard information seems hard to come
by. I believe that at least one provider out there uses 3DES-CBC-MAC,
which should be a much stronger algorithm.
The key generation and authentication algorithm (A3/A8; usually the
same algorithm) is implemented in the SIM. The voice privacy
encryption algorithm (A5/1, A5/2, or A5/0, depending on where you
are) is implemented in the handset. So: Replacing A3/A8 can be done
on a per-user basis by replacing the SIM and upgrading just your
provider's software (but not the software of any other provider
you might obtain roaming service from). Replacing A5, in contrast,
requires replacing all GSM handsets and base stations throughout
the world.
Note that 3GPP---the next-generation follow-on to GSM---has released
many more details about their system and the cryptographic algorithms
they use, which is (IMHO) a valuable step forward. I consider it much
less likely that the cipher (KASUMI) used in 3GPP will be attacked
the same way COMP128 was.
Note also that it is not clear to me whether the above cryptographic
weaknesses are routinely exploited, or what their financial impact is.
(The answers at present might well be "no, and effectively none".)
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Crypto question
Date: Wed, 18 Apr 2001 17:17:37 -0500
> The problem I have is where the receiver decodes the sender's digital
> certificate: How can the receiver decode something that is encoded with
the
> sender's *private* key? To put it another way, Alice encodes a message
using
> her *private* key and sends it to Bob. How can Bob decode that message
using
> Alice's *public* key? Is this normal? My understanding is that Alice can
> only encode messages using Bob's public key, and Bob then will decode that
> message using his private key.
If she ONLY encrypted in her private key then anyone could decrypt the
message with her public key. She has to use both her private key AND Bob's
public key. Think of the key pairs as mathematical function "reciprocals".
The public key "flips" the private key and vice versa.
------------------------------
From: "M.S. Bob" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 22:59:07 +0100
Mark G Wolf wrote:
>
> Please don't bother telling me you can't reuse a one time pad.
>
> If I had a "large" one time pad and used random fixed size "chunks" of it to
> essentially generate other one time pads to encrypt the exact same message,
> what would be the relationship between the time (given a fixed speed of
> computation) to break the coded message and the size of the pad, the size of
> the chunks, and the number of times the pad is reused.
How does one decipher such an algorithm?
Let me state it this way, which is roughly what you said.
Let K be a bitstring of length n, which is the key. This is securely
exchanged between both parties (Alice and Bob of course). To encipher a
message M of length p, where p <= n, randomly selected bits of K are
used to encipher message M by
for i = 1 to p
c_i = m_i ^ k_rand[i]
^ means exclusive-or
and the ciphertext is C.
I don't see how Bob can decrypt the message without knowing the which
key bits Alice used to encipher the message.
If this "random selection" is based on a function, then it is not
random, and we can analysis this unspecified function for weaknesses.
=================================
Ignoring your 'random fixed size "chunks"' -- since this is not specific
enough to encipher and decipher.
If the key is length n, and the message is at least 2n -- that is each
bit is reused (in sequence) only twice, then using simple comparison,
the key material can be recovered and the message can be read in a
trivial amount of time.
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 17:32:56 -0500
> Let K be a bitstring of length n, which is the key. This is securely
> exchanged between both parties (Alice and Bob of course). To encipher a
> message M of length p, where p <= n, randomly selected bits of K are
> used to encipher message M by
> for i = 1 to p
> c_i = m_i ^ k_rand[i]
>
> ^ means exclusive-or
> and the ciphertext is C.
>
> I don't see how Bob can decrypt the message without knowing the which
> key bits Alice used to encipher the message.
>
> If this "random selection" is based on a function, then it is not
> random, and we can analysis this unspecified function for weaknesses.
Let's just call it the secret sauce.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: A practical idea to reinforce passwords
Date: 18 Apr 2001 23:01:02 GMT
In <9bksje$1a8q$[EMAIL PROTECTED]> "Mark G Wolf"
<[EMAIL PROTECTED]> writes:
]> ]Sounds like a pretty good idea to me. In fact it's something I've been
]> ]thinking about quite a bit lately. The idea that the intended recipient
]or
]> ]user actually has to do some brute force work to decrypt messages to
]enhance
]> ]security. In fact I'm often surprised it's not mentioned more often.
]Gee,
]>
]> I do not see how it enhances security. If the far side does not know
]> your key, then he has to brute force the whole thing anyway. If he does,
]> it is no harder for him than you. Ie, what advantage does your not
]> knowing what your own key is (in part) give you?
]I was thinking more in general. As far as the password thing goes, it
]depends on the login process. For instance it could be a kind of Kerberos
]interaction between your password and smartcard. In that case you're kind
]of sending a message to yourself. You can use a simple to remember password
]which gets padded by the server so that if someone should get at your card
]temporarily they couldn't compromise the card as easily. The whole point is
]that server doesn't know your logon without both getting your password and
]smartcard. You can make your password easier to remember at the expense of
]a longer logon process.
]There's that Trinity thing again. Hey you think them Catholics know
]something the others don't.
Sorry, still does not make sense. If neither you not the other side know
the extra stuff, then an attacker can stick in arbitrary junk and the
other side does not know that it is arbitrary junk. Ie, the attacker
need just guess your simple password, and stick on junk and your machine
will accept it. If the additional stuff is known by the far side, then
this is no different from a longer password.
Kerberos works because there is a known secret between the machines.
That secret must be known to both systems. It is just a "longer
password".
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: There Is No Unbreakable Crypto
Date: 18 Apr 2001 23:05:29 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (John
Savard) writes:
]On 17 Apr 2001 21:16:24 GMT, [EMAIL PROTECTED] (David Wagner)
]wrote, in part:
]>Mok-Kong Shen wrote:
]>>I continue to think, as said in another post, that this
]>>means one can generate from, say, 128 random bits, a
]>>secure bit string of infinite length, which seems to
]>>be very counter-intuitive.
]>Well, not infinite: only polynomial length, and only _if_
]>you have a secure, length-doubling PRG. But yes, it's a
]>marvelous, counter-intuitive, beautiful result.
]And, unless a brute-force search of a 128-bit key is possible, there
]doesn't seem to be anything that implausible about such a result.
But the brute force search sets the upper limit on the strength. Thus
the bit string is no more secure than 128 bits.
I have no idea what a "secure length-doubling PRG" is. This is using the
word "secure" in a sense which is unfamiliar. To me a "secure bit string
of L length" is a bit string which cannot be determined by any
information of length less than L.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Reusing A One Time Pad
Date: 18 Apr 2001 23:07:33 GMT
In <9bl4od$5qgq$[EMAIL PROTECTED]> "Mark G Wolf"
<[EMAIL PROTECTED]> writes:
...
]> I don't see how Bob can decrypt the message without knowing the which
]> key bits Alice used to encipher the message.
]>
]> If this "random selection" is based on a function, then it is not
]> random, and we can analysis this unspecified function for weaknesses.
]Let's just call it the secret sauce.
Ah. It is called "Snake Oil".
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
