Cryptography-Digest Digest #731, Volume #12 Thu, 21 Sep 00 09:13:01 EDT
Contents:
Re: Algebra, or are all block ciphers in trouble? ("Douglas A. Gwyn")
t ("lala")
Re: t ("Douglas A. Gwyn")
Re: Double Encryption Illegal? (Guy Macon)
cryptogram solver available (David Eppstein)
Dr Mike's "Implementing Elliptic Curve Cryptography" - reader comment (Paul Rubin)
Re: t (Thomas Pornin)
3DES - keyoptions ("kihdip")
Re: 3DES - keyoptions (Runu Knips)
Re: md5 fail -x test under Digital UNIX C Compiler (Robert Harley)
Re: SUN SPOT 6.51 BILLION square kilometers in size (Mark S. Bilk)
Re: Dr Mike's "Implementing Elliptic Curve Cryptography" - reader comment (Tom St
Denis)
Re: Hardware RNGs (Runu Knips)
Re: Stream cipher (Runu Knips)
Re: Software patents are evil. (Runu Knips)
Re: 3DES - keyoptions ("Abyssmal_Unit_#3")
Re: Software patents are evil. (Runu Knips)
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: Tying Up Loose Ends - Correction (Tim Tyler)
----------------------------------------------------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Algebra, or are all block ciphers in trouble?
Date: Thu, 21 Sep 2000 00:17:09 -0400
By the way, it is a somewhat interesting exercise (of the kind that
would be assigned for homework in a class on the subject) to take
each of the 16 distinct binary operators alone, e.g. {K} where K
is AND, and determine which of these algebras it generates.
------------------------------
From: "lala" <[EMAIL PROTECTED]>
Subject: t
Date: Thu, 21 Sep 2000 14:16:58 +1000
t
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: t
Date: Thu, 21 Sep 2000 00:31:51 -0400
lala wrote:
> t
Yes, indeed. In fact that (although in upper case) was the
entire content of the first page of an experimental book I
once wrote, which explored how much communication might be
developed between agents that could perceive the symbols but
had utterly different modes of thought and no a priori shared
knowledge. The second page was
NNT
The third was
NF
You get the idea (maybe).
Others who have approached this problem have usually assumed
more commonality among the communicants; see
http://www.nsa.gov/docs/efoia/released/ufo/ufo34.pdf
for a representative example.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Double Encryption Illegal?
Date: 21 Sep 2000 06:29:27 GMT
Arturo wrote:
>
>On 20 Sep 2000 02:13:48 GMT, [EMAIL PROTECTED] (Guy Macon) wrote:
>
>>Trevor L. Jackson, III wrote:
>>>
>>>
>>>Guy Macon wrote:
>>>
>>>> You mean I shouldn't be applying ROT-13 twice? Several experts have
>>>> told me that applying ROT-13 twice is *so* secure that an attacker
>>>> with infinite resourses can't even tell what algorithm I used...
>>>
>>>They also can't tell which of the four combinations DD, DE, ED,
>>>or EE were used.
>>
>>Who could possibly ask for more security than that???
>
>Hope nobody is taking you guys seriously ;-)
Oh, *real* clever, Arturo. Did you think that nobody would notice
you double encrypting your post using ROT13? Well *I* noticed, and
I double DEcrypted it with ROT13 bnefor replying. So there!
------------------------------
From: David Eppstein <[EMAIL PROTECTED]>
Crossposted-To: rec.puzzles
Subject: cryptogram solver available
Date: Wed, 20 Sep 2000 23:50:01 -0700
I have a new cryptogram-solving applet, which is available at
http://www.ics.uci.edu/~eppstein/cryptogram/
It uses an iterative technique based on English word frequencies to build
up a table of probabilities for each letter pair -- details available at
the web page. This seems like a primitive idea, but it works surprisingly
well in many cases.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
[EMAIL PROTECTED] http://www.ics.uci.edu/~eppstein/
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Dr Mike's "Implementing Elliptic Curve Cryptography" - reader comment
Date: 21 Sep 2000 01:11:17 -0700
I just got this from bn.com (I don't buy from Spamazon any more). I
won't call this post a "review" since I haven't read through the book
but have only looked at it for an hour or two. I'm somewhat
disappointed.
The writing style is friendly enough but I felt that a lot of the
material could have been simply omitted, and what's left often seems
presented in a way that makes it look more complicated than it really
is. A lot of the book is filled with code listings many of which
aren't especially necessary or even ECC-relevant (e.g. a six page
implementation of the SHA-1 hash function, 14 pages on an integer
bignum library, etc.) and there is a lot of material on elementary
math which seems pointless. Will anyone who doesn't understand what
modular arithmetic is even think of building or maintaining an ECC
implementation? Someone like that (I imagine the intended audience of
this book is a not-very-math-savvy programmer who has to code up ECC
for some larger project, e.g. a WTLS-enabled WAP client) is probably
better off just using an existing library from somewhere.
Also, almost all the ECC material is about ECC over fields of
characteristic 2. There's basically nothing about characteristic p > 2,
and in fact the book on p. 108 seems to confuse ECC over GF(p) with an
obscure scheme (at least I'd never heard of it before) to do ECC over
the ring Z_n for composite n. I got the book mostly in the hope of
finding some good computational tricks for doing ECC over GF(p) so
this is a let-down.
The book's main strength seems to be identifying the various
tribulations that a programmer must go through to make an IEEE
P1363-conformant ECC implementation starting from scratch and getting
him/her through them. However, I feel it concentrates too much on
code and is somewhat weak on math. (To be fair, many of the reviewers
quoted in the blurb seem to consider this a virtue).
Anyway, I'll probably go back to reading Koblitz's "Course in Number
Theory and Cryptography", the P1363 draft standard, and the stuff on
Certicom's web site.
------------------------------
From: [EMAIL PROTECTED] (Thomas Pornin)
Subject: Re: t
Date: 21 Sep 2000 09:03:10 GMT
According to Douglas A. Gwyn <[EMAIL PROTECTED]>:
> Others who have approached this problem have usually assumed
> more commonality among the communicants
On a slightly different point of view, read "The Forever War" from
Joe Haldeman.
There is also the classical "Stranded on Venus" problem: some scientists
have a technical problem on the ground of planet Venus. To get back to
the orbital station, a button must be pushed on the control panel of the
station, but there is nobody left to push that button... except some
bypassing (and altogether cooperative) aliens.
The scientists manage to establish a radio communication with the
aliens, and build up some sort of language (they are *good* scientists).
But the main problem is that there are two buttons on the panel. The
left one is the one to be pushed. The other one is the self-destruct
command.
How will the scientists and aliens agree on the notion of left and right ?
--Thomas Pornin
PS: besides, "T" is a great letter, since my first name begins with a T.
------------------------------
From: "kihdip" <[EMAIL PROTECTED]>
Subject: 3DES - keyoptions
Date: Thu, 21 Sep 2000 11:33:13 +0200
This is probably an ordinary question that has been discussed before, but I
hope you'll enlighten me:
3DES has three key-options:
key1 != key2 != key3 (key-option 1)
key1 = key3 != key2 (key-option 2)
key1 = key2 = key3 (key-option 3)
(Using != as 'not-equal-to')
What is the clever thing with key-option 3 ?? Isn't it just an incredible
slow DES ?? (As 3DES is EDE)
Kim
------------------------------
Date: Thu, 21 Sep 2000 12:06:55 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: 3DES - keyoptions
kihdip wrote:
>
> This is probably an ordinary question that has been discussed before, but I
> hope you'll enlighten me:
>
> 3DES has three key-options:
> key1 != key2 != key3 (key-option 1)
> key1 = key3 != key2 (key-option 2)
> key1 = key2 = key3 (key-option 3)
>
> (Using != as 'not-equal-to')
>
> What is the clever thing with key-option 3 ?? Isn't it just an incredible
> slow DES ?? (As 3DES is EDE)
No, DES is NOT slow in hardware. And the last option is simply there to
allow 3DES chips to be compatible with ordinary DES.
------------------------------
From: Robert Harley <[EMAIL PROTECTED]>
Subject: Re: md5 fail -x test under Digital UNIX C Compiler
Date: 21 Sep 2000 12:55:07 +0200
[EMAIL PROTECTED] writes:
> I have md5 running on Alpha and it fails md5 -x self-test producing
> garbage instead of the expected digest.
> The version of md5 was taken from
> http://theory.lcs.mit.edu/~rivest/crypto-security.html#Algorithms
> (as distributed by RSA DSI)
> Here is the cc version info:
> Digital UNIX Compiler Driver 3.11
> DEC C V5.9-005 on Digital UNIX V4.0 (Rev. 1229)
> Operating system: OSF1 V4.0 1229 alpha
> I assume it is not an algorithm bug, most likely the compiler,
> but I can't figure out what is going on. Any suggestions ?
Your assumption is wrong. The source code is clearly not 64-bit clean
since right at the top it says:
/* typedef a 32 bit type */
typedef unsigned long int UINT4;
Nuke the "long".
Bye,
Rob.
.-. .-.
/ \ .-. .-. / \
/ \ / \ .-. _ .-. / \ / \
/ \ / \ / \ / \ / \ / \ / \
/ \ / \ / `-' `-' \ / \ / \
\ / `-' `-' \ /
`-' [EMAIL PROTECTED] `-'
------------------------------
From: [EMAIL PROTECTED] (Mark S. Bilk)
Crossposted-To: sci.military.naval,alt.conspiracy,sci.geo.earthquakes
Subject: Re: SUN SPOT 6.51 BILLION square kilometers in size
Date: 21 Sep 2000 10:59:24 GMT
In article <[EMAIL PROTECTED]>,
Doug Berry <[EMAIL PROTECTED]> wrote:
>I'm sort of confused as to what sort of conspriacy is inviolved
>in creating sunspots.
Well it's pretty clear that it has to be either the Jews,
the Masons, the Homosexuals, the Bilderburgers, the British,
the namby-pamby Environmentalists, or -- and this would be
my guess -- the World Communist Conspiracy, also known as
the Liberals.
One of these groups is tampering with the Sun, turning it
all spotty.
And why is it made of hydrogen anyhow? Wouldn't helium
be a lot safer? What if the Sun caught fire? We'd all
be killed!
>And why isn't sci.astro on this list?
What the hell would they know about it?
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Dr Mike's "Implementing Elliptic Curve Cryptography" - reader comment
Date: Thu, 21 Sep 2000 11:04:33 GMT
In article <[EMAIL PROTECTED]>,
Paul Rubin <[EMAIL PROTECTED]> wrote:
> I just got this from bn.com (I don't buy from Spamazon any more). I
> won't call this post a "review" since I haven't read through the book
> but have only looked at it for an hour or two. I'm somewhat
> disappointed.
>
> The writing style is friendly enough but I felt that a lot of the
> material could have been simply omitted, and what's left often seems
> presented in a way that makes it look more complicated than it really
> is. A lot of the book is filled with code listings many of which
> aren't especially necessary or even ECC-relevant (e.g. a six page
> implementation of the SHA-1 hash function, 14 pages on an integer
> bignum library, etc.) and there is a lot of material on elementary
> math which seems pointless. Will anyone who doesn't understand what
> modular arithmetic is even think of building or maintaining an ECC
> implementation? Someone like that (I imagine the intended audience of
> this book is a not-very-math-savvy programmer who has to code up ECC
> for some larger project, e.g. a WTLS-enabled WAP client) is probably
> better off just using an existing library from somewhere.
>
> Also, almost all the ECC material is about ECC over fields of
> characteristic 2. There's basically nothing about characteristic p >
2,
> and in fact the book on p. 108 seems to confuse ECC over GF(p) with an
> obscure scheme (at least I'd never heard of it before) to do ECC over
> the ring Z_n for composite n. I got the book mostly in the hope of
> finding some good computational tricks for doing ECC over GF(p) so
> this is a let-down.
>
> The book's main strength seems to be identifying the various
> tribulations that a programmer must go through to make an IEEE
> P1363-conformant ECC implementation starting from scratch and getting
> him/her through them. However, I feel it concentrates too much on
> code and is somewhat weak on math. (To be fair, many of the reviewers
> quoted in the blurb seem to consider this a virtue).
>
> Anyway, I'll probably go back to reading Koblitz's "Course in Number
> Theory and Cryptography", the P1363 draft standard, and the stuff on
> Certicom's web site.
I also have a copy of his book. I was a newbie (still pretty much am)
at ECC when I picked it up. It explains ECC very well for a newbie
since it covers the "trivial basics". I find it disappointing that it
doesn't cover the case p>2 but ECC in GF(2) is simple both in hardware
and software. I think the NISTS recommendation is to add a few
hundread bits over p>2 cases.... so a 500 bit field is not huge
considering all you are doing is xor's, shifts, etc...
It's not a very techy book, obviously alot of theory has been omitted,
but it's a good start.
Tom
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 21 Sep 2000 13:11:36 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Hardware RNGs
Mark Carroll wrote:
> Whoops - sorry, I didn't notice that sci.crypt.random-numbers exists. I'll
> post there instead.
Really ? Damned, my newserver doesn't have this one ! :-(
...but maybe thats also big luck for the people there ;-)
------------------------------
Date: Thu, 21 Sep 2000 13:16:48 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Stream cipher
Jerry Coffin wrote:
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
> > [EMAIL PROTECTED] wrote:
> > > I am trying to implement a stream cipher with low resource requirements
> > > [...] the encryption algorithm should be free and not patented (no RC4
> > > or SEAL or Shareware).
> >
> > RSADSI has a trademark and trade secret "RC4". Because the algorithm has
> > been published anonymously 1994 in this newsgroup, it isn't a secret
> > anymore. Everyone can use it freely IF AND ONLY IF one calls it
> > "Arcfour"
> > instead of "RC4", because RSADSI still has the trademark on "RC4".
>
> You're NOT required to call it "Arcfour" by any means -- you simply
> can't call it "RC4".
Correct. Thats what I wanted to say.
------------------------------
Date: Thu, 21 Sep 2000 13:33:07 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Software patents are evil.
Terry Ritter wrote:
> Patents on "processes" ("do this, do that") have been common for
> at least a century.
Where "At least a century" == "not much more than a century"
Compared to most other financial concepts, patents are
an extremely young concept.
And, of course, from the beginning, there where scientists
which refused to patent, because they want everyone to
benefit from their studies.
> Patents on a computational process which ends up providing some
> benefit for use seems a very natural extension.
Such as destroying open source, destroying smaller
computer companies, making programs far more expensive
and having to pay 3 lawyers per programmer, to search
for patent problems.
------------------------------
From: "Abyssmal_Unit_#3" <[EMAIL PROTECTED]>
Subject: Re: 3DES - keyoptions
Date: Thu, 21 Sep 2000 07:51:04 -0400
has anyone found a data sheet for the Motorola DES hardware chip?
circa 1979?
--
best regards,
hapticz
>X(sign here)____________________________________________<
Runu Knips wrote in message <[EMAIL PROTECTED]>...
|kihdip wrote:
|>
|> This is probably an ordinary question that has been discussed before, but I
|> hope you'll enlighten me:
|>
|> 3DES has three key-options:
|> key1 != key2 != key3 (key-option 1)
|> key1 = key3 != key2 (key-option 2)
|> key1 = key2 = key3 (key-option 3)
|>
|> (Using != as 'not-equal-to')
|>
|> What is the clever thing with key-option 3 ?? Isn't it just an incredible
|> slow DES ?? (As 3DES is EDE)
|
|No, DES is NOT slow in hardware. And the last option is simply there to
|allow 3DES chips to be compatible with ordinary DES.
------------------------------
Date: Thu, 21 Sep 2000 14:18:14 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Subject: Re: Software patents are evil.
Jerry Coffin wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
> > Well consider the patent on rotation. A japanese company recently
> > claimed that most of the AES finalist violate their patent. So
> > what is their patent ? Using rotation in encryption !!!!!!!
>
> You're making the same mistake as most people who condemn software
> patents: you start by picking a patent that perhaps shouldn't have
> been granted in the first place because it may have been more or less
> marginal WRT things like originality.
I didn't made an error, I tried to get an example which is
especially clear.
> You don't leave it at the fact that being run by humans, the PTO
> makes mistakes now and then though -- you got a step further, and
> grossly mis-characterize the patent entirely.
Nope. The american patent office doesn't do many checks,
compared to those in europe, and even worse the people
there are paid for the number of patents that they have
given (not those they have testet, or the hours they
have worked).
> In this case, the patent is NOT simply on using rotations in
> cryptography at all. It's on using a specific number of input-
> dependent rotations combined in a fairly specific fashion.
Okay, then the claim of patent violation is even more absurd.
> > Not to note that using rotation is the oldest concept of
> > encryption, even the first of all ciphers, the caesar one, was
> > a rotation in 26 alphabetic characters, this patent was also given
> > long after, for example, DES has been published (DES rotates the
> > key bits), and this is a practical example how people patent maths.
>
> No, it is not. It is a practical example of how people stretch the
> truth to justify their positions.
Yep. If it is that way, I agree.
> IOW, no, you can't get a patent on any piece of math you wish.
Okay, then the practical question: So I can design a cipher
using multiplication mod 2**16+1, addition and xor, and
don't violate the IDEA patent ? I can easily construct, for
example, a Feistel network with these operations !
> > Why don't you patent "using addition in mercantile computations
> > to get the sum of something" ? Hey, its patentable !
>
> Says who?
That was ironic.
> So far, you've said so, but the PTO hasn't agreed. Even
> if they did, it wouldn't necessarily mean a lot: you'd have to sue
> somebody for infringement and get your patent upheld in court before
> it meant much of anything.
I have no illusions that I have a chance to win a process
against a big company. I simply have to pay too much at
the start of it (even if I would get that money back). At
least in Germany it is this way.
> > Software patents will, for example, destroy free software if we
> > can't hinder it. I can't see how you want to get such losses
> > back.
>
> People have been saying this for decades now.
Have they ?!?
> In fact the examples
> they first used (e.g. on RSA encryption) are now expired. Look
> around, and try to tell me that there's less free software today than
> there was 20 or 30 years ago.
AFAIK PGP has simply violated the RSA patent. And GnuPG
became possible because ElGamal expired.
> In reality, software patents are going to contribute heavily to free
> software: when somebody writes a patent, they must reveal all the
> secrets and details of how to implement the invention, and when the
> patent expires, the invention is automatically placed in the public
> domain. There's no room for question about whether you can use it or
> not, etc. -- it's known for certain to be public domain.
And until that, there are masses of free software around
which in fact violates patents. Just look at the tricks
the authors of the LAME project had to use to write a
OSS mpeg encoder.
The reason why open software projects haven't been destroyed
by patents yet is simply that (a) they violate them and are
hard to catch, and (b) there where no software patents in
europe.
> Furthermore, the inventor has provided assistance so any person of
> ordinary skill in the art can implement the invention as it was
> intended to work.
But _IF_ I don't want to get such a help ? Before a while
I have heared someone tried to create a open sound format,
patentfree. He has checked the U.S. patents and finally
gave up. Even the simplest things are patented there...
> Further still more, there's a requirement that the
> inventor reveal the best mode of embodiment. This basically means
> the inventor has to tell you the intended area for the invention's
> use. For example, if he invents some method of building legs to put
> under buildings to prevent damage from both flooding and earthquakes,
> his patent can be completely invalidated if he tries to mislead you
> into believing that this is really about how to build table legs
> instead.
Why doesn't he just keeps calm if he only wants to let
people to use his or her inventions if they pay money to
him ?
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Sep 2000 12:30:35 GMT
Trevor L. Jackson, III <[EMAIL PROTECTED]> wrote:
: Tim Tyler wrote:
:> John Savard <[EMAIL PROTECTED]> wrote:
[sorry about all the quoting]
:> : I think that trying to remove redundancy as far as possible is a good
:> : idea. While I disagree with Mr. Scott on one detail on his 1-1 scheme []
:>
:> It seems that any technique which takes a bitstreams and converts them
:> reversibly to files of 8-bit bytes will exhibit some statistical
:> anomolies, of the type I believe you're objecting to.
:>
:> Any system which attempts to avoid such artefacts completely seems
:> obliged to use some sort of random padding.
:>
:> John's scheme proposes adding such padding after coompressing, and before
:> encryption.
:>
:> An alternative - which I've not seen discussed on this forum - would be
:> to use an encryption device which is capable of encrypting variable length
:> bitstrings, and is not confined to multiples of 8 bits. I attribute this
:> idea to David Scott.
:>
:> Indeed - if dealing with the output of an arithmetic compressor, files
:> of a fractional number of bits in length are also possible - i.e. a
:> message may be 10.5 bits long.
:>
:> After the compresssed file is encrypted, it can be safely padded out with
:> zeros, to a byte boundary without any security concerns. If you want to
:> obscure the length of the file from your adversary, as much random padding
:> as you like can be used at this stage.
: The fails to meet his criteria that any bitstream be both plain and
: compressed text.
I presume you refer to David Scott's criteria?
I think we're on different tracks here. David's criteriaon (if I
interpret this reference correctly) was intended to apply to the
output of compression programs.
The type of compression employed above was deliberately not specified.
If a suitable compressor was used, it's output would indeed fulfill
David's criterion.
Your objection seems ambiguous. I can't see how it applies to the
system described above.
If there's a problem with theprocess described, it seems to be that I
didn't specify how to distinguish any random padding from the data.
This is not an issue I feel inclined to go into at this juncture.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Reply-To: [EMAIL PROTECTED]
Date: Thu, 21 Sep 2000 12:42:48 GMT
SCOTT19U.ZIP_GUY <[EMAIL PROTECTED]> wrote:
: [EMAIL PROTECTED] (Tim Tyler) wrote in <[EMAIL PROTECTED]>:
:>Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
:>: If my message is over one hundred bytes, do you think
:>: that I need to care about wasting 5 bits?? [...]
:>
:>At worst, this can reduce the size of keyspace by a factor of 32.
:>
:>It might make the difference between an analyst looking at 32 different
:>possible messages, and one unique one.
:>
:>Of course, whether you consider this sort of thing to be potentially
:>important is up to you.
: Tim as a thought experiment I tried to do a very simple calulation
: that seems to round to zero on my HP 15C suppose one is writting
: a random file with only 255 character types. make the file 65,636
: bytes long. And use the 256th character type as a EOF marker. One
: could view MoK problem like this. The file I was statically compress
: ing has each symbol occurring the same number of times. so the tree
: reduce to the one where all lengths 8 bits. WHat are the odds if one
: encrypts this string that when one uses a false key that it could be
: a valid string witch could have been compressed. Well it would have to be a
: file that does not contain the 256th charter in all but the last byte.
: looking at only the last byte you eliminate all but 1 out 256 weaking
: the key by 8 bits. But what is the chance that the 256th bit EOF marker
: will not appear in the first 65,636 bytes. It is ( 255/256)**(65,636)
: which is "ZERO". Well it can't be zero but I think you will agree it will
: weaken the key so that if an AES candidate was used the only key that
: fits is the one used for the encryption.
While these sums are correct there are other methods of ending Huffman
symbol strings that don't necessitate using an EOF marker, that don't
go as far as your 1-1 method.
All you need is to make sure that some 8-bit-or-greater length symbols
remain in the Huffman tree. If there are any objects with a frequency
of < 1/256, this is going to be the case anyway. Then just stick
a partial symbol at the end of the file as a terminator (if the exact EOF
has not been reached).
This isn't ever going to reduce the keyspace by more than 8 bits.
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
** 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
******************************
