Cryptography-Digest Digest #933

2001-03-18 Thread Digestifier

Cryptography-Digest Digest #933, Volume #13  Sun, 18 Mar 01 14:13:01 EST

Contents:
  Re: How to eliminate redondancy? ("Tom St Denis")
  PGP key expiration (was Re: Encryption software) (Benjamin Goldberg)
  Re: Cryptoanalysis of stream cipher ("Tom St Denis")
  Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION ("Henrick Hellström")
  Re: Cryptoanalysis of stream cipher (Frank Gerlach)
  Re: Profile analysis and known plaintext (Frank Gerlach)
  Re: Profile analysis and known plaintext (Frank Gerlach)
  Re: Profile analysis and known plaintext ("Tom St Denis")
  Re: Cryptoanalysis of stream cipher ("John A. Malley")
  old RNG request ("Tom St Denis")
  Re: Idea (amateur)
  Re: Idea (amateur)
  FISHING (bandjur)
  Re: Profile analysis and known plaintext (Steve Portly)
  Re: Idea (John Joseph Trammell)
  Re: Idea (John Joseph Trammell)
  Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION (SCOTT19U.ZIP_GUY)
  Re: How to eliminate redondancy? (SCOTT19U.ZIP_GUY)
  Re: IDEAL ENGLISH TEXT RIJNDAEL ENCRYPTION (John Savard)
  Re: Idea (amateur)



From: "Tom St Denis" [EMAIL PROTECTED]
Subject: Re: How to eliminate redondancy?
Date: Sun, 18 Mar 2001 16:11:08 GMT


"SCOTT19U.ZIP_GUY" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
 [EMAIL PROTECTED] (Douglas A. Gwyn) wrote in [EMAIL PROTECTED]:


Compression goes along why towards solving the problem if it
  allows for any possible input block.
 
 All commonly used compression schemes work for any input.
 
 

Here is where you maybe missing it. Compression is a two
 sided coin. compression/decompression. Most people are so
 focused on the frontside they fail to check the backdoor.
 True most compressors at the front door the compresion side
 do handle all 8-bit byte binary files. But they leave the
 back door wide open. They don't handle the decompression of
 all possible files. If they did it then
 1) for any file X then compress( uncompress(X))= X
 would be true for all files.
  This in something anyone can check. Take a file use
 Notepad enter a message "hello world" save it as a file.
 Now uncompress it with any of your favorite compressors.
 Most will fail on the spot possibly giving an error message.
 You may have to go to DOS or use some method to change file
 name extension to the type your compressor uses.
 A few will actually do somthing. Next if you get this far
 compress the resultant file using the compressor part of your
 compressor. Know check it with "fc /b file1 file2" see if
 the match. If not your compressor failed.

I still don't see 1-1 as a valid condition for security.  I can brute force
your 1-1 system just like I can brute force a non "1-1" compressor.

Tom



--

From: Benjamin Goldberg [EMAIL PROTECTED]
Subject: PGP key expiration (was Re: Encryption software)
Date: Sun, 18 Mar 2001 16:11:32 GMT

Joe H. Acker wrote:
[snip]
 I have another problem with PGP: I once forgot my passphrase for a
 non-expiring key and didn't make a key revocation certificate, which
 means that there will now be two keys (the new one and the old one)
 forever on the keyserver, but I can only decrypt for one. That's
 really bad... and I think this can happen to many unexperienced PGP
 users.  Wouldn't it be possible to require regular confirmation of key
 expiry or not, instead of no expiry at all or fixed expiry? That way,
 if somebody lost his passphrase to a private key, he could not confirm
 "no don't expire this public key" and so the public key would expire
 automatically.

It's an interesting idea, but it requires rather alot of work on the
part of the keyserver (ie, regularly asking each user with a
conditionally expiring cert whether or not he wants it to expire). 
Plus, if the user goes on vacation, he's got a problem.

A better method would be to design a special "advance expiration date"
message, which one would send to the keyserver, so that we only need a
one-way communication, not a two-way communication.

A more practical solution would be to have PGP automatically create a
key revocation certificate when a new key is made, and nag the user into
putting it on a floppy disk, and further nag him into sticking that
floppy in a safe place.

-- 
The difference between theory and practice is that in theory, theory and
practice are identical, but in practice, they are not.

