Cryptography-Digest Digest #268, Volume #12 Sat, 22 Jul 00 02:13:01 EDT
Contents:
Encrypting RPCs and visible procedure numbers/session ids ([EMAIL PROTECTED])
Re: Encrypting RPCs and visible procedure numbers/session ids (Thierry Moreau)
Re: RC4 free for noncommercial ? (Bill Unruh)
Re: Q: Cascading multiple block algorithms (Terry Ritter)
Re: Cascading multiple block algorithms (Terry Ritter)
Re: what is the symmetric algorithm for protection of classified info by gov
agencies ? (John Savard)
Re: Has RSADSI Lost their mind? (DJohn37050)
Rabin's information dispersal algorithm (Wei Dai)
IExplore AutoComplete crypto-algorithm ([EMAIL PROTECTED])
Re: On block cipher and automata (Bryan Olson)
Re: Has RSADSI Lost their mind? ("Trevor L. Jackson, III")
Re: Good free stream cipher ? (wtshaw)
Re: IExplore AutoComplete crypto-algorithm (Paul Rubin)
Re: Help with getting started. (David Hopwood)
Re: RC4 free for noncommercial ? (David Hopwood)
Re: Hashing hash algorithms: a waste of time (David Hopwood)
Re: Random Appearance (Mack)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Encrypting RPCs and visible procedure numbers/session ids
Date: Sat, 22 Jul 2000 00:06:52 GMT
Hi all,
I was thinking about encrypting an RPC-based program. Does anyone know
of any packages that fits seamlessly into RPCs? Both Certicom and RSA
do not (they handle things at the TPC/IP level, which is too low for my
application). I have a workaround in place right now, but I'm wondering
if there's another packages that works directly with RPCs.
My second question is this:
What sort of information is passable cleartext and still be
considered okay by cryptoanalysts?
Let's say I've already set up a scheme where I can encrypt all my data
using a magic SDK. The encryption key is calculated by both the client
and server but the encryption key is never passed over the wire. Each
client will have a unique encryption key.
In order to decrypt my data on the server side, I have to know which
client key to use. My solution is for the client and server to agree to
a particular sessionID and the server will keep the key in a binary
tree, indexed by the sessionID. Every call from the client to the
server will include the sessionID and the data to be decrypted.
Is it okay to have this sessionID passed cleartext and not be scoffed at
by cryptologists? Does having the sessionID sent in cleartext pose some
type of security hazard?
Oh, and I know I can encrypt the data to the server with the server's
public key, but because of the way my application is set up, it would be
much to intrusive to do this, because of it's RPC nature. I basically
have to keep the RPC calling intact and work above it.
Thanks for any info.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Thierry Moreau <[EMAIL PROTECTED]>
Subject: Re: Encrypting RPCs and visible procedure numbers/session ids
Date: Fri, 21 Jul 2000 14:17:00 -0500
[EMAIL PROTECTED] wrote:
> Hi all,
>
> My second question is this:
> What sort of information is passable cleartext and still be
> considered okay by cryptoanalysts?
>
> Oh, and I know I can encrypt the data to the server with the server's
> public key, but because of the way my application is set up, it would be
> much to intrusive to do this, because of it's RPC nature. I basically
> have to keep the RPC calling intact and work above it.
>
You are referring to a security requirement called traffic flow
confidentiality, because a cleartext session ID in an eavesdroped packet
gives the ennemy some insight into the level of activity occurring on the
line for a particular session end-point. You should be able to judge by
yourself whether traffic flow confidentiality is important for your
application. Usually, traffic flow confidentiality protection is too
demanding.
- Thierry Moreau
CONNOTECH Experts-conseils inc.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RC4 free for noncommercial ?
Date: 22 Jul 2000 01:06:53 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Doug Stell) writes:
]1. The name "RC4" is copyrighted and can not be used without a
]license.
Trademarked. You cannot copyright a name (not suffcient orginality).
]2. The code was a trade secret, but not patented. It has been argued
]that once the code was reverse engineered, it has lost its
]protections.
Yes. It has. Which is why RSADSI refuses to confirm that arc4 is the
same as RC4, despite the fact that they seem to interoperate completely.
]So, ARC4 may indeed be the obvious choice.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Q: Cascading multiple block algorithms
Date: Sat, 22 Jul 2000 01:31:18 GMT
On Fri, 21 Jul 2000 22:55:42 +0200, in
<[EMAIL PROTECTED]>, in sci.crypt Ichinin
<[EMAIL PROTECTED]> wrote:
>[...]
>I think what he is saying is that the strenght of the (cascade)
>crypto is as weak as the weakest algorithm.
He may be saying that, but it's wrong.
>(why hit a tank from the side when the top armour is weaker?)
Why build a tank with just one layer of armor?
---
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: Cascading multiple block algorithms
Date: Sat, 22 Jul 2000 01:38:42 GMT
On Fri, 21 Jul 2000 15:46:04 -0700, in <e3$rS328$GA.278@cpmsnbbsa07>,
in sci.crypt "Joseph Ashwood" <[EMAIL PROTECTED]> wrote:
>> Sorry, I need further help. Which cipher is the first of the cascade, ci
>or co?
>ciphertext = co(ci(plaintext, key1), key2)
>
>> I suppose it must be co. But I don't yet quite follow the reasoning. Could
>> you please explain the matter together with the semantics of the two
>attacks,
>> i.e. what the analyst gets in each case?
>The analyst gets to choose the plaintext going into ci.
>This plaintext knowledge gives probably knowledge of the output of ci.
>Which translates directly to probable knowledge of the input of co
>From which point the analyst can perform a (probable) known-plaintext attack
>on co, by exploiting a flaw in ci.
But the alternative to having a series of ciphers is to have only one
cipher, and when we have only one cipher, known-plaintext can be
directly applied. So even if the second cipher is as weak as
postulated, it *still* has made things worse for the opponents by
constraining the attack to very limited plaintext structures.
And the whole argument depends upon the second cipher being weak. But
if we can postulate a cipher being weak, we have a real worry when we
are using only one cipher.
The argument shows that it is possible to construct a case in which a
sequence of ciphers is not much stronger than one cipher. That case
is when one of the ciphers is almost invisibly weak in a way which can
be attacked without known-plaintext. In other words, just as there is
no proof of strength for any cipher, there is also no proof of
strength for any sequence of ciphers.
Suppose, however, we have three ciphers in sequence: Then, even if
one cipher is weak in a way which can be addressed in such a stack,
known-plaintext is *still* not useful on either of the other two
ciphers. Where known-plaintext is the worst possible cipher-exposure,
we have thus created a situation which can retain security in the face
of the complete failure of a cipher upon which we are willing to
depend. I'd call that an interesting result.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: what is the symmetric algorithm for protection of classified info by gov
agencies ?
Date: Sat, 22 Jul 2000 02:01:17 GMT
On Fri, 21 Jul 2000 13:44:46 -0500, "Ron Shaffer"
<[EMAIL PROTECTED]> wrote, in part:
>Amazing how much informtion about crypto gets spewed forth in
>this group yet no one here knows crap. The federal government uses
>Type 1 encryption modules for all US classified information. The
>algorithms are classified but the names are not. Just look on the
>Web for any products that are Type 1 certified. Some manufacturers
>are Mykotronix, VLSI (now Philips), Racal, Morotola, and L3.
I've bumped into the names of a lot of Type 1 algorithms in my web
searches for more information about cryptography. However, I would
tend to assume that someone asking 'what is the algorithm' would not
be satisfied with the *name* of the algorithm (and is anyways under
the misinformation that there is only one).
As for Skipjack, a book on INTELINK which seemed to have had as its
main purpose advocating the benefits of SGML says that SKIPJACK was
qualified for use on SECRET but not TOP SECRET information, despite
being primarily aimed at 'sensitive but unclassified' use and
infliction on the great unwashed in the company of key escrow.
Noting that 2^10 = 1024, the old 40-bit exportable keys had just over
a trillion possible values. 80-bit SKIPJACK had a trillion trillion
keys.
Some web sites advertising military encryption products mention that
they have 120-bit keys, and are suitable for controlling the launch of
nuclear missiles. I suppose that at least tells us how *strong* the
algorithms used for classified information must be.
Since the exportability threshold has moved from 40 bits to 64, I
suppose we might multiply by three again; but that still means that if
the AES really is as secure as hoped - no attacks better than brute
force - it would be as good as anything the NSA thinks worth bothering
with. I suppose that's reasurring news.
John Savard (teneerf <-)
Now Available! The Secret of the Web's Most Overused Style of Frames!
http://home.ecn.ab.ca/~jsavard/frhome.htm
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Has RSADSI Lost their mind?
Date: 22 Jul 2000 02:00:35 GMT
NIST has always said and continues to say that they MIGHT pick multiple ciphers
as AES winners. We will just have to see what the actually do.
Don Johnson
------------------------------
From: Wei Dai <[EMAIL PROTECTED]>
Subject: Rabin's information dispersal algorithm
Date: Fri, 21 Jul 2000 18:52:07 -0700
Here is an idea to make Rabin's information dispersal algorithm (IDA)
more efficient, especially when the expected number of missing pieces
is small. If it's already published somewhere, a reference would be
greatly appreciated.
IDA is a method of producing k pieces from a message such that any n of
them can be used to recover the message. If the message length is m,
then each piece has size m/n, and it takes O(m*k) operations to
generate the pieces and O(m*n) operations to recover the message. The
new method improves the run-time to O(m+m*(k-n)) operations to generate
the pieces and O(m+n^2+m*r) operations to recover the message, where r
is the number of pieces among the first n pieces that are missing.
IDA works by treating the message as coefficients of a polynomial of
degree n-1, and evaluating it at k points to produce the k pieces.
Recovery involves polynomial interpolation to obtain the n
coefficients.
The new method treats the message as the values of a degree n-1
polynomial evaluated at points 0,...,n-1. The first n pieces are
produced simply by cutting the message into n equal sized chunks. The
other k-n pieces are produced by interpolating the polynomial at k-n
other points. Recovery involves interpolating the values of the
polynomial at only the missing points. The coefficients of the
polynomial is never explicitly determined.
--
weidai.com
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.security.misc,fr.misc.cryptologie,alt.security
Subject: IExplore AutoComplete crypto-algorithm
Date: Sat, 22 Jul 2000 02:49:34 GMT
IExplore comes with a "nice" feature called AutoComplete, which
stores typed URLs inside forms, search words, passwords, credit card
numbers and so on in the registry.
No need to say how "nice" is this when you are at a cybercafe or
when you share your computer with anyone. :-(
Monitoring registry changes shows as that those values are stored
under:
HKEY_LOCAL_MACHINE\Software\Microsoft\Protected Storage Systems
Provider
The values are stored at
HKEY_LOCAL_MACHINE\Software\Microsoft\Protected Storage Systems
Provider\YourComputerName\Data
The words are stored Item Data binary values and are ciphered.
So the question is, has anybody found or is willing to find or
does know the algorithm used to cipher them? Further, has anyone found
the way to break it?
What kind of crypto-algorithms are typical for Microsoft to use,
apart from propietary (bad)ones such as the flamed PPTP?
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: On block cipher and automata
Date: Sat, 22 Jul 2000 02:52:48 GMT
Mok-Kong Shen wrote:
>
>
> Bryan Olson wrote:
> > The large block is not really necessary. We could use most
> > of the same randomness across multiple blocks, while mixing
> > in a little new randomness with each.
[...]
>
> You are right. One can reserve space in the block for the random
> bits and put into the block correspondingly less number of plaintext
> bits.
But that's beside the point. You can have much more
randomness in each block than that the amount of reserved
space, by re-including randomness from previous blocks.
> The following scheme should also work:
>
> Let n = cipher block size, P_i = ith plaintext block with n-b bits,
> R_i = ith random bit block with b bits, C_i = ciphertext block with
> n bits. Algorithm:
>
> K= given key; R_0 = 0; i=0;
> do
> i=i+1;
> K = K + R_(i-1) mod 2^n;
> C_i = E(K, P_i || R_i);
That seems like a waste. With one random bit per block,
after 100 blocks there are 100 possible values for K (given
the original K) and the middle one's are most likely. For
the same price you could have gotten 2^100, all equally
likely.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Fri, 21 Jul 2000 23:09:20 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Has RSADSI Lost their mind?
Roger Schlafly wrote:
> "Trevor L. Jackson, III" wrote:
> > Interoperability has nothing to do with meeting the governments
> > encryption requirements.
>
> Interoperability *is* one of the gubmnt requirements.
Of course it is. But interoperability does not mandate a single selection.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Good free stream cipher ?
Date: Fri, 21 Jul 2000 21:53:22 -0600
In article <[EMAIL PROTECTED]>, Runu Knips <[EMAIL PROTECTED]> wrote:
> What is going on with my newsserver ? My answer to this posting here
> doesn't appear, and the above posting doesn't appear either... sci.crypt
> is a really small group, shouldn't be hard to load ???
>
For many reasons, sci.crypt does get poor treatment. And, some actually
think that by censorship they can control things they do not understand.
--
Pat B. reminds us that he served in the Nixon Administration for
six years. How can he be proud of that?
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Crossposted-To: comp.security.misc,fr.misc.cryptologie,alt.security
Subject: Re: IExplore AutoComplete crypto-algorithm
Date: 22 Jul 2000 05:21:10 GMT
In article <8lb23q$e11$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
> So the question is, has anybody found or is willing to find or
>does know the algorithm used to cipher them? Further, has anyone found
>the way to break it?
Yes, a description is somewhere on Peter Gutmann's web site. It's
fairly trivial. But it's intended to save stuff on your own computer,
so it doesn't try to provide real security.
------------------------------
Date: Fri, 21 Jul 2000 17:53:58 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Help with getting started.
=====BEGIN PGP SIGNED MESSAGE=====
Chris wrote:
>
> Could someone with more experience on the subject point me in the right
> direction on how to go about deciphering text encrypted with the following
> algorithm?
>
> Start with an arbitrary length password and 32 arrays of 256 random bits
> each (call them array0 to array31) and the text to be encrypted (call it
> text). array0 may be entered with the password, the other 31 arrays are
> preset.
Without specifying how array0 is generated, the algorithm isn't complete.
I'll assume that array0 is the same for several encryptions with the
same password.
There are several weaknesses in your algorithm, but the simplest to
exploit is that, at least for the part of the algorithm given in your
post, the same value is being XOR'd with the plaintext for each message
block (possibly with some initial byte swaps, which don't make very much
difference to the attack). This can be broken in the same way as XOR
with a repeated 256-bit key.
Another weakness is that, for example, in the following step:
> if seg1 is even xor array1 across text (the result from above)
> if seg1 is odd xor array2 across text from the previous function.
some bits of array1 and array2 will be identical; for those bits, this
step has a constant (hence easily reversed) effect. There are similar
weaknesses in the other steps, which suggests that even if the attack
mentioned above were fixed (or for some reason not applicable to the
whole cipher), this probably isn't a very productive approach to
cipher construction.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOXh/7TkCAxeYt5gVAQET/AgAuUTfJQkmrgXCsgTiyPi2rhosfdExhj+D
kROsSWYtZq0ZCSpx0FJisIEKP9RtIt7XxSTFElGw+tyxcUjqR5BwyU38kIEUV7CD
laFuXBDA+DLdD6Yt3H87tarNYQCmNpuAM8dJ290gJ6Ij03IslHn/pxhVFAeVzKWW
9q5kimixo5VZeI1YjWNB5/l1FGFWgJwrNS47dGUekSV6wKswKu2YshvYB9xzIFRO
MSHEtSC88QJQQUPWDsM156AEuHLDNTGZ6yu+p4L718NWBQBJdDv8jB2Sx0GdoLXv
RKMZveKM8Fm1+ardRqn9OqTdeg96JTHYL3qrYomZlxUpN8w1kYJkww==
=WtlI
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 21 Jul 2000 14:35:32 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: RC4 free for noncommercial ?
=====BEGIN PGP SIGNED MESSAGE=====
Runu Knips wrote:
> Runu Knips wrote:
> > I'm looking for a good & free stream cipher algorithm.
> > Does anybody have a suggestion ?
>
> My crypto book states that 'RC4 requires a license fee
> for commercial use'.
That's wrong, RC4 is not patented. Which crypto book?
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOXhRlTkCAxeYt5gVAQEe9Af+NnO2bVHlwjyCdRWCXcQQpMHZDYPs+Xsk
NJA0rVrKoLazrikCnrQRGk/zx0bBseaTujvtuHP2vF0tQnO0PzuXbz7ZbYplc/Zv
DeZDs/+Qn6cArlVdQ53ymGotD3I75lPlBQ7Mwr2GYsMpsnSG3GX5wxZMZVtNyNcH
cwTcKl+xvfNeq0cmaNIGBYy/U1QZiScsql19195N2rP3/YGIaCSxtdkogGxs52dR
HNXoS9ELmDp6ncieMmKfztOvMEJ8v+D0p4itVyOJGjadV/Gf/31e+5U1Z9z2XRMc
TYMCk8N4khfzfRkBGlwVguPdthW0R7uoBS6SvdB49E3ecfcZmCRDMw==
=mRGB
=====END PGP SIGNATURE=====
------------------------------
Date: Fri, 21 Jul 2000 17:38:37 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Hashing hash algorithms: a waste of time
=====BEGIN PGP SIGNED MESSAGE=====
lcs Mixmaster Remailer wrote:
> When computing a signature, does it add security to include the sig and
> hash algorithm in the data which is hashed?
Including a specification of the hash function in the input to the
encoding method is called a "hash function firewall". (There isn't
really much point in including a specification of the signature
algorithm itself, unless there are several similar variants of it.)
The idea is to ensure that if one hash function is broken, this will
not affect the security of the algorithm in the situation where the
relying party is prepared to accept the broken hash, but signatures are
only generated using a different hash. However, read:
Burt Kaliski,
"Hash Function Firewalls in Signature Schemes,"
Slides presented at IEEE P1363 Working Group Meeting, June 2, 2000
(Rev. June 8, 2000)
[somewhere on the P1363a site; I don't have the exact URL]
which shows that whether a hash function firewall achieves the desired
benefits depends a great deal on the signature encoding method, and
an alarming number of encoding methods don't work very well in this
respect. (Fortunately PKCS #1 with RSA seems to be OK.)
[...]
> Consider attacks based on substituting weaker algortihms. For example,
> DSS always uses SHA1. Suppose someone proposes an alternative form of
> DSS that uses a different hash but still the same signing algorithm,
> DSA. Suppose further that this hash eventually is found to be weak.
> Call it JUNKHASH.
>
> Now, using DSA + JUNKHASH allows one to forge signatures, because it
> is easy to create a fake message M_fake which, hashed with JUNKHASH,
> creates the same hash as a legitimate message M_real hashed with SHA1.
> The attacker takes an existing legitimate DSS signature on M_real,
> and substitutes M_fake, saying to use hash algorithm JUNKHASH. The DSA
> signature value is left alone, and the new signature will verify correctly
> since the hash is the same.
>
> This is the basic idea of the attack. Now, the question is, does
> including the algorithm specification (DSS vs DSA+JUNKHASH) in the
> material that is hashed make the attack harder to execute?
In all the cases I'm aware of, the algorithm specification isn't in the
input to the hash, it is an extra input to the encoding method. I agree
that including it in the hash input wouldn't necessarily help much, and
I don't know of any standard that does that other than the DSIG draft
you pointed out.
(In general, the XML security WG seems to be re-inventing a lot of wheels
badly. The last time I looked at a DSIG draft, it seemed as if the authors
had tried to include every idea that might possibly be needed by some
application. Having more than one canonicalisation method introduces a
lot more problems than it solves, for example. IMHO the whole spec could
do with drastic simplification.)
OTOH, even for a variant of DSA where the hash ID is appended to the
hash of the message, the firewall can be broken by inverting JUNKHASH
about 256 times - this is one of the cases considered in Kaliski's slides.
> Of course, it may turn out that requiring the algorithm spec in that place
> does happen to make the attacker's job more difficult, due to the specific
> nature of the weakness he is exploiting. But on the other hand, it could
> conceivably make his job easier, if the exploit happened to work well
> with the particular encoding of the alg spec in the specified location.
An encoding of the algorithm spec will be non-random, and usually constant,
which in principle could have a negative effect on the security - the
encoding methods that have been proven secure generally achieve that by
making the input to the signature primitive close to uniformly distributed
(loosely speaking).
It's possible to make encoding methods secure against hash substitution
attacks, except in "pathological cases", without having an explicit
algorithm spec, though, as described (briefly) in Burt Kaliski's slides
for the version of PSS/PSS-R from P1363a Draft 4.
- --
David Hopwood <[EMAIL PROTECTED]>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOXh8GDkCAxeYt5gVAQF+cggAum56m/S2lWwZVKcQaDj+HBQxdtczYnj3
RK3WVhafa90M9RmbChBUfi+VVzd5jHMwd/rRKM/9pI3KCtDmXmwAGh0V1GMkroYQ
NgiZIF/PvfjI9uvBeVd7DOz7KkUOEaWhljjr3aqgWBUQd5qweznNaYPAsZjHnvCH
m8v7mozXkQFArW/zQOPCkcwEZJrCCxpC1tC9aMHE/ZzVW2x/YqM1mh0mLVn5ZC4e
9iQ/+KTiwiGh5yFhl+RfvTHdEOqJJT8WzAo4eKQH7q849C9/lKHU9Vl2xrEg2KlU
VvMor5Lz5CbOpIqxvrXAZH4temjVUhz5aTRW6lYyMs3J/wKGr7uLOw==
=n38V
=====END PGP SIGNATURE=====
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Random Appearance
Date: 22 Jul 2000 05:33:42 GMT
>
>I forgot about pictures. It seems that merely diluting the message
>would be possible, but I am thinking that a dense message that
>wastes no characters might seem orderly but not be the oder which
>is the intended message. If the ciphertext seemed to be a plausible
>English message but was not the message and was only about as long
>as the real message and was cryptographically strong, that would
>qualify. I don't know if there are other approaches. As I
>indicated in my question, I certainly don't know if anybody has
>succeeded in such a thing.
>
>
>Jim Trek
>Future Beacon Technology
>http://eznet.net/~progress
>[EMAIL PROTECTED]
>
Actually this is more like the old code book ciphers. Which result
in messages such as the classic "Father is deceased"
while "Father is dead" would actually mean something else.
Of course such systems are more like OTPs. They are
subject to known plaintext attacks.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
** 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
******************************
