Cryptography-Digest Digest #591, Volume #10 Fri, 19 Nov 99 14:13:02 EST
Contents:
Re: A Random Key Cipher Machine (Tom St Denis)
Re: Fingerprints for encryption alg. (crippa)
Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: ATTN Scott Nelson (CoyoteRed)
Re: Question about enigma rotors (Erik H.)
Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
Re: AES cyphers leak information like sieves (David Wagner)
Re: Ultimate Crypto Protection? ("Douglas A. Gwyn")
Re: What part of 'You need the key to know' don't you people get? ("Douglas A. Gwyn")
Re: Simpson's Paradox and Quantum Entanglement ([EMAIL PROTECTED])
Re: Backdoor Tactic (Albert P. Belle Isle)
Re: AES cyphers leak information like sieves (Tim Tyler)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A Random Key Cipher Machine
Date: Fri, 19 Nov 1999 13:14:13 GMT
Typing for the most part is too regular to use as 'random' sampling
points along a smooth sine wave. You would be sampling at common
points during 'typing bursts'.
Neat idea otherwise.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: crippa <[EMAIL PROTECTED]>
Subject: Re: Fingerprints for encryption alg.
Date: Fri, 19 Nov 1999 15:06:27 +0100
Roger Carbol wrote:
>
> JPeschel <[EMAIL PROTECTED]> wrote
>
> >>is it possible to construct an encryption algorithm X which
> >>will give the encrypted message a fingerprint? The fingerprint
> >>will assure any reader of the encrypted message -even a reader
> >>without the appropriate key- that the underlaying plaintext
> >>has been encrypted with the X algorithm.
>
> >Sure it is.
>
> Depends on what [EMAIL PROTECTED] means by "assure"
> I suspect. I don't see any way of eliminating false positives,
> that is, detecting the fingerprint mistakenly in any old
> ciphertext, although certainly it could be made unlikely.
>
> .. Roger Carbol .. [EMAIL PROTECTED]
Correct interpreted.
Alice sends the enciphered message, having
this fingerprint, to Bob. If Eva intercept the enciphered
message and performs the fingerprint verification she will
conclude that enciphering algorithm X was used.
If you know how the algorithm works performing the fingerprint
verification one could possibly add certain data D to an, by
the unbreakable algorithm Y, enciphered message so that it would
pass the fingerprint verification.
But then the question arise, how should this data D be added
without destroying the encipherment done by algorithm Y?
This is the situation:
M = plaintext message.
Eub = UnBreakable encipher algorithm (forbidden by ...the world, government
etc.)
Dub = Deciphering algorithm of Eub.
Ex = legal encipher algorithm accomplishing the fingerprint.
V = the algorithm for the fingerprint verification. Returns true or false.
Fd = the Faking Data algorithm giving V(Fd(M))=true for any message M.
1: V(Eub(M)) = false
2: V(Ex(M)) = true
3: How should Fd be constructed such that
V(Fd(Eub(M))) = true
and also that we can find/know the reversing
algorithm RFd of Fd (RFd(Fd(M)) = M ) such that
Dub(RFd(Fd(Eub(M)))) = M
holds ??
If it is impossible to find this Fd and RFd then we are done.
And we could conclude that an enciphering algorithm leaving
a fingerprint is possible.
But alas, we have one situation still to deal with, shown below:
4: V(Ex(Eub(M))) = true
To over come this situation Ex must be able to understand what kind
a message it is about to encipher. The Ex must make sure that M is
a message written in a pre-known language, e.g. English, Swedish,
C++ code etc. But this is most likely infeasable in practice.
(The Ex must at least hold a dictionary and frequency statistics
of the language in question.)
So much for this idea.
--
Best Regards
/Christofer
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
! Christofer T�rnkvist ! ERICSSON UTVECKLINGS AB !
! �L2/UAB/F/V ! SOFTWARE ARCHITECTURE LABORATORY !
! Phone/fax: +46 8 727 57 52 /75 ! Box 1505, SE-125 25 �LVSJ�, SWEDEN !
! [EMAIL PROTECTED] ! Visiting address: Armborstv�gen 1 !
! Take juunk away when mailing ! Ext: www.ericsson.se/cslab !
! ! Int: www-sarc.ericsson.se/public !
! T H E o p e n s o u r c e a t--------------- http://www.erlang.org
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES cyphers leak information like sieves
Date: Fri, 19 Nov 1999 15:08:29 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>[ ... ]
>
>> I'm not certain, but I have difficulty in imagining a "chaining mode"
>> of a block cypher that produces very much diffusion of information
>> between blocks. If using a fixed size, small block block cypher, you
>> should probably applu diffusion to your message first.
>
>Keep in mind that ScottXXu (for one example) is really a block cipher
>with quite a small block size, the uses a chaining mode to get the
>effect of treating the entire file as a single large block (in at
>least some respects).
>
>[ ... ]
>
>> Hell, if it's really important, *and* there's no chance to retransmit it,
>> *and* the channel is really noisy, *and* the bandwidth is so limited you
>> can apply little error correction,
>
>[ ... ]
>
>Let's face reality: you're ultimately talking about one fairly
>specific situation, while AES isn't. You're basically talking about
>how to design a complete secure system for use almost exclusively in a
>single set of circumstances: sending messages over the Internet. If
>it makes you happy to hear somebody say that using AES, (or any AES
>finalist) all by itself is insufficient to ensure secure
>communications in this environment, and that it's possible to improve
>on that, I (for one) have no hesitation in agreeing.
>
>At the same time, I'll ask that YOU keep in mind that AES is intended
>to be one (relatively small) piece in a relatively large puzzle. AES
>is intended purely and only as an encryption algorithm, nothing more.
>In some situations, (as I've said before) it makes sense to use it
>without a chaining mode (I.e. in ECB mode). In most situations, it's
>preferable to use a chaining mode. Along with the solicitation for
>algorithms, if you'd bothered to read through the AES web page, you'd
>have noticed that the NIST is also actively seeking comments about
>chaining modes. They've listed off the chaining modes approved for
>use with DES, give a link to the FIPS pub describing them in more
>detail, and ask for comments suggesting whether others should be
>added, etc. If you (for example) think a chaining mode should be
>added that's similar (or identical) to David Scott's wrapped PCBC
>mode, I'm sure they'd welcome a comment to that effect.
I doubt the bastards would welcome such a commnet. I treid
to enter the AES competion and could not. The ACM give me a pile
of shit and said sure we may publish your compression but most organiizations
like the above are FIXED. No way in hell would the crypto gods
allow "wrapped PCBC" to be a chaining mode for general use.
They would never allow it for two reasons. One it would make the
code to hard to break. And two ass holes like Mr BS who run or
influence the outcome would never let a sugguestion from an
amatuer see the light of day. But thanks for the hollow suggestion
maybe you even meant it.
>
>At the same time, please at least attempt to remain aware that it's
>unlikely to EVER be the sole chaining mode approved or in use. There
>are simply too many situations in which it's completely unusable for
>it to become anywhere close to universal. I've already given one sort
>of situation in which its use in contraindicated. Another obvious
>area is in things like network cards that work with data streams
>instead of relatively high level constructs such as files. At most,
>these could using chaining between the blocks of a single frame. In a
>minimum Ethernet or ATM frame (for a couple of VERY widely used
>examples) they'd have to add padding to even have TWO blocks to chain
>together.
No it would never be approved for use as an alternative. You can bet your
sweet ass the rules are such that no such chaining mode would be allowed
no fucking way would the NSA allow such a mode becasue my friend they
don't really want you or I to have strong crypto.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 19 Nov 1999 15:23:02 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny Bravo)
wrote:
>On Fri, 19 Nov 1999 03:40:26 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>> Well Tom I have to admit I have no idea what you are trying to do.
>
> You had no idea how many wheels with 26 positions would be required
>to have more than 2^128 states and instead of asking what he was doing
>you called him a fool, misspelled stupid, then said he was full of
>shit. Your lack of understanding is only exceeded by the fear you
>exhibit when you don't understand something, and the rage you fly into
>when people don't take you seriously because you are incapable of
>presenting your ideas in a clear and coherent manner.
You asshole he messed his math up and admitted it so shut the fuck up.
The argument really is over wheather one just considers the starting postions
of 3 or more fixed wheels as the key. Or if the actuall order of the
characters on the wheels should count as part of the key. I prefer to count
the wheel types possible it seems you and tom only want to use fixed wheels.
Which greatly reduce the key space. But face it one is simulating the engima
the order of characters on the wheels would be part of the key space.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: ATTN Scott Nelson
Date: Fri, 19 Nov 1999 14:21:10 GMT
Reply-To: this news group unless otherwise instructed!
Scott Nelson said...
> If you have trouble seeing that, consider the
> following sequence. Start anywhere in the first
> half, and what ever number in that position, move
> that many to the right. You'll always end up on
> the last 3.
No, I see that he /can/ get be into sync fairly easily /once/ he has
sync.
I'm just thinking that it would be /much/ harder to get /into/ sync
with skipping, but I do realize that I'm relying on the difficultness
of sampling the signal. I do see your point about using a hash on
each sample, if he gets out of sync, he stays. But, still, if he is
testing say the first 10 bits of the 100 bits string that he has (or
is trying) for a match, and /gets/ a match, he can still follow it out
even with SHA1, right? Because as soon as he gets a mismatch, he
stops and tries each possibility until he gets it right and then off
he goes again.
To prevent the attacker from even beginning a sync, couldn't we start
with a 'seeded' accumulator? Something simple, say, a tick count from
a mouse click. This way he would have to test for each possiblility
of the accumilator at each starting point in his samples.
I do believe that using your technique (if I'm following it correctly)
will get us more bits per second AND perhaps eliminate the possibility
of the attacker /falling/ into sync somewhere in the middle of the
string.
But does this still allow us to keep a good really random number or
will it affect the randomness some way? (other than the fact we can
massage our numbers into the same string, again.) I'm thinking if we
start random then we will stay random /and/ unpredicable, but I
haven't been studying this long enough to know for sure.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: Erik H. <[EMAIL PROTECTED]>
Subject: Re: Question about enigma rotors
Date: Fri, 19 Nov 1999 14:16:00 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> Erik H. <[EMAIL PROTECTED]> wrote, in part:
>
> > See my posting ...
>
> The rotors have 26 electrical contacts, arranged in a circle, on each
> side.
>
> Between these two circular groups of contacts, wires create a
> permutation of the alphabet.
>
> When the rotor is rotated by 1/26th of 360 degrees, a "transposition
> of the alphabet" takes place on the input side of the rotor, and an
> equal and opposite "transposition of the alphabet" takes place on the
> output side of the rotor. The net result is that the rotor provides a
> different permutation of the alphabet, but the different permutations
> are related by means of transpositions.
>
> So in position 1, substitute a with x, b with r;
>
> in position 2, substitute b wity y, c with s.
>
> John Savard (don't snooze, don't snore)
> http://www.ecn.ab.ca/~jsavard/crypto.htm
>
Thank you!
Know I found the 'bug' in my way of thinking how the rotors are build
and used 8-)
Bye,
Erik
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 19 Nov 1999 15:36:47 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry
Coffin) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>[ ... ]
>
>> Your argument appears to be "*IF* the cypher is known to be secure,
>> cryptanalytic attack is useless, so defending against it is a waste of
>> time".
>
>Hardly -- my argument is that if the underlying cipher is weak enough
>that a known-plaintext attack is useful to start with, then it's going
>to take more than a change in chaining mode to fix the problem.
>
You can not be sure that the chosen AES cipher is weak against some
plaintext attack by the NSA.
And true most chaining modes 3 three letter ones that you point out
while the public is lead to belive they are designed with "error recovery"
or same such thing will not be fixed much by there use.
But "wrapped PCBC" does protect a lot better from variuos plaintext attacks
for at least 2 reasons. One you don't have to end on some large multiple of
the underlying ciphers block size. You can encrypt long blocks with out
changing there lengths. Two it is much harder to find and input output pair of
data that is actaully used with the underlying cioher. This is trivailly easy
to do with the letter ciphers under plaintext attack.
You can think of scott19u as only a 19bit cipher ( its a random single cycle
S table form the space of all 19 bit single cycle S tables) that is woven
togher by "wrapped PCBC" you can even add the first and last pass mods
if you truely parinoid.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: AES cyphers leak information like sieves
Date: 19 Nov 1999 08:12:35 -0800
In article <[EMAIL PROTECTED]>, Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> No doubt, D.Scott has presented some interesting, original,
> and potential even useful ideas, although his manner of
> doing so is often extremely rude and annoying, which helps
> explain the lack of serious attention some people accord him.
Interesting. I missed it (perhaps due to the factors you mentioned).
Can you summarize one of his useful ideas? If he's on to something
interesting, I'd honestly like to know.
(The idea of compressing before encrypting isn't new. Neither is the
idea of all-or-nothing-style encryption algorithms which diffuse bits
through the entire ciphertext and plaintext. Those were the only two
that I heard from him.)
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Ultimate Crypto Protection?
Date: Fri, 19 Nov 1999 15:38:53 GMT
Paul Koning wrote:
> "Douglas A. Gwyn" wrote:
> > HJS wrote:
> > > But only by 'practical cryptanalysis' i.e. theft, and not by
> > > pure cryptanalysis.
> > Nope.
> Well, you're not going to get very far by asserting a claim
> that OTP systems, without pad reuse, were broken, unless you
> back up that assertion with an explanation.
Somebody else made an incorrect assertion. Should I let it stand?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 19 Nov 1999 15:43:35 GMT
Tom St Denis wrote:
> Assuming 26 pins per wheel you need 28 wheels to match a 128-bit key.
I don't know how you computed that, but it's bogus on several counts.
An Enigma key consists of (wheel selection and order, stecker plugging,
initial wheel settings). Each wheel wiring was fixed, although that
could in principle be made part of the key.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Simpson's Paradox and Quantum Entanglement
Date: Fri, 19 Nov 1999 16:43:17 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> [EMAIL PROTECTED] wrote, in part:
>
> >Given that
>
> > 1) A and B are complementary
> > 2) A and B are both true XOR A and B are both false
>
> >then, that 1) contradicts 2) is the essence of Simpson's Paradox.
>
> >We can make an arbitrary determination that "A is True"
> >to resolve that paradox, but this choice is arbitrary as we could
> >equally have chosen to make the determination that
> >"B is True". Regardless of the choice we can then instantly
> >determine the complementary variables state as "anti-correlated".
>
> Given (1) and (2), A is not true, and A is not false.
>
> Since (1) and (2) have caused A and B to be self-referential
> statements, the law of the excluded middle no longer applies to them.
>
> This is like the "liar paradox"
It is like _any_ paradox in terms of contradiction;
much in the same sense that 'solving' one NP-complete
problem, will 'solve' the rest.
Paradoxes form a class and any solution on one paradox
gives a clue for solving others simultaneously and
instantaneously.
> either A and B are lacking in
> concrete meaning, or the "givens" are themselves false. You are
> missing whatever part it has that makes it really paradoxical, if any.
>
> Quantum-mechanically, a particle can have a state such that "A has
> spin up" is neither true nor false, but subject to a probability
> distribution. But once A is observed, if B is observed later, B may
> have its own probability distribution, or it may correlate with A in
> some fashion. But it can't, after observation, be both spin up and
> spin down, either.
You're thrashing here abit.
There is no 'probability Distribution' (PD) after the state
is measured. It's only active while everything is dynamic
and not measured and in a very large sense it is only an
abstraction during that interlude between measurements.
A histogram or barchart is a set of possible states with relative
frequencies attached to each state, but as such it is not
interpreted probabilistically. It is just a bunch of
positive amplitudes distributed over the _space_ of states.
If we interpret this histogram or bar chart probabilistically,
then we get a "probability _distribution_". If we Fourier
transform this probabilistically interpreted histogram
or space-like _distribution_ (spectrum) into
the time-like domain, we get a "probability density _function_" (PDF)
or "wavefunction". This is just a time-like Function with a
probabilistic interpretation just as its complementary
space-like Distribution was given a probabilistic interpretation.
The Fourier transform (or more generally, an orthonormal transform):
turns functions into distributions, and vice versa.
Both the PD and the PDF "collapse" when _a single_ measurement
is made into _a single_ state of all the possible states.
You can take that single state measured and add it into
your PD (or its corresponding PDF) to increase its
forecasting ability in future measurements.
_Empirically_, we never really know for sure how large a
state space is, but experimentation can indicate it's size
probabilistically speaking. This empircal and so this
non-deterministic approach leaves open the possibilities of
measuring a state that was never before considered part of the
state space (a hidden variable).
_Theoretically_, we might try to do better and deterministically
define the state space size. But quantum mechanics does not use
this approach (as Einstein was wanting to say to Bohr)
So, measuring a single spin-up particle collapses
both its PD in the space-like domain and its PDF in the
time-like domain and all the other states are then "false"
(in this case there is only one other state in the binary
state-space of up and down spins, so that the spin-down
state is instantly "false" when the spin-up state is
measured as "true")
This is the usual consideration for superpositions of
states (or phasors in state space...) and their corresponding
wavefunction phases in time within the time-domain.
But, entanglement is an additional problem when you consider
not just the state-space of a single particle, but the
state space of two particles that interacted and so their
PD's and PDF's have some memory of that event as if they
were two bell's (or impulse response functions[1]) that
once clanged together and when separated, they maintained
a "memory" of that event in their separate sets of PDs and PDFs.
Those separate memorys are what allow the two particles
to be non-locally correlated, or "entangled".
Those memories however tend fade away (decohere) after a while.
But they should be maintainable, by a _local_ resonant
communications between the entangled particles.
Of what use that may be to quantum cryptography &c.,
I am not concerned with, as I think there are more significant
implications than that.
[1] have a look at the "perturbation" methods
and "Green's" functions in this context.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: Backdoor Tactic
Date: Fri, 19 Nov 1999 11:56:45 -0500
Reply-To: [EMAIL PROTECTED]
On 19 Nov 1999 00:43:42 GMT, [EMAIL PROTECTED] (UBCHI2) wrote:
================================ snip ============================
>
>I challenge the readers of this message to identify a single commercial
>encryption product that does not leave a plaintext tag or one that permits you
>to decrypt without the tag.
>
================================ snip ============================
Document Security Manager.
See
http://www.CerberusSystems.com/INFOSEC/products/docusec.htm
from which I quote:
"Document Inventory gives you centralized access to all of your
sensitive files, while inhibiting identification of encrypted files
for traffic analysis by type or by name. Encrypted files are left in
their original folders, with unchanged names and type-extensions.
Files you choose to decrypt are opened with their associated programs
automatically, after an SHA1 integrity check. On exit, re-encryption
of files is automatic."
The first 8 bytes of the enciphered file are the CBC I.V. and the next
24 contain the encrypted 168-bit (onetime) file-encryption key which
is TDEA-enciphered with a masterkey. The next 296 bytes are a header
containing file integrity data (SHA1 hash digest, original file size
and creation time, etc.) that are TDEA-enciphered using the same I.V.
and one-time key as the body of the file, which follows.
No key ever used to generate more than 2GB of ciphertext.
No plaintext tags.
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Fri, 19 Nov 1999 16:47:53 GMT
wtshaw <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
: ...
: So many have worked so hard to define as respectable those ciphers which
: do not provide error recovery within themselves, while down playing those
: that might. The discussion highlights that normal respectable designs
: are, in essence, insufficent in themselves.
: It does me good to see so many beginning to define vital problems, even as
: I have already solved them. And, if my solutions have fallen on deaf ears
: because they sound strange, better start giving a listen, as they are
: sound answers to the types of difficulties under discussion.
I /presume/ you refer to The Grandview Algorithm - as described at:
http://radiofreetexas.com/wts/gva.htm
After looking at this, I observe that it /appears/ to have the same
characteristic that is being criticised here, that there's almost a 1-1
relationship between between the cyphertext and the plaintext.
I've only given the system a cursory look, but it /appears/ to me that
the consequences of an error in a single letter will /usually/ affect
three adjacent letters in the plaintext (and there's a small chance that
they will destroy the message totally?).
Information /appears/ to propagate horizontally through the message
in only one direction, and by at most two characters.
Please say, if my understanding of this is mistaken.
If it is not mistaken, then this does not appear to be a terribly
attractive scheme to me.
Most of the time, I'd rather have better security than error recovery -
since typically I plan to compress my messages - and compression and
error-recovery are not good bedfellows.
I agree that error recovery should make the messages longer. However,
I think this should be applied *after* any encryption, in most cases.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I pretend to work. They pretend to pay.
------------------------------
** 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
******************************