--

From: "Tom St Denis" [EMAIL PROTECTED]
Subject: Re: Cryptoanalysis of stream cipher
Date: Sun, 18 Mar 2001 16:11:34 GMT


"Yevgen" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
 Hi All!

 I need any information about cryptoanalysis of stream cipher.

 Thanks in advance.

Which stream cipher?



--

From: "Henrick Hellström" [EMAIL PRO

Cryptography-Digest Digest #933

2000-10-15 Thread Digestifier

Cryptography-Digest Digest #933, Volume #12  Sun, 15 Oct 00 20:13:01 EDT

Contents:
  Re: Is it trivial for NSA to crack these ciphers? ([EMAIL PROTECTED])
  Re: Problem in Message Digest ([EMAIL PROTECTED])
  Re: SDMI - Answers to Major Questions ("Paul Pires")
  Re: Is it trivial for NSA to crack these ciphers? (CiPHER)
  Re: CRC vs. HASH functions (Mack)
  Re: A newbie in block ciphers (Dido Sevilla)
  Re: ECDSA ("Jesper Stocholm")
  Re: Is it trivial for NSA to crack these ciphers? (David Wagner)
  Re: ECDSA (Roger Schlafly)
  Re: Is it trivial for NSA to crack these ciphers? ("John A. Malley")
  Re: A new paper claiming P=NP (default)
  Re: On block encryption processing with intermediate permutations (Bryan Olson)
  Re: SDMI - Answers to Major Questions (Mack)
  pseudo random test (=?ISO-8859-1?Q?Jacques_Th=E9riault?=)
  Try This One (Jim)
  Re: Bored with AES? SHA-256/384/512 spec now out! (John Savard)



From: [EMAIL PROTECTED]
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Sun, 15 Oct 2000 18:55:41 GMT

Stephen M. Gardner [EMAIL PROTECTED] wrote:
 What do you suppose keeps bright young mathematicians working in an
 environent in which they cannot share their insights freely with
 others?  What do you suppose the impact on their creativity is?  How
 long do you suppose it takes for such an environment to turn a bright
 young scholar into a government drone or drive them away?  Oh, did I
 mention how the bright young person has to suffer a periodic foray into
 his sex life, what substances he consumes recreationally, an who he
 associates with by some cynical and jaded "security wonk" with a
 cold-war stick up his butt?  Do the best and brightest put up with that
 for long?

If we assume that the NSA is significantly ahead of the private
sector, the inability to publish is more than offset by the access to
information noone else has. I suspect that if you told anyone they
could read every file the NSA has, provided they never discussed them
later, most people would leap at the chance.

On the other hand, if they're on par with the open community, the
inability to publish is offset for many people by the ability to
accomplish meaningful work without having to deal with publishing! ;)
Saving lives, and the ability to work against the best advesaries the
rest of the world has to offer are strong motivations.

As to the intrusion into your private life, the private sector is not
doing much better in that particular case. The current trend in many
companies is mandatory drug testing, immediate dismissile for smoking
on or off the premisis at some places, etc.

-- 
Matt Gauthier [EMAIL PROTECTED]

--

From: [EMAIL PROTECTED]
Subject: Re: Problem in Message Digest
Date: Sun, 15 Oct 2000 19:02:35 GMT

Joyce [EMAIL PROTECTED] wrote:
 I would like to digest a message. However, a compile error is prompted:
 Error #: 362 : cyclic inheritance involving class
 java.security.MessageDigest at line 30, column 43. It indicates that there
 is an error in MessageDigest.getInstance("MD5", "CryptixCrypto").

 Please kindly tell me what's going wrong.

Where should we start? ;)

1. This is sci.crypt, not comp.lang.java so the entire message is way
off base.

2. Use of the sun.* packages in production code is a Bad Idea(tm).

3. You can do the same thing with approximately 10% of the code by
using MessageDigest.getInstance("MD5"). That saves you the _entire_
cryptix library, and probably runs faster to boot.

And if I had to guess, the first place I'd look is that you're adding
the provider correctly.

-- 
Matt Gauthier [EMAIL PROTECTED]

--

From: "Paul Pires" [EMAIL PROTECTED]
Subject: Re: SDMI - Answers to Major Questions
Date: Sun, 15 Oct 2000 12:06:57 -0700

