Cryptography-Digest Digest #171, Volume #13      Thu, 16 Nov 00 22:13:01 EST

Contents:
  RE: Big-block cipher, perhaps a new cipher family? ("Manuel Pancorbo")
  Re: Hitachi - on what grounds ?? ("Paul Pires")
  Re: Big-block cipher, perhaps a new cipher family? (Terry Ritter)
  Re: Hitachi - on what grounds ?? (Terry Ritter)
  Re: Is Triple DES the BEST Algorithm ? (Tom St Denis)
  Re: Re: ECC help please ("James Russell")
  Re: My new book "Exploring RANDOMNESS" (Greggy)
  Silly idea to prevent decrypt (Silly Things)
  Re: Book recommendation, please (Greggy)
  Re: Randomness from key presses and other user interaction (Steve Roberts)
  Re: voting through pgp (Sundial Services)
  Re: WS_FTP is insecure - it supports SSL, but only with 40-bit keys! ("George 
Peters")
  Re: Silly idea to prevent decrypt (Tom St Denis)
  [Question] Export restrictions on following algos. (Shri Desai)
  [Question] XOR encryption (Shri Desai)
  [Question] Generation of random keys (Shri Desai)
  Re: My new book "Exploring RANDOMNESS" (Tim Tyler)

----------------------------------------------------------------------------

From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: RE: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov 2000 00:27:03 GMT


"Mok-Kong Shen" <[EMAIL PROTECTED]>


>
> But in the scheme you described there are the functions
> F and G which you don't specify in detail.

I will; give me a couple of days and I'll publish the whole code with
graphic explanation and test packets.


> If the F is
> not good, you wouldn't have good diffusion.

In fact I have no *good* diffusion: only 16 bits (for F) and 24 bits (for G)
out of 32, are affected by a single bit change in input *at the first step*.
Good diffusion is obtained by running this kernel cipher over the packet
(and backwards).

> One can have
> a combination of stream and block techniques. I designed
> one with a block size of 640 bits driven by a PRNG with
> feedback to the PRNG by hash values obtained during the
> processing and with block chaining. In other words, the
> state of the PRNG is influenced by the plaintext blocks
> and the processing of the blocks is determined by the
> PRNG outputs and the successive blocks are chained. See
> my web page.
>

My cipher method  has no upper limit (except the system memory) for the
packet size. You can apply it to a 1 MByte file without chaining (provided
enough memory).

Nevertheless I don't pretend be original. The question is: if this
"large-block-stream-ish" ciphers are really faster than traditional block
ciphers, good diffusive and strong against known attacks... why not give
them more attention?

--
____________________________________________________________________

 Manuel Pancorbo
 [EMAIL PROTECTED] (Apply ROT13)
____________________________________________________________________


------------------------------

From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Hitachi - on what grounds ??
Date: Thu, 16 Nov 2000 16:49:19 -0800


<Snip>
> If you have other methods which the communication partners
> can easily and safely employ (i.e. without weakening
> the cipher) and hinder the work of the opponent, then it
> would be fine if you would let others of the group partake
> you knowledge through posting these to the group.
>
> Anyway, if you think that posts (not only those of mine)
> you see in the group do not contain materials giving
> sufficient answer to your five questions listed in a
> previous follow-up, then please be kind enough to say so.
> This is why we have a 'discussion' forum, isn't it?

As usual you and I are misconnected, I'm trying to back out
of it gracefully. If you wish to continue the discussion by E-mail
I will be happy to do so. I am feeling a little self concious about
how the group feels about this and don't want to continue this
here as it has gone way past anything usefull or interesting.

I don't have any problems, criticisms or questions about the
thread you mentioned. I also have no interest in the topic.
I suggested the questions as general content for the hypothetical
or example situation you originally brought up, not any actual thread
that might exist. Which, by the way, has nothing to do with the
original topic of discussion.

I do not disparage the content or authorship of any of that
material since I have not read it and have no interest in the
topic or knowledge of the subject. You don't have to
prove me an idiot, I freely admit it after getting sucked
into another weird exchange with you. We have to stop
meeting like this.

For someone who has such a problem with English,
you sure don't seem to have a problem with
condecension, misdirection and snide comments.

Be careful, that Columbo act is wearing a little thin.

Paul






------------------------------

From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Fri, 17 Nov 2000 00:54:50 GMT


On Fri, 17 Nov 2000 00:27:03 GMT, in
<rX_Q5.1169$[EMAIL PROTECTED]>, in sci.crypt "Manuel
Pancorbo" <[EMAIL PROTECTED]> wrote:

>[...]
>Nevertheless I don't pretend be original. The question is: if this
>"large-block-stream-ish" ciphers are really faster than traditional block
>ciphers, good diffusive and strong against known attacks... why not give
>them more attention?

http://www.io.com/~ritter/NEWS/HUGEBLK.HTM
http://www.io.com/~ritter/ARTS/DISTAVA.HTM
http://www.io.com/~ritter/ARTS/VSBCNONL.HTM
http://www.io.com/~ritter/MIXCORE.HTM
etc.

---
Terry Ritter   [EMAIL PROTECTED]   http://www.io.com/~ritter/
Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM


------------------------------

From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Hitachi - on what grounds ??
Date: Fri, 17 Nov 2000 00:55:21 GMT


On Thu, 16 Nov 2000 19:55:35 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:

>
>Lest Hitachi comes onto further ideas of patenting based
>on variability, let's note that variable block sizes,

http://www.io.com/~ritter/PATS/VSBCPAT.HTM

>variable keys, variable substitutions/permutations, 
>variable number of rounds, variable operator types,
>variable parameters, variable round key orderings, variable 
>cipher stacks, variable processing through PRNG control 
>and, most generally, a variable 'structure' of the entire 
>encryption algorithm (see the recent thread 'The ultimate 
>cipher' initiated by me) have all been discussed in this 
>group and are therefore already prior art of crypto and 
>not patentable.
>
>M. K. Shen

---
Terry Ritter   [EMAIL PROTECTED]   http://www.io.com/~ritter/
Crypto Glossary   http://www.io.com/~ritter/GLOSSARY.HTM


------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Is Triple DES the BEST Algorithm ?
Date: Fri, 17 Nov 2000 01:17:17 GMT

In article <[EMAIL PROTECTED]>,
  Eric Smith <[EMAIL PROTECTED]> wrote:
> "Laurent" <[EMAIL PROTECTED]> writes:
> > Is Triple DES the BEST Algorithm ?
>
> Answers to your question (choose any one):
>
>      Yes
>
>      No
>
>      Sometimes
>
>      Maybe
>
>      On thursdays

So far so good.

>
>      42

42?  Hehehe.. that's the answer to life!

>      A giraffe
>
> But which is the BEST answer to your question?

You mean they need to think it out on their own before plugging cheap
software marketed as "worlds best military strength super-duper mickey-
mouse would be impressed" cryptography?

hehehehe...

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: [EMAIL PROTECTED] ("James Russell")
Subject: Re: Re: ECC help please
Date: 16 Nov 2000 17:27:10 +0100

Thank you very much to all three of you for taking the time to respond.  I 
think I understand the situation now, and your knowledge-sharing is much 
appreciated.

James
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.


-- 
Posted from [206.156.202.110] by way of f194.law10.hotmail.com [64.4.15.194] 
via Mailgate.ORG Server - http://www.Mailgate.ORG

------------------------------

From: Greggy <[EMAIL PROTECTED]>
Crossposted-To: sci.math,sci.logic
Subject: Re: My new book "Exploring RANDOMNESS"
Date: Fri, 17 Nov 2000 01:33:51 GMT

In article <8v0rmr$c7v$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] wrote:
> Hi, in December Springer-Verlag London will publish
> my new book "Exploring RANDOMNESS" and it will be
> available first in the UK and three months later
> world wide.  Amazon.co.uk is already accepting orders.
> For more information, including the cover of the book,
> its table of contents, and the software for the book,
> see http://www.cs.umaine.edu/~chaitin/ait
>     http://www.cs.auckland.ac.nz/CDMTCS/chaitin/ait
> Regards,
> Greg Chaitin
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

Have you considered making parts of it free for all of us to study,
such as the algorithms?  In fact, have you considered making the book
online and free to read through?  I for one have no curiosity for such
a book if I have to pay for it.  Sounds like snake oil.  Or can I get
my money back if I don't think it was worth the price?


--
I prefer my fourth amendment rights over a dope free
society, even if the latter could actually be achieved.

Al Gore - quite possibly America's greatest threat today


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Silly Things <[EMAIL PROTECTED]>
Subject: Silly idea to prevent decrypt
Date: Fri, 17 Nov 2000 03:24:18 +0200

Just an idea maybe very silly one
( from a almost oridinary comp user)

1) to prevent intruder finding any traces of a possible found
succesfull key: how about cloning the data to be decrypted into
lets say to a 100 to 1000 identical data-units.

