Cryptography-Digest Digest #963
Cryptography-Digest Digest #963, Volume #13 Wed, 21 Mar 01 15:13:01 EST
Contents:
Re: unbreakable code (Benjamin Goldberg)
Re: Fast and Easy crypt send (Hard)
Re: unbreakable code ("Tom St Denis")
Re: redodancy (Fermat)
[OT] Java (Benjamin Goldberg)
New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged (Bob C.)
Re: Most secure way to add passphrase verification to "CipherSaber" (Benjamin
Goldberg)
Re: [OT] Java (Jeffrey Williams)
Re: redodancy (Benjamin Goldberg)
Re: [OT] Java ("Tom St Denis")
Re: What happens when RSA keys don't use primes? (Doug Stell)
Re: I was so so right about PGP ... so right when I started writing(Frank
Gerlach)
Re: NSA in the news on CNN (John Hairell)
Re: I was so so right about PGP ... so right when I started writingabout PGP and
about one author so right . ("Mxsmanic")
Re: I was so so right about PGP ... so right when I started writing about PGP and
about one author so right . ("Mxsmanic")
Re: What happens when RSA keys don't use primes? ("Mxsmanic")
Re: What happens when RSA keys don't use primes? ("Mxsmanic")
Re: What happens when RSA keys don't use primes? ("Mxsmanic")
Re: Popular Mechanics article on NSA ("Mxsmanic")
Re: Advice on storing private keys (SCOTT19U.ZIP_GUY)
From: Benjamin Goldberg [EMAIL PROTECTED]
Subject: Re: unbreakable code
Date: Wed, 21 Mar 2001 18:38:07 GMT
Tom St Denis wrote:
"dexMilano" [EMAIL PROTECTED] wrote in message
news:99ad0o$dorm$[EMAIL PROTECTED]...
For the others
"
About all Rabin's scheme buys you is that you don't have to know
how to build a decent random number generator. In all other respects
it's just a standard one-time pad.
-Ben
".
Whoever said the above is a friggin liar. The BBS generator (or any
other SQRT type thing) is not like an OTP at all.
Tom
Umm, Tom, he's talking about Rabin's *recent* scheme, where both parties
are listening to a high speed source of truly random bits, and use a
cheap, otherwise insecure, PRNG to tell how many bits to skip/take from
this source. He's NOT talking about the rather older RSA-like scheme,
where the message is squared, mod some n=pq.
--
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.
--
From: [EMAIL PROTECTED] (Hard)
Subject: Re: Fast and Easy crypt send
Date: Wed, 21 Mar 2001 18:44:29 GMT
you can prepend "rank " to your handle.
that will clear it up.
--
From: "Tom St Denis" [EMAIL PROTECTED]
Subject: Re: unbreakable code
Date: Wed, 21 Mar 2001 18:47:25 GMT
"Benjamin Goldberg" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
Tom St Denis wrote:
"dexMilano" [EMAIL PROTECTED] wrote in message
news:99ad0o$dorm$[EMAIL PROTECTED]...
For the others
"
About all Rabin's scheme buys you is that you don't have to know
how to build a decent random number generator. In all other respects
it's just a standard one-time pad.
-Ben
".
Whoever said the above is a friggin liar. The BBS generator (or any
other SQRT type thing) is not like an OTP at all.
Tom
Umm, Tom, he's talking about Rabin's *recent* scheme, where both parties
are listening to a high speed source of truly random bits, and use a
cheap, otherwise insecure, PRNG to tell how many bits to skip/take from
this source. He's NOT talking about the rather older RSA-like scheme,
where the message is squared, mod some n=pq.
Whoopsy doodle... hehehe I wasn't following the thread that closely...
Sorry..
Tom
--
From: Fermat [EMAIL PROTECTED]
Subject: Re: redodancy
Date: Wed, 21 Mar 2001 19:52:13 +0100
Something like this?
n= function_countstrings()
i=0
Repeat
[
i=i+1
word(i) = word_to_compare
for j= 1 to i-1
( if word(j)=word_to_compare
then function_Remove redundance (word_to_compare)
)
for j=i+1 to n
(if word(j)=word_to_compare
then function_Remove redundance (word_to_compare)
)
]
until i=n
dexMilano wrote:
Is there some simple algoritm to remove redodancy in text?
I tried ZIP but it's too heavy.
Thx
dex
--
From: Benjamin Goldberg [EMAIL PROTECTED]
Subject: [OT] Java
Date: Wed, 21 Mar 2001 18:56:32 GMT
Tom St Denis wrote:
[snip]
Sorry this is OT but...
JAVA sucks... it's slow, non-portable and gives errors on anything a
normal C compiler would just warn you about. It's hard to develop
software for...
Tom
Absolutely! I mean, I try to assign a pointer to int to a pointer to
floa
Cryptography-Digest Digest #963
Cryptography-Digest Digest #963, Volume #8 Mon, 25 Jan 99 20:13:02 EST
Contents:
Re: Random numbers from a sound card? (Paul Rubin)
Re: Metaphysics Of Randomness (Patrick Juola)
Re: The Performance of Meet-in-the-Middle ([EMAIL PROTECTED])
Re: Metaphysics Of Randomness (Patrick Juola)
Re: Random numbers from a sound card? (Nathan Kennedy)
Re: Random numbers from a sound card? (R. Knauer)
Would the gentleman with Mondex knowledge in the USA please contact me again.
("Simon Copsey")
Re: S-box cycles (Anthony)
Re: [req]:Cryptanalysis tool - word pattern table (©ú¥Õ)
Unicity, DES Unicity and Open-Keys ([EMAIL PROTECTED])
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Random numbers from a sound card?
Date: Mon, 25 Jan 1999 21:21:09 GMT
In article [EMAIL PROTECTED],
David Ross [EMAIL PROTECTED] wrote:
Has anyone had success using a sound card (like a Sound Blaster) to
generate streams of random numbers?
Yes, see http://www.lila.com/nautilus/index.html and download the
source from one of the sites mentioned there.
What sort of audio source would you suspect would be the best to use
in generating random numbers?
We ask the user to blow into the microphone to make noise, IIRC.
How would you test the 'quality' of the generated random number
stream?
We just test the total amount of energy in the audio to make sure
the mic isn't dead. We expect that the raw audio will have lots
of correlation, so we run it through a hash function or block cipher;
I don't remember the details.
--
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: Metaphysics Of Randomness
Date: 25 Jan 1999 09:07:36 -0500
In article [EMAIL PROTECTED],
What is the actual likelihood of a readable text string
being output from an OTP? Most of the encrypted files
I've looked at contained very few readable strings of
even two characters. I would think that a readable
string output would be more likely to be the result of
an accidental transmission of plaintext or a zero key
than it would be the result of a readable string
encrypting to another readable string.
To answer this precisely you need to provide a definition of "a readable
text string". In terms of letters and spaces in ASCII the odds would be
(65/265)^N where N is the length of the string of text. Of course this
formula treats upper and lower case as similar so it includes WiErD
STRingS liKE thiS One.
(n.b. -- if the message I receive reads "attacd at
nown", and you use
a stronger filter of never allowing six successive
zeros, then I can
still unbutton your message. The reason being the pad
necessary to
produce "attack at noon" would be an illegal pad --
and hence you're
still attacking at dawn).
Is this an indication of a "fatal flaw" in the OTP?
From what I've read in this newsgroup, it appears that
much of an analyst's work is discovering how plaintext
is leaked into the ciphertext. With the OTP, any byte
of zero in the key leaks a plaintext character, and
that would seem to make analysis possible. Or, as
described here, maybe easy. On the other hand, if I
knew that the only two possible messages were "attack
at noon" and "attack at dawn", I wouldn't bother
worrying about which the message specified. I'd already
know enough to prepare for an attack.
This isn't an indication of a fatal flaw in the OTP. The reason is,
bluntly, that the amount of "leakage" produced by a zero character
in the bad -- or even a zero bit in the pad -- is *exactly* balanced
by the amount of "false leakage" where something it put into the
pad. So if you see an 'E' in the cyphertext, you have no way of knowing
whether or not this is a leaked 'E' or a spurious 'E' created by
something else XORing to E.
And, in fact, if this "leakage" *weren't* there, then you would KNOW
every time you saw an 'E' that the plaintext letter COULDN'T be an 'E',
which would be a significant weakness..
As to whether or not the loss of entropy is
significant to make a
practical difference -- that depends on the degree
of filtering.
What you do really buy by doing the filtering? Not
much --- and
every time the filter triggers introduces a
weakness.
Among other things, a crypto system needs to inhibit
the identity operation on
plaintext. I.e., the idea of a crypto system that
includes the possibility that
ciphertext == plaintext has a flaw. Mathematically,
the system including the
possibility is infinitesimally "stronger" due to the
larger search space, but
that's not the unit of measure for crypto strength.
See what I mean? Both paragraphs above make sense and
sound right. There are (simplistically) only four
possibilities:
The first is wrong and the second is right.
The first is right and the second is wro