David A Molnar [EMAIL PROTECTED] wrote in message
news:8sapp2$qtc$[EMAIL PROTECTED]...
 Scott Craver [EMAIL PROTECTED] wrote:
  Alas, I do research in the field of watermarking and watermarking
  attacks, and my ears are pretty crummy.  Plus I have to do most of
  my work in a room with big loud fans.

 Can't you just find some music majors on campus and use them as guinea
 pigs (I'm assuming their ears are relatively good)? Maybe you could even
 get a psych major to set up and run experiments as a thesis topic, thus
 saving you the trouble...

It's already been done.
Although not as fun, there are better uses for students than scientific
experiment :-)

Audio professionals are

A, pre-selected to be talentened.
B, trained and experienced to recognise and inderstand what they hear.

The one I know is astounding.

Paul



 -David





--

From: CiPHER [EMAIL PROTECTED]
Subject: Re: Is it trivial for NSA to crack these ciphers?
Date: Sun, 15 Oct 2000 19:23:40 GMT

In article [EMAIL PROTECTED],
  "

Cryptography-Digest Digest #933

2000-06-03 Thread Digestifier

Cryptography-Digest Digest #933, Volume #11   Sat, 3 Jun 00 19:13:01 EDT

Contents:
  Re: http://www.infraworks.com product ("Paul Pires")
  Re: Good ways to test. (Mok-Kong Shen)
  Re: Need "attack time" measurements on a toy cipher...   (long) ("TheGPFguy")
  Re: Good ways to test. (tomstd)
  Re: Need "attack time" measurements on a toy cipher...   (long) ("TheGPFguy")
  Re: No-Key Encryption (Mok-Kong Shen)
  Re: Good ways to test. (Mok-Kong Shen)
  Re: No-Key Encryption (Mok-Kong Shen)
  Re: XTR independent benchmarks (Wei Dai)
  Re: Good ways to test. (tomstd)
  Re: Need "attack time" measurements on a toy cipher... (long) (Baruch Even)



From: "Paul Pires" [EMAIL PROTECTED]
Subject: Re: http://www.infraworks.com product
Date: Sat, 3 Jun 2000 14:52:18 -0700

I had to look at the web page,

Sorry.

"After the 45 minutes or the 1 time view, the document is shredded from your
hard drive"

Their software runs on my machine (all the time presumably) and decides to
shred documents? On my machine?

So I load the document, say an AutoCad file, for my 1 hour and then kill
their process. (CNTRL, ALT, DELETE and end task)

"* Provides total protection by destroying the content if any security
elements are violated. "

This is a good thing?

I once called Microsoft with a problem with Exchange behaving badly with
User Profiles. After many hours and constant movement up the food chain it
was explained to me that I did not have a bug but that I had actually found
an "Undocumented Feature".

I am not calling these guys.

Paul







--

From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Good ways to test.
Date: Sun, 04 Jun 2000 00:08:57 +0200



tomstd wrote:

 You are missing the picture.

 Crypto:  I can say a block cipher has 'X' resistance to 'Y'
 attacks.

 Medicine:  I can say 'X' people get better and 'Y' people get
 dead.

 Same thing.  In crypto I can say 'DES has a resistance to linear
 attacks effectively of O(2^43) work' making it 'strong'.  In
 medicine I can say 99.99% people got better but 0.01% died
 making it 'a cure'.

 We didn't know (or now either) if DES could have been broken
 easily, same for medicine.  Those 0.01% may have had kids before
 they died that have some wierd genetic disease making 0.01%
 become much larger.

 That's why I called it comparative.  You wouldn't use FEAL-8
 over Blowfish would you?  Why because given all that we know
 Blowfish is more secure.  Is that definative?  Not a shot in
 hell.  But it's better then "What cipher will I use today?".

