Cryptography-Digest Digest #273, Volume #11 Tue, 7 Mar 00 17:13:01 EST
Contents:
Re: are self-shredding files possible? (Paul Koning)
Re: sci.crypt Cipher Contest (Adam Durana)
Re: why xor?(look out,newbie question! :) (Mike Rosing)
Re: sci.crypt Cipher Contest (Mike Rosing)
Re: Best language for encryption?? (Jerry Coffin)
Your Recommended Choice On Std Crypto Parts ([EMAIL PROTECTED])
Re: are self-shredding files possible? (Vernon Schryver)
Re: why xor?(look out,newbie question! :) (Vernon Schryver)
Re: Your Recommended Choice On Std Crypto Parts (Jerry Coffin)
RE: The Voynich manuscript ("Manuel Pancorbo")
Re: Best language for encryption?? (Roger Carbol)
Possibly dumb question about re-encrypting a data stream ([EMAIL PROTECTED])
Re: are self-shredding files possible? (Nikita Borisov)
Re: are self-shredding files possible? (Dave Howe)
Re: Crypto Speeds... (D. J. Bernstein)
Re: math error? NOT AT ALL ... (jungle)
Re: RC4 and salt (Pawe� Krawczyk)
Re: Cellular automata based public key cryptography ([EMAIL PROTECTED])
Re: Help me to win a challenge! (Jim Gillogly)
----------------------------------------------------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Tue, 07 Mar 2000 12:07:46 -0500
Nikita Borisov wrote:
>
> In article <uyvUqbvh$GA.247@cpmsnbbsa04>,
> Joseph Ashwood <[EMAIL PROTECTED]> wrote:
> >To consider such is an excercise in faith, to practice such
> >is foolishness. You have no way of stopping an individual
> >from taking your code, and debugging it. From there it is a
> >simple matter to grab the key, or create an altered client
> >that will permanently store the keys.
>
> Disappearing Inc.'s threat model is that both the sender and the
> receiver of a message are not malicious (or at least that's what they
> claimed last time I talked to them). The expected usage is two parties
> who want their business communications via email to have non-permanence
> properties similar to phone conversations (modulo the 30-day expiration
> period). Claiming protection against non-cooperative sender or receiver
> is indeed foolish, but last time I checked, Disappering Inc. wasn't
> doing that.
That's not how I read what they say on the website. What you
describe makes no sense at all. If you only think about
two parties and neither is malicious, all you need is
plaintext email.
The reason you need more is that you have a malicious
sender, a malicious receiver, or a third party. It is only in
that context that you need more than simple email. In particular,
in that context a "self shredding" file would be really nice to
have. It would protect you from the case where the third party
is the government, armed with a warrant. But unfortunately
that goal is impossible.
Disappearing Inc. clearly says that they "Reduce... liability by
preventing disclosure of old messages". I'd love to see how they
plan to reply the first time they are hit with a subpoena.
paul
------------------------------
From: Adam Durana <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest
Date: Tue, 07 Mar 2000 18:15:30 GMT
> Ever heard the phrase "a little knowledge is dangerous"?
> In my opinion, there is no such thing as an "amateur cryptographer",
> any more than there is such a thing as an "amateur brain surgeon".
> "amateur" is a synonym for "I have not studied this subject
sufficiently
> to be competent".
Actually by amateur I meant a non-professional cryptographer, someone
who studies cryptography as a hobby, not a profession. And it is
possible for an hobbyist to have a great deal of knowledge on his/her
hobby.
> Oy Vay. I very seriously doubt whether there are more than 3 regular
> contributors to this newsgroup who are actually competent to design
> one.
Maybe you could take part in the contest by breaking a few ciphers, to
prove this point. You could show the incompetent how much more they
really need to learn.
I hope you will take part.
- Adam Durana
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Tue, 07 Mar 2000 12:34:49 -0600
Mok-Kong Shen wrote:
> I don't understand. From my (certainly outdated) knowledge, a
> manufacturer issues a document where the arithmetic instructions
> are described. These are certainly dependent on a single type
> of the ordering of the 'high' and 'low' bytes. So one manufacturer
> couldn't belong to both groups, I suppose.
"Endianness" (what a cool word!) comes from the history of
microprocessors.
When small machines began to have larger registers than bus width, the
order
the register was filled or dumped with mattered. It makes sense both
ways,
for little-endian order you can march thru memory and go from 8 to 16 to
32 bits
and not have to change your pointers. For big endian order it's easier
to
see what is in ram if things are in readable order.
Today bus width is the same or larger than the register width. So
endianness
doesn't matter. Most processors have a bit you can flip which will
change the
storage order in ram. It just passes the data thru a permutation
register
which doesn't take very many gates.
I grew up on big-endian processors, so I always have bugs to fix when I
do
things on little-endian ones. Manufacturers have taken pity on me and
made
their processors do it either way, so if I want big-endian I can get it.
Patience, persistence, truth,
Dr. mike
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest
Date: Tue, 07 Mar 2000 12:51:23 -0600
Quisquater wrote:
>
> Maybe it's time to see at
>
> http://cryptonessie.org
Interesting. Possibly too formal for a Cipher Contest but certainly
accessable
to hobbiests. I only have one quick comment on the proposal:
:9.Asymmetric identification schemes
: The minimal computational effort for an attack should be of the
order of 280 3-DES
:encryptions. The probability of impersonation should be smaller than
2^-32.
I think that should be 2^-40 or better 2^-64. Present world population
is approaching
2^32 and having a probability of impersonation in the possible range
doesn't give
a warm fuzzy intuition. I'm sure it's good enough, but when someone can
impersonate
a leader of a country things get bad :-)
Patience, persistence, truth,
Dr. mike
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Tue, 7 Mar 2000 11:56:05 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> Algol 60 is the original strongly typed language; all the others
> (Pascal, Modula, Algol 68, Ada) derive from that.
Only sort of true at most -- just for example, ML derives a great
deal more from LISP than Algol.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED]
Subject: Your Recommended Choice On Std Crypto Parts
Date: Tue, 07 Mar 2000 19:06:45 GMT
Technical Question.
If I want speed and good security for encrypting
a data stream, and I only want one choice of
crypt algorithim for each part, with no patent $
issues, what should i choose, more importantly
what would You use.
I do not want to support N different algorithims,
or key length choices, etc..
The data is not ultra-sensitive, ie., not e-
commerce, or long-term secrets.
There is no Trusted Certificate Provider. (
public key is manually verified by user )
And I don't want to use, what would be for my
application, a feature bloated protocol like SSL
or SSH.
If the underlying crypto technologies loses
favour in 10 years, then an outright new protocol
version / implementation is acceptible.
Desperatly want to avoid feature creap / allow
for easier analsys.
Is there an existing minimilistic style protocol
that meets the above requirements, otherwise My
initial preferences are listed, but seeking
consensus, alternatives.
- Public Key? : D & H
- Symetric? : TwoFish 128 bit key
- Key setup times is important % as may be
small sessions.
- Must be FPGA friendly
- Cryptographic Hash? : SHA-1???
- Is SHA1 $ free in all situations?
- Is there an acceptible hybrid (aware of SSH
crc-32 fiasco)
- Given data is not high sensitive, is a weaker
faster crypt hash acceptible.
- Is writting 'n' of the first bits of the key
in the encrypted stream an acceptable soloution
to reduce data expansion, or is this an
instrinsically bad practice [ as optionally
available in ssh ].
- Preference for MAC?
- Should I use magic numbers from both sides
- ???
- PRNG : Yarrow-160 for wintel : and on unix?
- Any Ports in the pipe line ?? ;-)
- Your Gut Feelings and Any other
recommendations.
The Full Source will be open to all for review
during/after implementation.
If there is a better location to discuss this,
please let me know.
thanx.
ben.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: 7 Mar 2000 12:27:51 -0700
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
> ...
>Disappearing Inc. clearly says that they "Reduce... liability by
>preventing disclosure of old messages". I'd love to see how they
>plan to reply the first time they are hit with a subpoena.
Why can't they answer "we're sorry, your honors, but we don't have that
key anymore"?
(Not that the claim of self-shredding is other than dishonest snake oil
against an uncooperative recipient who chooses to do any of the obvious
things, from manually transcribing the message or taking screen shots
of the decrypted message to patching the application binary to capture
the text just before rendering it. Note that to patch the binary you
probably would not need to modify it. It's likely that a special DLL
with a special version of ExtTextOut() or similiar would be effective.)
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: why xor?(look out,newbie question! :)
Date: 7 Mar 2000 12:33:41 -0700
In article <[EMAIL PROTECTED]>,
Mike Rosing <[EMAIL PROTECTED]> wrote:
>> I don't understand. From my (certainly outdated) knowledge, a
>> manufacturer issues a document where the arithmetic instructions
>> are described. These are certainly dependent on a single type
>> of the ordering of the 'high' and 'low' bytes. So one manufacturer
>> couldn't belong to both groups, I suppose.
> ... Manufacturers have taken pity on me and made
>their processors do it either way, so if I want big-endian I can get it.
That might be understood as a switch that must be set when a box is
designed or built. I fact, some high volume commercial processors swizzle
the bytes depending on a processor status bit that is associated with a
process, and that suffers the necessary changes during a kernel/user
transition.
("Swizzle" is an offical term of the art in at least one of the vendors
that has designed such processors.)
(There are some patents on run-time or boot-time byte swizzling that seem
to me to be obvious to anyone even slightly skilled in the art, but then
I'm not a lawyer.)
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Your Recommended Choice On Std Crypto Parts
Date: Tue, 7 Mar 2000 12:56:19 -0700
In article <8a3k01$3b0$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> If I want speed and good security for encrypting
> a data stream, and I only want one choice of
> crypt algorithim for each part, with no patent $
> issues, what should i choose, more importantly
> what would You use.
[ ... ]
> - Symetric? : TwoFish 128 bit key
> - Key setup times is important % as may be
> small sessions.
> - Must be FPGA friendly
Skipjack is another algorithm worth considering, at least IMO. As I
understand it, Skipjack is patented but free for all uses.
> - Cryptographic Hash? : SHA-1???
> - Is SHA1 $ free in all situations?
Yes, at least as I understand things.
> - Given data is not high sensitive, is a weaker
> faster crypt hash acceptible.
MD5 or RIPE-MD 160 are both perfectly reasonable alternatives.
Offhand, I don't believe any of them has a huge speed advantage over
the others.
> - Is writting 'n' of the first bits of the key
> in the encrypted stream an acceptable soloution
> to reduce data expansion, or is this an
> instrinsically bad practice?
IMO, it's perfectly reasonable practice if and only if N is 0.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: "Manuel Pancorbo" <[EMAIL PROTECTED]>
Subject: RE: The Voynich manuscript
Date: Tue, 7 Mar 2000 20:06:38 +0100
>=20
> Some artificial languages, instead of merely being constructed from
> mixtures of natural languages (like Esperanto) with some
> regularization of grammar and spelling, instead are designed so that
> even the individual letters are associated with meanings; thus, in
> English, 'cat' and 'dog' are the names of animals, and 'chair' and
> 'desk' are the names of pieces of furniture - in an artificial
> language of this kind, the word for cat might be kaman, the word for
> tiger might be kamap, the word for dog might be kapeg, and the word
> for chair might be temog and the word for table might be temul.=20
I think you are a bit misinformated about Esperanto; under the point of =
view of the discussion, it's not "merely" a construction from natural =
languages in mixture.
Esperanto _also_ has the property that the words are builded up with =
common significant units, in a manner slightly different to the Savard's =
example but consequent with the actual discussion. The minimal =
significant unit is not always a single letter, but often. For example:
bov'o -> bull =20
bov'in'o -> cow
bov'ej'o -> dairyfarm
bov'ajh'o -> beef
bov'ist'o -> cowboy
bov'um'i -> to act as a cow :-)
...and this rules can be aplied to any wordroot. Moreover Esperanto is =
"grammar-coded" so the different grammar functions of a word are coded =
consistently: substantives end in "-o", adjectives in "-a", present =
tense in "-as", etc, etc.
In the following address there is some reference links with information =
about Esperanto in english.
http://www.esperanto.net/info/index_en.html
--=20
+ Manuel Pancorbo
+ [EMAIL PROTECTED]
+ "...
+ M=E1s vale aprender una sola l=EDnea de Ciencia
+ que postrarse cien veces en oraci=F3n. (Cor=E1n)
+
+ Pli valoras lerni ech nur unu linion de Scienco
+ ol preghe genui cent fojojn. (Korano)
+ ..."
------------------------------
Subject: Re: Best language for encryption??
From: Roger Carbol <[EMAIL PROTECTED]>
Date: Tue, 07 Mar 2000 20:14:29 GMT
This is silly. Everyone knows the best language
for encryption is Navajo.
.. Roger Carbol .. [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Subject: Possibly dumb question about re-encrypting a data stream
Date: Tue, 07 Mar 2000 20:29:14 GMT
Hello,
This might be a dumb question, I just don't know. All I know is that
I'm suspicious of everything.
Consider the following scenario:
1) Alice encrypts a message and sends it to Bob.
2) Bob decrypts it and re-encrypts it with another key. He sends it
to Carl.
3) Interloper Eve receives both messages and wants to know what was
said, and/or anything about the key.
A stream cipher is used with XOR being the operator.
Can Eve gain anything knowing that the same plaintext was used in both
cases?
I know this is a problem if Alice is hostile and wants to know Bob's
key. But if Alice and Bob trust each other, is there a problem with
this scheme? I also know that this scheme is suceptible to replay
attacks - let's just say I've got that covered already.
Forever learning,
Charles R. Wright
------------------------------
From: [EMAIL PROTECTED] (Nikita Borisov)
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: 7 Mar 2000 20:51:47 GMT
In article <[EMAIL PROTECTED]>,
Paul Koning <[EMAIL PROTECTED]> wrote:
>That's not how I read what they say on the website.
I don't see anywhere on their site where they say that their system will
work in the face of malicious communicating parties (although I will
grant that they don't explicitly say that they won't).
>What you
>describe makes no sense at all. If you only think about
>two parties and neither is malicious, all you need is
>plaintext email.
One of the points that they were making was that your email message may
go through several mail servers, all of which may make backups.
Further, even with cooperating users, you may want to keep a copy of the
message on your disk for a few days to refer back to it. Even if you
remember to delete all copies after some period of time, there may have
been backups made, or perhaps the mere fact of writing it to disk has
left a copy on some empty sectors. Disappearing Inc's plugin never
writes the plaintext to disk. The expiration period lets you keep a
message around for a bounded amount of time, but afterwards, any copies
you or anyone else might have made are useless. The bottom line is that
it's possible to do all this without the aid of Disappearing Inc., but
it requires a higher level of security consciousness than most business
users typically have.
>Disappearing Inc. clearly says that they "Reduce... liability by
>preventing disclosure of old messages". I'd love to see how they
>plan to reply the first time they are hit with a subpoena.
Deleting old keys is their routine and advertised business practice.
It's true that this is somewhat of an uncharted legal territory, but I
think they should be able to draw parallel between the existing practice
of shredding documents and what they do.
- Nikita
------------------------------
From: Dave Howe <DHowe@hawkswing>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: are self-shredding files possible?
Date: Tue, 07 Mar 2000 20:51:02 +0000
Reply-To: DHowe@get_email_from_sig
In our last episode (<alt.security.pgp>[Sun, 05 Mar 2000 17:44:34
-0800]), Michael Sierchio <[EMAIL PROTECTED]> said :
>Joseph Ashwood wrote:
>> You obviously don't do much programming, at least none
>> security related.
>I see no future in communicating with someone who compounds
>ignorance with arrogance. <PLONK>
I agree with you in respect to this individual - but note that this
approach *IS* valid - if and *only* if the user wants to be able to
repudate access to the message later. Against a user determined to
bypass the security, there isn't a chance in hell.
------------------------------
From: [EMAIL PROTECTED] (D. J. Bernstein)
Subject: Re: Crypto Speeds...
Date: 7 Mar 2000 21:19:51 GMT
Eric Young wrote:
> For most crypto using non-standard constructs, hand coding is a big win.
Runu Knips <[EMAIL PROTECTED]> wrote:
> But in practice I would use the GNU MP libary for code like this.
Um, do you realize who you're talking to? Eric's BN library (from
OpenSSL 0.9.3) is faster than GMP 2.0.2 for 512-bit multiplication on
both of the major Pentium lines. See
http://cr.yp.to/speed/mult.html
for benchmarks. (My own experimental library from
http://cr.yp.to/zmodexp.html
is even faster.)
``Reuse an expert's code'' is the right advice for most people. But it's
useless advice for the experts writing the code in the first place.
---Dan
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: math error? NOT AT ALL ...
Date: Tue, 07 Mar 2000 21:37:22 GMT
when you have a problem with my estimation,
please post your findings to the forum for pier review
when you will read my description again, you will see why it is not flawed ...
Bruce Hudson wrote:
>
> jungle wrote:
> >
> > I will do again, this time specially for you ...
> > he is building pass from 10 words, each word is = 2 random char ...
> > my assumption is, that each word is = 4 random char, not 2 ...
> > therefore the key space is 4 [ char ] x 10 [ words ] = 40 char long ...
> > for the 40 char long pass, key space for brut force is
it is not for calculation of combinations of 10 words 4 char long !!!
the original person used DICEWARE to help select 10 random words + connecting
char to create pass text, he estimated that each word in his pass text EQUAL ==
HAS WEIGHT of 2 random char [ or about 3 char per DICEWARE, when I can remember
well ... ], the physical length of each word from DICEWARE used is more than 2
random char allocated for computation, the words are about 6 or 7 char long
to make this comprehensible to ALL people,
the DICEWARE pass text [ sentence ] of 10 words + connecting char EQUAL to ~ (
10 x 6 char + 9 connecting char ) ~ 70 char long >> PHYSICAL sentence LENGTH
which in turn is EQUAL to ~ 20 char long PASSWORD [ 1 word 20 char long ] >>
with his assumption of word == 2 random char which in turn is EQUAL to ~ 40
char long PASSWORD [ 1 word 40 char long ] >> with MY assumption of word == 4
random char
the assumptions [ 10 / words / DICEWARE / word == 2 random char / word == 4
random char ]
has been used to compute the pass length only == pass is [ 20 ] 40 char long &
all calculation are to estimate what is the number of passwords created by
permutation [ no repetition ] in the set of 40 char
> > nPr = n!/(n-r)! ; when n = 40 & r=40
^^^^^^^^^^^^^^^^^^^^^^^
the nPr == for calculating Permutations [ no repetition ]
the BIT SPACE for brut force crack pass 40 char long is
2^(40 char x 8 bits) == 2^320 = 2 x 10^96
compared to 2^128 == 3 x 10^38 in symmetric 128 bit encryption, you should see
that in any mean the BIT SPACE WITH RANDOM 40 CHAR PASSWORD [ 1 word ] will
exhaust all possible computational power
it is base on needed computational power to crack [ brut force ] symmetric
encryption with key 128 bit long
symmetric encryption 128 bit key == 3 x 10^38
40 random char long password == 2 x 10^96
40 random char long permutation password == 8 x 10^47
== no char repetition !!! >> my assumption !!!
== to make the probability of any CHAR from the set of 40 char
in the 40 char long pass EQUAL
== NO REPETITION == LESS passwords
== in CHAR SPACE, & NOT in BIT SPACE !!!
> [ 26 lower case + 14 other characters to simplify calculation !!! ]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > nPr = 40! = 8.2 x 10 ^ 47 >>>> 8.2 x ( 10 to power 47 ) >>>>> 10 to power 48
> >
> > the ball is in your court ...
> >
>
> Your math is flawed. To start with, the equation you are using
> (nPr) is for sets built "without replacement". In other words, it only
> applies if each of your 40 characters can only be used once each. You
> may want to pick words without replacement but I doubt you would want
> to restrict the letters that way. The correct formula with replacement
> is n^r.
>
> p = number of passwords
> w = number of different words
> l = word length
> n = number of characters
> r = number of words per password
>
> If you want to insist on distinct words in each password, then
>
> p = w! / (w! - r!)
>
> The number of words will depend on what-ever "language" you want
> to use but:
>
> w < (n ^ l) [and probably much, much less]
>
> The upper bound (assuming arbitrary 4 letter combinations is:
>
> p = (n ^ l)! / ((n ^ l)! - r!)
>
> = (40 ^ 4)! / ((40 ^ 4)! - 10!)
>
> This is roughly equal to "p = (40 ^ 4) ^ 10 = 40 ^ 40", the equation
> for allowing duplicate words in a password. This is about 10^65 by my
> rough estimate. Obviously, as the number of words decreases from 40^4
> the effect of disallowing replacement becomes stronger.
------------------------------
From: Pawe� Krawczyk <[EMAIL PROTECTED]>
Subject: Re: RC4 and salt
Date: 7 Mar 2000 21:29:05 GMT
[EMAIL PROTECTED] wrote:
> http://turing.vironix.co.za/public/andrewr/Cryptography.htm
> The machine does not seem to exist. Anyone out there know a working
> site to find this paper?
http://www.tik.ee.ethz.ch/~mwa/RC4/WeakKeys.txt
A CLASS OF WEAK KEYS IN THE RC4 STREAM CIPHER
PRELIMINARY DRAFT
ANDREW ROOS
VIRONIX SOFTWARE LABORATORIES
--
Pawel Krawczyk, CETI internet, Krakow. http://ceti.pl/~kravietz/
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cellular automata based public key cryptography
Date: Tue, 07 Mar 2000 21:32:55 GMT
In article <8a1occ$3vm$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Dr. Yongge Wang) wrote:
>
> I have just checked that page. I am not familiar with CA. But I am
> familiar with FSM (from Hopcroft etc. book). It seems that
> CA is a completely different notion than the Finite Automaton.
> CA equiv Turing machine, so are different from Finitte Automaton.
> If your notion of FSM is not Finite Automaton.i
> then we may talk about completely different things. And if I am wrong
> then I would like to apologize for the previous email.
>
You and your previous message are *correct*,
not wrong. Cellular Automata (CA) are arrays
of identical FSMs that operate with
synchronicity. The input to the FSM at each
cell is the set of state variables from the
FSMs at neighboring cells. The nature of the
automaton is determined by the
dimensionality and topology of the array
*in addition to* the transition diagram of
each FSM. A CA is programmed by putting the
states of its cells into a given initial
configuration from which it evolves
autonomously. As Misra and Mitral first
demonstrated, FSMs can be synthesized from
CA. To more formally understand the
relationship between FSMs and CA go to
http://www.mrc.uidaho.edu/mrc/people/
nystrom/ccp_rick/node3.html
AND
http://alife.santafe.edu/alife/topics/cas/
ca_faq/general.html
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Help me to win a challenge!
Date: Tue, 07 Mar 2000 21:45:42 +0000
Oriol Quinquill� Capdevila wrote:
> Given the English alphabet, they're going to make a permutation
> (for example: A->C (C->A), B->Z (Z->B), D->K (K->D), and so on),
> and using it they will encrypt a text. Given the cipher, we have to
> recover
> the original text.
> * * * The winer is the one who develops the algorithm which consumes
> less CPU ***
If they give you the correct word divisions, then the min-CPU algorithm
will almost certainly be one that includes a good word list and matches
pattern- and non-pattern words to iteratively narrow down the possible
words at each step. If they suppress word divisions, developing a fast
program to solve it will be more challenging, especially if the challenge
cipher is rather short (e.g. 30-100 characters). In either case individual
letter frequencies will be inadequate for achieving a complete solution.
If the permutation they choose is in fact reciprocal, as in your
example above, be sure to use that fact in your search strategy.
--
Jim Gillogly
Highday, 16 Rethe S.R. 2000, 21:40
12.19.7.0.6, 10 Cimi 14 Kayab, Sixth Lord of Night
------------------------------
** 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
******************************