2) ok, now they are identical, then arrange them to a spreadsheet
table so that each unit is put into its own row and each character
into its own column

|L|I|K|E| |I|N| |T|H|I|S|.|
|L|I|K|E| |I|N| |T|H|I|S|.|
|L|I|K|E| |I|N| |T|H|I|S|.|
|L|I|K|E| |I|N| |T|H|I|S|.|
|L|I|K|E| |I|N| |T|H|I|S|.|
|L|I|K|E| |I|N| |T|H|I|S|.|
|L|I|K|E| |I|N| |T|H|I|S|.|
|L|I|K|E| |I|N| |T|H|I|S|.|
|L|I|K|E| |I|N| |T|H|I|S|.|

3) Then use a pseudo random generator to make "random" changes into
the the spreadsheet table, so that nothing meaningsfull seems to
be preserved.

above example with pseudo random errors put into table, so that a slight

majority or minority of a certain characters is presented in a single
row.


|L|F|B|E|6|D|R| |D|B|R|V|5|
|T|U|N|G| |9|8|B|2|Y|I| |G|
|U|O|J|E|J|W|N|7|G|L|4|O|T|
| |I|7|K|G|I|H|5| |V| |E|1|
|I|C|0|E|R|K|N|W|T|9|I|I| |
|L|5|K| |M|I|R|2|I|H|2|S|C|
|W|9|R|8|Y|4|W|A|T| |I|S|.|
|Y|I|P|L| |V|A|B|3|2|M| |L|
|4|6|K|X|I|7|M| |M|H|F|N|.|