I wish that there are plenty of people who accept that sort of
numerical figures of yours. But please don't count on me. I don't
buy that.

 2.  I know too little about chemistry or phamacology to know
 what
  substance you mentioned is. But apparently you were
 referring to
  the issue of the yet unknown side effects of drugs. Yes,
 this does
  seem to have analogy in crypto, namely the yet unknown
  (not yet existing or already existing but secret)
 techniques of attack.
  To that point all what I can say is to repeat my
 conviction that
  anyone applying crypto is responsible to himself for the
 consequence
  of what algorithm he chooses and how the whole security
 system is
  organized and run. No other person can carry that
 responsibility
  for him. He can gather all relevant informations that he
 can manage
  to obtain. But he has to make his own decision (including
 such as
  to blindly and totally rely on what a certain guru says)
 and has no
  one but himself to blame, if that decision happens to turn
 out to
  be wrong.
 

 You're right.  Companies like Entrust and RSA are *liable* for
 any damages that occur when people use their tools.  So I would
 assume they are doing the best they can.

In principle the same comment as above.

M. K. Shen


--

From: "TheGPFguy" [EMAIL PROTECTED]
Subject: Re: Need "attack time" measurements on a toy cipher...   (long)
Date: Sat, 03 Jun 2000 22:01:10 GMT


Paul Pires [EMAIL PROTECTED] wrote in article =
99d_4.57122$[EMAIL PROTECTED]...
 I know you set up a pretty good work plan for the folks in here to =
follow
 but you have to understand that no one here is very good at coloring =
inside
 the lines.

Before I continue further, let me publicly thank you for your clear and =
concise explanation of what to expect here.  I mean that literally, not =
sarcastically.

=20
 Your basic statement is self contradictory. You state that there is a =
short
 secrecy horizon, that the same key is always used and yet you claim =
the
 plaintext is unknown. All plaintext or just the stuff inside your =
security
 horizon ?
=20

The statement is contradictory because I set up a trial 

Cryptography-Digest Digest #933

2000-01-19 Thread Digestifier

Cryptography-Digest Digest #933, Volume #10  Thu, 20 Jan 00 00:13:01 EST

Contents:
  Re: Predicting Graphs. (Guy Macon)
  newbie help (elliptic)
  Re: What about the Satanic Seven??? ("r.e.s.")
  Re: ECC vs RSA - A.J.Menezes responds to Schneier (DJohn37050)
  ANN: ECBackup 1.1 - archiver with strong-security, based on open key technology 
(ECC) ("Andre N Belokon")
  Encryption Speeds of Stream Ciphers Implemented on Hardware ("Duncan")
  Re: New Crypto Regulations ("Trevor Jackson, III")
  Re: McDonald's claims Nobel peace fries ("Trevor Jackson, III")
  Re: Java's RSA implimentation (Paul Schlyter)
  Re: Java's RSA implimentation (Paul Schlyter)
  Re: RSA survey ("Trevor Jackson, III")
  Re: MIRDEK: more fun with playing cards. ("r.e.s.")
  Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
  Re: RSA survey (NFN NMI L.)
  Re: Forward secrecy for public key encryption (new proposal, long) (David Wagner)



From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Predicting Graphs.
Date: 19 Jan 2000 21:02:13 EST

In article 865fve$t2k$[EMAIL PROTECTED], [EMAIL PROTECTED] ([EMAIL PROTECTED]) 
wrote:

Come on, somebody, answer my question!

O.K.  Happy now?


--

From: elliptic [EMAIL PROTECTED]
Subject: newbie help
Date: Thu, 20 Jan 2000 01:57:55 GMT

I need some help for implementing strong encryption in Perl(MacPerl).
Onyone wann give me a hand???


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

--

From: "r.e.s." [EMAIL PROTECTED]
Subject: Re: What about the Satanic Seven???
Date: Wed, 19 Jan 2000 18:22:16 -0800

Thanks for the link.

What does it mean for simply discussing, say, ARC4's algorithm?
It's still not clear to me whether, for US citizens, public-domain
"hard crypto" source code or algorithms may be posted without
restriction in NGs.  Does Paragraph 15 imply that it's OK to do so
as long as one somehow informs BXA concurrently with every posting?!

--
r.e.s.
[EMAIL PROTECTED]



"David Crick" [EMAIL PROTECTED] wrote ...
: "John E. Kuslich" wrote:
: 
:  How do you stop those people in the seven bad nations from downloading
:  your stuff??? Do you have to have your server attempt to filter this
:  stuff?
:
: See  http://207.96.11.93/Encryption/qanda.htm  for answers to these
: and many other questions :)
:
:   David.




--

From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: 20 Jan 2000 02:24:15 GMT

In the Montgomery talk, he only had each machine talking to its N,S, E, and W
neighbors.  And each machine had only a part of the matrix.  A lot was over my
head.
Don Johnson

