Cryptography-Digest Digest #902, Volume #8 Wed, 13 Jan 99 22:13:03 EST
Contents:
New Public Key better than RSA (Terry Boldt)
Re: Encrypted WordPerfect 5.1-files (DOS) ([EMAIL PROTECTED])
Re: Irish school kid encryption (Martin Miller)
Re: HIGH ENTROPY ENCRYPTION IS A MUST!! ([EMAIL PROTECTED])
Rimfire, a base-translation cipher (wtshaw)
Re: What is better : Blowfish, Des, Tripple-Des ([EMAIL PROTECTED])
Re: crypto machines (MKinneyJR)
Re: DES Hardware Implementation!! ([EMAIL PROTECTED])
Re: On the Generation of Pseudo-OTP (Patrick Juola)
Re: On the Generation of Pseudo-OTP (Darren New)
Re: Sarah Flannery and the "Cayley-Purser" Algorithm ([EMAIL PROTECTED])
Re: On the Generation of Pseudo-OTP (Terry Ritter)
Re: On the Generation of Pseudo-OTP (Terry Ritter)
Wassenaar agreement ("David Barton")
----------------------------------------------------------------------------
Date: Wed, 13 Jan 1999 20:03:54 -0500
From: Terry Boldt <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: New Public Key better than RSA
An item was posted to slashdot.com today about a new encryption
algorithm using matrices that is as secure as the RSA algorithms and
much, much faster. The item references the article at:
http://news.bbc.co.uk/hi/english/sci/tech/newsid_254000/254236.stm
Has anybody learned anything about this new algorithm, its merits,
demerits and whether it is as good as the news claims?
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Encrypted WordPerfect 5.1-files (DOS)
Date: Thu, 14 Jan 1999 01:30:04 GMT
AccessData Corp. can help you. They specialize in password recovery. Check
out their web site at http://www.accessdata.com.
In article <916184814.815873@marvin>,
"K&G" <[EMAIL PROTECTED]> wrote:
> Hi there,
>
> I'd like to know if someone who could help me to decrypt
> some (DOS) WordPerfect 5.1-files that are mine (I can
> prove that) but I've lost the password.
>
> Thanx,
>
> Guy Cornet
> [EMAIL PROTECTED]
>
>
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Martin Miller)
Subject: Re: Irish school kid encryption
Date: Wed, 13 Jan 1999 20:42:43 -0500
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
>
> Does anyone have any more specific details about
> this or know where they may be found?
Check this link:
http://slashdot.org/articles/99/01/13/0931237.shtml
And read the comments about the article, there is some more
information...
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: HIGH ENTROPY ENCRYPTION IS A MUST!!
Date: Thu, 14 Jan 1999 01:42:25 GMT
In article <77hvuq$oa4$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Markus Kuhn) wrote:
> [EMAIL PROTECTED] writes:
> |> What I mean by perfect encryption. Perfect encryption
> |> is such that the total entropy is added to the entropy
> |> of the data in the best way possible. Note the total
> |> entropy of data and encryption can never exceed that
> |> of the total message being encrypted. Also note
> |> the entropy added can never exceed the key length that
> |> is used to represent the state of the file. Which
> |> for IDEA for example is 128.
>
> Some Claude E. Shannon has already been there fifty years
> ago (see the nice introduction to the relationship between
> information theory and cryptography in intro crypto
> textbooks such as Douglas R. Stinson: Cryptography -
> Theory and Practice, CRC Press, 1995, 448 pages,
> ISBN 0-8493-8521-0.
>
> Entropy is a pretty lousy concept for measuring
> security of crypto parameters, a very commonly
> made mistake:
The mistake is that people like you don't understand that
Entropy is a statistically thing and applies to the thing
on average. Yes distributons can be skewed or lumpy but
What Entropy does show is this.
If the "plain text message entropy is X" and
if the "encryption entropy is Y" but the message
lenght is Z"
Then if X+Y is greater than Z if the data is not
(again assuming perfect encryption)
lumpy and the key then it is possible to have totally
secure communications.
However it is possible that some information can be
lost if lumpy but not ALL.
Second the case where X + Y less than Z in this case
it is IMPOSSIBLE to always hid all the information from
your attacker. But if limpiness occurs sometimes some of
it can be hidden.
Now in most posts I may talk about averages. But not here
since you made a big deal about your distorted example
so what I have said above is true. Your just a plant trying
to trick people into using weak crypto. Entropy considerations
are very VERY valuable.
Secondly what you have not shown is if this encryption
method is a perfect encryptiion. The entropy of the
encryption method is a UPPER limit to the value that
the encryption method can add the the main message
when encrypting. One could take a message with
entropy 5 and use a encryption method of 6
but end up wiht a combined product of 7.
What I stated was that "perfect encryption is such
that the total entropy is added to the entropy
of the data in the best way possible"
I am not sure if your method meets this critera
but I think you already know that.
I think you read my message you should have seen how
I defined the encryption term or maybe you lack a
good understanding of Entropy Shannon was right you
are wrong and your most likely a plant trying to confuse
people.
>
> Consider the following key generator: 50% of the
> keys are a 1024-bit string of all zeros, the other
> 50% are uniformy distributed truely ramdom 1024-bit
> strings. The entropy of this key generaor is
> obviously
>
> sum p*log_2(1/p) = 0.5 * log_2(1/0.5) +
> 2^1024 * 0.5 * 2^-1024 * log_2(2 * 2^1024) =
> 0.5 * 1 + 0.5 * 1025 = 513 bit
>
Actully your formula is wrong since the all zero string
is used as one of the case there are not 2^1024 case left
but why confuse you with facts you may not have the
mathematical background to follow what I am saying.
But one of the big main things you beggered up is you seem
to lack the knowledege of the correct formula has minus
signs in it like the first term is -.5*(log_2 (1/2)) but maybe
your to stupid to know the log_2(1/2) is -1
But again I can see that complex concepts are beyond
your limited brain.
> A key with 513 bit entropy sounds pretty secure, yet you can
> easily break 50% of all messages by guessing that they
> have been encrypted with the all zero key. Entropy is
> somewhat irrelevant here, the maximum probability
> (or minimum decision content) of every possible key
> is of much more concern for security.
>
> Similar conclusions also apply to the plaintext, on which
> your discussion was focussing. It is better not to talk
> about entropy unless you have fully understood what it
> means.
>
> Markus
May be some day when you learn about logs and stuff you to
can learn about entropy but first you are going to have to
learn a little about basic math. So I suggust you not tlak
so far above your head until you get a better understanding
of the math used in this kind of discussion it is obviouly
way over your head.
David Scott
P.S. study up a little bit next time.
>
> --
> Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
> Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
>
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Rimfire, a base-translation cipher
Date: Wed, 13 Jan 1999 19:16:52 -0600
The basic cipher was presented at the ACA meeting last August in a brief
presentation. It uses two bases, 100 for plaintext and 22 for
ciphertext. It accepts all standard keyboard characters, plus these,
which may or may not display on your screen: � � � �
Since with 22, we can take a shot at almost anything, Cycliste took my
unnamed cipher and said it should be called Rimfire, so it now is.
The exact cipher used at that time is better known as Rimfire 12, and it
used my standard 22 character alphabet, no J, Q, W, or X. In it, a
plaintext block is six characters, which, since they are numbered from 00
to 99, gives you 12 digits per block. The digits are transposed according
to a key, twelve letters from A to L, the demonstration key being IKEGAD
FHLCBJ. The new series of digits resulting from the transposition are put
into three groups of four digits each. Each group will be from 0000 to
9999. Each four number is reduced to 3 letters, giving a result of 9
characters of ciphertext in base 22 for the original 6 in base 100.
Rimfire 12: Pt group is 6 characters, 12 digits are transposed, Ct group
is 9 characters.
This basic cipher is greatly enhansed in implementation that can do
several sizes, Rimfire 8/12/16/20/24, and all aspects of the application
are automatically scaled to the current selected size. The
transpositional key is a series of letters A to whatever, normal sequence,
Rimfire 24 needing to use A to X. For prospective solving, best use
Rimfire 8, and the standard 22 alphabetic set without nulls.
In the implementation, the ciphertext alphabet, Base 22 can be ANY 22 of
the 26 characters in any permuted order. A option allows the unused 4
characters to be automatically inserted as nulls, which are filtered out
in decryption.
The keys can be generated separately, or at the same time from any random
alphabetic strings, text, or the actual key strings themselves, another
use of the THF procedure. The keys are fairly simple ones, as expected.
Let's go whole hog and see what keys generated together will result from
these words for use with Rimfire 24:
Subs(RF): beqmnirsjcgtkoafdphluw
Trans(RF): asmdxrje nfpbtgcu okhvliqw
Preformatting allows completion of the last group which must contain 12
characters. The actual display shows 11 characters short for the last
group, so I will simply ignore the colon at the end of the passage. I'm
using the same sentence for plaintext. The raw encrypted ciphertext in
the expected 18 character groups is as follows:
jccfqanmiaeqfjtuij aplrbqeogabedajkeb oclawjujqabbddqeur
bkphtqeoufhkhjhgbr dsmjdmanodeudtkbda eijssruiphstdsgbkk
qbdliqpwrhsgdudauw emgnnasleagkhjuume aohsfkhmoeklnnmnmm
A function is available to put everything in 5-character groups, but is in
also in the null function. Here is the passage with the added nulls:
jccfq yzanm iaeqf jtuij apylx rbxqe ogabe dxajk ebocl awjuj qabbd dqeur
bkphx tqeou fhkhj hgxbx rdzsm xjdma nodeu dtkbd aeijs sruip hstds gbkkq
vbdlz iqpwr hxsvg yduda uwemx gnnas leagk hjuum eaohs fkhmo eklnn ymnmm y
The last group could be filled out. For decryption, select Decrypt, then,
Postformat, to restore the text. Some compromise is needed, only 1
sequential space, but double return are retained with one of the special
characters. This program is designed for upto 10 K in text lengths, ample
for something like email.
Don't get me wrong, this is not the strongest cipher around, but it gets
some pretty spectacular results from some very basic technology. I
figured that a single 19 permutation table in crude terms is the limit to
stay under 56 equivalent bits, but such a key with this application is
going to be much softer than DES would be.
Being a completely scalable cipher, it could be Rimfire X, as long as X is
a multiple of 4. Long blocks do get difficult to count and pad.
Concerning the swelled output, this can be somewhat helped by converting
the output, apt to have 26 characters, to base 81. I had the option to
design with 27 characters through out, but I chose to be a classical
purist this time. One could even scatter in the /'s by hand, only to
further mask the nature of the algorithm.
Naturally, in I'll try the Base 100 front-end on some other bases, weird
names already chosen for several.....stay tuned....same bat channel.
--
If government can make someone answer a question as they want him to, they can make
him lie, then, punish him for not telling the truth. Such an outrage constitutes
entrapment.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: What is better : Blowfish, Des, Tripple-Des
Date: Thu, 14 Jan 1999 01:54:17 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (David Hamilton) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>
> [EMAIL PROTECTED] wrote:
>
> (snip almost all)
>
> >David A. Scott
>
> >Professional thorn in the side to fishy weak encryption methods!
>
> One dictionary definition of professional is:
> Having or showing the skill of a branch of advanced learning or science as
> one's main paid occupation (often as distinct from amateur).
GEE HAVE A COW
David A. Scott
Amateur thorn in the side of fishy weak encryption methods
Hope your more Happy:)
since I am not paid to do this
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (MKinneyJR)
Subject: Re: crypto machines
Date: 14 Jan 1999 01:55:15 GMT
I don't know if it is still there but at ebay.com someone was selling the
manual of an old M-209 cipher machine. It was a copy of the manual and not in
the best of condition. Hopefully this will help you.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES Hardware Implementation!!
Date: Thu, 14 Jan 1999 01:36:02 GMT
In article <[EMAIL PROTECTED]>,
Vincenzo Liguori <[EMAIL PROTECTED]> wrote:
> We sell such DES implementation in VHDL and Verilog.
See also:
http://www.users.bigpond.com/oceanlogic/des.htm
http://www.hammercores.com/html/des.htm
http://www.sican.com/sbs/Do_DES.htm
http://merchant.calweb.com/business3/business3/memecdesign/xf-des.htm
http://www.altera.com/html/atlas/soln/rd05271998_5681.html
http://www.cast-inc.com/cores/xdes/xdes.htm
http://www.imsdd.fhg.de/ext/produkt/sys2/des_eng.html
http://www.asicint.com/cores2.htm
http://www.workxpert.com/inventra/softcore/catalog/index.html#encrypt
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Patrick Juola)
Subject: Re: On the Generation of Pseudo-OTP
Date: 13 Jan 1999 14:13:21 -0500
In article <[EMAIL PROTECTED]>,
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>Patrick Juola wrote:
>>
>
>> >This means if you find a true absolute assertion then it must have
>> >been deduced from axioms by logical rules.
>>
>> Doesn't follow, I'm afraid. I can make lots of true absolute
>> assertions -- "my coffee cup is full," for instance -- that are
>> not the product of logical deduction.
>
>You are here not working with paper and pencil but are doing
>deduction with your mind.
But, as has been pointed out by more researchers than I care to
count, "deduction with my mind" is not logical in the formal
sense of the word -- and a lot of times, not even in the informal
sense of the word.
It's true that *if* you have a correct set of axioms and a correct
set of rules, *then* you can infer correct assertions via
logical deduction. But the converse -- that a true statement
must have been arrived at through such a deduction, is not only
not true, but it's also disprovable through formal logic.
(Cf. Godel and Tarski).
-kitten
------------------------------
From: Darren New <[EMAIL PROTECTED]>
Subject: Re: On the Generation of Pseudo-OTP
Date: Thu, 14 Jan 1999 01:14:51 GMT
> >> I would respectfully suggest that "Chaitin's Omega" is fairly well
> >> compressed just like that.
>
> >Except for those of us who do not already possess the decompression
> >algorithm.
>
> But first, you need to read his papers so there can be no
> misunderstanding of what it is he is actually saying.
At which point I would then have the decompression algorithm. Sorry, I
missed a smiley in there. :-)
(Now that I've fetched the papers, I'll read them. :-)
--
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: [EMAIL PROTECTED]
Subject: Re: Sarah Flannery and the "Cayley-Purser" Algorithm
Date: Thu, 14 Jan 1999 02:01:44 GMT
In article <77irp9$7rn$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Hi,
>
> Here is a news report from The Times, england. Has anybody seen this
> so called Cayley-Purser Agorithm? Any comments on whether this is an
> important development?
>
> ------------------------------------------------------------------------
> Teenager cracks e-mail code
>
> BY AUDREY MAGEE, IRELAND CORRESPONDENT
> AN Irish schoolgirl was yesterday hailed as a mathematical
> genius after devising a code for sending secret messages by
> computer.
>
> Sarah Flannery used the science of cryptography to design a
> code that is ten times faster than the one currently used to
> convert confidential information so that it can be sent via the
> Internet and e-mail. She has been inundated with offers of
> jobs and scholarships from international computer companies
> and universities.
>
> Miss Flannery, 16, from Blarney, Co Cork, used matrices to
> formulate an alternative to RSA, the current data protection
> code, devised by three students at the Massachusetts
> Institute of Technology in 1977. The result is an algorithm, a
> mathematical blueprint, that is far faster than the RSA and
> equally secure.
>
> Miss Flannery, whose father, David, lectures in mathematics
> at Cork Institute of Technology, devised her code to enter the
> Irish Young Scientists and Technology Exhibition. She won at
> the weekend and left the judges unable fully to comprehend
> her project. They described her work as "brilliant" and one
> judge advised her to patent it.
>
> Miss Flannery said she was thrilled. "I had to go through lots
> of stuff before I finalised the theory," she said. "I reached
> critical points where I would get stuck for three weeks or so.
> I just kept thinking about it and then the whole thing slipped
> into place." The oldest of five children, she earned eight As in
> her junior certificate, the Irish equivalent of GCSEs, with
> extra tuition from her father.
>
> Miss Flannery is now deciding what to do with her new code,
> the Cayley-Purser, named after Arthur Cayley, an eminent
> 19th-century Cambridge mathematician, and Michael
> Purser, a cryptographer who inspired her. She is considering
> publishing her findings rather than patenting as she does not
> want people to pay for her discovery.
>
> She will represent Ireland at the EU Science Contest in
> Greece in September.
>
> -----------== Posted via Deja News, The Discussion Network ==----------
> http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
>
The article is nothing about cracking anything but title does
say "Teenager cracks e-mail code" did she or didn't she?
also as a kid I remmber comments about kissing the blarney stone
so is this like an april fools day joke. Secondly even if it
was good would anyone care or even know?
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19u.zip
http://members.xoom.com/ecil/index.htm
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: On the Generation of Pseudo-OTP
Date: Thu, 14 Jan 1999 03:07:24 GMT
On Wed, 13 Jan 1999 22:33:18 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (R. Knauer) wrote:
>On Wed, 13 Jan 1999 21:25:30 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>>>The radioactive decay TRNG is based on a fundamentally
>>>random physical process, not some characterization of the bitstream
>>>that it outputs.
>
>>One could say similar things about many noise sources:
>
>Yes, that is true. Wherever there is quantum behavior, there is the
>potential for total randomness.
>
>>Thermal noise in a resistance is "fundamentally random."
>
>Yes, but is it crypto-grade random, since there a 1/f white noise
>spectrum associated with it?
It is "white" noise that has a flat spectrum; "pink" noise is 1/f.
(The term "spectrum" comes from light; the low-frequency light is red,
so having more low frequency is a "pink" spectrum.)
As to "crypto grade," I don't think it is necessary to demand that a
physically-random measurement device produce white noise. It will
generally be necessary to process the data from the hardware RNG.
>>Reverse-biased junctions
>>in breakdown seem to be fundamentally random. Nuclear events may be
>>random, but that does not make up for "quench time" delays in Geiger
>>tube detectors.
>
>Who would use a Geiger-Mueller tube these days - assuming a serious
>design?
>
>But yes, there is a latency (dead time) associated with all avalanche
>detectors, even proportional counters which have a quench gas present.
>That has to be taken in account when designing the TRNG.
I don't think quench time *can* be taken into account. If another
event occurs during the quench time, it will not be detected, and may
affect the quench time itself. And when an event is *not* detected,
it can hardly be taken into account. Quench time will introduce an
uncertainty of the time between event pulses, which would otherwise be
"perfectly" Poisson-distributed.
>>A great deal of effort has been spent in making
>>really random generators, and we have many satisfactory designs, butt
>>none that one might call "theoretically proven random."
>
>I disagree. A radioisotope TRNG of proper design is proveably random
>to an arbitrary practical level of precision (which recognizes that
>nothing in the real world is truly "perfect").
Fine. Provide some references to serious articles by serious
experimenters who seriously state that they have a random number
machine which is "provably random."
>It might be slow as all hell, but the output meets the specification
>for a TRNG, namely that it is capable of generating all possible
>sequences of a given length equiprobably (to within an arbitrary level
>of precision).
It is easy for a handwave to meet that specification. But only real
machines actually produce sequences, and real machines neither measure
nor report reality precisely, especially at quantum levels. Nor is it
clear that we can ever know the full story of the distortions in our
measurements.
If the values from physical measurements must be a flat, unbiased
distribution, I doubt we will every have such a machine. If we can
accept post-processing, we don't need such precision, but then of
course we have less of an argument for "absolute" randomness.
>>I have several literature surveys on randomness topics, one of which
>>is "Random Number Machines: A Literature Survey":
>
>> http://www.io.com/~ritter/RES/RNGMACH.HTM
>
>Why didn't someone tell me about this before!
I guess not everyone listens.
There is also a wide array of randomness links on my links page.
---
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: On the Generation of Pseudo-OTP
Date: Thu, 14 Jan 1999 03:07:30 GMT
On Wed, 13 Jan 1999 22:17:59 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (R. Knauer) wrote:
>On Wed, 13 Jan 1999 20:59:42 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote:
>
>>Are you reading the same FIPS 140-1 that I am? That would be:
>>"SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES," 1994 January 11.
>>I find no instance of "strong mixing" or even "mixing" in that text.
>
>Dammit! I mixed that up (no pun intended) with RFC 1750, which is
>where strong mixing is mentioned.
RFC 1750 describes fairly well-known techniques, and there is
remarkably little "proof" argument there.
I claim that any good hash should be a good randomness mixer,
especially when more goes into it than comes out. While RFC 1750 does
not mention CRC mixing, I often argue that a linear CRC hash provides
a fine mixing for really random streams. Many of our hash designs are
essentially "ad hoc," but CRC has a strong mathematical basis for
doing what it does and nothing else.
Certainly any good block cipher fits their criteria of strong mixing;
thus, we can imagine mixing a few bits in a keyed substitution table.
We could use a keyed Latin square combiner, or the combiner-based
ciphering structures I have been promoting for the past few years.
>[...]
>>These attacks address the production of stream cipher confusion
>>streams by *combining* multiple sources, and the combiners allow
>>information from the original sources to leak to the output. We see
>>attack after attack, and subsequent attempts to avoid the attacks.
>
>That seems to imply that the recommendations in RFC 1750 are
>inadequate for purposes of practically secure crypto.
I take no such an implication. I would say that one probably would
not expect a mathematical proof of the "strength" of mixing techniques
(indeed, if such a term applies) unless they are, in some sense,
perfect. Such as a Latin square.
>>But I am unaware of a general theory of "decorrelation" that could
>>avoid any such attack, or transform a sequence with internal
>>correlations into a sequence with no correlations.
>
>Could that be because trying to remove correlations with an
>algortihmic procedure is counterproductive, since such procedure
>itself can introduce correlations because it is algorithmic?
I suppose we might say that of nearly anything in modern cryptography.
Presumably, ineffective procedures have compromised what needs to be
done in some way or other. The need to have "fast complexity" often
compromises designs, but does not mean that there is not some other
technique which is effective.
>After all, if one can compute the nth and n+1th state of an algorithm,
>there is a strong correlation between the two outputs.
In a stream cipher, we traditionally address such concerns by having
more than one substitution alphabet ("polyalphabetic substitution").
Then the issue becomes producing and selecting the alphabet,
presumably based on keyed internal state. Then we ask "can anyone
reproduce that internal state?"
>>The lack of such
>>a theory might make the topic somewhat difficult to discuss.
>
>Maybe that is the theory - that algorithmic decorrelation is
>impossible.
"Algorithmic decorrelation" certainly *could* be impossible if you
define it that way. That seems rather unuseful, however.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "David Barton" <[EMAIL PROTECTED]>
Subject: Wassenaar agreement
Date: Thu, 14 Jan 1999 01:42:41 -0000
Does any one know of any (rough) dates for the Wassenaar agreement to be
implemented in any of the participating countries, particularly the UK?
Thanks Dave
------------------------------
** 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
******************************