4) ok easy, each row now contains 2 signigicant characters
which make a sentence

 "LIKE IN THIS."

and if you would happen to have lets say 140 dublicates (lines in table)

then they could contain about 2 ASCII characters of the significant
character in each row.

5) ok, now some characters are more present than the others

6) still easy, but if you put EXTRA characters before each
row then it would start to become confusing.

see below:

|Z|L|F|B|E|6|D|R| |D|B|R|V|5|
|4|H|L|T|U|N|G| |9|8|B|2|Y|I| |G|
|T|J|4|M|I|U|O|J|E|J|W|N|7|G|L|4|O|T|
|9|B|N| |I|7|K|G|I|H|5| |V| |E|1|
|I|C|0|E|R|K|N|W|T|9|I|I| |
| |J|L|5|K| |M|I|R|2|I|H|2|S|C|
|W|9|R|8|Y|4|W|A|T| |I|S|.|
|R|Y|I|P|L| |V|A|B|3|2|M| |L|
|4|6|K|X|I|7|M| |M|H|F|N|.|


and with these extra characters you can adjust the amount of each
character,
so that no anomaly in amount of characters seems to be in the table.

7) extra characters could also be added at the end of each line and even

whole insignificant bogus lines too.

8) when ready remove "new line characters" from the table so it seems
like
one meaningless mess with equal amount of each character.

ZLFBE6DR DBRV54HLTUNG 98B2YI GTJ4MIUOJEJWN7GL4OT9BN I7KGIH5 V
E1IC0ERKNWT9II JL5K MIR2IH2SCW9R8Y4WAT IS.RYIPL VAB32M L46KXI7M MHFN.


9) sure there could be found some information from it, but by making it
full of insignicant characters by pseudorandom generator, and
controlling
the amount of each fake character (if too many of X suggest a new
character)
how on earth would anyone be able to find any significance of it?


10) encrypt the package with a real algoritm and post it.

What would the needed extra "making-sence-key" be like? It would give
answars to

-amount of clones in the table
-amount of extra characters at the beginning of each line
(-amount of extra characters at the end of each line)
(-numbers of bogus lines in table and row numbers)

so the recipient must have a code that takes away all the pogus
characters,
(instructions to do so might not need to be many kilobytes)