--

From: "Andre N Belokon" [EMAIL PROTECTED]
Subject: ANN: ECBackup 1.1 - archiver with strong-security, based on open key 
technology (ECC)
Date: Thu, 20 Jan 2000 04:34:27 +0200
Reply-To: "Andre N Belokon" [EMAIL PROTECTED]

Hi All !

In new version add BWT-based compression method (like bzip2). Improved
compression speed. For more detail visit to http://softlab.od.ua

ECBackup 1.1
is a archiver with strong-security, based on open key technology.
We used elliptic curves for open key and Blowfish for cipher. This has
allow to get the greater security in contrast with RSA-based systems under
the smaller length of key and more high speed. Key length up to 1900 bits
(equivalent to more than 50,000 bits RSA-key) - it's a "paranoic"
level of security !
Package contains three programs - keymaker, archiver and viewer. Keymaker
create public key for your private password. Archiver uses this public
key (not private password) for cryptooperation. With viewer you can view
and extract files from archive, but for this you are to know private
password.
Open key technology guarantees impossibility of recovering a secret key
on an known open key.
Also you are to use this program for the safe exchange (like PGP) any
types of files over internet or other facility to communications.

WBR Andre N Belokon
http://softlab.od.ua
mailto:[EMAIL PROTECTED]






--

From: "Duncan" [EMAIL PROTECTED]
Subject: Encryption Speeds of Stream Ciphers Implemented on Hardware
Date: Wed, 19 Jan 2000 21:40:48 -0500

I'm looking for the encryption speeds of stream ciphers implemented on
chips. Bruce Schneier's Applied Cryptography 2/e (Table 17.3) gives the
speeds of A5, PIKE, RC4 and SEAL on a 33MHz 486SX. Is there any information
about the speeds of stream ciphers on hardware?



--

Date: Wed, 19 Jan 2000 21:55:32 -0500
From: "Trevor Jackson, III" [EMAIL PROTECTED]
Subject: Re: New Crypto Regulations

JPeschel wrote:

 "Douglas A. Gwyn" [EMAIL PROTECTED] writes:

 JPeschel wrote:
  "Do

Cryptography-Digest Digest #933

1999-01-19 Thread Digestifier

Cryptography-Digest Digest #933, Volume #8   Tue, 19 Jan 99 22:13:03 EST

Contents:
  Re: Visual Basic Cipher ("Oliver Keeling")
  Re: Metaphysics Of Randomness (Darren New)
  Re: interview (Mr. Tines)
  Re: Trying to find simple, yet effective implementation of crypto... (Mr. Tines)
  Re: Metaphysics Of Randomness (Darren New)
  Re: Metaphysics Of Randomness (R. Knauer)
  Re: Metaphysics Of Randomness (R. Knauer)
  Re: Metaphysics Of Randomness (Darren New)
  Re: Metaphysics Of Randomness (R. Knauer)



From: "Oliver Keeling" [EMAIL PROTECTED]
Subject: Re: Visual Basic Cipher
Date: Tue, 19 Jan 1999 22:10:55 GMT

Following on this thread - I came across the following in a VB news group.
I haven't had the time yet to look at it in any detail but it seems to be
XOR based - dunno how secure it is either, but it seems to work quite fast.
There are some problems though - it seems to struggle with de-coding large
string (it encodes OK) but drops short on the de-code.  I put a 196Kb file
through it and it encrypted it in a second or two (not lightening fast I
know) but better than anything else I have tried in VB.  But when I tried to
decrypt it - it only de-crypted the first 20 lines or so.  This I think is
in part coz VB seems to take ASCII 26 to be the end of file marker so
using -

do while not eof(1)

leads to problems!!

Anyway - hope this helps and maybe some of the cryptanalists out there may
be able to pass comment on how secure it is.

Olly


Option Explicit


Function StrEncode(ByVal s As String, key As Long, salt As Boolean) As
String

Dim n As Long, i As Long, ss As String
Dim k1 As Long, k2 As Long, k3 As Long, k4 As Long, t As Long
Static saltvalue As String * 4

