Cryptography-Digest Digest #96, Volume #11 Fri, 11 Feb 00 13:13:01 EST
Contents:
Re: Message to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Eurocrypt 2000 (Eurocrypt 2000)
Re: Period of cycles in OFB mode ("Scott Fluhrer")
Re: Twofish vs. Blowfish ("Scott Fluhrer")
Re: New standart for encryption software. (Albert P. Belle Isle)
Re: Period of cycles in OFB mode (Tim Tyler)
Re: Newbie Encrypt question (JPeschel)
Re: Which compression is best? (John Chandler)
Re: Which compression is best? (John Chandler)
Re: Which compression is best? (Jerry Coffin)
Re: Message to SCOTT19U.ZIP_GUY (Tim Tyler)
Re: Compression cannot prevent plaintext recognition (was Re: is signing a
signature with RSA risky?) (Tim Tyler)
Re: Message to SCOTT19U.ZIP_GUY (DTRuth)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Fri, 11 Feb 2000 17:18:14 GMT
In article <87uuf3$kvf$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>HERE IS YOUR MESSAGE IN FULL POSTED A WHILE BACK....Perhaps you and Tim
>or anyone else would care to Comment on IT:::::::::
>
>**********************************************************************
>
>I know most of you will never have access to good ciphers. The NSA and
>crypto gods will see to that. But it does not
> mean that
> you can't use some of the weak AES methods and still obtain a
> far higher degree of security than what they want. Below is a
> procedure that is "not all or nothing" but would allow one to encrypt
>by removing the so called error recovery "feature"
> that most people are stuck using.
> Here it is in a nutshell You need 3 ciphers and 2 one to one
> compressions to achieve the results. IF you have access to the
> routines them selves it can be done in one pass since each method works
>on the data previously processed but I will
> explain it as 5 passes.
I am sure I wrote this from the point of view that one is using 3
seperate encryptions in series. And what could one do if one was going
to use 3 seperate encryptions of AES and one still want a way to prevent
the NSA of breaking it in an easy way. I should have added a pass zero
of compression since I usually compress first no matter what. But you
don't have to and what follows is just an easy substitution of a method
if one was going to use 3 seperate passes of AES
>
> Pass one Encrypt with AES using weak 3 letter chaining even ECB
> Pass two use Compression A "explained latter"
> Pass three Encrypt with different key (with different method if one
>wishes} Pass four use Compression B
> Pass five Encrypt with different key
>
> For the truely insecure among you. You can make this "all or nothing"
>by reversing the byte order in the file after each
> compression. But that requires whole file at one time..
yes I like to reverse the file it is a good idea if one can.
Better yet use my compression with just one pass of scott16u or
scott19u. Or failing to do that at least use one of mine with two
other AES methods.
>
> Know for a disccusion of how to implement the Compression.
> by Compression A I mean one of my one to one compressions that
> uses a "condition file" with all 256 possible characters. This makes a
>starting tree that can be greatly varied. But since
> compression is one to one no information is added to data stream. Also
>the message will as it passes through the
> compression will change in length so that it is highly unlikely that
>one can know where a block from the previous
> encryption layer is passed to next encryption layer and it is highly
>unlikely to even be the same length. For Compression B
> you use a different "condition file" with all the 256 possible
>characters in the file.
>
> The input file should be at least long enogh for a few blocks to be
>encrypted or you can reject the file as to short. Notice
> also that each compression will most likely make the file longer and
>that
> the encryption methods should handle short blocks at the end of files.
>Most methods already have a way to do this but if
> at least one block is encrypted on each pass you can just pass the
>short block without doing anything to it. Since the
> state of the adapative huffman compressor will be such that the data in
>last block will be transformed by the
> compression.
>
> Any thoughts on this by my nonadmirers.
>
>
>
> David A. Scott
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
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***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: Eurocrypt 2000 <[EMAIL PROTECTED]>
Subject: Eurocrypt 2000
Date: Fri, 11 Feb 2000 17:33:07 +0100
==============================================================
E U R O C R Y P T 2 0 0 0
Bruges (Brugge), Belgium, May 14-18, 2000
http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/
==============================================================
Anyone interested in the latest developments in cryptology
and its applications to information security is encouraged
to attend Eurocrypt 2000.
This conference is organized by the International Association
for Cryptologic Research (IACR, http://www.iacr.org/) in
cooperation with the Katholieke Universiteit Leuven
(K.U.Leuven, Belgium, http://www.esat.kuleuven.ac.be/cosic/).
A provisional program (list of accepted papers), and all
registration details and accommodation information can now
be found on the conference web site:
http://www.esat.kuleuven.ac.be/cosic/eurocrypt2000/
==============================================================
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Period of cycles in OFB mode
Date: Fri, 11 Feb 2000 08:34:46 -0800
Mok-Kong Shen <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Scott Fluhrer wrote:
> >
>
> > Well, one obvious approach would be to add in a step counter after every
> > encryption step. That is, (if X(n) is the internal state at step n),
turn:
> >
> > X(n+1) = Encrypt( X(n) )
> >
> > into
> >
> > X(n+1) = Encrypt( X(n) ) + n
> >
> > where the above + is either xor, or addition modulo the block size.
> > Then, cycles are impossible (if X(n) = X(m) for some n!=m, then
> > X(n+1) != X(m+1) )
>
> Every sequence computed in the space of the finite block size
> cannot have a period length of infinite. So I wonder how could
> 'cycles are impossible' be possible?
Well, the OP was asking about short cycles, and I just ellipsed out
the word short. If you are encrypting more than 2**64 blocks (with
a 64 bit block size), then the attacker will be able to form a code
book anyways, and so a cycle is irrelevant.
--
poncho
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Twofish vs. Blowfish
Date: Fri, 11 Feb 2000 08:38:48 -0800
John Myre <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Eric Lee Green wrote:
> >
> > My personal thoughts: Go with one of the AES candidates, such as
> > TwoFish, unless you are releasing the product tomorrow. Use a standard
> > crypto API so that you can 'plug in' any of the AES candidates as
> > desired without re-coding your application.
>
> If you go to the trouble (which isn't much) of allowing the algorithm
> to be changed (either quick-and-dirty by replacing source files, or
> something fancy that allows new choices to be added after delivery),
> I'd start with RC6 (another of the AES candidates), because it is by
> far the easiest to code, which means it is the easiest to get right.
>
> Later in the development process, when you have an alpha or beta or
> something that sort of works, you can replace RC6 (if necessary)
> based on more recent information (like an AES decision).
Umm, I don't know if that is legal. I believe that RC6 is patented, and
so use of it (without RSA's permission) is illegal. If it does become the
actual AES algorithm, then the patent issues go away, but that hasn't
happened yet, and may never.
--
poncho
------------------------------
From: Albert P. Belle Isle <[EMAIL PROTECTED]>
Subject: Re: New standart for encryption software.
Date: Fri, 11 Feb 2000 11:54:43 -0500
Reply-To: [EMAIL PROTECTED]
On 11 Feb 2000 01:27:21 GMT, [EMAIL PROTECTED] (Peter Gutmann)
wrote:
>
>
>Albert P. Belle Isle <[EMAIL PROTECTED]> writes:
>
>>Document Security Manager has (for years) made its built-in FIPS 81,
>>SP500-20, FIPS 180-1 and FIPS 140-1 self-tests available to the user
>>interface.
>
>[...]
>
>>The ANSI X9.17c keystream generator can produce its next megabyte of
>>pseudorandom bytes to disk, on command. The fact that it is used to
>>generate the last overwrite-and-verify pass from the NAVSO P5239-26
>>overwriting routines means that any command to Sanitize a file per
>>DOD5220.22-M produces a keystream generator test output to disk of
>>that size.
>
>Isn't that kind of risky? Because of the design of the X9.17 generator
>(which I'm not a great fan of for this reason), it means you end up revealing
>vast amounts of internal state to an attacker. Admittedly an attacker will be
>up against triple DES to get the generator key, but providing hundreds of
>thousands of plaintext/ciphertext pairs seems risky (you can for example scan
>memory for blocks of high entropy which produce the given ciphertext from the
>given plaintext via 3DES). I'd at least pass the results through SHA-1 on the
>way out.
>
>Peter.
Mr. Gutmann:
This was, indeed a subject of some consideration, but we decided that
providing access to the output byte stream for anti-spiking assurance
purposes offered far more benefit to our users peace-of-mind than
could be offset by the probability of an attacker being able to
"backtrack" through the output TDEA encipherment to get back to the
state.
(Our implementation is such that both generator re-seeding and
re-keying occurs quite frequently from user-generated entropy.)
Obviously, if a TDEA-crack were to be discovered, the entire product
would be at risk and we'd have to replace _all_ instances of it in our
implementation.
We were hoping to take our time in moving to whatever candidate
larger-block cipher is chosen for AES. After all, its long history is
the main attraction that the DEA core cipher offers, and we'd not want
to be premature in the pursuit of "cipher fashionability."
Do you have reason to believe that TDEA (168-bit-keyed, outer-CBC-mode
triple DES) is presently at risk?
Albert P. BELLE ISLE
Cerberus Systems, Inc.
================================================
ENCRYPTION SOFTWARE with
Forensic Software Countermeasures
http://www.CerberusSystems.com
================================================
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Period of cycles in OFB mode
Reply-To: [EMAIL PROTECTED]
Date: Fri, 11 Feb 2000 16:48:39 GMT
Scott Fluhrer <[EMAIL PROTECTED]> wrote:
: Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
[possible short cycles in OFB mode]
:> I am interested to learn about what efforts (if any) have been made
:> to avoid these problems in block cyphers in OFB mode.
:
: Well, one obvious approach would be to add in a step counter after every
: encryption step. That is, (if X(n) is the internal state at step n), turn:
: X(n+1) = Encrypt( X(n) )
: into
: X(n+1) = Encrypt( X(n) ) + n
: where the above + is either xor, or addition modulo the block size.
: Then, cycles are impossible (if X(n) = X(m) for some n!=m, then
: X(n+1) != X(m+1) )
Yes.
This either required unboundedly large quantities of memory - or
still allows cycles of the order of the maximum size of the counter.
I can't easily think of a more effective method of resolving the
problem than this one, though.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
We are not punished for our sins, but by them.
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Newbie Encrypt question
Date: 11 Feb 2000 17:05:48 GMT
[EMAIL PROTECTED] writes:
>I want to write my own
>simple encrypt program (C/C++). From what I understand one way to
>encrypt is to shift the underlying binary data and then Xor it with a
>password. Question I have is where the heck to you store the
>password???
>
>Example, say I encrypt a paragraph and the password I use is "mypass".
>This would be used for the xor part. Now when I send it to my friend
>and he brings up the program to de-crypt it he has to use "mypass". But
>in order for my program to verify the password is correct it would have
>to be stored in the file. That doesn't seem very safe. Any ideas?
>
Your scheme, "XOR encryption," with or without a stored password
is unsafe.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (John Chandler)
Subject: Re: Which compression is best?
Date: 11 Feb 2000 16:18:31 GMT
In article <880pkb$btt$[EMAIL PROTECTED]>,
Thomas Pornin <[EMAIL PROTECTED]> wrote:
>According to <[EMAIL PROTECTED]>:
>> 1) From a security perspective, how important is compression?
>
>Rather unimportant. If your cipher is weak when used without
>compression, you should not use it anyway. And if your cipher is not
>weak, there is no security implication in the choice of one algorithm
>over another (otherwise this would be considered as a weakness of the
>algorithm).
>
>But it is always good to compress data before encryption, for the sake
>of bandwidth. After encryption, the data looks mainly random (if the
>cipher is correct) and no compression algorithm will do anything good
>with it. So, if the data is to be compressed at all, this must be done
>before encryption.
>
> --Thomas Pornin
How about the following possibilities:
1) Use adaptive Huffman compression instead of any static scheme.
With adaptive compression, the Huffman frequency table changes as
compression proceeds, and at any given point the table depends on the
initial table _and_ on the preceding characters in the message.
This seems like a good idea, cryptographically speaking,
a little reminiscent of chaining a block code.
It should be kept in mind that static Huffman decompression
almost always resynchronizes itself automatically after
a bit has been dropped or flipped by noise,
but adaptive Huffman does not.
2) The initial frequency table for adaptive Huffman compression
could be very simple (containing many 1's, for example)
and the non-simple part of the table could be part of the key.
While not cryptographically strong, this could be quite
inconvenient for a cryptanalysis.
3) Recommendations have been made to prepend a segment of random or
pseudorandom garbage to any message before encryption,
to make it harder to find the header. (Another recommendation
was to break the message in two and swap the halves,
putting the header in the middle of the message.)
Would this be a particularly good thing to do before
carrying out an adaptive compression? Possibly.
--
John Chandler
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John Chandler)
Subject: Re: Which compression is best?
Date: 11 Feb 2000 16:27:46 GMT
In article <881con$[EMAIL PROTECTED]>,
John Chandler <[EMAIL PROTECTED]> wrote:
>
>How about the following possibilities:
>
>1) Use adaptive Huffman compression instead of any static scheme.
> With adaptive compression, the Huffman frequency table changes as
> compression proceeds, and at any given point the table depends on the
> initial table _and_ on the preceding characters in the message.
> This seems like a good idea, cryptographically speaking,
> a little reminiscent of chaining a block code.
>
> It should be kept in mind that static Huffman decompression
> almost always resynchronizes itself automatically after
> a bit has been dropped or flipped by noise,
> but adaptive Huffman does not.
>
>2) The initial frequency table for adaptive Huffman compression
> could be very simple (containing many 1's, for example)
> and the non-simple part of the table could be part of the key.
> While not cryptographically strong, this could be quite
> inconvenient for a cryptanalysis.
>
>3) Recommendations have been made to prepend a segment of random or
> pseudorandom garbage to any message before encryption,
> to make it harder to find the header. (Another recommendation
> was to break the message in two and swap the halves,
> putting the header in the middle of the message.)
> Would this be a particularly good thing to do before
> carrying out an adaptive compression? Possibly.
I just noticed a post crediting "DS" with suggesting using
adaptive compression in _both_ directions before encrypting.
Great idea!
I hadn't thought of that.
--
John Chandler
[EMAIL PROTECTED]
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Which compression is best?
Date: Fri, 11 Feb 2000 10:26:02 -0700
In article <880n6m$u2u$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
> As I've read here, it's good to compress before you encrypt the data. Now
> I've got 2 questions about this:
>
> 1) From a security perspective, how important is compression? Is prior
> compression just a kind of "weak enhancement" or is considered it an
> integral part of the encryption process as a whole?
A few people consider it extremely important, but most of us realize
otherwise. It's of no use at all against a known-plaintext attack.
If it's designed with encryption in mind, it can be of minimal help in
slowing a ciphertext-only attack. The most fundamental problem is
that it doesn't really make enough difference to care about: just for
example, David Scott makes much of the compression method he uses, and
the fact that if you decompress the wrong text, it produces output
that's statistically similar to normal plaintext. Doing some quick
testing shows that this is more or less true if you look only at
frequencies of single characters, but not really true at all when you
look at frequencies of digraphs, trigraphs, etc. IOW, it produces
letters at about the right frequencies, but they're not in the right
orders -- it looks vaguely like text that's been run through a
transposition cipher.
Mr. Scott also uses a method of compressing once from beginning to
end, and then again in the opposite direction (using dynamic
compression in both cases). This basically means you have to
decompress the entire message before you can collect statistics on it,
rather than decompressing a block or two at a time like you can with
most others. This is a theoretical help, but of an extremely limited
degree: it slows an attack down by a factor roughly proportional to
the length of the message. If you send small messages, it makes
almost no difference at all; with larger messages the effect grows.
IMO, to be considered secure, an algorithm needs to be at least
sufficiently secure regardless of how small a message may be. If you
make the algorithm sufficient with small messages, then it's still
sufficient with large messages.
IOW, for an algorithm to really be worth anything, it's got to ignore
any help this provides in any case.
> 2) Are there special compression algorithms that are specifically well-
> suited in combination with block cyphers? Is any of the standard
> algorithms as good as the other? (I don't mean in compressing of course,
> but in security matters dependant on my first question)
Yes -- most LZ-based forms of compression (for one example) are of
little use in the areas mentioned above. You're looking for something
like arithmetic compression or Huffman compression to get any good out
of it at all.
One place compression really DOES help is in simply reducing the
amount of encrypted text you send. Many attacks depend upon
collecting LARGE amounts of encrypted text for which the plaintext is
known. Almost any form of compression obviously slows this sort of
attack by simply reducing the rate at which an attacker can collect
data. I feel obliged to point out, however, that this is in somewhat
the same situation as the bits above: you can't really depend upon
getting anything out of it so you can't reasonably take it into
account in your designs, except in extremely limited ways. It might
be useful in one way, however. If, for whatever reason, you're forced
to do your encryption in ECB mode, pre-compressing can at least
prevent _obvious_ patterns from emerging if you happens to have blocks
in the input repeated.
For these purposes, special forms of compression make little
difference. Instead, you're simply looking for whatever produces the
smallest output.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Message to SCOTT19U.ZIP_GUY
Reply-To: [EMAIL PROTECTED]
Date: Fri, 11 Feb 2000 17:04:58 GMT
[EMAIL PROTECTED] wrote:
: HERE IS YOUR MESSAGE IN FULL POSTED A WHILE BACK...
The original material was helpful - to me anyway.
: Perhaps you and Tim or anyone else would care to Comment on IT [...]
I'd probably compress before encrypting initially.
Apart from that, it all sounds like reasonably sensible way of doing
multiple encryptions.
It's hard to evaluate the security benefit that the variable change in
file length the "compression" produces has on the analysis of fixed-length
AES-style blocks - but no doubt it helps.
You'd be hard-pressed to get this type of effect with any sort of padding
scheme.
I'm not sure DS's:
``the input file should be at least long enough for a few blocks to be
encrypted or you can reject the file as to short.''
...attitude would go down well with users ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
Jesus saves. Vishnu invests.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Compression cannot prevent plaintext recognition (was Re: is signing a
signature with RSA risky?)
Reply-To: [EMAIL PROTECTED]
Date: Fri, 11 Feb 2000 17:12:22 GMT
James Felling <[EMAIL PROTECTED]> wrote:
[snip]
: Just a couple of quibbles here.
: 1) If the compressor has some noticable traits when used on say english text(
: most leave some artifacts of the compressing process) we may still be able to
: setup a "candidate recogniser" that will look for those traits [...]
One simple solution to this is to avoid that type of compressor.
I was talking about compressors of a high quality in terms of compression
ratio, anyway. With such compressors, there's not much "room" for leaving
artefacts of the compression process in the resulting message.
: 2) The greatest benefit as far as attack resistance is the fact that there is
: less cyphertext generated. This reduces the material available to the
: analyst, and thereby may prevent or make difficult some attacks vs the
: encoding mechanism.
I'm not sure I'd describe this as the "greatest benefit" of compressing.
However it happens, and it helps.
I'm at a bit of a loss to see how your comments could be described as
"quibbles" when looking at my previous posts on this thread.
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
What happened to the good ol' days: when sex was dirty and the air was clean?
------------------------------
From: DTRuth <[EMAIL PROTECTED]>
Subject: Re: Message to SCOTT19U.ZIP_GUY
Date: Fri, 11 Feb 2000 06:25:49 +0100
So how would this work.
You compress with Compressor A
Encrypt with Block Cipher A ( Key kA)
Compress with B
Encrypt with Cipher B (Key kB)
Compress with C
Encrypt with Cipher C (kC)
Then to decrypt:
Decrypt with Cipher C (kC)
Decompress with Compressor C
Decrypt with Cipher B
Decompress with Compressor B
Decrypt with Cipher A
Decompress with Cipher A
Hopefully you are back where you started ??? Right???
And what about the Compressors A, B,C
Is it the same Compressor?
And why three Encryption's, why not two or five layers or chains???
"SCOTT19U.ZIP_GUY" wrote:
> In article <87uuf3$kvf$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> >HERE IS YOUR MESSAGE IN FULL POSTED A WHILE BACK....Perhaps you and Tim
> >or anyone else would care to Comment on IT:::::::::
> >
> >**********************************************************************
> >
> >I know most of you will never have access to good ciphers. The NSA and
> >crypto gods will see to that. But it does not
> > mean that
> > you can't use some of the weak AES methods and still obtain a
> > far higher degree of security than what they want. Below is a
> > procedure that is "not all or nothing" but would allow one to encrypt
> >by removing the so called error recovery "feature"
> > that most people are stuck using.
> > Here it is in a nutshell You need 3 ciphers and 2 one to one
> > compressions to achieve the results. IF you have access to the
> > routines them selves it can be done in one pass since each method works
> >on the data previously processed but I will
> > explain it as 5 passes.
> I am sure I wrote this from the point of view that one is using 3
> seperate encryptions in series. And what could one do if one was going
> to use 3 seperate encryptions of AES and one still want a way to prevent
> the NSA of breaking it in an easy way. I should have added a pass zero
> of compression since I usually compress first no matter what. But you
> don't have to and what follows is just an easy substitution of a method
> if one was going to use 3 seperate passes of AES
> >
> > Pass one Encrypt with AES using weak 3 letter chaining even ECB
> > Pass two use Compression A "explained latter"
> > Pass three Encrypt with different key (with different method if one
> >wishes} Pass four use Compression B
> > Pass five Encrypt with different key
> >
> > For the truely insecure among you. You can make this "all or nothing"
> >by reversing the byte order in the file after each
> > compression. But that requires whole file at one time..
> yes I like to reverse the file it is a good idea if one can.
> Better yet use my compression with just one pass of scott16u or
> scott19u. Or failing to do that at least use one of mine with two
> other AES methods.
> >
> > Know for a disccusion of how to implement the Compression.
> > by Compression A I mean one of my one to one compressions that
> > uses a "condition file" with all 256 possible characters. This makes a
> >starting tree that can be greatly varied. But since
> > compression is one to one no information is added to data stream. Also
> >the message will as it passes through the
> > compression will change in length so that it is highly unlikely that
> >one can know where a block from the previous
> > encryption layer is passed to next encryption layer and it is highly
> >unlikely to even be the same length. For Compression B
> > you use a different "condition file" with all the 256 possible
> >characters in the file.
> >
> > The input file should be at least long enogh for a few blocks to be
> >encrypted or you can reject the file as to short. Notice
> > also that each compression will most likely make the file longer and
> >that
> > the encryption methods should handle short blocks at the end of files.
> >Most methods already have a way to do this but if
> > at least one block is encrypted on each pass you can just pass the
> >short block without doing anything to it. Since the
> > state of the adapative huffman compressor will be such that the data in
> >last block will be transformed by the
> > compression.
> >
> > Any thoughts on this by my nonadmirers.
> >
> >
> >
> > David A. Scott
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Before you buy.
>
> 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***
>
> I leave you with this final thought from President Bill Clinton:
>
> "The road to tyranny, we must never forget, begins with the destruction of the
>truth."
------------------------------
** 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
******************************
