Cryptography-Digest Digest #970, Volume #12 Sat, 21 Oct 00 13:13:00 EDT
Contents:
Re: Storing an Integer on a stream (John Savard)
Re: deterministic RSA key generation (Francois Grieu)
Re: SHA-384 and SHA-512 (Kent Briggs)
Re: Dense feedback polynomials for LFSR ("Trevor L. Jackson, III")
Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
Re: How to post absolutely anything on the Internet anonymously (jungle)
Re: BIOS password, will it protect PC with PGPDisk against tampering ?
([EMAIL PROTECTED])
Re: Hypercube structure / balanced block mixing (Mok-Kong Shen)
Re: Looking for small implementation of an asymmetric encryption algorithm ("Daniel
Lieman")
Re: My comments on AES (Mok-Kong Shen)
Re: ---- As I study Rinjdael... ("Scott Fluhrer")
Re: Huffman stream cipher. (SCOTT19U.ZIP_GUY)
Re: newbie pathetic question (SCOTT19U.ZIP_GUY)
Re: For those touting "compression as encryption" ideas - Upcoming IEEE conference
of interest (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Storing an Integer on a stream
Date: Sat, 21 Oct 2000 13:50:39 GMT
On Fri, 06 Oct 2000 13:34:28 GMT, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote, in part:
>If I'm writing a file, whose format is a 64 bit file length, followed by
>some amount of data, followed by some [random] padding, which of the
>following is the best way to store that length value:
>1) 8 base-256 digits. With this format, we always use 8 bytes.
>2) Some number of base-255 digits, with leading 0 digits stripped,
>terminated by the value 255. With this format, we always use at least 1
>byte (for a value of 0, which is written as just the terminator (255)),
>but generally use 2..9 bytes.
>3) Some number of base-128 digits, with leading 0 digits stripped, all
>but the last prefixed by a 0 bit, and the last prefixed by a 1 bit.
>With this format, values 0..127 use 1 byte, 128..(128**2-1) uses 2
>bytes, etc, with 9 bytes being used for a 63 bit value, and 10 bytes
>used for a 64 bit value.
None of those formats are that great, although they certainly are
simple. The third format - using a word mark - is at least simpler
than converting from binary to base 255. And if I were old enough to
have programmed the IBM 1401, it would bring back memories.
One format that wouldn't be too bad, since your lengths are at maximum
2^64, would be this:
1) six bits giving the length of the length, in bits
followed by
2) the length, with the leading 1 bit stripped.
However, if your encryption method doesn't change the length of the
file being encrypted, there's a *really simple* way to deal with the
problem:
don't encrypt the length at all, since the length is visible anyways.
(The leading zeroes, obvious though they are, are *not* your only
source of known plaintext.)
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: deterministic RSA key generation
Date: Sat, 21 Oct 2000 16:47:51 +0200
Roger <[EMAIL PROTECTED]> wrote:
> Francois Grieu wrote:
> > One thing strikes me: it would often be usefull to use a
> > deterministic, standardised method to generate an RSA key from
> > a seed value, like a passphrase.
> >
> > Question: is there an established standard for something like
> > (p, q) = F(passphrase, bit-size_of_pq, public_e) ?
>
> I think the ANSI X9.30 does that. They had some sort of
> theory that the banks couldn't be trusted to generate
> their own primes. So they have Bob Silverman's algorithm
> for generating the primes from a given seed
You may be thinking of Bob Silverman's fast sieving technique [1]
to generate strong primes, which I think he proposed to ANSI X9.31
(despite his own viewpoint strong primes are not useful).
Though a step in this direction, it does not appear to be a fully
specified passphrase-to-key transformation, for lack of a specified
pseudo-random bit generator, of a procedure to generate integers
in a given range from random bits, and a few other missing details.
I have not read the (possibly revised) standard X9.31, has it
expanded this work to a fully deterministic RSA key generation ?
Francois Grieu
[1] Robert D. Silverman, Fast generation of random strong RSA primes.
available from <http://www.rsasecurity.com/rsalabs/technotes/>
caution: nonstandard postscript dialect; can be viewed or converted
to pdf with Ghostscript.
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: SHA-384 and SHA-512
Date: Sat, 21 Oct 2000 14:56:50 GMT
Daniel Leonard wrote:
> BTW, why is it "128 bit" and not "128 bits" ?
In that context, "bit" is an adjective, not a noun. The same reason you say "5
car pileup" instead of "5 cars pileup".
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
Date: Sat, 21 Oct 2000 10:58:18 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Dense feedback polynomials for LFSR
Joaquim Southby wrote:
> In article <[EMAIL PROTECTED]> Tim Tyler, [EMAIL PROTECTED] writes:
> >The original idea makes no sense, but execution time does not appear to be
> >a problem with it.
> >
> Simply because you fail to grasp an idea or possible applications for it
> doesn't mean it makes no sense.
>
> I didn't come up with this idea; it was passed on to me from a friend who
> uses me as a sounding board from time to time. She pointed out that
> sub-maximal LFSR's have most of the same behaviour as maximal LFSR's. If
> a maximal length LFSR has a tap sequence of n, A, B, C, then an LFSR with
> the tap sequence n, n-A, n-B, n-C will also be maximal length. Guess
> what -- it works for sub-maximal LFSR's, too. The state spaces of two
> sub-maximal LFSR's constructed in that way and using the same init vector
> are the same size. What's interesting is that many of the states in
> their state spaces are different. What's even more interesting is that
> every state in one of those spaces is the mirror image of a state in the
> other space.
>
> One group of behaviours that is dissimilar between the two is how
> "random" the output stream looks. The output over a period of a
> maximal-length LFSR will *always* have the same characteristics: a) # of
> 1's minus # of 0's = 1; b) the number of runs is strictly quantifiable --
> 1/2 of all runs have length 1, 1/4 have length 2, etc.; c) perform a
> circular shift of some number less than the period on the output string
> and then XOR the result with the original string -- the result of the XOR
> will exhibit the same characteristics described in a) and b).
>
> Conversely, the output over a period of a submaximal-length LFSR is not
> constrained to these characteristics. (The autocorrelation exhibited in
> part c is still very strong, though.) In that regard, this output looks
> more like a random stream of bits because it will statistically vary from
> the idealized output described above. (Before anyone jumps in with the
> old "what is random" thread, I did not say that the output is random -- I
> said it looks more like a random stream than that of the maximal-length
> LFSR.)
There's a logical gap here. In order to claim something "looks more random"
one must provide a criteria by which one detects the degree of randomness. My
criteria leads to the conclusion that fractional LFSR periods are far less
random looking than their maximal versions because the missing bit patterns are
glaring artifacts.
So, I'll show you mine if you show me yours (tersely). What "looks random" to
you?
> Can you see any possible uses for a sub-maximal LFSR now?
>
> If you think about LFSR's in terms of state spaces, you might realize
> that the two types we're discussing differ only in the number of state
> spaces. All LFSR's have at least two state spaces; one of these is the
> space that contains the single state of zero. The maximal-length LFSR
> has two state spaces: one is that zero state space and the other consists
> of all the states between 1 and 2^n - 1. The sub-maximal LFSR has more
> than 2 state spaces. Of the non-degenerative (by this I mean an LFSR
> that returns to its original state -- those that have an odd number of
> taps or that do not include the output bit in the tap sequence will not
> do so) sub-maximal LFSR's I've had time to investigate, every one has an
> even number of state spaces; at least one of those spaces' size was equal
> to a power of 2 minus 1.
The parenthetical remark is confusing. An even number of taps implies that
there are two degenerate states corresponding to all zeros and all ones. But
the rest of the states may form a maximal length cycle, which yields an odd
number of cycles.
Also, not including the output bit in the tap list means that you have a
smaller register than you thought. Assuming the contrary leads to a
contradiction. Take a small register, say 10 bits and add a pipeline of 90
unused bitcells to the output yielding a register of length 100. Clearly the
"exhaust pipe" has no effect on the state of the register. The effective
length is still 10 bits. The output bit is *defined* to be the last downstream
bit that is part of the feedback.
> These puppies are a lot more interesting than
> their maximal-length brethren simply because of the wider range of
> behaviour that, AFAIK, hasn't been explored yet.
Think about LFSRs with inverters in the feedback. You'll find that only the
parity of the inverter count matters. You'll also find that the degenerate
cases are those with alternating bits 0xAAA... and 0x555.... That change
eliminates the bias of more ones than zeros that afflicts a normal,
non-inverted LFSR.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encryption processing with intermediate permutations
Date: Sat, 21 Oct 2000 17:32:13 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
.........
[snip]
>
> In the special case of your reduced version in which there
> is only one permutation, the sibling pairs and thus the
> equations are obvious. You will discover how to find them
> if you put forth an effort.
I believe that you have till now misunderstood me. Let me
try to explain my point therfore once again. First I repeat
what I posted previously:
Input of first cycle (known to opponent, being chosen):
(u,u) (u,u) (u,u) (u,u)
Output of first cycle:
(v,w) (v,w) (v,w) (v,w)
(Assumed) permutation (unknown to opponent) of words,
resulting in input of second cycle:
(v,v) (v,w) (w,v) (w,w)
Output of second cycle (know to opponent):
(a,b) (c,d) (e,f) (g,h)
Let the cipher be such that with input block (L,R) one gets
with round-keys S1,S2 the output block (X,Y) as follows
(I use a more general functional form than what would be
the case with DES-type of construction):
X=F1(S1,S2,L,R)
Y=F2(S1,S2,L,R)
Now the communication partners, since they know the
permutation and hence the whole history depicted above,
can start from e.g. the first ciphertext block (a,b) (or
similarly any other ciphertext block above) and compute as
follows, assumining that the four round-keys are K1, K2,
K3 and K4:
Since (a,b) is the encryption of (v,v) in the second cycle,
we have, using the above relationship:
a=F1(K3,K4,v,v)
b=F2(K3,K4,v,v)
We have now to find v. Since (u,u) is encrypted to (v,w)
in the first cycle, we have
v=F1(K1,K2,u,u)
Thus we obtain finally the relationship
a=F1(K3,K4,F1(K1,K2,u,u))
b=F2(K3,K4,F1(K1,K2,u,u))
from which one could presumably use sort of techniques of
differential analysis gain certain information about the
round-keys and hence the key of the cipher.
Now the crucial point is that the opponent, since he
is ignorant of the permutation, doesn't know that (a,b)
above is the encryption of (v,v) in the second cycle. For
with a different permutation it could have equally been
(v,w) or (w,v) or (w,w) instead. In each of the four
possible cases (which he has no means to know to be
actually the one he has at hand) he will have to employ
a different set of equations relating a and b to u, in
order to gain information about the key of the cipher.
What should he exactly do? Could you please kindly tell?
Thanks in advance.
M. K. Shen
===============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,alt.freespeech
Subject: Re: How to post absolutely anything on the Internet anonymously
Date: Sat, 21 Oct 2000 11:20:16 -0400
Anthony Stephen Szopa wrote:
>
> jungle wrote:
> >
> > how this is better then old remailer method ?
> > they are asking to use proxy ...
> >
> > Anthony Stephen Szopa wrote:
> > >
> > > How to post absolutely anything on the Internet anonymously
> > >
> > > http://www.sciam.com/2000/1000issue/1000techbus2.html
>
> I am not terribly familiar with the remailer method. Sounds to me
> that the remailer method is emailing data anonymously.
posting to newsgroup / s anonymously ...
basically, m2n = mail to news ...
> Whereas this system actually posts the data to numerous internet
> servers where anyone can down load it
I see the difference, post v up-load ...
> while at the same time making
> it highly unlikely that anyone, including the government, could
> remove the information from all the servers.
same is in newsgroup, almost impossible to remove ...
> While also providing to make it impossible for the server owner to
> be held accountable since the server owner has no way of knowing
> what is on their server since this file is encrypted.
very excellent point ...
> Since the data is encrypted, no one knows what is contained in the
> files unless they have the key.
it's sound very promising ...
> The key is broken up into, say, 100 fragments, any of 20 will
> generate the entire key. Thus like the encrypted file, removing the
> fragmented key from numerous servers will also prove very difficult
> if not impossible even for a government.
excellent again ...
> It is the Publius software that will search the net for the file and
> the key fragments and will decrypt the file and download it to your
> web browser.
the search part therefore must be very [ extremely slow ] ...
time to read they paper ...
> I am not sure, but using an anonymous service may not be required
> but it does add another layer through which it will be very
> difficult to trace the poster through. It was suggested that a
> poster could use Publius while posting through a public host. This
> would certainly anonymize the poster.
when poster will trust this server ...
is this ONLY one point of up-load data ?
> But the power of Publius is that the file can be posted on the
> Internet and even the government will not be able to censor it, even
> if the post is deemed illegal.
finally we will have this ...
for this one future only it's worth to use ...
> Power to the People!
definitely !!!
> It is a little more involved than this but these are some of the
> characteristics and advantages.
>
> I have downloaded the paper but have not had time to read it yet.
>
> It is 14 pages long.
>
> But Scientific American thinks it is a big deal.
>
> That is enough for me to look into it further.
it's look to me to that this is big deal ...
> "INTERNET_ANONYMITY
>
> Speech without Accountability
>
> New software makes it nearly impossible to remove illegal material
> from the Web--or to find out who put it there"
>
> Scientific American
>
> http://www.sciam.com/2000/1000issue/1000techbus1.html
>
> Publius Site
>
> http://www.cs.nyu.edu/~waldman/publius/publius.html
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: BIOS password, will it protect PC with PGPDisk against tampering ?
Date: Sat, 21 Oct 2000 15:19:46 GMT
why are we bothering to crack the BIOS password? Just open the case,
pop the battery, which wipes the CMOS, boot up, set the disks back up
in BIOS (which these days is automatic), and you are in - I've had to
do that urmmm quite a few times.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Hypercube structure / balanced block mixing
Date: Sat, 21 Oct 2000 18:01:37 +0200
Benjamin Goldberg wrote:
>
> The structure of edges in a hypercube, and the structure of mixing pairs
> used in balanced block mixing are identical. I wanted to create a
> cipher which used a hypercube like structure, when I noticed the
[snip]
> I've tried myself (using 3 nested loops) but I can't seem to get it
> right. I suspect it will require 4 nested loops, but I'm not sure how.
>
> It might be only doable with a recusive function; I hope not.
I believe that a recursive formulation is natural and
elegant (benefit of easily getting it right) for the
present case, unless you happen to use a programming
language that does not support recursive function calls.
M. K. Shen
------------------------------
From: "Daniel Lieman" <[EMAIL PROTECTED]>
Subject: Re: Looking for small implementation of an asymmetric encryption algorithm
Date: Sat, 21 Oct 2000 16:09:34 GMT
Hi -
> With such a small packet size, I would suggest NTRU with N=7, p=3, q=128
> This uses exactly 49 bits per encrypted message. You can only have a
> plaintext message with 7*log2(3) bits of information.
If one used NTRU with N=7, an attacker could construct a lattice of
dimension 14 to recover the private key from the public key (this is an
analagous attack to suggesting that one use RSA with, say, 50 bit numbers,
and an attacker just factoring the public key). This attack would run in
seconds on a good workstation.
In general, the parameters of NTRU that are used in the company's
implementations are chosen carefully to make such attacks unfeasible, and
should be modified only with extreme care and consideration (for example, to
obtain a security level comparable to RSA 1024, one needs to use an N in the
range of 250 or so).
Daniel Lieman, NTRU
[EMAIL PROTECTED]
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: My comments on AES
Date: Sat, 21 Oct 2000 18:33:36 +0200
Tim Tyler wrote:
>
>
> How about the bit where he wrote (from the URL above):
>
> ``I believe that within the next five years someone will discover an
> academic attack against Rijndael.''
However, if an academic attack is only of interest
academically and not a genuine menace in practice, then
that would be only a happy and laudable success of some
intellectual endeavour, nothing more.
M. K. Shen
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: ---- As I study Rinjdael...
Date: Sat, 21 Oct 2000 08:55:30 -0700
Tim Tyler <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
> Eric Lee Green <[EMAIL PROTECTED]> wrote:
> : [EMAIL PROTECTED] wrote:
>
> :> That narrows the choice to a) use Rijndael, and provide advesaries
> :> with complete documentation of the algorithm, and test vectors. Or b)
> :> use an equally strong system and make advesaries guess the algorithm.
>
> : Or c), say nothing, and make adversaries guess as to what algorithm
they're
> : using. Could you tell, just by looking at a file, whether it was
> : encrypted via Rijndael, 3DES, IDEA, or NSA256?
>
> I can partly distinguish between sets of files encrypted with the above
> algorithms. All I do is look at the size of the blocks.
And how do you determine the block size? Especially if either they use a
block cipher mode that does not require padding, or alternatively, they
always pad to a 256 byte boundary to partially foil traffic analysis?
--
poncho
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Huffman stream cipher.
Date: 21 Oct 2000 16:14:23 GMT
[EMAIL PROTECTED] (Benjamin Goldberg) wrote in
<[EMAIL PROTECTED]>:
>SCOTT19U.ZIP_GUY wrote:
>[snip system of 2 psuedo-random huffman trees in forward direction]
>
>> Actually a long time ago I proposed very similare stuff
>> except I prefer to passes in 2 directions through the file
>> so it more closely approaches an all or nothing type to transform
>> all it one can use optiomal endings to make bytes endings instead
>> of what your trying to do. THe code for the above it totally availble
>> at my site. To do the huffman coding in revese direction of the file
>> you use the reverse file program that I supply
>
>Although making the passes go in 2 different directions adds a little
>bit of security, it eliminates the possibility of using this as a stream
>cipher, and can only work on files, and requires the creation of an
>intermediate file containing the results of the first pass (or else a
>HUGE memory buffer). Also, if you are going to make a second, backwards
Yes youre right it could not be used as a stream cipher. So don't use
it as one unless you chop it up into long blocks where each could be
used as a seperate file.
>pass, actually creating a reversed version of the file is stupid and
>inefficient; It is much smarter to seek to the end of the file, and
>seek backwards 2 characters after each read.
>
It depends on the complier. I have tried this on the C I used and
it took longer timewise. But one is free to test it on there machine
with their compliers.
>Also, unless I misrecall, your "proposal" contained no analysis of the
>security of the system whatsoever, no examples of any attacks, or things
>which could be used as attacks.
>
Of course you misrecall. And the best attack was by a german who
noticed that if you compress with this form of adaptive huffman
compression. An attacker may notive that the observered file expansion
ratio for a files choosen at random was ususally much greater than
that obtained from the compression in the 2 different directions.
So an attacker may notice on his first pass to undo that it is not the
corect "KEY" since the correct one would offer little expansion.
However most people seemed confused about how to do optimal huffman
compression in the first palace JS and MOK seem to be the most
confused by it as 99% of arugments are over the concept of just what
a single pass does.
The way I proposed to fix somewhat fix "the observered ratio"
problem involed was to reverse the file and uncompress using
another huffman pass reverse and compress again, That way the
first full decompression would have an expansion ratio like that
of decompression a true random file.
As for the fact a stream is not a file in one sense of the word
you seemed to use it in other senses like in the case in adding
an integer to a stream. In reading that problem I took it as a file
and you did not object. Also I give you an example for that other
thread. WHere you capaple of following it or what?
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: newbie pathetic question
Date: 21 Oct 2000 16:26:21 GMT
[EMAIL PROTECTED] (Chris McKenzie) wrote in
<[EMAIL PROTECTED]>:
>Danilo wrote:
>
>> I wonder why is arithmetic coding not used to scramble messages ?
>>
>> If I arithmetic compress a message, but using a frequency table which
>> is actually my key (both in the frequencies and in the order of the
>> bytes), wouldn't it be very hard to decrypt ?
>>
>> Excuse in advance for my pathetic ignorance of the matter.
>>
>> Danilo
Never saw the original post. But yes compression before encryption
is very useful if done correctly. But most compression methods are
not suited for use with encryption evern though it is common to use
them. And yes arithmetic compression can be used for a first pass
before encryption but as far as I know there is only one arithmetic
compress that is safe to use for this purpose. It is Matt Timmermans
and I have a pointer to it at my site. However it is fairly easy
to test a compressor decompress set of functions to see if it can
be used with compression. Call X any file from the set of all
eight bit byte binary files and Call Y any file from the see of
all files of a given type you wish to compress. If the compress
decompress function allows a 1-1 mapping bewteen these two set
then it is safe to use. To test at random pick a X's and see
if compress( uncompress( X )) = X and pick a few Y's at random
and check if uncompress( compress( Y)) = Y if any of the cases
fail then the method is not that good to be used with encryption.
>
>This is actually the cause of some exciting research I have been doing.
>If I here you correctly you are implying that the use of a one time pad
>wherein you randomly enumerate a sequence of elements in a set (let's
>say an alphabet) to the length of the plaintext. After this there
>should be a 1/26 ratio (using an english alphabet) when doing a
>frequency analysis of the ciphertext. This has upto this point been
>seen as perfect encryption. However the flaw here is that you have to
>transmit the one time pad. In other words you have to secure a
>connection to send the pad. This in its essense defeats the true
>purpose of cryptography because if one was to use cryptography they have
>already implied that their connection with the reciever is insecure. If
>this is so, a one-tiem pad offers the same kind of security as sending
>say every odd letter and then every even letter. All that Eve has to do
>is listen in to both transmissions and the painstaking effort is gone
>because she can easily reconstruct the message. My research falls under
>many theoretical implications that may be incorrect so I do not want to
>embarass myself by telling you what it is. However if you are duly
>interested in it you can e-mail me privately.
>
Don't be afraid why not em bare ass your self. You only live once.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: For those touting "compression as encryption" ideas - Upcoming IEEE
conference of interest
Date: 21 Oct 2000 16:45:09 GMT
[EMAIL PROTECTED] (John A. Malley) wrote in
<[EMAIL PROTECTED]>:
>Over the past few months several posters described and debated:
>
>1. the relative merits of and security afforded by different compression
>schemes prior to encryption;
>
>2. adaptation of arithmetic encoding as a form of encryption;
>
>3. adaptations of Huffman codings as forms of encryption.
>
>
>Here's a great chance to present analyses and results - the
>
>
>***** IEEE Data Compression Conference (DCC'2001) *****
>
> Snowbird, Utah
>
> Tues, March 27 - Thurs March 29, 2001
>
>A call for papers is posted at: www.cs.brandeis.edu/~dcc
>
>
>John A. Malley
>[EMAIL PROTECTED]
I doubt that it would cover the optimal kind of adaptive
compression we are talking about here. Ny guess is it will
be a BULL SHITT conference so a bunch of A holes can pat them
selves on the back. I have yet to see Acidemia use optimal
unadulterated compression. I would attempt to write a paper
myself but not being morman and not being good at bribeing
officals like what the news media is saying about how the
next olymics was choosen for Uath, I can't see a snowballs
chance in hell if them allowing an honest outsider who has
stuided the compression encryption problem in. But I have
heard from a lot of truck drivers Uath is a fun palce
especailly of you like blondes. But I prefer Nevada myself
when I use to avail my services of true professional women.
Yes I wrote this sarcasticcly since I smell the same
crap from the ACM when the lying bastards talked my into
writting a paper that they promised would get reviewed and
that I would have a chance to clean it up. Of cource the
bastards lied and this guy is making it sound like all of
us discussing compression and encryption here would have
a honest chance to present it at SNOWBIRD. Which I realize
is a fuckin lie so I just decided to bitch in advance since
it falsely makes it look like I would have a chance to present
something. In school I was an "Eta Kappa Nu" not a member of
the "IEEE"
David A. Scott
However if they ASK me to come I will come but every email
they send me we be posted on the NET here. But don't hold
you breath. They don't call Utah the Flem Flam state for no
reason at all
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
http://members.xoom.com/ecil/index.htm
Scott LATEST UPDATED source for scott*u.zip
http://radiusnet.net/crypto/ then look for
sub directory scott after pressing CRYPTO
Scott famous Compression Page
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
------------------------------
** 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
******************************