Sure the packages would be big :) , but so is also the transfer capacity

100 kbytes of text is guite many pages of documents and by taking 100
clones
of it --> 10Mb and adding lets say 5 times of that extra characters and
lines
to it 50MB (about nothing in 5 years from now).


QUESTION IS how on eart could any quantum or similar deluxe-computer
know it has find the real key(even with the right key), when all
characters are
equally divided and pseudo number generated characters represent no such

algorithm that could be tried.


Greetings: Silly Things


------------------------------

From: Greggy <[EMAIL PROTECTED]>
Subject: Re: Book recommendation, please
Date: Fri, 17 Nov 2000 01:36:23 GMT

In article <[EMAIL PROTECTED]>,
  "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> My 16 year old son has become interested in cryptography (after
> reading Cryptonomicon).  He is very computer literate, takes AP
> Computer Science in school, and does a fair amount of C++ programming
> in school and for fun.  What book or books can this group recommend as
> an introduction to the science of Cryptography?  I'd like to encourage
> his interest with a good introduction,  without overwhelming him.
> Would  Applied Cryptography by Bruce Schneier be the way to go ?
>
> Thanks in advance

You know, it would be pretty cool if there was an online high school
course on the subject both in general and on specific topics.  Free, of
course.

--
I prefer my fourth amendment rights over a dope free
society, even if the latter could actually be achieved.

Al Gore - quite possibly America's greatest threat today


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: [EMAIL PROTECTED] (Steve Roberts)
Subject: Re: Randomness from key presses and other user interaction
Date: Fri, 17 Nov 2000 02:06:10 GMT

Tim Tyler <[EMAIL PROTECTED]> wrote:

>Steve Roberts <[EMAIL PROTECTED]> wrote:
>
>: Aargh, the user will just hold a key down so that all the key strokes
>: will have the same spacing in time!!  Don't forget that humans will
>: usually find the easiest possible way of doing something.  The same
>: thing for human-chosen random typing - there will be a lot of repeated
>: a's out there.
>
>You can detect this easily.  Insisting on a number of key releases
>is one counter-measure to having the user hold down a key.

But if that is implemented then the work-minimising user, on finding
that holding the key down won't do, will repeatedly press the same
key, or alternate with two different keys.  For that sort of reason,
in the stream of characters I required the user to copy there were no
repeated consecutive letters.

Steve

------------------------------

Date: Thu, 16 Nov 2000 19:08:14 -0700
From: Sundial Services <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: voting through pgp

Don't bet on it, "bit."  When nearly-absolute power is at stake, people
can become very ugly, very fast.

Furthermore, we could easily encounter the "Dewey Defeats Truman"
problem if we did have electronic voting.  This famous headline came
about because the newspaper did a =telephone= poll when only a small
percentage of the population owned telephones.  They tapped into the
preferences of the rich -- who preferred Dewey.  They did not realize
that their statistical sample had an inherent bias.

The same problem could easily occur with voting.  Most of my friends do
not own computers, do not use e-mail or the Internet.  They are also
unlikely to do so.  Yet their vote counts just as much as anyone else's.

The only problem we face with this election now, is that one candidate
would like for the votes not to be counted, as long as the votes that
have been counted show a nonzero margin of victory.  "Greed for power"
has no solution in cryptography.


>binary digit wrote:
> 
> Imagine if everyone had pgp in the world and voted through pgp, every single
> vote could be verrified and everyone would be happy, and there wouldnt be
> this problem that is going on now in florida

------------------------------

From: "George Peters" <[EMAIL PROTECTED]>
Subject: Re: WS_FTP is insecure - it supports SSL, but only with 40-bit keys!
Date: Thu, 16 Nov 2000 19:30:30 -0600

Take a look at http://www.datasecuritysolutions.com .  They have an FTP
client that you would probably want to use.  You can download a limited time
full functional demo as well.

"Eric Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I've been trying to find an FTP client for Windows that supports SSL,
> and tried WS_FTP from Ipswitch.  It's inexpensive, and they provide
> a time-limited demo.
>
> I'm very glad that they provided the demo.  If I'd paid money for it
> I'd demand a refund.  I found out the hard way that they support
> *only* 40-bit ciphers.  I inquired of their technical support,
> expecting perhaps to be told that I needed an expensive SGC certificate
> in order to use secure crypto.  To my surprise they said that they
> don't support it at all.
>
> Although the product seems to be quite good in other respects, I have
> to recommend *against* it for anyone who actually is concerned about
> security.
>
> Eric Smith



