Cryptography-Digest Digest #175, Volume #14 Wed, 18 Apr 01 14:13:00 EDT
Contents:
Re: "UNCOBER" = Universal Code Breaker (John Savard)
Re: Proof of RSA (Bill Unruh)
Re: "UNCOBER" = Universal Code Breaker (Volker Hetzer)
Re: Lorentz attractor... (Mike Rosing)
Re: "UNCOBER" = Universal Code Breaker (Volker Hetzer)
Re: "UNCOBER" = Universal Code Breaker (Volker Hetzer)
Re: C code for GF mults (Mok-Kong Shen)
Re: A practical idea to reinforce passwords ("Mark G Wolf")
Re: Reusing A One Time Pad (SCOTT19U.ZIP_GUY)
Re: A practical idea to reinforce passwords ("Mark G Wolf")
Re: A practical idea to reinforce passwords ("Mark G Wolf")
Re: Reusing A One Time Pad ("Tom St Denis")
Re: C code for GF mults (David Eppstein)
Re: A practical idea to reinforce passwords ("Tom St Denis")
[NEWS] PGP broken (maybe) (Fight Boschloo)
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: Reusing A One Time Pad ("Tom St Denis")
Re: A practical idea to reinforce passwords ("Paul Pires")
Re: A practical idea to reinforce passwords (Mok-Kong Shen)
Re: There Is No Unbreakable Crypto (Mok-Kong Shen)
Re: Reusing A One Time Pad ("Mark G Wolf")
Re: A practical idea to reinforce passwords ("Mark G Wolf")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 16:56:02 GMT
On Wed, 18 Apr 2001 12:07:29 -0300, newbie <[EMAIL PROTECTED]>
wrote, in part:
>The more important is to bring ideas.
True, but since you _are_ a newbie, would it not seem reasonable that
perhaps you should learn more before others will think it likely your
ideas are of interest?
I think people critical of your posts are much more concerned about
your lack of background on some important points in cryptography than
they are with your language skills.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Proof of RSA
Date: 18 Apr 2001 16:57:47 GMT
In <[EMAIL PROTECTED]> sianglin <[EMAIL PROTECTED]> writes:
>Can someone prove that, in RSA, D(E(M)) = M where M=message,
>E=Encryption, D=Decryption?
Would not be worth too much if this were not true, would it?
Uses
If A<pq (where p,q primes) and ed=1 mod(p-1)(q-1)
then
A^(ed)=A mod pq
A^e mod pq is the encrypted text. Then (A^e mod pq)^d mod pq = A^ed mod pq
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 19:12:34 +0200
newbie wrote:
>
> What is important is not to find all the key.
> You have to analyse the context of the plain-text.
> You are not going to find a word "homo erectus " in business letter. It
> is quite impossible.
But that won't help you. Given the size and address of the letter
everything you can learn from the letter is in your hand. You
might guess that the first five letters are "Dear " but you won't need the
encrypted letter for that, right? And after having finished guessing you have
no way to verify that's indeed "Dear " and not "Hated".
So, if you know it's a business letter, all you now is indeed "It's a
business letter.". Nothing more.
> But dollars yes, company, yes etc...
> Algo to decrypt OTP :
> - look for words used in the context (business, personal, etc...)
> - try to slide the corresponding bit-string on ciphertext until it
> matches.
> - build the disclose little by little.
>
> If you try to find the key, it is a wrong strategy.
Ok, here's an example:
Message is "1" (one Bit)
Key is "0"
Ciphertext is: "1"
Now, given only the ciphertext, what would the plaintext be?
Repeat for any number of encrypted bits.
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Lorentz attractor...
Date: Wed, 18 Apr 2001 11:57:01 -0500
"Douglas A. Gwyn" wrote:
>
> Richard Heathfield wrote:
> > It was, in fact, a young tabby kitten who engineered the only
> > ciphertext-based OTP break in history. The incident is shrouded in
> > suspicious mystery, but we *can* be sure that the kitten in question
> > belonged to a Mr Schroedinger. What he did to the kitten, when he
> > discovered that it had learned his secret, remains uncertain.
>
> We don't even know if the cat in question is still alive.
You gotta have a smiley with that! :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 19:16:45 +0200
newbie wrote:
>
> OTP is theorically unbreakable.
> You forget the context where the word occur.
> I gave some samples in my last post to Mister Savard.
It's not about forgetting the context.
The fact is that given the context and the message
you know *exactly* as much about the letter as if you've
been given the context and just the length of the letter.
It's impossible to learn more.
Therefore the encrypted letter provides no information to you.
Therefore you can't break the OTP that way.
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: "UNCOBER" = Universal Code Breaker
Date: Wed, 18 Apr 2001 19:28:07 +0200
newbie wrote:
>
> What is yabbing? I did not find it in my humble dictionary
> I found yaping. Only dog yap. I'm not dog.
> I'm newbie.
Tom has an unfortunate tendency to lose control at the same time
he loses patience. Nevertheless he's right in that you
are talking nonsense without realizing it.
The security of the OTP has been proven about 60 years ago.
OTP breakers are usually sorted into the same drawer than
perpetuum mobile builders and circle squarers. In fact,
an OTP break is even less possible than a perpetuum mobile because
the thermodynamic laws are derived from experience only whereas
the OTP is maths and therefore provable in an absolut sense.
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: C code for GF mults
Date: Wed, 18 Apr 2001 19:13:30 +0200
David Eppstein wrote:
>
> GF(256) (and GF(2^2^k) more generally) also has an interesting
> representation devised by J.H.Conway that I think may not fit into the
> usual polynomials-mod-primitive-polynomial framework:
> see http://www.ics.uci.edu/~eppstein/numth/nim.shar.gz
> for (C++) code.
Could you give the reference to Conway's paper? Thanks.
M. K. Shen
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 11:57:47 -0500
> My idea is that upon selecting a password, X bits of
> random data is added to the password. You are not
> informed of what these bits are, nor does the computer
> store them. The computer only stores how many bits
> there are, and brute-forces them every time you enter
> you password.
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 wonder why. Most methods today assume that the intended receiver just
computes what he receives with the given key. So if the person doing the
intercepting has more powerful computers than you do, he has an advantage in
that he is more likely to decrypt your messages before you decrypt his.
Assuming you were in some kind of war. But! If you partially encrypted
your messages with a key or portions of a key which even you didn't know,
the unintended receiver would have a much difficult time than the intended
one. This would effectively balance the power between computers, assuming
he wasn't doing the same thing, which of course he is. I think it's a
splendid idea.
If computer A is faster than computer B, and both add random bits to some
key or method, can you find and are there certain algorithms that make it
much more difficult for the unintended receiver such that the faster
computer would not have an advantage?
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Reusing A One Time Pad
Date: 18 Apr 2001 17:14:58 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in
<fLiD6.43031$[EMAIL PROTECTED]>:
>"Modestly large OTP" is a meaningless description. An OTP must by
>definition be the same size as the message. And if it's a true OTP you
>need not encrypt it any "further" to get a more secure system, it's
>already provably secure.
>
Actually an OTP does does not have to be the same size as the
message sent. Suppose one defines the set of all messages that
one wants to encrypt to be 1000 bytes max. By 1000 bytes I mean
that is the length after compression and the bijective padding
transformtion to get the data to exactly 1000 bytes. At this point
you use 1000 fresh bytes of your OTP to encode the message. This
would be far more secure than using a OTP on the message and
leaving the length information there for the taking.
Many miss use the meaning of OTP. The idea is to give no additional
knowledge about the message as if the message is never sent. If
one always left the message the size of the input file that is
giving information away about the message. Since one can only send
finite file sizes you should pick a size that is large enough for
most messages. I would extend it to allow for larger files on
rare occasions but that adds some information since it longer than
most of your messages.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 12:16:49 -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 wonder why. Most methods today assume that the intended receiver just
computes what he receives with the given key. So if the person doing the
intercepting has more powerful computers than you do, he has an advantage in
that he is more likely to decrypt your messages before you decrypt his.
Assuming you were in some kind of war. But! If you partially encrypted
your messages with a key or portions of a key which even you didn't know,
the unintended receiver would have a much difficult time than the intended
one. This would effectively balance the power between computers, assuming
he wasn't doing the same thing, which of course he is. I think it's a
splendid idea.
If computer A is faster than computer B, and both add random bits to some
key or method, can you find and are there certain algorithms that make it
much more difficult for the unintended receiver such that the faster
computer would not have an advantage?
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 12:08:51 -0500
> My idea is that upon selecting a password, X bits of
> random data is added to the password. You are not
> informed of what these bits are, nor does the computer
> store them. The computer only stores how many bits
> there are, and brute-forces them every time you enter
> you password.
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 wonder why. Most methods today assume that the intended receiver just
computes what he receives with the given key. So if the person doing the
intercepting has more powerful computers than you do, he has an advantage in
that he is more likely to decrypt your messages before you decrypt his.
Assuming you were in some kind of war. But! If you partially encrypted
your messages with a key or portions of a key which even you didn't know,
the unintended receiver would have a much difficult time than the intended
one. This would effectively balance the power between computers, assuming
he wasn't doing the same thing, which of course he is. I think it's a
splendid idea.
If computer A is faster than computer B, and both add random bits to some
key or method, can you find and are there certain algorithms that make it
much more difficult for the unintended receiver such that the faster
computer would not have an advantage?
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 17:30:35 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <fLiD6.43031$[EMAIL PROTECTED]>:
>
> >"Modestly large OTP" is a meaningless description. An OTP must by
> >definition be the same size as the message. And if it's a true OTP you
> >need not encrypt it any "further" to get a more secure system, it's
> >already provably secure.
> >
>
> Actually an OTP does does not have to be the same size as the
> message sent. Suppose one defines the set of all messages that
> one wants to encrypt to be 1000 bytes max. By 1000 bytes I mean
> that is the length after compression and the bijective padding
> transformtion to get the data to exactly 1000 bytes. At this point
> you use 1000 fresh bytes of your OTP to encode the message. This
> would be far more secure than using a OTP on the message and
> leaving the length information there for the taking.
Um no actually you're wrong. Even given the length of the message you
cannot break an OTP. Knowing the length does not give you any useful
information about the actual message other than's it's length.
This could be used if you are replying with "yes" or "no" but real english
is typically larger... thus given say 96 random bits (12 ascii chars) you
can't easily figure out the message because it would be about 3 words and
could say anything...
As a side note, compressing the message is just aform of encoding. For
example, you could say that the message is compressed using ASCII instead of
lineart (row-major data) to store the characters... In either case if a OTP
was used both would be EQUALLY as secure.
Tom
------------------------------
From: David Eppstein <[EMAIL PROTECTED]>
Subject: Re: C code for GF mults
Date: Wed, 18 Apr 2001 10:08:47 -0700
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> David Eppstein wrote:
> >
> > GF(256) (and GF(2^2^k) more generally) also has an interesting
> > representation devised by J.H.Conway that I think may not fit into the
> > usual polynomials-mod-primitive-polynomial framework:
> > see http://www.ics.uci.edu/~eppstein/numth/nim.shar.gz
> > for (C++) code.
>
> Could you give the reference to Conway's paper? Thanks.
It's a book.
J. H. Conway. On Numbers and Games. Academic Press, 1976.
Chapter 6: The Curious Field On_2, pp. 50-63.
The Academic Press edition is long out of print, but there's now a 2nd
edition out (2000) from AK Peters:
http://www.amazon.com/exec/obidos/ASIN/1568811276
I don't know if the page numbers are the same, but I assume it has the same
material.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 17:31:51 GMT
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9bkh4b$2e60$[EMAIL PROTECTED]...
> > My idea is that upon selecting a password, X bits of
> > random data is added to the password. You are not
> > informed of what these bits are, nor does the computer
> > store them. The computer only stores how many bits
> > there are, and brute-forces them every time you enter
> > you password.
>
> 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 wonder why. Most methods today assume that the intended receiver just
> computes what he receives with the given key. So if the person doing the
> intercepting has more powerful computers than you do, he has an advantage
in
> that he is more likely to decrypt your messages before you decrypt his.
> Assuming you were in some kind of war. But! If you partially encrypted
> your messages with a key or portions of a key which even you didn't know,
> the unintended receiver would have a much difficult time than the intended
> one. This would effectively balance the power between computers, assuming
> he wasn't doing the same thing, which of course he is. I think it's a
> splendid idea.
>
> If computer A is faster than computer B, and both add random bits to some
> key or method, can you find and are there certain algorithms that make it
> much more difficult for the unintended receiver such that the faster
> computer would not have an advantage?
The reason this idea hasn't been done before is because it's stupid. Making
the intended receipient do more work then he/she should is a thing most
serious cryptographers try to avoid.
And this scheme still depends on the user entering a good password. (Read
my other reply in this thread).
Tom
------------------------------
Date: 18 Apr 2001 17:32:52 -0000
From: [EMAIL PROTECTED] (Fight Boschloo)
Subject: [NEWS] PGP broken (maybe)
Crossposted-To: alt.privacy.anon-server,alt.security-pgp
Sure Boschloo will announce that, now, to get some attention
===============================================
HISTORY:
That Boschloo bozo is a clown and a troll who has been looming around for nearly a
year.
Don't mistake a "regular" (troll) with a knowledgeable person: that self-proclaimed
"security expert" is not even a remailer user. In the past, he proved himself unable
to check a PGP signature, and got ridicule from every single technical topic he wante
d to talk about.
Besides false or inaccurate or misleading technical misinformation, his posts are
about his avowed mental illness, or for bashing remops or real freedom fighters: he
likes to quarrel with every one, and stir shit. Sometimes, it is even pure delirium
(whe
n he misses his pills?)
One of his last actions was to stage a hoax about his own suicide, just to try to grab
some sympathy, after he had been exposed as a troll and technically incompetent.
The worst being his teasing of Script-Kiddie until it triggered a new flood on apas.
Of course, he refuses to apologize.
Actually, the level of contempt he shows for remailer users:
they don't give their names, while he does
that can't do anything against him, without giving their names
is in no way different from what is displayed by Pangborn, Burnore and the like
Ignore him completely, killfile him, respect others' killfiles
KILLFILE:
To put him in your killfile, put "Author: Boschloo"
That will make disappear both him and people who warn about him
If you want to tell him to buzz off, or warn about him,
use a nickname containing "Boschloo" (Boschloo Hater, Boschloo Sucks,...)
to accomodate such killfile for "regulars", and still warn newbies
COURAGE:
Boschloo is getting _no_ answer from apas any more.
He has to crosspost to various newsgroups to try to grab some attention.
In a few months, it will be gone.
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 12:36:40 -0500
> [EMAIL PROTECTED] (Tom St Denis) wrote in
> <fLiD6.43031$[EMAIL PROTECTED]>:
>
> >"Modestly large OTP" is a meaningless description. An OTP must by
definition be the same size as the message. And if it's a true OTP you need
not encrypt it any "further" to get a more secure system, it's already
provably secure.
It seems my Prodigy server is skipping posters on me. I am using the
language rather loosely. My modestly large OTP is being "reused"
periodically in a variety ways for random bits, that's why I would encrypt
it further, among other things.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 17:43:13 GMT
"Mark G Wolf" <[EMAIL PROTECTED]> wrote in message
news:9bkjd6$5tqs$[EMAIL PROTECTED]...
> > [EMAIL PROTECTED] (Tom St Denis) wrote in
> > <fLiD6.43031$[EMAIL PROTECTED]>:
> >
> > >"Modestly large OTP" is a meaningless description. An OTP must by
> definition be the same size as the message. And if it's a true OTP you
need
> not encrypt it any "further" to get a more secure system, it's already
> provably secure.
>
>
> It seems my Prodigy server is skipping posters on me. I am using the
> language rather loosely. My modestly large OTP is being "reused"
> periodically in a variety ways for random bits, that's why I would encrypt
> it further, among other things.
Then it's not an OTP if use reuse the pad. Are you missing the replies or
just being plain ignorant?
Tom
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 10:47:32 -0700
Mark G Wolf <[EMAIL PROTECTED]> wrote in message
news:9bkh4b$2e60$[EMAIL PROTECTED]...
> > My idea is that upon selecting a password, X bits of
> > random data is added to the password. You are not
> > informed of what these bits are, nor does the computer
> > store them. The computer only stores how many bits
> > there are, and brute-forces them every time you enter
> > you password.
>
> 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 wonder why. Most methods today assume that the intended receiver just
> computes what he receives with the given key. So if the person doing the
> intercepting has more powerful computers than you do, he has an advantage in
> that he is more likely to decrypt your messages before you decrypt his.
> Assuming you were in some kind of war. But! If you partially encrypted
> your messages with a key or portions of a key which even you didn't know,
> the unintended receiver would have a much difficult time than the intended
> one. This would effectively balance the power between computers, assuming
> he wasn't doing the same thing, which of course he is. I think it's a
> splendid idea.
>
> If computer A is faster than computer B, and both add random bits to some
> key or method, can you find and are there certain algorithms that make it
> much more difficult for the unintended receiver such that the faster
> computer would not have an advantage?
It seems like a prudent thing to do if you can afford it but it doesn't do
much to help the problem that the original poster cited. That of a poor selection
for a password or logon. Its advantage is a *constant* multiplier of the work the
adversary has to do per guess. If it is applied to a horrid key, you've taken trivial
work to trivial work * 256 which could still be trivial. If it is a well chosen key it
goes from nasty to nasty * 256. The underlying problem isn't effected except in
some narrow boundry cases. I'd rather put the effort into using better keys.
What might be usefull is to force the work to be done on-line rather than off-line.
You have to do it in a place where the hash lives? I believe this is the rational
behind
other key stretching schemes I have seen but I still don't understand completely
how and why they work.
Paul
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 19:46:11 +0200
Mark G Wolf wrote:
>
> > My idea is that upon selecting a password, X bits of
> > random data is added to the password. You are not
> > informed of what these bits are, nor does the computer
> > store them. The computer only stores how many bits
> > there are, and brute-forces them every time you enter
> > you password.
>
> 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 wonder why. Most methods today assume that the intended receiver just
> computes what he receives with the given key. So if the person doing the
> intercepting has more powerful computers than you do, he has an advantage in
> that he is more likely to decrypt your messages before you decrypt his.
> Assuming you were in some kind of war. But! If you partially encrypted
> your messages with a key or portions of a key which even you didn't know,
> the unintended receiver would have a much difficult time than the intended
> one. This would effectively balance the power between computers, assuming
> he wasn't doing the same thing, which of course he is. I think it's a
> splendid idea.
>
> If computer A is faster than computer B, and both add random bits to some
> key or method, can you find and are there certain algorithms that make it
> much more difficult for the unintended receiver such that the faster
> computer would not have an advantage?
I wonder whether it is really that very exacting to require
the users to lengthen their passwords by 2 or 3 characters.
BTW, your server seems to have a problem. The same
post of yours appears three times.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: There Is No Unbreakable Crypto
Date: Wed, 18 Apr 2001 19:51:21 +0200
David Wagner wrote:
>
> 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.
I wonder whether it wouldn't be legitimate to consider
this as an indication that a secure length-doubling PRG
can't exist.
M. K. Shen
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Wed, 18 Apr 2001 13:01:54 -0500
> Then it's not an OTP if use reuse the pad. Are you missing the replies or
just being plain ignorant?
Ok I herby claim a Copyright on the following term for which I wish to be
credited when it becomes popular because it sounds "fun".
Crypto-Doodle Pad (CDP) - A file consisting of random bits, copies of which
are possessed by two or more people, used in conjunction with cryptological
algorithms for the exchange of ciphered information.
Crypto-Doodle Pad, cryptodoodle pad, cryptodoodle, CDP
Copyright � 2001 Mark G Wolf
------------------------------
From: "Mark G Wolf" <[EMAIL PROTECTED]>
Subject: Re: A practical idea to reinforce passwords
Date: Wed, 18 Apr 2001 13:07:18 -0500
> What might be usefull is to force the work to be done on-line rather than
off-line.
> You have to do it in a place where the hash lives? I believe this is the
rational behind
There's another dam good reason to do it that way.
------------------------------
** 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
******************************
