Cryptography-Digest Digest #167, Volume #14 Tue, 17 Apr 01 13:13:01 EDT
Contents:
Re: "I do not feel secure using your program any more." ("upyerkilt")
Re: Lorentz attractor... (Richard Heathfield)
Re: Publishing is *hard* ("John A. Malley")
Re: Publishing is *hard* ("John A. Malley")
Re: MS OSs "swap" file: total breach of computer security. (Richard Heathfield)
Re: Distinguisher for RC4 ("Scott Fluhrer")
Re: Distinguisher for RC4 ("Roger Schlafly")
Re: Note on combining PRNGs with the method of Wichmann and Hill (Mok-Kong Shen)
Re: Publishing is *hard* (Mok-Kong Shen)
Q: Choosing a Smartcard/Crypto Chip for PKI on Win2K ("Miguel Almeida")
Re: REAL OTP Systems (Mok-Kong Shen)
Re: Reusing A One Time Pad (SCOTT19U.ZIP_GUY)
Re: Reusing A One Time Pad (SCOTT19U.ZIP_GUY)
Re: Primality Testing Algorithm ("Jack Lindso")
Size of dictionaries (Mok-Kong Shen)
Re: "differential steganography/encryption" ("Paul Pires")
Re: Reusing A One Time Pad ("Tom St Denis")
Re: Reusing A One Time Pad ("Tom St Denis")
Re: REAL OTP Systems (Volker Hetzer)
----------------------------------------------------------------------------
Reply-To: "upyerkilt" <[EMAIL PROTECTED]>
From: "upyerkilt" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.misc,alt.hacker
Subject: Re: "I do not feel secure using your program any more."
Date: Tue, 17 Apr 2001 13:02:52 GMT
As you requested, Tom St Denis.
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:KoMC6.24724$[EMAIL PROTECTED]...
>
> "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > "I do not feel secure using your program any more."
> >
> > You sure jumped to a hasty conclusion.
>
> Who posed the quotation text? (BTW I may be in his killfile, so for fun
> could someone please just repost this message in it's completeness....)
>
>
> > For instance, one could suggest: "Why even generate these random
> > digit sequences using the OAP-L3 methods. I will just generate a
> > file containing nothing but the digit sequence 0123456789 repeated
> > until I have created a file of 18,144,000 bytes in length then I
> > will use the other methods from OAP-L3 to scramble these up to create
> > a random digit sequence."
>
> Why not juse use 0 and 1? for a binary system... I surely don't make files
> that are base10 in size...
>
> > You surely know that it won't take very many of these processes to
> > scramble up THIS file before the odds of guessing the final sequence
> > becomes practicably impossible to guess or analyze because there will
> > simply not be enough computing power available or time or energy to
> > accomplish this.
>
> Perhaps. Where does the source of entropy come from? What "mixing"
process
> is used? Not all mixing algorithms are equal. If only use 14 bits of
> entropy and a trivially stupid algorithm to shuffle the array it should be
> simple to figure out what the state is.
>
> > Again, using the methods of OAP-L3 to generate your random digit
> > sequences is just the first step of creating your OTPs. And since I
> > believe you would agree that even if you started with a known file
> > containing the sequences of 0123456789 of length 18,144,000 bytes
> > and this becoming very quickly practicably impossible to guess
> > using the methods from OAP-L3, then by actually generating the random
> > digit files using OAP-L3 makes this impossibility that much more
> > impossible.
>
> Unless the # of bits into OAP is the same as the # of bits out OAP can
never
> be a OTP (assuming OAP doesn't degrade the entropy). It's as simple as
> that.
>
> Again you assume that you shuffled your array with some good source of
> entropy at hand...
>
> > This is because if you have gone to ciphile.com and looked up the
> > Sterling Approximation web page you would know that there are about
> > 1E66,000,000 possible sequences to arrange three permutation files.
> > Of course there may be trillions and trillions of useable sequences.
> > How lucky are you at guessing one in 1E24 or 1E48 or 1E96, etc.
> > sequences from 1E66,000,000. Not even incredible Chinese gamblers
> > think they are this lucky.
>
> So what. Lucifer had a 128-bit key... that's
> 340,282,366,920,938,463,463,374,607,431,768,211,456.... what a big number!
>
> Does that mean it's secure... er NOPE!
>
> > Now you may feel that the problem is greatly simplified (as if
> > anything could simplify a problem with 1E66,000,000 possible
> > outcomes) if you just had some plaintext and encrypted text. How
> > so?
> >
> > The random number sequence you determine from having these two data
> > sources has so little relationship with the random digit file(s)
> > generated from using the OAP-L3 methods as to be worthless for
> > attacking subsequent numbers from the OTPs because this original
> > random digit file has been further processed using all the methods
> > available with OAP-L3, where above I hope you agreed, even
> > if you knew this file and its sequences, it would make no
> > difference.
>
> You assume your OAP methods are sound and non-degenerate. You have yet to
> prove this.
>
> <snip rest of your msg>
>
> Why not show us how good your OAP methods are? You never discuss
> efficiency, design or security in a sound method. Giving ad hoc
> descriptions and poor excuses for "security" are not ideal. You can't
claim
> a big key size as a means to a secure block cipher...
>
> Tom
>
>
------------------------------
Date: Tue, 17 Apr 2001 13:56:50 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: Lorentz attractor...
Gerhard Wesp wrote:
>
> In article <[EMAIL PROTECTED]>,
> Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> >I think you must mean use of chaos, because the problem for use in
> >encryption *is* the existence of attractors.
> >
> >You won't find much written on the use of kittens in encryption,
> >either, for much the same reasons.
>
> Is this a claim that the existence of these cute little 4-feeted balls
> of fur is a problem for encryption???
>
> ;-)
That's right. Feline quadrupeds are well-known for their inquisitive
nature. So are the young of many species. So young cats are
*particularly* inquisitive, and can ferret out (if you'll pardon the
expression) many a secret.
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.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Publishing is *hard*
Date: Tue, 17 Apr 2001 07:15:00 -0700
Mok-Kong Shen wrote:
>
[snip]
>
> Very dumb question: Does the article mean that there
> is indication of a probable weakness of ElGamal (for
> otherwise such an attack would be inconceivable) or
> else that for ANY secure cipher encrypting the output
> of a poor PRNG can be problematical?
Well, no, there is no new weakness in ElGamal identified by that paper.
The ElGamal PRNG in the paper uses the output of a LCG, whose parameters
are secret, as the random exponential in the ElGamal algorithm. (You
could say the output of the LCG is used as a nonces in the ElGamal
algorithm.) The ElGamal algorithm (on Z*_p where p is prime) encrypts a
secret constant C (serving as the message M in the ElGamal algorithm)
over and over by multiplying it with the ElGamal public key raised to
the sequence of nonces from the LCG. This result serves as the output of
an assumed supposed secure PRNG (since it will generate a permutation
of the integers 0 to p-1 as its output.) The paper shows an attack to
recover the secret parameters of the LCG from the output of the ElGamal
encipherment without solving the DH Problem by establishing
relationships between the discrete logarithms of pairs of outputs in the
output sequence. Thus it shows the assumed, supposed secure PRNG output
is not secure.
The submitted version of the paper acknowledged known problems in
ElGamal when used this way - ElGamal as used in the above example is not
semantically secure (and can't be on Z*_p)
( I can send you a copy of the submitted paper in postscript if you are
interested :-)
"'Pseudo-Random' Number Generation within Cryptographic Algorithms: the
DSS Case" by M. Bellare, S. Goldwasser and D. Micciancio and some public
debate on sci.crypt over the effectiveness of transforming insecure
PRNGs into secure PRNGs by encrypting the output of the insecure PRNG
inspired the paper.
This paper does not show that encrypting the output of a poor PRNG with
*any* secure cipher can be problematic. I thought the paper showed a
specific example of a "destructive" resonance between a PRNG and a
cipher but that's not how the paper was received. The reception brought
back memories of Rodney Dangerfield - "Whoa, tough crowd, tough crowd"
as he shrugs his shoulders and adjusts his tie. :-)
I'm going to rework the entire paper and my approach to the problem. The
referee gave good advice.
John A. Malley
[EMAIL PROTECTED]
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Publishing is *hard*
Date: Tue, 17 Apr 2001 07:25:28 -0700
"John A. Malley" wrote:
>
> This result serves as the output of an assumed supposed secure PRNG (since it will
>generate a permutation
> of the integers 0 to p-1 as its output.)
That should read "...integers 1 to p-1 as its output."
------------------------------
Date: Tue, 17 Apr 2001 15:26:13 +0100
From: Richard Heathfield <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.hacker
Subject: Re: MS OSs "swap" file: total breach of computer security.
Anthony Stephen Szopa wrote:
>
<snip>
> The only discretion one has at this time is to NOT use any leaky MS
> security sieve of an OS.
That's probably the most sensible thing I've ever seen you say.
http://www.linux.org/dist/ftp.html lists several non-MS distributions
which you may find of interest. And you get the source code, too, so if
you don't like the way they work, you can fix them to work the way you
want them to.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Distinguisher for RC4
Date: Tue, 17 Apr 2001 07:44:07 -0700
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Scott Fluhrer" <[EMAIL PROTECTED]> writes:
> > Yes, I just tried it on 256,000 keys, and I saw a zero as the second
byte
> > 1926 times.
>
> Interesting. I used an RC4 command-line utility I had lying around
> and gave it 32 bit keys from /dev/urandom. With this, after 22210
> iterations I saw 83 with the 2nd byte being zero, compared to an
> expected 86.75 if an even distribution, or 173.5 if biased in this
> way.
>
> Can you modify your test to try 32 bit keys? Maybe there is something
> about them that keeps S[2] from being 0 after key setup.
Doesn't appear to be. With 256000 32 bit bits, 0 came up as the second byte
1969 times.
Are you sure your RC4 command-line utility doesn't drop an initial part of
the keystream immediately after key generation (which is a common practice)?
Doing that obviously invalidates this distinguisher.
>
> > Here's why it works: suppose, immediately after key setup, S[2]==0.
Then,
> > if S[1]=X, then the first iteration sets j to X. Then, on the second
> > iteration, i is set to 2, j remains X (because S[i]=0), S[i] and S[j]
are
> > swapped (which sets S[j] to 0 and S[i] to X), and then S[S[i]+S[j]] =
S[X +
> > 0] = 0 is output. Actually, there are a few values of X where this
won't
> > work, but usually it does. This happens about 1/256 of time.
> >
> > Then, if S[2]!=0, then RC4 acts essentially randomly, and outputs 1/256
of
> > the time.
> >
> > Hence, the probability of a zero output is about 1/256+1/256 = 1/128
>
> Thanks, that makes sense. If S[1] is 0 then by a similar argument you
> can't get a zero output on the 2nd byte, but this only decreases the
> probability by about 1/256*256, so it is not noticeable.
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Subject: Re: Distinguisher for RC4
Date: Tue, 17 Apr 2001 14:29:48 GMT
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "Scott Fluhrer" <[EMAIL PROTECTED]> writes:
> > Yes, I just tried it on 256,000 keys, and I saw a zero as the second
byte
> > 1926 times.
> Interesting. I used an RC4 command-line utility I had lying around
> and gave it 32 bit keys from /dev/urandom. With this, after 22210
> iterations I saw 83 with the 2nd byte being zero, compared to an
> expected 86.75 if an even distribution, or 173.5 if biased in this
> way.
> ...
I missed the beginning of this thread, but Shamir claims that he can
distinguish the RC4 byte stream based on only 200 bytes. No details
are available yet, AFAIK.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Note on combining PRNGs with the method of Wichmann and Hill
Date: Tue, 17 Apr 2001 17:50:22 +0200
Brian Gladman wrote:
>
> "Mok-Kong Shen" <[EMAIL PROTECTED]> wrote:
> If you read my earlier posts you will see that I have already said that
> adding two generators with multipliers of 1.0 and taking the result 'mod
> 1.0' will be uniform. This was never in doubt. The issue is not this but
> rather that of what happens when two such generators are added with
> multipliers that are both close to, but different from, 1.0.
Well, I suppose it is evident that as the multipliers
approaches 1.0, the result will also approach that for
the case with multipliers exactly equal to 1.0. This
is from simple 'continuity' considerations. Thus your
previous claim that using small deviations from 1.0 will
lead to very large non-uniformness clearly cannot hold.
>
> For example, here is the result of 10,000,000 trials for each of 3 PRNGs,
> two uniform generators, A and B, and a third C, which is (0.9 * A + 1.1 * B)
> mod 1.0:
>
> range gen A gen B gen C
> [0.0:0.1) -> 999970 999545 958872
> [0.1:0.2) -> 999207 1002146 1009123
> [0.2:0.3) -> 998672 999233 1009761
> [0.3:0.4) -> 1000023 999415 1009993
> [0.4:0.5) -> 1000984 999239 1009305
> [0.5:0.6) -> 1001546 1000377 1010543
> [0.6:0.7) -> 998803 998860 1010898
> [0.7:0.8) -> 1000290 999234 1008644
> [0.8:0.9) -> 1001218 1000259 1011547
> [0.9:1.0) -> 999287 1001692 961314
>
> Notice that the first and last intervals for the combined generator (C) are
> significantly less populated than the other eight - these intervals are
> respectively about 0.96 and 1.01 times the frequency expected from a uniform
> generator.
You have to study uniformity with standard statistical
methods. I suppose that the chi-square test is useful
for that. There must be a sufficient sample size in
order to be able to obtain reasonable results. Small
sample size cannot provide useful data in the sense of
statistics. (The FIPS tests, for example, need quite a
bit of data, even though someone in the group considered
the amounts to be too small.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Publishing is *hard*
Date: Tue, 17 Apr 2001 18:05:25 +0200
"John A. Malley" wrote:
>
[snip]
> This paper does not show that encrypting the output of a poor PRNG with
> *any* secure cipher can be problematic. I thought the paper showed a
> specific example of a "destructive" resonance between a PRNG and a
> cipher but that's not how the paper was received.
[snip]
Without understanding the content of your paper, I guess
it could be said that such a 'destructive resonance'
shows that two algorithms of (apparently) different
'nature' could indeed interact in a rather negative sense.
This is a valuable point, I suppose.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] ("Miguel Almeida")
Subject: Q: Choosing a Smartcard/Crypto Chip for PKI on Win2K
Date: Tue, 17 Apr 2001 16:09:21 +0000 (UTC)
Hi!
I'm trying to select a crypto chip to put on a Smartcard for a medium-sized
PKI implementation. Because the project assumes a custom card with other
features besides the crypto chip, we're not considering the ready-to-use
solutions from several vendors (which include both the cards and the
software for the PKI).
The software infrastructure will most probably be based on a custom solution
mixed with the Microsoft Windows 2000 PKI.
My question is: knowing there are several chips on the market and given
we're using W2K, security features aside, which chips/readers would you
recommend to assure hardware/driver/w2k compatibility? Or do the current
offers imply a chip/infrastructure-software bond?
(please cc: any answers to [EMAIL PROTECTED])
Thanks in advance
--
Miguel Almeida
[EMAIL PROTECTED]
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
--
Posted from [212.18.191.61] by way of f72.law4.hotmail.com [216.33.149.72]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: REAL OTP Systems
Date: Tue, 17 Apr 2001 18:13:25 +0200
Frank Gerlach wrote:
>
> Check www.nsa.gov for SIGSALY. This is a *very* expensive 1940s OTP voice
> communication system for UK/USA government communications. OTP has *and is* being
> used in real systems. It is *not* just a theoretic concept.
But the technologies have advanced quite a lot and processing
speeds should allow very strong encryptions other than OTP
in realtime for voice communications, thus obviating the
inconvenience of transport and storage/management of OTP,
I believe.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Reusing A One Time Pad
Date: 17 Apr 2001 16:34:51 GMT
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in
<[EMAIL PROTECTED]>:
>[EMAIL PROTECTED] (Joseph Ashwood) wrote in <ePD6covxAHA.328@cpmsnbbsa07>:
>
>>The moment you reuse *any* portion of the pad, the security immediately
>>falls to precisely 0. That's a simple fact of life (assuming you are
>>using a standard XOR based pad). There is no getting around that, no
>>amount of postulating will get around the mathematic problems involved,
>>your idea is plain and simply insecure.
>> Joe
>
> Actually the security is not ZERO. You may have reduced the
>ppssible set of the messages but as long as there is more than
>one plausble decryption it is not zero. But I agree the more
>you use the less secure and its not to had to reach ZERO.
>Especailly if the plain text file was known to be compressed
>as part of the encryption package as in PGP.
>
Sorry for poor wording but by compressed I meant if one
is using a poor nonbijective compression as what is commonly
used in products such as PGP.
>
>
>David A. Scott
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Reusing A One Time Pad
Date: 17 Apr 2001 16:32:10 GMT
[EMAIL PROTECTED] (Joseph Ashwood) wrote in <ePD6covxAHA.328@cpmsnbbsa07>:
>The moment you reuse *any* portion of the pad, the security immediately
>falls to precisely 0. That's a simple fact of life (assuming you are
>using a standard XOR based pad). There is no getting around that, no
>amount of postulating will get around the mathematic problems involved,
>your idea is plain and simply insecure.
> Joe
Actually the security is not ZERO. You may have reduced the
ppssible set of the messages but as long as there is more than
one plausble decryption it is not zero. But I agree the more
you use the less secure and its not to had to reach ZERO.
Especailly if the plain text file was known to be compressed
as part of the encryption package as in PGP.
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: "Jack Lindso" <[EMAIL PROTECTED]>
Subject: Re: Primality Testing Algorithm
Date: Tue, 17 Apr 2001 19:43:13 +0200
In a nutshell these witnesses are for the purpose of either telling you
whether these numbers are not primes or PSEUDO PRIMES with probability of P
(depends on the specific algorithm). Moreover this witnesses can proove to
ANYONE that these numbers are (not primes/pseudo primes) WITHOUT using the
algorith again.
--
Designing the future is all about envisioning the Infinity.
http://www.atstep.com
=============================================================
"Raymond Lee" <[EMAIL PROTECTED]> wrote in message
news:cmOC6.5860$[EMAIL PROTECTED]...
> I have a question about Primarlity Testing algorithm, hope u can give me
> some hints, I really don't know what's going on.
>
> There are 4 integers: 10111, 11111, 11101 and 12329 that we want to test
if
> they are prime. And we need to apply probabilistic primarlity testing
> algorithm to each one by choosing 5 witness that sum to the candidate
prime.
>
> What I am confused here is what's the purpose of witness? And what's the
> approach of this problem? Still confused after reading some reference
book.
>
>
> Thanks.
>
>
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Size of dictionaries
Date: Tue, 17 Apr 2001 18:45:45 +0200
I am interested to know the order of magnitude of the
minimum size of a dictionary in English that could permit
ordinary messages of common people (private and commercial)
to be written in as terse a manner as possible without
negatively affecting the essential semantics that is to be
conveyed. In other words, I am thinking of writing in a style
like telegrams. Among technical points to be clarified seem
to be those of grammatical forms, e.g. whether the present
participle of a verb is to be in the dictionary and how
special words, if needed but not in the dictionary, can be
represented (using escape symbols?), etc. etc. As foreigner,
I clearly can barely have good ideas about these. Would
2^12 be an appropriate size of the dictionary? In that case
each word of a message could be coded into 12 bits, which
means quite a significant compression ratio, isn't it?
Thanks for your comments in advance.
M. K. Shen
==========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: "differential steganography/encryption"
Date: Tue, 17 Apr 2001 09:43:19 -0700
Dopefish <[EMAIL PROTECTED]> wrote in message
news:3adb6540$[EMAIL PROTECTED]...
> would it be possible to make a program that could take, say, a 20 KB picture
> and a <20KB text file and generate a file that gives the difference between
> the two? so, if i wanted to send somebody a private message and he already
> has the same exact picture that i do, i can send him the difference file and
> he could generate the message from it and the picture. thank you for your
> comments (if any)
>
>
> james
You could do it. XOR the binary file of the picture with the binary content
of your "plaintext". A few things to consider. Kinda obvious.
1, Pictures rarely have much local variation. Shades and intensity usually transition
smoothly or if abrupt, they do this along connected boundries or edges. Many
of your plaintext characters in a local area are going to be modified by the same
or a predictably different picture value. This is not a good property.
2, Unless you do something sneaky you can only use a picture once. If
a secret message becomes known or can be guessed, the secret key
picture can solved for and all other messages (with that picture as key) are
then solved.
This isn't really steganography, a message is not being hidden in otherwise
normal traffic. It is simple xor encryption using an untreated picture as
the PRNG. A poor one at that.
Not good at all.
Paul
>
>
> --
> ------BEGIN SIGNATURE------
> A.K.A "Dopefish" or "fish" for short on Usenet.
>
> Microsoft? Is that some kind of toilet paper?
>
> "Rockin' the town like a moldy crouton!"
> - Beck (Soul Suckin' Jerk - Reject)
>
> "Help me, I broke apart my insides. Help me,
> I've got no soul to sell. Help me, the only thing
> that works for me, help me get away from
> myself."
> - Nine Inch Nails (Closer)
>
>
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GO dpu s++:++ a---- C++++ U--->UL
> P L+ E? W++ N+++ o+ K--- w+>w+++++
> O--- M-- V? PS+++ PE Y-- PGP t 5--
> X+ R tv b+ DI D+ G-- e- h! r z
> ------END GEEK CODE BLOCK------
> (www.geekcode.com)
>
> ------END SIGNATURE------
>
>
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Tue, 17 Apr 2001 16:49:04 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Joseph Ashwood) wrote in <ePD6covxAHA.328@cpmsnbbsa07>:
>
> >The moment you reuse *any* portion of the pad, the security immediately
> >falls to precisely 0. That's a simple fact of life (assuming you are
> >using a standard XOR based pad). There is no getting around that, no
> >amount of postulating will get around the mathematic problems involved,
> >your idea is plain and simply insecure.
> > Joe
>
> Actually the security is not ZERO. You may have reduced the
> ppssible set of the messages but as long as there is more than
> one plausble decryption it is not zero. But I agree the more
> you use the less secure and its not to had to reach ZERO.
> Especailly if the plain text file was known to be compressed
> as part of the encryption package as in PGP.
Um to disprove anything you have said for the past 8 years or so.. an OTP is
secure even if the message was compressed with deflate..... so tell me again
how the compression hurts?
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Reusing A One Time Pad
Date: Tue, 17 Apr 2001 16:49:52 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote in
> <[EMAIL PROTECTED]>:
>
> >[EMAIL PROTECTED] (Joseph Ashwood) wrote in <ePD6covxAHA.328@cpmsnbbsa07>:
> >
> >>The moment you reuse *any* portion of the pad, the security immediately
> >>falls to precisely 0. That's a simple fact of life (assuming you are
> >>using a standard XOR based pad). There is no getting around that, no
> >>amount of postulating will get around the mathematic problems involved,
> >>your idea is plain and simply insecure.
> >> Joe
> >
> > Actually the security is not ZERO. You may have reduced the
> >ppssible set of the messages but as long as there is more than
> >one plausble decryption it is not zero. But I agree the more
> >you use the less secure and its not to had to reach ZERO.
> >Especailly if the plain text file was known to be compressed
> >as part of the encryption package as in PGP.
> >
>
> Sorry for poor wording but by compressed I meant if one
> is using a poor nonbijective compression as what is commonly
> used in products such as PGP.
Again, why are you targetting PGP? Just because Nai can write a program
that you can't (who knows why) doesn't mean you should belittle everyone
else.
Tom
------------------------------
From: Volker Hetzer <[EMAIL PROTECTED]>
Subject: Re: REAL OTP Systems
Date: Tue, 17 Apr 2001 19:06:40 +0200
Mok-Kong Shen wrote:
> But the technologies have advanced quite a lot and processing
> speeds should allow very strong encryptions other than OTP
> in realtime for voice communications, thus obviating the
> inconvenience of transport and storage/management of OTP,
> I believe.
Maybe, but for *some* applications, paranoia is ok.
If you want to keep things secret forever (like a hundred
years or so), nothing beats a provable cipher.
Besides, the system is in place and works and is no less
secure today than it was when it was established, something
that cannot be said for any other known cipher. So why change it?
Greetings!
Volker
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
------------------------------
** 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
******************************