------------------------------

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Silly idea to prevent decrypt
Date: Fri, 17 Nov 2000 02:23:08 GMT

In article <[EMAIL PROTECTED]>,
  Silly Things <[EMAIL PROTECTED]> wrote:
> Just an idea maybe very silly one
> ( from a almost oridinary comp user)
>
> 1) to prevent intruder finding any traces of a possible found
> succesfull key: how about cloning the data to be decrypted into
> lets say to a 100 to 1000 identical data-units.
>
> 2) ok, now they are identical, then arrange them to a spreadsheet
> table so that each unit is put into its own row and each character
> into its own column
>
> |L|I|K|E| |I|N| |T|H|I|S|.|
> |L|I|K|E| |I|N| |T|H|I|S|.|
> |L|I|K|E| |I|N| |T|H|I|S|.|
> |L|I|K|E| |I|N| |T|H|I|S|.|
> |L|I|K|E| |I|N| |T|H|I|S|.|
> |L|I|K|E| |I|N| |T|H|I|S|.|
> |L|I|K|E| |I|N| |T|H|I|S|.|
> |L|I|K|E| |I|N| |T|H|I|S|.|
> |L|I|K|E| |I|N| |T|H|I|S|.|
>
> 3) Then use a pseudo random generator to make "random" changes into
> the the spreadsheet table, so that nothing meaningsfull seems to
> be preserved.
>
> above example with pseudo random errors put into table, so that a
slight
>
> majority or minority of a certain characters is presented in a single
> row.
>
> |L|F|B|E|6|D|R| |D|B|R|V|5|
> |T|U|N|G| |9|8|B|2|Y|I| |G|
> |U|O|J|E|J|W|N|7|G|L|4|O|T|
> | |I|7|K|G|I|H|5| |V| |E|1|
> |I|C|0|E|R|K|N|W|T|9|I|I| |
> |L|5|K| |M|I|R|2|I|H|2|S|C|
> |W|9|R|8|Y|4|W|A|T| |I|S|.|
> |Y|I|P|L| |V|A|B|3|2|M| |L|
> |4|6|K|X|I|7|M| |M|H|F|N|.|
>
> 4) ok easy, each row now contains 2 signigicant characters
> which make a sentence
>
>  "LIKE IN THIS."
>
> and if you would happen to have lets say 140 dublicates (lines in
table)
>
> then they could contain about 2 ASCII characters of the significant
> character in each row.
>
> 5) ok, now some characters are more present than the others
>
> 6) still easy, but if you put EXTRA characters before each
> row then it would start to become confusing.
>
> see below:
>
> |Z|L|F|B|E|6|D|R| |D|B|R|V|5|
> |4|H|L|T|U|N|G| |9|8|B|2|Y|I| |G|
> |T|J|4|M|I|U|O|J|E|J|W|N|7|G|L|4|O|T|
> |9|B|N| |I|7|K|G|I|H|5| |V| |E|1|
> |I|C|0|E|R|K|N|W|T|9|I|I| |
> | |J|L|5|K| |M|I|R|2|I|H|2|S|C|
> |W|9|R|8|Y|4|W|A|T| |I|S|.|
> |R|Y|I|P|L| |V|A|B|3|2|M| |L|
> |4|6|K|X|I|7|M| |M|H|F|N|.|
>
> and with these extra characters you can adjust the amount of each
> character,
> so that no anomaly in amount of characters seems to be in the table.
>
> 7) extra characters could also be added at the end of each line and
even
>
> whole insignificant bogus lines too.
>
> 8) when ready remove "new line characters" from the table so it seems
> like
> one meaningless mess with equal amount of each character.
>
> ZLFBE6DR DBRV54HLTUNG 98B2YI GTJ4MIUOJEJWN7GL4OT9BN I7KGIH5 V
> E1IC0ERKNWT9II JL5K MIR2IH2SCW9R8Y4WAT IS.RYIPL VAB32M L46KXI7M MHFN.
>
> 9) sure there could be found some information from it, but by making
it
> full of insignicant characters by pseudorandom generator, and
> controlling
> the amount of each fake character (if too many of X suggest a new
> character)
> how on earth would anyone be able to find any significance of it?
>
> 10) encrypt the package with a real algoritm and post it.
>
> What would the needed extra "making-sence-key" be like? It would give
> answars to
>
> -amount of clones in the table
> -amount of extra characters at the beginning of each line
> (-amount of extra characters at the end of each line)
> (-numbers of bogus lines in table and row numbers)
>
> so the recipient must have a code that takes away all the pogus
> characters,
> (instructions to do so might not need to be many kilobytes)
>
> Sure the packages would be big :) , but so is also the transfer
capacity
>
> 100 kbytes of text is guite many pages of documents and by taking 100
> clones
> of it --> 10Mb and adding lets say 5 times of that extra characters
and
> lines
> to it 50MB (about nothing in 5 years from now).
>
> QUESTION IS how on eart could any quantum or similar deluxe-computer
> know it has find the real key(even with the right key), when all
> characters are
> equally divided and pseudo number generated characters represent no
such
>
> algorithm that could be tried.
>
> Greetings: Silly Things

