Cryptography-Digest Digest #535, Volume #10 Tue, 9 Nov 99 20:13:03 EST
Contents:
Re: How protect HDisk against Customs when entering Great Britain
([EMAIL PROTECTED])
Re: Re: How protect HDisk against Customs when entering Great Britain (CoyoteRed)
Re: Can the SETI@home client be protected? (John Savard)
Re: Can the SETI@home client be protected? (John Savard)
Re: Can the SETI@home client be protected? (John Savard)
Re: Can the SETI@home client be protected? (John Savard)
Re: Can the SETI@home client be protected? (Justin)
Re: Lenstra on key sizes (Justin)
Re: The story of a small boy --- sealed envelops --- encryption technologies
(bob98g)
Re: Build your own one-on-one compressor (Tim Tyler)
Is there a secure-messaging service? (MDR)
Re: Build your own one-on-one compressor (Tim Tyler)
Re: The story of a small boy --- sealed envelops --- encryption technologies
(SCOTT19U.ZIP_GUY)
Re: Build your own one-on-one compressor (Tim Tyler)
Re: The story of a small boy --- sealed envelops --- encryption technologies
([EMAIL PROTECTED])
Re: Compression: A ? for David Scott (Tim Tyler)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.security.pgp,comp.security.pgp.discuss,comp.security.pgp.tech,alt.privacy,alt.privacy.anon-server
Subject: Re: How protect HDisk against Customs when entering Great Britain
Date: Tue, 09 Nov 1999 20:38:27 GMT
On 9 Nov 1999 01:45:29 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote:
>
>No. US law prevents you from taking any encryption, no matter where you
>got it, out of the US without a license.
Didn't realize that. So everytime the laptop goes out with PGP,
encrypted browser etc..., the carrier is commiting a criminal offense?
I knew that was the case with certain versions of browser encryption
and with the US version of PGP but didn't think that carried over to
the international versions. Guess that explains why the US version
can't be obtained outside the US and why the international versions
always seem to go to a site outside the US for download. Truly an
example of a law that will never work as was originally intended yet
will probably remain in place as it will give the authorities yet
another reason to harass various individuals without a real reason.
------------------------------
From: [EMAIL PROTECTED] (CoyoteRed)
Subject: Re: Re: How protect HDisk against Customs when entering Great Britain
Date: Tue, 09 Nov 1999 20:37:50 GMT
Reply-To: this news group unless otherwise instructed!
On Tue, 09 Nov 1999 19:57:11 GMT, [EMAIL PROTECTED] wrote:
>
>I encrypt most of these files and then hide the directories. How
>detectable are files/folders hidden by such a utility. It would be
>hard to imagine Joe Blow Customs dude being able to find them without
>bringing in the super geeks from hell at the government Orwell
>division.
I read the instructions on Magic Folders and it says that it does not
protect against someone seeing it from a LAN, etc. You have a small
program that runs at boot that hides the directories, if you don't
have that file running then you have your directories in full view.
I did say before to look into Magic Folder, but now I saying Magic
Folders is /very/ lame. It /might/ guard against a causal viewer, but
boot from a clean floppy, look in from a LAN, or maybe even bring it
up in safemode, and your protection is gone.
Don't rely on Magic Folders to secure your data.
--
CoyoteRed
CoyoteRed <at> bigfoot <dot> com
http://go.to/CoyoteRed
PGP key ID: 0xA60C12D1 at ldap://certserver.pgp.com
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Can the SETI@home client be protected?
Date: Tue, 09 Nov 1999 20:48:39 GMT
[EMAIL PROTECTED] (Guy Macon) wrote, in part:
>Once you find a case where the modified client gives a different
>answer, you have your test for that patch. The problem is that it
>breaks the scientific method even if the modified client gives correct
>answers. The scientists need to know that code X produced result Y.
>Hacked code lowers the confidence of any result even if it gives
>correct answers.
This I can understand. It is possible to improve how your software is
protected against unauthorized modification, although it is not
possible to make it as hard to do that as it is to break encryption.
It might also help, from a human engineering point of view, if there
were an avenue through which suggested optimizations to the SETI@home
client could be offered, and had a chance of acceptance. This wouldn't
get everyone to act responsibly, but it would probably reduce the
number of people motivated to act on their own like this.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Can the SETI@home client be protected?
Date: Tue, 09 Nov 1999 20:49:59 GMT
[EMAIL PROTECTED] (Guy Macon) wrote, in part:
>In article <[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (Francois Grieu) wrote:
>>1) Encourage, rather than fight, the efforts in the direction of speeding
>>up the algorithm : the authors would be foolish to hope having the best
>>possible implementation ! Emulation worked well in DES cracking efforts.
>>Properly document the algorithm, openly supply test cases and a reference
>>implementation in source form, maybe even set up a plugin/DLL interface.
>>Define a public method to tag results with the id/version of the
>>algorithm/plugin that produced them, and report the rate achieved by each.
>That is already impemented. The major hackers refuse to comply.
Ah. I had suggested that too - not in as much detail.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Can the SETI@home client be protected?
Date: Tue, 09 Nov 1999 21:08:42 GMT
[EMAIL PROTECTED] (Guy Macon) wrote, in part:
>The scientists are working on a new version of both the client
>software that you can download and the server software at Berkeley.
>In the newsgroup some folks (not the SETI scientists) have opined
>that it is impossible to protect the client software from such
>patches, and that any such protection can be broken without breaking
>the actual encryption. Is this true?
Yes, it is true that software can in general be tampered with, even if
parts are encrypted, without breaking the encryption. This is because
for a program to work, it needs to "know" everything it needs to run.
There are techniques that are very effective, though; one I think is
fairly good would be to use a P-code interpreter for part of the
code...and have it run an interpreter for another P-code, written in
the first P-code. Even there, a hacker disassembles the first P-code
interpreter, writes tools to deal with that P-code once he understands
it...
Since that technique is slow, it would just be used to protect some
small piece of the software that checks if the other part is modified,
and reports on this in encrypted fashion to the server.
Since a server is used, though, the client could be distributed in
partially encrypted form, and the server could supply the client, when
it is running, with the key needed to read itself. This forces the
hacker to intercept the program in memory, instead of just working
from the copy on disk, for which breaking the encryption really would
be needed.
>There is no need to actually prevent patched clients from running -
>if the server can detect that the client is patched, it can stop
>sending work to be processed, thus shutting the client down.
If you can force the client to admit it is patched, you can prevent it
from running or make it do anything, so that doesn't seem to help any.
However, if a patched client were unable to prove it wasn't patched,
that would help. (I think, though, the approach based on committing to
intermediate results will be too slow to be helpful to you in
practice, although I'm no expert on exotic things like "zero-knowledge
protocols". A simple hash of intermediate calculation results at
various points through the algorithm would only be useful for a spot
check, since to determine its value, one would have to repeat the
computation. But if there's a way to do it that forces the original
algorithm to be used, and allows a "spot check" _within_ a single
reported result, this might be your solution.)
One possibility is to interrogate the client at random about itself,
thus forcing any patched version to contain a complete copy of the
unpatched version. Would that minor annoyance be enough to deter the
hackers of interest?
>Is this an intractable problem?
At present, yes. But there are new support chips for the Pentium III,
and some newer Celerons, aimed at protecting software such as DVD
players, that perhaps could make a client for _that_ platform
relatively safe. Contact Intel for details; some documentation is
available on their web site, but you may need to sign an NDA for what
is needed to make use of the item.
Tamper-proof hardware which would internally decrypt your program
would essentially solve your problem. Intel's support chip doesn't
quite cause the program to be decrypted inside the microprocessor
chip, but it is supposed to do something almost as good.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Can the SETI@home client be protected?
Date: Tue, 09 Nov 1999 21:17:02 GMT
[EMAIL PROTECTED] (Guy Macon) wrote, in part:
>Sppedups of the client are good for bragging
>rights only: the telescope can't shovel data into the pool of PCs
>any faster no matter how fast the client software gets.
Oh, yes: that reminds me: for a while, there was a problem in that
everybody was getting the same data blocks over and over. I know my
computer (at work; I eventually had to remove the client to keep my
computer stable) did two blocks, and sent them, but wasn't credited
for either, so I assume they were both duplicates (my computer was a
slow 100 MHz Pentium, and for the second block, the computer wasn't
left running for a number of evenings due to a risk of electrical
storms).
If at the present time, you have more than twice as many people
running SETI@home out there as are actually needed, simply checking
the second copy of a processed block recieved against the first -
after taking care that the data is distributed out in an even way -
could help to increase the level of confidence that nothing fishy is
going on, and detect any clients that are producing invalid results.
(If you don't save returned uninteresting data sets, just noting their
date and time and frequency, you can always just save a checksum as
well.)
Since the blocks are going out from tape, and in to tape - your
budget, doubless, prevents you from having the disk capacity of
AltaVista - there may be obstacles in the way of such an approach.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Justin <[EMAIL PROTECTED]>
Subject: Re: Can the SETI@home client be protected?
Date: Tue, 9 Nov 1999 16:31:48 -0500
On Tue, 9 Nov 1999, John Savard wrote:
> [EMAIL PROTECTED] (Guy Macon) wrote, in part:
>
> >Sppedups of the client are good for bragging
> >rights only: the telescope can't shovel data into the pool of PCs
> >any faster no matter how fast the client software gets.
>
> Oh, yes: that reminds me: for a while, there was a problem in that
> everybody was getting the same data blocks over and over. I know my
> computer (at work; I eventually had to remove the client to keep my
> computer stable) did two blocks, and sent them, but wasn't credited
> for either, so I assume they were both duplicates (my computer was a
> slow 100 MHz Pentium, and for the second block, the computer wasn't
> left running for a number of evenings due to a risk of electrical
> storms).
>
> If at the present time, you have more than twice as many people
> running SETI@home out there as are actually needed, simply checking
> the second copy of a processed block recieved against the first -
> after taking care that the data is distributed out in an even way -
> could help to increase the level of confidence that nothing fishy is
> going on, and detect any clients that are producing invalid results.
> (If you don't save returned uninteresting data sets, just noting their
> date and time and frequency, you can always just save a checksum as
> well.)
Why not just have the server randomly spot-check some blocks. Then it
becomes a probability game, and people who would eventually have
rediculously high stats have a high probability of getting eliminated
before achieving that goal. I would think the bottleneck is the network
interface, so there should be enough time to do at least minimal checking
(like check one block once in every 100 submissions).
Justin
------------------------------
From: Justin <[EMAIL PROTECTED]>
Subject: Re: Lenstra on key sizes
Date: Tue, 9 Nov 1999 16:45:25 -0500
On Tue, 9 Nov 1999, Mok-Kong Shen wrote:
> DJohn37050 wrote:
> >
> > AES design criteria is to be suitable for a long time. It is conservative as
> > we do not know what is possible a few years hence.
What's the point of the AES process? Say one gets picked. Five years
from now a discovery is made that makes attacks on any key size practical
for any moderately funded organization. Now you have a large number of
companies and governments with lots of encrypted data, all of which can be
simply decrypted because everyone is using the vulnerable algorithm.
Why not have a pool of algorithms and revise it every year? There could
be rankings based on running time, memory usage, etc., and it could be a
contest. There could be a special pool from algorithms that have survived
analysis for a certain amount of time. If someone wants to implement
encryption in network cards, let them go to ieee, get a standard approved
for whatever algorithm they want to use, just like 802.11 is using rc4.
If a flaw is ever discovered in one algorithm, only a portion of the
people using algorithms from the pool will have to redesign hardware or
reencrypt all critical data.
Justin
------------------------------
From: bob98g <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.cia,alt.math,soc.culture.russian
Subject: Re: The story of a small boy --- sealed envelops --- encryption technologies
Date: Tue, 09 Nov 1999 04:54:42 -0500
'ole Markkue wrote:
>QUESTION 1. In your opinion, what are the 5-10 most
>significant applications of encryption technologies currently
>in commercial enterprises?
>
>1. Secure E-Mail / Secure E-mail SMTP/POP3 mail client
Why not share your real email address and other personal
data with us? I have some really "neat CIA spy shit" I would
like to send you.
bob98g
------------------------------
Crossposted-To: comp.compression
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Build your own one-on-one compressor
Reply-To: [EMAIL PROTECTED]
Date: Tue, 9 Nov 1999 22:06:29 GMT
In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:> : The second rule apprears to be sufficient.
:>
:> To quote from: http://www.alife.co.uk/securecompress/
:>
:> ``This condition is necessary to prevent pathological cases: If "and" and
:> "wander" are both words - and if "and" <=> "#" and "wander" <=> "&", then
:> there is no chance that the string "w#er" will compress to "wander" - and
:> then decompress to "&".''
: But all these steps are reversible, so from & you can get back
: your w#er, don't you?
The file is parsed from top to bottom. "wander" will be identified and transformed to
"&" before the "and" in "wander" can be spotted. This causes problems.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Something wonderful has happened.
------------------------------
Date: Tue, 09 Nov 1999 15:45:06 -0700
From: MDR <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Is there a secure-messaging service?
I would like to know if there is a web-site out there like the
following. (If there isn't, remember who gave you the idea when you go
public.)
This would be a secure messaging service that would allow me to register
as a person that you could send mail to. You could securely send
messages to me whether you were registered or not, although you would
need to be registered for me to send a reply back to you.
The messaging service would present a SSL-protected web-page to you,
allow you to enter your message. It would then encrypt the message
using the PGP public-key that I had previously provided when I
registered. The encrypted message would be stored on their server until
I came to pick it up. Or, it could be e-mailed to me in its encrypted
form. Or both.
The messaging service would store a randomly-generated cookie on your
system the first time you used the service, in order to further identify
the person who was sending the message to you in case, in future
transactions, you needed more assurances that they are likely to have
been the true sender. This would just be a convenience feature.
The messaging service would not store the message in unencrypted form.
(Let's take for granted that they really would not.)
I could log on, retrieve the encrypted message using SSL (for added
protection), and presumably I would know how to decrypt it from there.
This would provide any subscriber with the ability to have secure
messaging, for example from clients who wished to send messages to them
on matters secret without owning a cryptography product themselves.
------------------------------
Crossposted-To: comp.compression
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Build your own one-on-one compressor
Reply-To: [EMAIL PROTECTED]
Date: Tue, 9 Nov 1999 22:37:17 GMT
In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: [I]n a most recent follow-up I questioned whether your first rule could
: be redundant.
I don't think so.
: I have further thought about the whole thing. I
: currently believe that even your second rule could be weakened a bit.
I *believe* I once claimed the two rules I presented were both "necessary"
and "sufficient".
I have not yet seen anything to change this view.
: Using your <--> convention, i.e. when doing processing anything
: on the left CAN be replaced by what is on the left and vice versa
: and that one may left things unchanged (cf. one of your previous
: examples), the only rule that is needed seems to be the same as that
: for Huffman encoding, i.e. the prefix-freeness. That is, no string
: (the whole entity on any side of <-->) may be the prefix of any
: other string in the dictionary.
I've presented a counter-example to this, which appears to mean that
the "no-substrings" condition is also required.
: So the superiority of schemes in the direction of your proposal
: remains to be demonstrated.
I've not claimed my scheme compresses (say) text very well.
It can usefully be used as a pre-processor to David's compressor,
where it will produce better compression.
: In particular, how your dictionary is
: to be built from scratch (i.e. general guidelines for constructing
: an 'optimal' one) appears to be unclear, at least for me.
Building an /optimal/ dictionary for a set of target files may well be tricky.
Building dictionaries is not itself very difficult, though.
: In a previous thread I pointed out that, if one sacrifies one Huffman code symbol,
: namely the one consisting of all 0's, to take care of the file ending
: problem
Won't this mean a symbol is missing from the rest of the stream?
Couldn't an analyst exploit this fact?
: then the normal Huffman algorithm (together with the
: rule that on compression O's at file end may be
: truncated and on decompreesion 0's may be appended)
: can also function under the requirement of 'one-to-one'.
This sounds pretty unlikely.
A file with 0000 on the end will behave the same as one ending with 000000.
This is not good news for the o-o-o property.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Destroy Microsoft.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: alt.politics.org.cia,alt.math,soc.culture.russian
Subject: Re: The story of a small boy --- sealed envelops --- encryption technologies
Date: Tue, 09 Nov 1999 23:44:51 GMT
In article <[EMAIL PROTECTED]>, Best Wishes
<[EMAIL PROTECTED]> wrote:
>Markku J. Saarelainen wrote:
>
>> "Encryption and many cryptography technologies are very important for
>> any future electronic commerce applications and implementations.
>
>For those interested, here is a list of free cryptography software, some
>in English, some in Russian
>
>http://www.listsoft.com/eng/95/crypt.htm
>
>Best Wishes
>
Well it does not have good free crypto.
Try mine at my site.
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***
------------------------------
Crossposted-To: comp.compression
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Build your own one-on-one compressor
Reply-To: [EMAIL PROTECTED]
Date: Tue, 9 Nov 1999 22:58:00 GMT
In sci.crypt Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
: If your English dictionary gives a number, of 16 bits, for each entry,
: then you can simply translate your sentences into a sequence
: of numbers which together form a binary string. These numbers
: occupy fixed number of bytes, so no prefix property needs to hold.
Yes.
: The main trouble with a scheme like that is to have the general
: public accept a standard (or defecto standard) of numerical coding.
: On the other hand, the Unicode gives coding of Chinese 'words' in
: two bytes. So there is already a precedence case.
I suspect the *main* problem is finding a dictionary that actually
compresses text at all.
I assert than English text simply doesn't have anything like 65536 symbol
strings which are longer than two bytes, and which occur with approximately
equal frequency ;-(
You'll still need individual letters to be represented by two-byte symbols,
for example. If these need to be used very often, compression ratios
will suffer.
: I like to take this opportunity to remark that I have the impression
: that the discussions in this thread have been highly biased toward
: the 'one-to-one' property, while the compression aspect seem to be
: comparatively very less stressed.
The advantages of good compression are already well understood.
I'm /partly/ concentrating on the new property *because* it's new,
and appears to be ill-understood.
: Perhaps it may be pointed out
: that if a compression scheme is such that the 'one-to-one' property
: (as understood in this thread) only fails very rarely, then the
: analyst couldn't get much information from that direction and we
: could in my humble opinion fairly well let such a scheme be used
: in crypto applications.
I agree that little information is better than giving away lots.
This is certainly true. However you may want to quantify to what
extent information is leaking when the compressor is used on your target
files, before using it.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Destroy Microsoft.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: alt.politics.org.cia,alt.math,soc.culture.russian
Subject: Re: The story of a small boy --- sealed envelops --- encryption technologies
Date: Tue, 09 Nov 1999 23:13:20 GMT
Anyone wanting to visit this little boy MARKKU can try the following:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
1-770-998-7855
1-770-232-1425
(one was FAX, can't remember just which one right now)
Post Office Box 1672
Roswell, GA 30077
or :
2441 Inverloch Circle
Duluth, GA 30096
................ or better yet, drop in on one his neighbors, like
maybe IN JUNG (@ 2442 INVERLOCH CIRCLE). IN lives across the street
from MARKKU (@ 2441 INVERLOCH CIRCLE). Then there is also ED RICKETT,
maybe TJ CLARK or even TRUDY FOURMY????????
"The information man, it's all about the information!!!!!!!!!!!"
Have fun.
"fried of the Great White Father"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression: A ? for David Scott
Reply-To: [EMAIL PROTECTED]
Date: Tue, 9 Nov 1999 23:19:02 GMT
Tom <[EMAIL PROTECTED]> wrote:
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression: A ? for David Scott
Newsgroups: sci.crypt
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <7vc81f$128$[EMAIL PROTECTED]>
<7vcg8v$n94$[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<7veo86$24g8$[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <7vqnq6$sjk$[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Organization:
Reply-To: [EMAIL PROTECTED]
Tom <[EMAIL PROTECTED]> wrote:
: (SCOTT19U.ZIP_GUY) wrote:
:>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
:>>What I'm begnning to wonder is if the information that's said to be
:>>added information in non o-o-o can really be considered to be a
:>>byproduct of the standard compression algorithm not fully compressing,
:>>similar to that of low ratio o-o-o leaving patterning behind. DS has
:>>claimed that the two types of information present different types of
:>>weaknesses, but this leads me to question if it's true if the type of
:>>plaintext file (and thus it's patterning) is known.
:>
:> I think your actaully Tommy St Dennis since you don't seem to understand
:>what is goin on. And seem not to actaully read the posts.
:
: It's not a question of understanding, it's a question of believing any
: of it.
Hopefully, reason - rather than faith - will prove sufficient.
:> Again if you don't use o-o-o compression you open your self up
:>to cipher only attacks. Do you understand this point before we go
:>into other areas to explore.
:
: The only cipher only attack that has been presented is a reduction in
: the set of possible output files from standard compression, which is a
: factor of the compression being non-perfect, not of it being non
: o-o-o, and of irreversibility, and this also isn't a function of it's
: being non o-o-o.
"irreversible" and "non-o-o-o" are pretty much synonyms...?
: Both give less information than a full known
: plaintext attack, which would be possible with the headers of many
: file formats.
The o-o-o property is indeed irrelevant if you tack on a known-plaintext header.
I'd hope the case under discussion is where such a obvious problem has been avoided.
: They may also give less information than the patterning
: still present from less than optimal compression, o-o-o or not.
Maybe less, maybe more - but quite possibly adding the same type of information
to differing plaintexts, and even to differing *types* of plaintext ;-(
: Again, this o-o-o concept is not generally accepted, nor has it been
: proven to be true.
What exactly is your problem with it? It demonstrably prevents scertain types
of security leak.
: If you were to claim that a compressor where y=Decompress(x), where x
: can be any file, I'd agree it could be of some advantage. That's true
: for o-o-o, but o-o-o isn't required.
The property you mention is inadequate (or at least sub-optimal) from a
security POV.
o-o-o compression offers better protection than this.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Destroy Microsoft.
------------------------------
** 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
******************************
