Cryptography-Digest Digest #750, Volume #9 Tue, 22 Jun 99 18:13:03 EDT
Contents:
Re: EKE, SPEKE, etc (Thomas Wu)
Re: Question related to letter frequencies... (John Savard)
Re: A different method of encryption (John Savard)
Re: A different method of encryption (JPeschel)
Prime-Number Generation ([EMAIL PROTECTED])
A Crypto Page Disappears (John Savard)
Re: Phone scrambler : what encryption used ? ([EMAIL PROTECTED])
Re: Phone scrambler : what encryption used ? (sb5309)
Are IIS4 ASP SessionIDs secure? (Alex Ramos)
Microsoft Netmeeting Encryption ([EMAIL PROTECTED])
Re: Cipher ([EMAIL PROTECTED])
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (DJohn37050)
Re: Blowfish Variant (Bruce Schneier)
Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length? (Bob
Silverman)
Re: DES Encryption Function and an MLP ([EMAIL PROTECTED])
Re: DES versus Blowfish (Bruce Schneier)
Re: Are IIS4 ASP SessionIDs secure? (Eric Young)
Re: RC4 Susectability (fungus)
Re: Polyalphabetic Keyword Alphabets (Rebus777)
Re: Are IIS4 ASP SessionIDs secure? ("Thomas J. Boschloo")
Re: A different method of encryption (Paul Koning)
Re: Arbitrary Huffman tree and weights distribution (was: huffman code length)
(SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: EKE, SPEKE, etc
Date: 22 Jun 1999 10:50:12 -0700
[EMAIL PROTECTED] (John Savard) writes:
>
> I've been able to turn up
>
> http://world.std.com/~dpj/strong.html
>
> which is part of the SPEKE page.
>
> There's also
>
> http://theory.stanford.edu/~tjw/krbpass.html
>
> a paper on Kerberos which proposes EKE or SPEKE as ways to correct a
> security deficiency.
That page also links to <http://srp.stanford.edu/srp/>, the main SRP
resource page.
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Question related to letter frequencies...
Date: Tue, 22 Jun 1999 18:13:18 GMT
[EMAIL PROTECTED] (Mike Keith) wrote, in part:
>Surely I must be able to say more than "well, on
>average, there will be so many", mustn't I??
Well, if I know that the probability is 18% that any given character
is an E,
Ah! _Now_ I see your point!
The probability that the text is EEEEE... is probably _lower_ than
0.18 raised to the power of the number of letters in the text. For
standard English texts, digraph frequencies and other properties
enforce a *lesser* variance in letter frequencies than the
all-characters-independent model would predict.
The biggest noticeable manifestation of this effect would be seen in
how constant the proportion of vowels to consonants remains.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A different method of encryption
Date: Tue, 22 Jun 1999 18:15:40 GMT
[EMAIL PROTECTED] wrote, in part:
>Maybe we could be a little less critical?
While, in general, I'm in favor of being gentle and encouraging to
newcomers, this particular post was an extreme case.
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: A different method of encryption
Date: 22 Jun 1999 18:38:37 GMT
>[EMAIL PROTECTED] (John Savard) writes:
>While, in general, I'm in favor of being gentle and encouraging to
>newcomers, this particular post was an extreme case.
Your response tickled me so much that I wish I'd written it.
J
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED]
Subject: Prime-Number Generation
Date: 22 Jun 1999 18:39:38 GMT
***
*** This is an email anonymiser service. We are not responsible
*** for any offensive or illegal content. Posters spamming or
*** extensively cross-posting will be deleted automagically.
***
For Rabin-Miller prime generation, instead of using a random value
for <a> (the number which is randomly chosen), could you use a set
of pre-chosen numbers? What numbers would be good for this?
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: A Crypto Page Disappears
Date: Tue, 22 Jun 1999 18:33:16 GMT
"Toby's Cryptopage", by Torbjorn Andersson, has disappeared from the
Web! (Well, I'm going to Altavista to see if it has moved to a new
URL...)
This is unfortunate, as his site was very interesting, and had quite a
few rare photographs of old cipher machines, such as a
Russian-language version of the B-211 and pictures of the T-52 as
well.
Photographs are one thing my site completely lacks. (I've been busy
improving my backgrounds recently to ensure that they cause less
difficulty in clearly seeing the printing on my pages for reading
them.)
John Savard ( teneerf<- )
http://members.xoom.com/quadibloc/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Phone scrambler : what encryption used ?
Date: 22 Jun 1999 18:34:55 GMT
But A5 is crap. The ideas are good, but it's crackable. It's also NSA-made.
Undoubtabley they can crack it. And if they can crack it, ... Who knows?
My suggestion for Phones would be:
* Diffie-Hellman for Key Exchange
* A lossy compression algorithim (I'm not a compression expert, so
I can't recommend one)
* Blowfish
>
> Re: Phone scrambler : what encryption used ?
>
> From: "Lassi Hippeläinen" <[EMAIL PROTECTED]>
> Reply to: "Lassi Hippeläinen"
> Date: Tue, 22 Jun 1999 13:27:39 +0300
> Organization: Speaking for myself
> Newsgroups:
> sci.crypt
> Followup to: newsgroup(s)
> References:
> <[EMAIL PROTECTED]>
> <7k92gu$vh0$[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
>I'm not Dan, but I might help a bit...
>
>A5 is a stream cipher that xors the data with output from a PRNG. Sort
>of pseudo-OTP. The exact algorithm has never been published officially.
>Naturally somebody eventually leaked the information, and soon enough A5
>was found to be less secure than promised.
>
>A5 is not only popular, it is THE algorithm used in GSM and its
>derivatives. Most likely also in the 1900 MHz variant in America.
>
>More information at http://jya.com/crack-a5.htm
>
>-- Lassi
>
>sb5309 wrote:
>>
>> Hi Dan, are you still reading this thread ?
>>
>> Any web link to a description of A5 algorithm ?
>>
>> Thanks.
>>
>> Dan Moschuk wrote:
>>
>> > Last I checked A5 was a popular algorithm in cellular phones (I know it was
>> > quite popular in Europe at least, I don't know if North America uses it).
>> >
>> > Dan
------------------------------
From: sb5309 <[EMAIL PROTECTED]>
Subject: Re: Phone scrambler : what encryption used ?
Date: Thu, 17 Jun 1999 16:35:55 +0800
I don't know which one because as of now I am not concerned with a
particular type. I am curious about the commonly used methods.
May be you could drop some insights for me, whichever convenient. Thanks
!
Major Wood wrote:
> >>I have been to a few phone scrambler web pages
> Please specify which ones. This is a subject I know a bit about. - MW
------------------------------
From: Alex Ramos <[EMAIL PROTECTED]>
Subject: Are IIS4 ASP SessionIDs secure?
Date: Tue, 22 Jun 1999 18:50:36 GMT
IIS4 (the webserver from Microsoft) automatically does session
management for the applications programmer. The mechanism is
based on a unique Session ID stored in the client.
If an attacker can "guess" at a currently valid Session ID,
they can potentially access other user's data (depends on the
application). Anyone connecting to the server receives a
Session ID; therefore an attacker can collect as many valid
IDs as needed for cryptanalisys.
Does anybody know if the algorithm for assigning SessionID's
is cryptographically secure? Has Microsoft even published it?
Or, do I need to wrap my own security around it?
thanks
Alex Ramos
send responses to [EMAIL PROTECTED]
send spam to [EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Microsoft Netmeeting Encryption
Date: Tue, 22 Jun 1999 19:51:31 GMT
Does anybody know where I can find details or know anything about the
encryption that is included within Netmeeting 3.0?
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cipher
Date: Tue, 22 Jun 1999 20:11:27 GMT
oooooooooooooh.... meow.
shut up. PLEASE!
PLEASE!
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: 22 Jun 1999 20:22:32 GMT
One insight that was useful to me is that the index calculus methods depend on
an idea of closeness (as in additive closeness). With the normal discrete
logarithm, besides multiplication (which is the group operation one cares
about) there is also addition (which one would just as soon like to not be
there, but cannot get rid of in the normal case). This extraneous ability to
do addition can be seen as allowing for index calculus methods to work. One
picks small values to include in the "factor base" with a hope that combining
them will generate large values and essentially the entire group.
As there is no second operation on an elliptic curve group (for historical
reasons the EC operation is known as addition), there is no way to know one
point is "close" to another point, just by looking at it, so one cannot even
start to build a factor base.
Also note that if the Xedni (note it is opposite of Index) ideas of Joseph
Silverman would, if they had worked, have cracked every asymmetric hard
problem. But as he himself has pointed out, they are (much) worse than
existing methods. For example, I think he could factor a 2-digit composite
interger in a matter of hours, using Xedni.
Don Johnson
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: Blowfish Variant
Date: Tue, 22 Jun 1999 20:05:41 GMT
On Tue, 22 Jun 1999 15:15:48 GMT, [EMAIL PROTECTED] wrote:
>Inspired by the neatoness of the Twofish team I decided to rework
>Blowfish into a leaner meaner 64-bit block cipher. I changed the sbox
>so it is 4 times smaller, the key setup requires only 9 encryption
>steps (plus the time to create the sboxes). The algorithm uses a
>bijective F function inspired by Twofish (I don't use a MDS though).
>
>Check it out if you want at
>http://mypage.goplay.com/tomstdenis/bv.c
>
>The cipher accepts keys upto 210 bytes (1680 bits). It doesn't occupy
>much of the cache so even 486 DX chips should run nice and fast.
>
>Any comments?
How does it fare against the weak key attack by Serge Vaudenay? At
the very least, it should be no worse. Better is if it is better.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Why Elliptic Curve Cryptosystem is stronger with shorter key length?
Date: Tue, 22 Jun 1999 19:44:10 GMT
In article <7kofgd$[EMAIL PROTECTED]>,
"Harvey Rook" <[EMAIL PROTECTED]> wrote:
> The supposed extra difficulty gained by ECC never sat well with me.
>From a
> slightly naive point of view, because all finite fields or order M are
> identical up to isomorphism; you can take an elliptic curve, find a
map to
> the integers,
This is precisely the problem. One can't find such a map. If one
uses the Tate or Weil pairing to lift points from the curve to Q,
the heights of the lifted points blow up exponentially. Thus, it
is improbable in the extreme that one can find smooth points after
they are lifted.
For now, Index Calculus methods do NOT seem to work, nor does the
Xedni approach (for much the same reasons).
We need new ideas.
> Of course, finding the isomorphism may be intractable.
Find a map isn't hard. Finding one that controls the heights of the
lifted points seems impossible because points on elliptic curves over
Q are few and far between.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: DES Encryption Function and an MLP
Date: Tue, 22 Jun 1999 19:44:28 GMT
David G. Boney wrote:
> [EMAIL PROTECTED] wrote:
> > Sure. We can easily build the inverse table
> > given the image of all (but one) of the 2^n
> > strings of n bits. Any algorithm that uses even
> > a couple fewer blocks will usually fail for the
> > majority of the (2^n)! functions F.
> >
> > We must make limiting assumptions about F in order
> > to do interesting cryptanalysis. For example, we
> > might consider n as a variable and require that F
> > be polynomial-time in n.
[...]
> I think making limiting assumptions make the problem
> harder, not easier. First off, thinking in terms of
> any encryption algorithm that might map onto this
> space certainly limits the search ability of the
> optimization process to find a solution. An example
> would be DES.
No, you specified no parameters. DES with some
particular key would be an example of a function F
with n=64 bits. Now if you don't make any /a priori/
assumption about F, then DES with a particular key is
never a better guess than any other function that is
consistent with the input/output pairs you've seen.
> As far as the example, genetic programming will
> find it very quickly. I will post a link to some
> experiments in the next couple of weeks.
Converging on the zero Hamming weight output
differences for particular inputs is easy. Are you
claiming it will accurately predict DES outputs for
inputs other than those already used in the fitness
test? If so, that would be a terrific result.
--Bryan
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Bruce Schneier)
Subject: Re: DES versus Blowfish
Date: Tue, 22 Jun 1999 20:07:28 GMT
On 22 Jun 1999 12:09:04 -0400, [EMAIL PROTECTED] (Patrick Juola)
wrote:
>In article <[EMAIL PROTECTED]>,
>Bruce Schneier <[EMAIL PROTECTED]> wrote:
>>On Tue, 22 Jun 1999 12:25:19 GMT, [EMAIL PROTECTED] wrote:
>>>Doesn't Twofish itself have weak (?) whitening keys? Has that been
>>>addressed? Is it actually a weakness?
>>
>>No. There are no weak Twofish keys. Mizra and Murphy published a
>>paper showing a property of the whitening keys, but there is no way to
>>turn that into an attack. And there are no "weak" keys that cause
>>that property to arise.
>
>Does this read "there are no known weak keys," or does it mean
>that someone has proven that all keys are equivalently strong?
>If the latter, I'd like a reference to the proof for my library.
It's all in the paper. We do not have any mathematical proofs, but we
did brute-force statistical analyses of the S-boxes for 128-bit keys,
and Monte Carlo statistical analyses for the other key sizes.
More detail than you could possibly want are in the paper.
Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN 55419 Fax: 612-823-1590
Free crypto newsletter. See: http://www.counterpane.com
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: Are IIS4 ASP SessionIDs secure?
Date: Wed, 23 Jun 1999 06:58:57 +1000
Alex Ramos wrote:
> IIS4 (the webserver from Microsoft) automatically does session
> management for the applications programmer. The mechanism is
> based on a unique Session ID stored in the client.
>
> If an attacker can "guess" at a currently valid Session ID,
> they can potentially access other user's data (depends on the
> application). Anyone connecting to the server receives a
> Session ID; therefore an attacker can collect as many valid
> IDs as needed for cryptanalisys.
If I am following you correctly, you are talking about the SSL
session-id. The session-id is normally a 16-byte* random
identifier used to identify a set of previously calculated
security parameters. It is used to avoid the cost of a public
key exchange.
If you can guess an existing session-id, all that will happen
is that the server will start exchanging encrypted data
with you using encryption and mac keys that you do not
know. The Session-ID is just a unique identifier which
is transmitted as clear text.
eric
* due to a bug in early Netscape servers, one is forced to
use 16 byte Session-ID's in SSLv3 instead of longer
32 byte ones when using SSLv3.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: RC4 Susectability
Date: Wed, 23 Jun 1999 00:00:50 +0200
[EMAIL PROTECTED] wrote:
>
> > Oh, and throwing away the first 256 bytes of output from the
> > generator it widely thought to be a good idea. This is to avoid
> > cases where you might be able to guess part of the key from
> > the first few bytes of the output.
>
> That is not required. If you can guess the state from the first 256
> output bytes then you can guess the state at any point.
Did I say "guess the state"? I could have sworn I said "guess part
of the key"...
With a random key[*], the chances of the first byte output being
the same as the first part of the key are 36%. Having a 36%
chance of knowing one byte of the key is a fairly big weakness.
Throwing away the start of the output should be seen as essential
for a good RC4 implementation.
[*] The chances of this happening with an ASCII key are actually
much less. I can't remember the exact figure but I think it's
on the Ciphersaber web site.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Rebus777)
Subject: Re: Polyalphabetic Keyword Alphabets
Date: 22 Jun 1999 20:45:56 GMT
Thanks for your comments.
I understand that there are many ways to create more complex aphabets. My
comments are meant to encourage somebody new to polyalphabetic ciphers to do
them with paper and pencil and really see how they work in their head. When I
have tried to share my interest with some newcomers, a complicated key
set up has caused some to loose interest before they really get into it.
Setting up an alphabet with a key word makes it easy for them to pass it on to
someone else. I tried to show why this was not the best system. Thanks
again for your comments. I enjoy reading your posts.
-RSC
[EMAIL PROTECTED] wrote:
>Aside from the fact that it may matter greatly how a key isused to judge
>the scrambling results, a weaker key is apt to be more easily found, which
>is an acknowledged help to those who like to actually solve
>cryptosystems. If your orientation is to actually discourage this type of
>activity, then your key generation procedures are apt to be more complex.
>--
------------------------------
From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Subject: Re: Are IIS4 ASP SessionIDs secure?
Date: Tue, 22 Jun 1999 22:49:32 +0200
Alex Ramos wrote:
>
> IIS4 (the webserver from Microsoft) automatically does session
> management for the applications programmer. The mechanism is
> based on a unique Session ID stored in the client.
<snip>
> Does anybody know if the algorithm for assigning SessionID's
> is cryptographically secure? Has Microsoft even published it?
> Or, do I need to wrap my own security around it?
I am not sure if you were aware of this, but according to
http://www.cert.org/advisories/CA-99-07-IIS-Buffer-Overflow.html there
was a bug discovered in IIS4 this weekend that allowed a hacker to run
arbitrary code on the IIS server (if I get things right).
Seems like Microsoft did it again!
Thomas
--
Buy an AMD K6-III <http://www.bigbrotherinside.com/#help>
PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl
------------------------------
From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: A different method of encryption
Date: Tue, 22 Jun 1999 16:27:03 -0400
[EMAIL PROTECTED] wrote:
> ...
> Let the letter r represent the file to be encrypted, and let r(n)
> represent the nth byte of that file. Let s represent a file full of
> random bytes, as many bytes as there are in r, where s(n) is the nth
> byte of that file. Let t represent the file that will be produced once
> the encryption process is complete, t(n) representing the nth byte of
> that file.
>
> t(n) is computed as follows:
> t(n) = (r(n) + s(n)) % 256,
> where the % operator corresponds to the C++ modulus (remainder)
> operator (identical to the BASIC MOD operator). This computation is
> carried out as many times as there are bytes in r, that is, for each n.
> Note that r, s, and t will all be of equal length.
Congratulations. You have just reinvented the One Time Pad, almost
a century after its original creation.
paul
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: comp.compression,alt.comp.compression,sci.math
Subject: Re: Arbitrary Huffman tree and weights distribution (was: huffman code length)
Date: Tue, 22 Jun 1999 22:40:54 GMT
In article <7ko7fi$ajm$[EMAIL PROTECTED]>, Alex Vinokur
<[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> Alex Vinokur wrote:
>>
>> >
>> > Let W = {w1, w2, ..., w#n} be
>> > a non-decreasing sequence of positive numbers:
>> > w1 <= w2 <= w3 <= ... <= w#n.
>> > The W sequence is called normalized
>> > if w1 + w2 + ... + w#n = 1.
>> > The W sequence of integers is called 100-normalized
>> > if w1 + w2 + ... + w#n = 100.
>> >
>> > Let T be a Huffman tree for the W sequence.
>> >
>> > * Level#0
>> > /\
>> > / \
>> > * * Level#1
>> > ............
>> >
>> > * * * * ... * Level#k
>> >
>> > ............
>> >
>> > * * * ... * Level#n (Last)
>> >
>> > (I think) The following conditions must take place for Huffman tree:
>> >
>> > ---------------------------------------------
>> > A-conditions : for each level of Huffman tree
>> > ---------------------------------------------
>> > Let a1, a2, a3, ..., a#m be nodes of Level#k
>> > (a1 is the leftest node on this level,
>> > a#m is the rightest node on this level).
>> > ---> A-Conditions are : a1 <= a2 <= a3 <= ... <= a#m.
>> > ---------------------------------------------
>> >
>> > ---------------------------------------------
>> > B-conditions : for each level of Huffman tree
>> > ---------------------------------------------
>> > Let Q be a such piece of Huffman tree :
>> >
>> > * Level#(k-2)
>> > /\
>> > / \
>> > * * Level#(k-1)
>> > /\ /\
>> > / \ / \
>> > a b c d Level#k
>> >
>> > ---> B-Condition is : (a + b) >= d.
>> > ---------------------------------------------
>>
>> For a Huffman tree that is for a W-sequence of your definition
>> than your A-Condition holds (via definition if the nodes are
>> ordered that way). But how about an arbitrarily given Huffman tree?
>>
>> M. K. Shen
>>
>> M. K. Shen
>>
>
>Hi,
>
>Let W be the following sequence : 10 11 15 20
>
>Here are Huffman algorithm stages :
>
>(I think) If the sequences are sorted on each stage
> of the Huffman algorithm
> then A-Conditions take place.
>
>=======================================================
>Example 1.
>=========
>Stage#0 : 10 11 15 20
>Stage#1 : 15 20 (21)
>Stage#2 : (21) (35)
>Stage#3 : (66)
>Note! The sequences are sorted on each stage.
> So, A-Conditions take place for this tree.
>
> 66
> /\
> / \
> 21 35
> /\ /\
> / \ / \
> 10 11 15 20
>
>
>
>
>
>###############################################
>We can "desort" first two weight
> on some (or all) stages of Huffman algorithm.
>In this case A-conditions don't take place for Huffman tree.
>###############################################
>=======================================================
>Example 2.
>=========
>Stage#0 : 11 10 15 20 The sequence isn't sorted
>Stage#1 : 20 15 (21) The sequence isn't sorted
>Stage#2 : (21) (35) The sequence is sorted
>Stage#3 : (66)
>Note! There are "desorted" sequences.
> So, A-Conditions don't take place for this tree.
>
> 66
> /\
> / \
> 21 35
> /\ /\
> / \ / \
> 11 10 20 15
>
>
>###############################################
>(I think) If we use Huffman algorithm with "desorting",
>apparently we need to use the weights permutations
>on each level to build Conditions like A-Conditions.
>
>By the way, is there any reason to use Huffman algorithm with
>"desorting"?
>
Yes I think there are resons to use Huffman trees that are not quit sorted
the way it usually is done. The main reason would be to create a headerless
dynamic huffman compression. Since the last byte compressed seldom
ends up on a byte bouday something special must be done. See what I
did at my web page on compression.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