The problem came from a computer and will be solved on a computer.

Unorthadox cryptography is rarely a real solution to any problem.  Why
obfuscate the plaintext handling?

Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: Shri Desai <[EMAIL PROTECTED]>
Subject: [Question] Export restrictions on following algos.
Date: Fri, 17 Nov 2000 02:37:50 GMT

Hi,

I had following few questions:

1) If I use Blow Fish in an app. which may be used by all over the
world, are there any export restrictions in US? Actually, I am in
Canada.

2) How about the above case for Two Fish algo? 

3) Are the above 2 free for commercial and non commercial use?

4) What about the restrictions on Diffe-Helman algo. for key exchange?
   Is it also free for non and for commercial use?


Any info. on this would be appreciated. Will great if you email me.

Thanks,

Shri

------------------------------

From: Shri Desai <[EMAIL PROTECTED]>
Subject: [Question] XOR encryption
Date: Fri, 17 Nov 2000 02:41:35 GMT

Hi,

If my key is equal or larger then the input text then can simple XOR
of input text with key give me a good enough encryption?


Would appreciate your input.

Thanks,

Shri

------------------------------

From: Shri Desai <[EMAIL PROTECTED]>
Subject: [Question] Generation of random keys
Date: Fri, 17 Nov 2000 02:43:02 GMT

Hi,

Can someone point me to source code (C or VB)  to generate good random
keys (1024 bit)? Good enough to be used in Diffe Helman algo.

Would appreciate it,

Thanks,

Shri

------------------------------

Crossposted-To: sci.math,sci.logic
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: My new book "Exploring RANDOMNESS"
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Nov 2000 02:25:14 GMT

In sci.crypt Greggy <[EMAIL PROTECTED]> wrote:
: In article <8v0rmr$c7v$[EMAIL PROTECTED]>,
:   [EMAIL PROTECTED] wrote:

:> Hi, in December Springer-Verlag London will publish
:> my new book "Exploring RANDOMNESS" [...]
:> For more information, including the cover of the book,
:> its table of contents, and the software for the book,
:> see http://www.cs.umaine.edu/~chaitin/ait
:>     http://www.cs.auckland.ac.nz/CDMTCS/chaitin/ait

: Have you considered making parts of it free for all of us to study,
: such as the algorithms? [...]

Um, did you try reading that post?  Or visiting the second URL?

: I for one have no curiosity for such a book if I have to pay for it.
: Sounds like snake oil.  Or can I get my money back if I don't think it
: was worth the price?

That's a matter for your local book store.  I understand some vendors
offer a read-and-return scheme.

If you think Chaitin's work is "snake oil", that's a sign that you have
applied your practice of not purchasing books to all his other works ;-|
-- 
__________  Lotus Artificial Life  http://alife.co.uk/  [EMAIL PROTECTED]
 |im |yler  The Mandala Centre   http://mandala.co.uk/  Free gift.

------------------------------


** 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 (and sci.crypt) via:

    Internet: [EMAIL PROTECTED]

End of Cryptography-Digest Digest
******************************

Reply via email to