If salt Then
For i = 1 To 4
t = 100 * (1 + Asc(Mid(saltvalue, i, 1))) * Rnd() * (Timer + 1)
Mid(saltvalue, i, 1) = Chr(t Mod 256)
Next
s = Mid(saltvalue, 1, 2)  s  Mid(saltvalue, 3, 2)
End If

n = Len(s)
ss = Space(n)
ReDim sn(n) As Long

k1 = 11 + (key Mod 233): k2 = 7 + (key Mod 239)
k3 = 5 + (key Mod 241): k4 = 3 + (key Mod 251)

For i = 1 To n: sn(i) = Asc(Mid(s, i, 1)): Next i

For i = 2 To n: sn(i) = sn(i) Xor sn(i - 1) Xor ((k1 * sn(i - 1)) Mod 256):
Next
For i = n - 1 To 1 Step -1: sn(i) = sn(i) Xor sn(i + 1) Xor (k2 * sn(i + 1))
Mod 256: Next
For i = 3 To n: sn(i) = sn(i) Xor sn(i - 2) Xor (k3 * sn(i - 1)) Mod 256:
Next
For i = n - 2 To 1 Step -1: sn(i) = sn(i) Xor sn(i + 2) Xor (k4 * sn(i + 1))
Mod 256: Next

For i = 1 To n: Mid(ss, i, 1) = Chr(sn(i)): Next i

StrEncode = ss
saltvalue = Mid(ss, Len(ss) / 2, 4)

End Function


Function StrDecode(ByVal s As String, key As Long, salt As Boolean) As
String

Dim n As Long, i As Long, ss As String
Dim k1 As Long, k2 As Long, k3 As Long, k4 As Long

n = Len(s)
ss = Space(n)
ReDim sn(n) As Long

k1 = 11 + (key Mod 233): k2 = 7 + (key Mod 239)
k3 = 5 + (key Mod 241): k4 = 3 + (key Mod 251)

For i = 1 To n: sn(i) = Asc(Mid(s, i, 1)): Next

For i = 1 To n - 2: sn(i) = sn(i) Xor sn(i + 2) Xor (k4 * sn(i + 1)) Mod
256: Next
For i = n To 3 Step -1: sn(i) = sn(i) Xor sn(i - 2) Xor (k3 * sn(i - 1)) Mod
256: Next
For i = 1 To n - 1: sn(i) = sn(i) Xor sn(i + 1) Xor (k2 * sn(i + 1)) Mod
256: Next
For i = n To 2 Step -1: sn(i) = sn(i) Xor sn(i - 1) Xor (k1 * sn(i - 1)) Mod
256: Next

For i = 1 To n: Mid(ss, i, 1) = Chr(sn(i)): Next i

If salt Then StrDecode = Mid(ss, 3, Len(ss) - 4) Else StrDecode = ss

End Function


'Private Sub cmdDecrypt_Click()

'Dim key As Long
'Dim salt As Boolean
'Dim s As String, ss As String

'key = 1234567890 'Or any other postive integer
'salt = False

's = txt.Text
'ss = StrDecode(s, key, salt)

'txt.Text = ss

'End Sub


'Private Sub cmdEncrypt_Click()

'Dim key As Long
'Dim salt As Boolean
'Dim s As String, ss As String

'key = 1234567890 'Or any other postive integer
'salt = False

's = txt.Text
'ss = StrEncode(s, key, salt)

'txt.Text = ss

'End Sub





--

From: Darren New [EMAIL PROTECTED]
Subject: Re: Metaphysics Of Randomness
Date: Tue, 19 Jan 1999 21:52:53 GMT

 Yes but calculating could take a very long time if the complexity of your
 algorithm is too great. See [1] for details.

These are turing machines. You have all the time in the world. ;-)
If you start worrying about the *efficiency* of your turing machines, or
their speed, you have to start worrying about how long that infinite
tape is going to get, too. :-)

-- 
Darren New / Senior Software Architect / MessageMedia, Inc.
 San Diego, CA, USA (PST).  Cryptokeys on demand.
"You could even do it in C++, though that should only be done
  by folks who think that self-flagellation is for the effete."

--

From: Mr. Tines [EMAIL PROTECTED]
Subject: Re: interview
Date: 19 Jan 1999 20:27 +

###

On 19 Jan 1999 00:56:37 GMT, in 01be4345$57776740$0acdc8d0@computer-liebe
  "Phred Dobbs (take out t