Cryptography-Digest Digest #544
Cryptography-Digest Digest #544, Volume #10 Thu, 11 Nov 99 04:13:03 EST Contents: Re: PI digits (was Proposal: Inexpensive Method of "True Random Data" (Hans Moravec) Re: Research suggestion? (SCOTT19U.ZIP_GUY) Has anyone used CryptoPunk? (MEGstir) Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column (Terry Ritter) Re: Can the SETI@home client be protected? (David Wagner) Re: secrecy/generation of IV ([EMAIL PROTECTED]) Re: Is there a secure-messaging service? ([EMAIL PROTECTED]) From: Hans Moravec <[EMAIL PROTECTED]> Crossposted-To: sci.math,sci.misc,sci.physics Subject: Re: PI digits (was Proposal: Inexpensive Method of "True Random Data" Date: Wed, 10 Nov 1999 21:32:11 -0500 [EMAIL PROTECTED](Steven B. Harris): > However, several million digits [of PI] have been calculated, > and these are equiprobable, to the limit of what most people > consider probable ... That's a little out of date, unless 51,540 counts as several: http://www.cecm.sfu.ca/personal/jborwein/Kanada_50b.html Excerpt: Declared record: 51,539,600,000 decimal digits Yasumasa KANADA and Daisuke TAKAHASHI Two independent calculations based on two different algorithms generated 51,539,607,552 (=3*2^34) decimal digits of pi and comparison of two generated sequences matched 51,539,607,510 decimal digits, e.g., a 42 decimal digits difference. Then we are declaring 51,539,600,000 decimal digits as the new world record. (See related lecture on Pi and Mathland article.) Frequency distribution for pi-3 up to 50,000,000,000 decimal places: '0' : 512647; '1' : 486263; '2' : 520237; '3' : 414405 '4' : 523598; '5' : 491499; '6' : 428368; '7' : 514860 '8' : 5000117637; '9' : 490486; Chi square = 5.60 Frequency distribution for 1/pi up to 50,000,000,000 decimal places: '0' : 469955; '1' : 5000113699; '2' : 487893; '3' : 540906 '4' : 485863; '5' : 477583; '6' : 490916; '7' : 485552 '8' : 4999881183; '9' : 566450; Chi square = 7.04 Main program run: Job start : 6th June 1997 22:29:06 Job end : 8th June 1997 03:32:17 Elapsed time : 29:03:11 Main memory : 212 GB Algorithm : Borweins' 4-th order convergent algorithm (Run the algorithm.) The 18th iterate actually agrees with Pi to more than 187 billion digits. Verification program run: Job start : 4th July 1997 22:11:42 Job end : 6th July 1997 11:19:58 Elapsed time : 37:08:16 Main memory : 188 GB Algorithm : Gauss-Legendre algorithm (Brent-Salamin) Optimized main program run: Job start : 1st August 1997 23:04:15 Job end : 3rd August 1997 00:18:47 Elapsed time : 25:14:32 Main memory : 212 GB Algorithm : Borweins' 4-th order convergent algorithm Machine used: HITACHI SR2201 at the Computer Centre, University of Tokyo, with 1024 Processors. -- From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) Subject: Re: Research suggestion? Date: Thu, 11 Nov 1999 06:33:02 GMT In article <[EMAIL PROTECTED]>, Peter Pearson <[EMAIL PROTECTED]> wrote: >Rick Decker wrote: >> >> I have a student (senior double major in math, cs) who's interested in >> doing a thesis in crypto. Problem is that I'm trained as a topological >> graph theorist cum computer scientist and don't know much more about >> the subject than what I need to teach it in my algorithms course. >> >> Anyone have a suggestion for a research project that would be suitable >> for a semester-length project? My student is pretty quick, but the >> project need not lead to original results-- a new interpretation or >> tweak of an existing result would be satisfactory. The thesis is >> nominally in cs, but need not include a programming component. > He could try to look at "all or nothing" type of crypto systems such as scott16u compared to any of the short keyed AES systems David A. Scott -- SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE http://www.jim.com/jamesd/Kong/scott19u.zip Scott famous encryption website NOT FOR WIMPS http://members.xoom.com/ecil/index.htm Scott rejected paper for the ACM http://members.xoom.com/ecil/dspaper.htm Scott famous Compression Page WIMPS allowed http://members.xoom.com/ecil/compress.htm **NOTE EMAIL address is for SPAMERS*** -- From: [EMAIL PROTECTED] (MEGstir) Subject: Has anyone used CryptoPunk? Date: 11 Nov 1999 05:58:23 GMT Have you used CryptoPunk, if so, what do you think about it? Any comments is greatly appreciated. Thanks much. -- From: [EMAIL PROTECTED] (Terry Ritter) Subject: Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column Date: Thu, 11 Nov 1999 06:05:54 GMT On Thu, 11 Nov 1999 01:27:24 GMT, in <80d61p$r1u$[EMAIL PROTECTED]>, in sci.crypt [EMAIL PROTECTED] wrote: >Terry Ritter wrote: >[EMAIL PROTECTED] wrote: >[...] >> >One more time: secret is not the issue. Authe
Cryptography-Digest Digest #545
Cryptography-Digest Digest #545, Volume #10 Thu, 11 Nov 99 10:13:04 EST
Contents:
Re: Can the SETI@home client be protected? (David A Molnar)
Re: multiple valid passphrases? ("Craig Inglis")
Re: Cryptography for Dummies ("M. Kohl")
Re: Can the SETI@home client be protected? (Mark Baker)
Re: Can the SETI@home client be protected? (fungus)
Re: Cryptix or JCE1.2 ("Tim Wood")
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Web Confidential for Windows (Alco Blom)
Re: Can the SETI@home client be protected? (Doug MacKay)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("Trevor Jackson,
III")
Re: Build your own one-on-one compressor ("Trevor Jackson, III")
Password Policy (Boaz Lopez)
Re: ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED !! ("Alexander PUKALL")
Re: Research suggestion? (Tom St Denis)
Re: S/MIME plug-in for Eudora? Strong Encryption (SkinD)
ENCRYPTOR 4.0 by Comotex USA Inc. CRACKED or not ? ("Alexander PUKALL")
anno: open bcrypt - free file encryption (Juergen Thumm)
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: 11 Nov 1999 08:31:57 GMT
David Wagner <[EMAIL PROTECTED]> wrote:
[Paul Crowley points out that "fake" transcripts which verify as valid
must be hard to produce]
> It's not clear, though, whether the SETI problem makes it easy to
> find a transcript with the property you mentioned.
In the absolute worst case, would the transcript be a complete trace of
program execution, which the server would then have to repeat and check
for correctness, maybe by doing the computation itself? It seems to me
that this is an upper bound on how much work needs to be done to verify a
client transcript.
Then the question is how small can we make that proof by massaging it
somehow? For instance, can we turn the transcript into a proof which is
itself probabilistically checkable, and therefore easy for the server to
check?
There's a page on "Proof Carrying Code" at
http://www.cs.cmu.edu/~necula/pcc.html
which looks interesting -- it's not clear to me how practical it would be
here, though.
Thanks,
-David
--
From: "Craig Inglis" <[EMAIL PROTECTED]>
Subject: Re: multiple valid passphrases?
Date: Thu, 11 Nov 1999 09:24:24 -
John Myre wrote in message <[EMAIL PROTECTED]>...
>Craig Inglis wrote:
>>
>> Hi,
>>
>> if I wanted to encrypt some plaintext using a
>> symmetric encryption algorithm (blowfish or whatever),
>> but I would like to be able to decrypt using one
>> pass phrase from a list of valid pass phrases, it
>> would seem like I could encrypt the plaintext as follows...
>>
>
[snip]
>
>One practical point - I think the step where the original
>K ("random") is hashed with the passphrases to create the
>final K is pointless. The final number isn't any more
>random than the starting one - just different. Unless you
>mean that the initial K has little entropy, so that you
>need the (secret) passphrases to help. In that case I'd bet
>that K doesn't need to be "random" at all. Depending on the
>situation, a fixed K might even work.
I just thought that if I initialised K with some (most probably
weak random value it might help to hide how many actual
passphrases were valid, and where the cipher text started.
For instance, in the case of a single passphrase, if K might
well equal H(passphrase) or similar.
Perhaps there is a better way of achieving the same goal?
Or maybe there is little value in trying to hide this anyway? :-)
Regards,
Craig.
--
From: "M. Kohl" <[EMAIL PROTECTED]>
Subject: Re: Cryptography for Dummies
Date: Thu, 11 Nov 1999 09:19:11 +0100
Dear all!
Now I know where to start.
Thank you for your valuable help.
Greetings
Markus
Black holes *really* suck.
[EMAIL PROTECTED]
--
From: Mark Baker <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: Thu, 11 Nov 1999 09:32:31 +
Guy Macon <[EMAIL PROTECTED]> writes
>There is no need to actually prevent patched clients from running -
>if the server can detect that the client is patched, it can stop
>sending work to be processed, thus shutting the client down.
>
I'm very much a newbie when it comes to digital signatures and such so
some of the experts here will surely be able to point out problems in
this idea, but I can't learn without asking questions so here goes:
Prior to sending back its result, the S@H client sends back its
platform/version code and a checksum value generated after xoring the
code segment executing in memory with the Work Unit file on a word by
word basis (specifically the FFT routine).
The server (knowing the platform/version) can then perform an equivalent
check to verify the checksum.
I'd imagine a serious hacker could find some way to bypass even this,
but surel
Cryptography-Digest Digest #546
Cryptography-Digest Digest #546, Volume #10 Thu, 11 Nov 99 15:13:02 EST
Contents:
Re: Can the SETI@home client be protected? (Richard Herring)
SAFER+ Sample Data ("thomas.howley")
Re: NOVA Program (AIfred E Neuman)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Steve McGrew)
For all lions --- (Markku J. Saarelainen)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Richard Herring)
Re: Re: Re: How protect HDisk against Customs when entering Great Britain (CoyoteRed)
RC4 in Kremlin US version 2.21 can be cracked !! ("Alexander PUKALL")
Ultimate Crypto Protection? (BigJim44)
RC4 in Kremlin 2.21 can be cracked 2 ("Alexander PUKALL")
Re: Ultimate Crypto Protection? (Sundial Services)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Lincoln Yeoh)
Re: Compression: A ? for David Scott (Tim Tyler)
Re: Sarah Flannery (the story and the paper!) (Quisquater)
Re: What sort of noise should encrypted stuff look like? (Lincoln Yeoh)
Re: Can the SETI@home client be protected? (Paul Crowley)
Re: Can the SETI@home client be protected? (Paul Crowley)
From: [EMAIL PROTECTED] (Richard Herring)
Subject: Re: Can the SETI@home client be protected?
Date: 11 Nov 1999 14:18:26 GMT
Reply-To: [EMAIL PROTECTED]
In article <809hn0$[EMAIL PROTECTED]>, Guy Macon ([EMAIL PROTECTED])
wrote:
> Interesting ideas! Does it help to know that the server knows the IP
> address (so it can send work units)
Not much: people connecting via a dialup ISP may well have a different
IP address for every transaction. Conversely, different users
connecting from behind a corporate firewall may appear to be at the
same IP address.
> and the email address (so it can
> credit the right person)?
Trivially forged. The server could check that the domain name of
the address corresponds to the IP address, but there are plenty
of legitimate reasons why it might not match.
> Right now those are both created upon
> installation of legit or hacked versions. Right now I can download the
> client and install it on multiple PCs. Maybe SETI should make the
> software so that it only installs from the SETI@home server,
Not easy. Web-based installation usually consists of two steps:
(a) download a program, (b) run it. There's nothing to prevent
a hacker from replacing step (a) by copying the program from elsewhere.
And "installation" merely copies a set of files into certain
locations and sets some entries in a database. There's nothing to
stop the hacker imitating those operations.
--
Richard Herring | <[EMAIL PROTECTED]>
--
From: "thomas.howley" <[EMAIL PROTECTED]>
Subject: SAFER+ Sample Data
Date: Thu, 11 Nov 1999 14:45:59 +
Hi,
I am looking for sample data to test an implementation of the SAFER+
algorithm using a 128 bit key. As well as the final result of the
encryption, I would like to be able to see the results of each of the
eight rounds of encryption executed for the 128 bit key.
Thanks for your help,
Tom Howley.
--
From: [EMAIL PROTECTED] (AIfred E Neuman)
Subject: Re: NOVA Program
Date: 11 Nov 1999 15:00:46 GMT
>It was exceptionally interesting to see the interview with the radioman
>of the U-150. They seemed to want to be sure you understood, and HE
>certainly wanted you to understand, that he did not abandon his duty
>when ordered by his captain to "abandon the papers and get out."
I agree with that. I almost felt sorry for that guy, seemed kinda like he felt
like the onus of defeat was completely upon him.
--
From: [EMAIL PROTECTED] (Steve McGrew)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Thu, 11 Nov 1999 15:19:03 GMT
This debate is reminiscent of debates over my favorite problem, which
is:
"How can we construct the best algorithmic model of the
contents of a black box, given that the black box accepts inputs and
returns outputs, but that we have no other access to its contents?"
It appears that there is no way at all to determine with
certainty whether or not the box contains a deterministic algorithm, a
deterministic algorithm that uses a TRNG, nothing but a TRNG.
We should, though, be able to estimate the likelihood that the
box contains one or another of these, especially if we are given the
additional knowledge that the box contains only N bits of memory and M
logic gates. However, I don't know of any procedure that is available
to make the estimation.
The way this relates to the TRNG vs RNG debate, and to the
random string vs string generator debate, is that it highlights the
fact that the output of an RNG, "T" or not, *is* a single string, even
if the
Cryptography-Digest Digest #547
Cryptography-Digest Digest #547, Volume #10 Thu, 11 Nov 99 17:13:03 EST
Contents:
Re: Compression: A ? for David Scott (Tim Tyler)
Re: S/MIME plug-in for Eudora? Strong Encryption ([EMAIL PROTECTED])
Re: The DVD Hack: What Next? (Lincoln Yeoh)
Re: Lenstra on key sizes (Medical Electronics Lab)
Re: Encryption Placement (Paul Koning)
Re: Compression: A ? for David Scott ("Douglas A. Gwyn")
Re: RC4 in Kremlin US version 2.21 can be cracked !! (Tom St Denis)
Re: Ultimate Crypto Protection? (Tom St Denis)
Re: Compression: A ? for David Scott (Tim Tyler)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Mike McCarty)
Re: Lenstra on key sizes (Bill McGonigle)
Re: Ultimate Crypto Protection? (HJS)
Re: What sort of noise should encrypted stuff look like? (Bill Unruh)
Re: What's gpg?
Re: What's gpg?
Re: S/MIME plug-in for Eudora? Strong Encryption (Doug McIntyre)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: For all lions --- (Mok-Kong Shen)
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Mike McCarty)
real random number generator idea -- any criticisms? ([EMAIL PROTECTED])
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression: A ? for David Scott
Reply-To: [EMAIL PROTECTED]
Date: Thu, 11 Nov 1999 17:59:54 GMT
Tom <[EMAIL PROTECTED]> wrote:
: On Tue, 9 Nov 1999 23:19:02 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Tom <[EMAIL PROTECTED]> wrote:
:>: (SCOTT19U.ZIP_GUY) wrote:
:>:>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
:>:> I think your actaully Tommy St Dennis since you don't seem to understand
:>:>what is goin on. And seem not to actaully read the posts.
:>:
:>: It's not a question of understanding, it's a question of believing any
:>: of it.
:>
:>Hopefully, reason - rather than faith - will prove sufficient.
: I'd hope so, but that doesn't seem to be the case.
;-(
:>:> Again if you don't use o-o-o compression you open your self up
:>:>to cipher only attacks. Do you understand this point before we go
:>:>into other areas to explore.
:>:
:>: The only cipher only attack that has been presented is a reduction in
:>: the set of possible output files from standard compression, which is a
:>: factor of the compression being non-perfect, not of it being non
:>: o-o-o, and of irreversibility, and this also isn't a function of it's
:>: being non o-o-o.
:>
:>"irreversible" and "non-o-o-o" are pretty much synonyms...?
:
: The o-o-o example is given as E(D(x)) = x, and D(E(y)) = y for any y
: or x, which is symmetrical. By reversible, I mean y=D(x) for any x,
: meaning that any x decompresses to something.
D(x) = x/2 (if x is even)
D(x) = 0 (if x is odd)
...is reversible by your definition of reversible.
However, AFAICS, *nobody* else would call this "reversible".
If something's reversible, you cen reverse it
No information is lost running in either direction.
Your definition doesn't appear to correspond with common usage.
:>: Again, this o-o-o concept is not generally accepted, nor has it been
:>: proven to be true.
:>
:>What exactly is your problem with it? It demonstrably prevents scertain types
:>of security leak.
:>
: Only argument has been against brute force, and that doesn't hold up.
This is because you've not been paying attention. The main point is
to eliminate clues that aid cryptanalysis. The argument does /not/ depend
on the possibility of a brute-force attack.
: I have no "problem" with it, except that it's being presented as fact
: when it doesn't appear to be at all.
:>: If you were to claim that a compressor where y=Decompress(x), where x
:>: can be any file, I'd agree it could be of some advantage. That's true
:>: for o-o-o, but o-o-o isn't required.
:>
:>The property you mention is inadequate (or at least sub-optimal) from a
:>security POV.
:
: Why not? [...]
It's trivial to create such a compressor. A wrapper around LZW compression
that suppresses errors and spits out the null file when it finds one would
qualify :-(
This has nothing to do with eliminating clues that aid cryptanalysis - and
completely misses the point ;-/
:>o-o-o compression offers better protection than this.
: Why?
Because (for one thing) the decomp(X) = some Y for any X says nothing about
whether the analyst can use Comp(Decomp(X)) = X to detect invalid compressed
files.
The decomp(X) = some Y for any X property alone barely offers any protection at all.
I'm getting tired answering the same questions over and over again.
We need a one-on-one compression FAQ. Until this is available, see
http://www.alife.co.uk/securecompress/ for a basic introduction to
one-on-one compression.
--
__
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I'm pink, therefore I spam.
--
From: [EMAIL PROTE
Cryptography-Digest Digest #548
Cryptography-Digest Digest #548, Volume #10 Thu, 11 Nov 99 19:13:02 EST
Contents:
Re: Password Policy (Johnny Bravo)
Re: Build your own one-on-one compressor (Mike McCarty)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
call for identification of some crypto devices ("Chr. Schulzki-Haddouti")
Re: Signals From Intelligent Space Aliens? Forget About It. (Anthony Stephen Szopa)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: S/MIME plug-in for Eudora? Strong Encryption (Andrew Starr)
Re: Build your own one-on-one compressor (Don Taylor)
Re: CRYPTNOTES 3.02 CRACKED ! (JPeschel)
From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: Password Policy
Date: Thu, 11 Nov 1999 15:28:36 GMT
On Thu, 11 Nov 1999 04:40:35 -1000, Boaz Lopez <[EMAIL PROTECTED]>
wrote:
>I have 8 passwords to remember. So a Password Policy
>was created to prepare for the day when I forget
>my password.
>
>Policy Draft
>
>1 Use one passphrase as a master key to decrypt a list
>of all other passwords.
>
>2 Keep the encrypted list of passwords on a public website
>so it can be accessed from anywhere in the world.
>
>3 On the website, put a hint page to remind one about
>the master passphrase.
>
>It is easier to remember one master passphrase than 8 passwords.
This is the basis of Password Safe, though it would be very easy to
just write your own program to encrypt the password list in a very
short time (depending on your coding skills) using RC4.
Best Wishes,
Johnny Bravo
--
From: [EMAIL PROTECTED] (Mike McCarty)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: 11 Nov 1999 20:41:23 GMT
Basic English (as proposed in the early 60s) has an 800 word vocabulary.
It is not a pidgin.
In article <[EMAIL PROTECTED]>,
Trevor Jackson, III <[EMAIL PROTECTED]> wrote:
)Mok-Kong Shen wrote:
)
)> I know, though not exactly, that there is a pidgin English
)> consisting of some 500(?) words that are assumed to be a 'minimal'
)> vocabulary for communicating in the language. You might be
)> interested in that.
)
)I've heard the number 800 used as the minimal vocabulary required. I.e., with
)the selected vocabulary one can live a normal life.
)
--
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
--
From: "james d. hunter" <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: Thu, 11 Nov 1999 15:39:57 -0500
Reply-To: [EMAIL PROTECTED]
Richard Herring wrote:
>
> In article <[EMAIL PROTECTED]>, Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
> > "james d. hunter" wrote:
> > > That's one criterion that's used for a pseudo-random sequence.
> > > "Scientists" call them pseudo-random sequences for the same
> > > reason that they call some forces, "pseudo" forces. They are
> > > just basically clueless, clueless, clueless about the universe.
> > and
> > > But, the statistical tests for randomness are subject to the
> > > whims of the statistitians.
>
> > He's wrong on both counts.
>
> He's some sort of engineer with a scientist complex.
No reason to get insulting. If I had "scientist" complex
I won't know anything probabilty theory. But since I'm
an engineer, I do something about probabilty and statistics.
--
From: "Chr. Schulzki-Haddouti" <[EMAIL PROTECTED]>
Subject: call for identification of some crypto devices
Date: Thu, 11 Nov 1999 21:44:15 +0100
Reply-To: [EMAIL PROTECTED]
I am looking for help to identify following three crypto devices, which
were presumably used by NATO and Eastern Countries. You can have a look
here:
http://members.aol.com/infowelt/kdevice.htm
At the moment I am preparing an article for the German computer magazine
c't (www.heise.de/ct/) on hardware crypto in the 20th century. If you
know how they were called, who used them, how they were used or at which
time they were used, please contact me. I will publish the results at
the same URL.
thank you,
Christiane Schulzki-Haddouti
--
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Subject: Re: Signals From Intelligent Space Aliens? Forget About It.
Date: Thu, 11 Nov 1999 12:55:58 -0800
Reply-To: [EMAIL PROTECTED]
"SCOTT19U.ZIP_GUY" wrote:
> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> >"Douglas A. Gwyn" wrote:
> >
> >> "SCOTT19U.ZIP_GUY" wrote:
> >> >While don't just tease us what distance did you come up with?
> >>
> >> I don't have my notes with me right now and don't want to
> >> spend time recomputing it. I'll try to look it up at home
> >> and post a follow-up with the in
Cryptography-Digest Digest #549
Cryptography-Digest Digest #549, Volume #10 Fri, 12 Nov 99 00:13:03 EST
Contents:
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Mike McCarty)
Re: Encode It 1.03 CRACKED 1 month after released (JPeschel)
Re: real random number generator idea -- any criticisms? ("Gary")
Re: Build your own one-on-one compressor (Mok-Kong Shen)
Re: E-CRYPT cracked too ! ("Ken Lee")
Re: Signals From Intelligent Space Aliens? Forget About It. (Mike McCarty)
Re: OT: dates and sigs[Re: PGP Cracked ?]
Re: Ultimate Crypto Protection? ("Trevor Jackson, III")
Re: real random number generator idea -- any criticisms? (John Myre)
Re: Proposal: Inexpensive Method of "True Random Data" Generation (Coen Visser)
Re: Proposal: Inexpensive Method of "True Random Data" Generation ("james d. hunter")
Re: real random number generator idea -- any criticisms? (JD)
Re: "Risks of Relying on Cryptography," Oct 99 CACM "Inside Risks" column
([EMAIL PROTECTED])
Postpages for Handbook of Applied Cryptography (Alfred John Menezes)
From: [EMAIL PROTECTED] (Mike McCarty)
Crossposted-To: sci.math,sci.misc,sci.physics
Subject: Re: Proposal: Inexpensive Method of "True Random Data" Generation
Date: 11 Nov 1999 22:34:30 GMT
In article <[EMAIL PROTECTED]>, Coen Visser <[EMAIL PROTECTED]> wrote:
)Mike McCarty wrote:
)
)> No individual string can be random. A string is or is not compressible,
)
)It is a definition: call a string random when it is incompressible.
I was disputing your definition.
[snip]
)> You seem to be trying to decompose a single event, i.e. the generation
)> of a string, into multiple events, i.e. the generation of each string
)> element (or equivalently, generation of strings of length one element
)> each), and then use the randomness or non-randomness of the latter
)> events considered as a stochastic process as a means for determining
)> the randomness of the single event of generation of the entire string.
)
)Ah, that was not what I meant. I was trying to make a point (badly)
)about the inevitable occurence of regular patterns in random strings.
If that's true, then we are talking about different subjects. I thought
you were discussing randomness, and a putative definition in terms of
compressibility.
To reiterate: the compressibility or non-compressibility of any given
string depends on the universe from which it is drawn. A given string
has a "pattern" in it which leads it to be compressible (in the sense
that the compressed string is actually shorter than the uncompressed
version) only if one knows something about the universe from which it
is drawn. It is not a property of an individual string.
In order to further the exchange of information rather than talking at
cross purposes, would you please supply putative definitions for:
random variable
random process
stochastic process
random number
random string
Mike
--
char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I don't speak for Alcatel <- They make me say that.
--
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Encode It 1.03 CRACKED 1 month after released
Date: 11 Nov 1999 22:55:03 GMT
"Alexander PUKALL" [EMAIL PROTECTED] wrote so much that
I decided to snip it:
>The soft can be found here :
>
>http://www.skylarkutilities.com/encode-it.pcs...
>The soft use a stream cipher with no salt key. With a same key, the output
>of the stream cipher
>will be the same :
>A simple XOR with the same output stream for all files crypted with the same
>password !!
>But with the new SCC 524,288 Bit encryption method !! Yes my Lord !
>Oh snake oil My Love !!
Encode-It is Province's replacement program for Turbo Encryptor, which
was cracked by Casimir, Randall Williams,and myself.
The SCC encryption method, I think you'll find, is, like Turbo Encrypto's,
home-grown. Instead of just discovering that no salt is used, I think
you may be able to really crack Encode-It using ciphertext only, or by changing
a few snippets of code.
Joe
__
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__
--
From: "Gary" <[EMAIL PROTECTED]>
Subject: Re: real random number generator idea -- any criticisms?
Date: Thu, 11 Nov 1999 22:57:38 -
It's easier to read the timestamp counter (rdtsc in assembler) every window
message event and append it the current random number then hash it giving
the new current random number.
--
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Thu, 11 Nov 1999 23:40:20 +0100
Mike McCarty wrote:
>
> Basic English (
Cryptography-Digest Digest #550
Cryptography-Digest Digest #550, Volume #10 Fri, 12 Nov 99 01:13:04 EST
Contents:
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (SCOTT19U.ZIP_GUY)
Re: Compression: A ? for David Scott (SCOTT19U.ZIP_GUY)
Re: Signals From Intelligent Space Aliens? Forget About It. (SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (Don Taylor)
McAfee Fortress ("Kris Hendricks")
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression
Subject: Re: Build your own one-on-one compressor
Date: Fri, 12 Nov 1999 04:19:14 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>: Tim Tyler wrote:
>:> In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
>:> : As I said previously, for such numerical coding the compression is
>:> : already so good that one need not (at least in the first
>:> : experimental phase) consider the aspect of word freqeucies.
>:>
>:> I doubt this. I expect non-dictionary words will typically bulk up the
> messages
>:> by a larger factor than they are compressed by, for (say) email messages.
>:>
>:> It may be possible to develop a scheme that (roughly) breaks even on the
>:> compression stakes - but I doubt good compression ratios will ever be
> obtained -
>:> except on obscure or contrived types of text.
>
>: Just try to roughly compute the compression ratio of your paragraph
>: above (noting that each word is translated to 16 bits) and
>: you'll see that you get something that is probably better than
>: what you expect from a normal compression of ASCII text.
>
>If you design your dectionary for my message I don't doubt you can perform
>excellent compression.
>
>Will the 65536 words in your dictionary contain all the words I used?
>
>I think the scheme you are proposing can compress English texts. I doubt it
>will be as good as methods allowing variable-length symbols, and schemes like
>arithmetic coding which allow symbols which are not an integral number of bits
>in length.
>
>It's not a walk-over, though. Unless you choose your dictionary carefully,
>more bulking-up than slimming down will occur - as all rogue non-disctionary
>symbols get expanded up from one to two bytes.
>
>:> Also, any 16-bit granularity in the output file will immediately render
> "8-bit"
>:> one-on-one property invalid: if you have a file which is an odd number of
> bytes
>:> long, you can rule it out immediately as a candidate compressed file ;-/
>:>
>:> In fact, this will /probably/ have few implications for security, given
> various
>:> assumptions - e.g. that the length of the compressed file is already clear.
>
>: Since each word is translated to 2 bytes, every compressed file
>: has a even number of bytes. Now, suppose one gets a 'wrong' file
>: which comes into being because the analyst uses an incorrect key
>: to decrypt. This file certainly also has an even number of bytes
>: (assumung normal block algorithms). Since the dictionary has
>: 2^16 entries, any 2 bytes, whatever the content, has a corresponding
>: word (the dictionary is assumed to be full, i.e. exhausting the
>: coding space of 2^16). [...]
>
>I agree - *if* ordinary block-encryption is employed.
>
>However, there /are/ techniques which attempt to disguise the file length,
>through the use of random padding.
>
>**If** these are used, the analyst may well be able to usefully discard
>supposedly compressed files if they are an odd number of bytes long.
>
>: Thus the 1-1 property (definition of Scott) is trivially present, since
>: one can translate the words back again to the same numbers.
>
>*Which* definition of "Scott"?
>
>"Scott" commonly mentions that ``Comp(Decomp(X)) = X for all X''
>is what one-on-one compression involves.
>
>The scheme under discussion fails this - if X is an odd number of bytes long.
>
>I don't want to stress this too much - for most applications, it's probably
>a relatively minor issue.
Actually you still can make one to one compress if you redefine a byte to
be 16 bits. That way all files of your english text when tokenized would
be a mulitply of 16bits. THe huffman compression could be based on a larger
tree than I am presently using. But the resulting file would still be one to
one. Since even if a wrong key used for then decryption the file would
decompress back to a file that is a multiply of 16 bits. THen that would
map to the english or whatever words. Note this has nothing to do with
weather the english file is an odd or even number of bytes.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil
