Cryptography-Digest Digest #761, Volume #12 Sun, 24 Sep 00 13:13:00 EDT
Contents:
Re: 128-bit Secure LFSR (Whoops) (Tom St Denis)
HAC DES Test Vectors ("Martin Wolters")
Re: Big CRC polynomials? ("bubba")
Re: Again a topic of disappearing e-mail? (Dan Kegel)
Re: 128-bit Secure LFSR (Whoops) (Simon Johnson)
Re: Big CRC polynomials? (Tom St Denis)
Re: free cpu for sci.crypt readers (Tom St Denis)
Cryptography Challenge (Buster Brown)
Re: What make a cipher resistent to Differential Cryptanalysis? (SCOTT19U.ZIP_GUY)
Re: Big CRC polynomials? (SCOTT19U.ZIP_GUY)
LFSR as a passkey hashing function? (Simon Johnson)
Re: Again a topic of disappearing e-mail? (Simon Johnson)
Re: What make a cipher resistent to Differential Cryptanalysis? (Tom St Denis)
Re: Big CRC polynomials? (Tom St Denis)
Re: LFSR as a passkey hashing function? (Tom St Denis)
Re: What make a cipher resistent to Differential Cryptanalysis? (Tom St Denis)
Re: LFSR as a passkey hashing function? (Simon Johnson)
Re: RSA occasional failure? (Roger Schlafly)
Re: Cryptography Challenge (Tom St Denis)
Re: LFSR as a passkey hashing function? (Tom St Denis)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
Re: Tying Up Loose Ends - Correction (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: 128-bit Secure LFSR (Whoops)
Date: Sun, 24 Sep 2000 13:55:53 GMT
In article <39ce02c3$0$62626$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jeff Gonion) wrote:
> Tom,
>
> I didn't look at your polynomial, but the first thing I noticed is
that
> your LFSR code seems to be incorrect. You need to shift EVERY time
through.
> The code on your website appears only to shift if the LSB is 0.
Learn to read C code first my friend.
>> } else
>> r = 0
>> m[0] = ...
The m[0] is not part of the else clause.
> Also, you should never need to shift anything more than once.
> Rather than shifting all of the m[]<<31, all you need to do is
> reverse the direction of every other m[]. After all, all you care
> about is the 1-bit output, and the 1-bit that propagates between
> stages. Try this (I haven't tested it, it's off the top of my head):
Hmm neat idea but I would have to reverse the polynomial, otherwise it
should work.
Note that my code is "AN EXAMPLE THAT IS SUPPOSE TO BE SIMPLE".
:-)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Martin Wolters" <[EMAIL PROTECTED]>
Subject: HAC DES Test Vectors
Date: Sun, 24 Sep 2000 16:33:11 +0200
Hi,
In the Handbook of Applied Cryptography,
the following DES-Test Vectors are shown:
Key: 0123456789ABCDEF
P: 4E6F772069732074 68652074696D6520 666F7220616C6C20
C: 3FA40E8A984D4815 6A271787AB8883F9 893D51EC4B563B53
My Implemention returns:
C: 5d1b45d8c23190cd 09b1c144bf6ff01b 603c73811b87f13b
I once checked my Implementation with a Test vector making HTML file,
and it seemed to be correct. Are the Test vectors in the HAC wrong?
------------------------------
From: "bubba" <[EMAIL PROTECTED]>
Subject: Re: Big CRC polynomials?
Date: Sun, 24 Sep 2000 15:03:25 GMT
Think of feeding a random bit string to an algorithm that validates a
message with a
CRC and to an algotithm that validates with a checksum.
Bad messages slip through with an equal probability.
The CRC bacame popular in serial data commumications where burst errors
are much more likely than random errors. This real-world situation is where
the CRC has an enormous advantage.
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:8qkoa7$bgo$[EMAIL PROTECTED]...
> In article <kTdz5.4621$[EMAIL PROTECTED]>,
> "bubba" <[EMAIL PROTECTED]> wrote:
> > Try this experiment on a scaled down example. Use CRC, use checksum.
> > Evaluate ALL files. Obviously the results will be equal, because each
> check
> > code aliases to the same number of different files. It is not really
> that
> > hard.
> > Maybe I will write a program to demonstrate.
>
> A CRC is more reliable then simple "summing" checksums, I don't care
> how you put it. Burst errors are what CRC's detect and 99.99% they
> catch them. I don't care much for maticulous manipulation of the file,
> I mean sure given enough time I could fake out md5....
>
> Tom
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
------------------------------
From: Dan Kegel <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Again a topic of disappearing e-mail?
Date: Sun, 24 Sep 2000 08:25:33 -0700
/dev/null wrote:
> When a disk rotates, the head never passes over the same exact cylinder
> area twice. There are tiny irregularities in the rotation of the disk
> surface and the mechanical parts of the head assembly. Those
> irregularities mean that erasing the drive will not actually remove
> everything that was ever written to the drive. A dedicated hardware man
> with a good piece of code that will read and read and read can recover
> quite a bit more than one would expect.
> ...
> If you want the data gone, you have to destroy the media.
Well... yes and no.
http://www.cs.auckland.ac.nz/~pgut001/secure_del.html
describes a procedure for maximizing the likelihood
of actual erasure.
http://www.toc.lcs.mit.edu/~cis/cis-threshold.html is also
of interest if you have more than one machine to spread the
data over.
And then there's the trick of keeping the encrypted data
on one machine, and the key on another.
Disappearing Inc. uses all three of these in their system.
- Dan
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: 128-bit Secure LFSR (Whoops)
Date: Sun, 24 Sep 2000 15:22:18 GMT
> P.S. - I've got a PDF paper that explains LFSR's pretty well, in
> everyday english, including Golumb�s criteria for randomness,
> modulo-2 polynomial math, and The Berlekamp-Massey algorithm,
> which is used to determine the shortest LFSR that can produce
> a given bitstream. If anyone would like a copy, I can email it,
> since this newsgroup doesn't seem to accept binaries.
> ----------------------------------------------------------------
Any chance you could stick it on you're webspace? My e-mail server is a
little dodgy! :)
Simon
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Big CRC polynomials?
Date: Sun, 24 Sep 2000 15:25:56 GMT
In article <1Joz5.2051$[EMAIL PROTECTED]>,
"bubba" <[EMAIL PROTECTED]> wrote:
> Think of feeding a random bit string to an algorithm that validates a
> message with a
> CRC and to an algotithm that validates with a checksum.
>
> Bad messages slip through with an equal probability.
>
> The CRC bacame popular in serial data commumications where burst
errors
> are much more likely than random errors. This real-world situation is
where
> the CRC has an enormous advantage.
Um are you just a troll or what? When I send a checksum it's much
easier for the checksum to be faked then a CRC. If you want data
integrity use a CRC32 or a hash function.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: free cpu for sci.crypt readers
Date: Sun, 24 Sep 2000 15:43:52 GMT
In article <8qjfcf$ok$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> I have a cyrix MII 300 (233mhz) to give away free (cuz I don't need
> it). Any sci.crypt reader is entitled to it, if they actually need it
> (i.e they have a socket7 board with a slow cpu in it).
>
> If you really could use it, email me at [EMAIL PROTECTED]
The cpu has been taken by a sci.crypt reader... :)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Cryptography Challenge
From: [EMAIL PROTECTED] (Buster Brown)
Date: Sun, 24 Sep 2000 15:52:13 GMT
Hi All,
Would any of you have read Talking to Strange Men, by Ruth Rendell.
Supposedly this novel contains an encryption method that escapes me.
The encryption method uses as key the first sentence of an agreed upon
novel.
For example:
Given the following cipher-text:
SIDKHKDM AF HCRKIABIE SHIMC KD LFEAILA
And the following key from a novel:
The snow lay thick on the steps and the snowflakes driven by the wind
looked black in the headlights of the cars.
WHAT IS THE ENCRYPTION ALGORITHM?
My friend, a computer science student, says I should easily solve this,
however I still can't determine what the algorithm is.
A simple subsitution was used, supposedly.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: 24 Sep 2000 15:43:25 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in <8ql10a$k8p$[EMAIL PROTECTED]>:
>Um considering the fact that all the differences occur in parallel yeah
>it's very bad in fact all of the bits in parallel are linearly
>correlated. However, (big however) the linear mixing phase of Serpent
>ensures that such parallisms do not hold with high probability at all.
>
>Obviously parallel distinct independent sboxes would be better for
>serpent but at a huge cost in performance and you *still* need the
>diffusion step. So Serpent is a very sound and careful design.
>
>
Um considering the fact all, and you come from over in performance and we
knowed about them once-- you'll see. Go for
serpent but at the river a-fishing, big however the river a-fishing, big
however the lunch and took a huge cost in and went over
in performance and went over in performance and careful design. So Serpent
is a lunch, big however the lunch, but at all kings
are linearly correlated. However, and raise whoopjamboreehoo. There, how
you *still* need the diffusion step. Obviously
parallel yeah it's very bad in and careful design.
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: Big CRC polynomials?
Date: 24 Sep 2000 15:47:17 GMT
[EMAIL PROTECTED] (Tom St Denis) wrote in <8ql6dm$pqb$[EMAIL PROTECTED]>:
>Um are you just a troll or what? When I send a checksum it's much
>easier for the checksum to be faked then a CRC. If you want data
>integrity use a CRC32 or a hash function.
>
Um are you please. If you want data integrity use a checksum to turn into a
troll or madly squeeze a most provoking thing when
he knows it teases. If you please. If you want data integrity use a CRC32
or a CRC32 or madly!
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: Simon Johnson <[EMAIL PROTECTED]>
Subject: LFSR as a passkey hashing function?
Date: Sun, 24 Sep 2000 15:59:14 GMT
Say we take a 128-bit primitive polynomial mod 2 and covert it to an
LSFR. If we want to store a 128-bit passkey for a 128-bit key
encryption algorithm, for example, we would enter the key as the
initial state of the register. We then clock it 128 times, to clear out
the passkey. Then we clock it a futher 128-bit times, and record this
bit sequence as the hash. Any problems with this design?
Simon
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: Again a topic of disappearing e-mail?
Date: Sun, 24 Sep 2000 16:14:27 GMT
In article <8qjgev$utf$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Matthew Skala) wrote:
> In article <[EMAIL PROTECTED]>,
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >requires email tracing. Meanwhile, privacy advocates applaud
> >the new software. One oil executive says he uses a beta version
> >of SafeMessage to prevent rivals from accessing his messages.
>
> An oil executive, huh? Sounds reptilian to me.
> --
> Matthew Skala
> [EMAIL PROTECTED] I'm recording the boycott
industry!
> http://www.islandnet.com/~mskala/
>
>
Store you're stuff on floppy disk...... You can quickly destroy the
media if nessary. I find a blender the best techinque :)
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Sun, 24 Sep 2000 16:22:12 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] (Tom St Denis) wrote in
<8ql10a$k8p$[EMAIL PROTECTED]>:
>
> >Um considering the fact that all the differences occur in parallel
yeah
> >it's very bad in fact all of the bits in parallel are linearly
> >correlated. However, (big however) the linear mixing phase of
Serpent
> >ensures that such parallisms do not hold with high probability at
all.
> >
> >Obviously parallel distinct independent sboxes would be better for
> >serpent but at a huge cost in performance and you *still* need the
> >diffusion step. So Serpent is a very sound and careful design.
> >
> >
>
> Um considering the fact all, and you come from over in performance
and we
> knowed about them once-- you'll see. Go for
> serpent but at the river a-fishing, big however the river a-fishing,
big
> however the lunch and took a huge cost in and went over
> in performance and went over in performance and careful design. So
Serpent
> is a lunch, big however the lunch, but at all kings
> are linearly correlated. However, and raise whoopjamboreehoo. There,
how
> you *still* need the diffusion step. Obviously
> parallel yeah it's very bad in and careful design.
Um how do you make a cipher without diffusion?
What the hell are you talking about? Real ciphers can't use sboxes
over 8x8. Real ciphers are fast and secure. Show me how serpent fails
to achieve those goals? It's small, fast, secure and takes little
memory. Your cipher on the other hand is big, slow, for the most part
trivially useless.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Big CRC polynomials?
Date: Sun, 24 Sep 2000 16:23:52 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] (Tom St Denis) wrote in
<8ql6dm$pqb$[EMAIL PROTECTED]>:
>
> >Um are you just a troll or what? When I send a checksum it's much
> >easier for the checksum to be faked then a CRC. If you want data
> >integrity use a CRC32 or a hash function.
> >
>
> Um are you please. If you want data integrity use a checksum to turn
into a
> troll or madly squeeze a most provoking thing when
> he knows it teases. If you please. If you want data integrity use a
CRC32
> or a CRC32 or madly!
Hahahahah that's so funny.
Anyways....
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: LFSR as a passkey hashing function?
Date: Sun, 24 Sep 2000 16:23:02 GMT
In article <8ql8cb$rte$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> Say we take a 128-bit primitive polynomial mod 2 and covert it to an
> LSFR. If we want to store a 128-bit passkey for a 128-bit key
> encryption algorithm, for example, we would enter the key as the
> initial state of the register. We then clock it 128 times, to clear
out
> the passkey. Then we clock it a futher 128-bit times, and record this
> bit sequence as the hash. Any problems with this design?
Not really except the fact that I can step it backwards and find your
passkey :-)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What make a cipher resistent to Differential Cryptanalysis?
Date: Sun, 24 Sep 2000 16:30:03 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> [EMAIL PROTECTED] (Tom St Denis) wrote in
<8ql10a$k8p$[EMAIL PROTECTED]>:
>
> >Um considering the fact that all the differences occur in parallel
yeah
> >it's very bad in fact all of the bits in parallel are linearly
> >correlated. However, (big however) the linear mixing phase of
Serpent
> >ensures that such parallisms do not hold with high probability at
all.
> >
> >Obviously parallel distinct independent sboxes would be better for
> >serpent but at a huge cost in performance and you *still* need the
> >diffusion step. So Serpent is a very sound and careful design.
> >
> >
>
> Um considering the fact all, and you come from over in performance
and we
> knowed about them once-- you'll see. Go for
> serpent but at the river a-fishing, big however the river a-fishing,
big
> however the lunch and took a huge cost in and went over
> in performance and went over in performance and careful design. So
Serpent
> is a lunch, big however the lunch, but at all kings
> are linearly correlated. However, and raise whoopjamboreehoo. There,
how
> you *still* need the diffusion step. Obviously
> parallel yeah it's very bad in and careful design.
Ok my previous reply was a bit heated... let's view the pros and cons
pros: Really small cipher, really fast cipher, really simple cipher
cons: Linearly correlated functions
Is that a problem? Um not really. There is a linear diffusion step
that destroys the paralism. Chances are very good that you can't
exploit the linear correlation between the 4x4 sbox usages.
Look at Twofish, similar idea. You can precompute the MDS/sboxes to
get 4 GF mults at once (using four look ups), to me that seems like a
good design.
Look at DES, you can do the luts in parallel, and the P-box diffuses
the bits.
I have yet to see your attack on Serpent, Twofish or DES that's faster
then brute force. In fact you have yet to attack any cipher.
I on the other hand have attacked several ciphers, I have a clue about
cipher design (although lots to learn still) and don't publicly
belittle others.
Can you behave more civil please?
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Simon Johnson <[EMAIL PROTECTED]>
Subject: Re: LFSR as a passkey hashing function?
Date: Sun, 24 Sep 2000 16:32:08 GMT
In article <8ql9oo$tgt$[EMAIL PROTECTED]>,
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <8ql8cb$rte$[EMAIL PROTECTED]>,
> Simon Johnson <[EMAIL PROTECTED]> wrote:
> > Say we take a 128-bit primitive polynomial mod 2 and covert it to
an
> > LSFR. If we want to store a 128-bit passkey for a 128-bit key
> > encryption algorithm, for example, we would enter the key as the
> > initial state of the register. We then clock it 128 times, to clear
> out
> > the passkey. Then we clock it a futher 128-bit times, and record
this
> > bit sequence as the hash. Any problems with this design?
>
> Not really except the fact that I can step it backwards and find your
> passkey :-)
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>
Ooops :) -> How, may i ask?
--
Hi, i'm the signuture virus,
help me spread by copying me into Signiture File
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: RSA occasional failure?
Date: Sun, 24 Sep 2000 09:41:38 -0700
Mark-Jason Dominus wrote:
> But Fermat's theorem only applies in this case if x is not a multiple
> of p; if x is a multiple of p then x^(p-1) (mod p) might be something
> other than 1.
Correct, so an extra argument is needed in that case (the way
you have phrased it). Even tho x^(p-1) (mod p) might be something
other than 1, x^p (mod p) is always x.
> Since x is the plaintext, it is chosen by someone who doesn't know p
> or q. It seems that if x unfortunately turned out to be a multiple of
> p, then the decryption process would fail and yield a gibberish
> result.
If x is a multiple of p, your argument shows that (x^e)^d = x (mod q).
It only remains to see that both sides are 0 (mod p), and everything
is ok.
> How is this avoided in practice? Or did I get something wrong?
As others pointed out, it is rare and would only happen is someone
knew your private key.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Cryptography Challenge
Date: Sun, 24 Sep 2000 16:37:44 GMT
In article <Nqpz5.14394$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Buster Brown) wrote:
> Hi All,
>
> Would any of you have read Talking to Strange Men, by Ruth Rendell.
> Supposedly this novel contains an encryption method that escapes me.
>
> The encryption method uses as key the first sentence of an agreed
upon
> novel.
>
> For example:
>
> Given the following cipher-text:
>
> SIDKHKDM AF HCRKIABIE SHIMC KD LFEAILA
>
> And the following key from a novel:
>
> The snow lay thick on the steps and the snowflakes driven by the wind
> looked black in the headlights of the cars.
>
> WHAT IS THE ENCRYPTION ALGORITHM?
>
> My friend, a computer science student, says I should easily solve
this,
> however I still can't determine what the algorithm is.
> A simple subsitution was used, supposedly.
If CASE doesn't MaTTER then TrY to just add (mod 26) the alphabetical
characters... for example
'T' + 'S' = 'K' (I think)
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: LFSR as a passkey hashing function?
Date: Sun, 24 Sep 2000 16:40:18 GMT
In article <8qlaa8$u4v$[EMAIL PROTECTED]>,
Simon Johnson <[EMAIL PROTECTED]> wrote:
> In article <8ql9oo$tgt$[EMAIL PROTECTED]>,
> Tom St Denis <[EMAIL PROTECTED]> wrote:
> > In article <8ql8cb$rte$[EMAIL PROTECTED]>,
> > Simon Johnson <[EMAIL PROTECTED]> wrote:
> > > Say we take a 128-bit primitive polynomial mod 2 and covert it to
> an
> > > LSFR. If we want to store a 128-bit passkey for a 128-bit key
> > > encryption algorithm, for example, we would enter the key as the
> > > initial state of the register. We then clock it 128 times, to
clear
> > out
> > > the passkey. Then we clock it a futher 128-bit times, and record
> this
> > > bit sequence as the hash. Any problems with this design?
> >
> > Not really except the fact that I can step it backwards and find
your
> > passkey :-)
> >
> > Tom
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>
> Ooops :) -> How, may i ask?
Well consider the four bit LFSR x0..x3, with a feedback x0^x3 we get,
with
x0 = x0^x3
... rotate bits ...
x0 = x0^x3
... rotate bits ...
You can invert it by rotating the opposite direction and xor'ing again.
I think that would work...
All LFSR's have predecessor states and they are linear so there should
be a nice inverse...
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Date: Sun, 24 Sep 2000 19:03:25 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
> >
> >"SCOTT19U.ZIP_GUY" wrote:
> >> If your "STATIC HUFFMAN TREE IS SECRECT" then having
> >> a EOF symbol still sucks. I am not saying finding the tree is
> >> easy it may be very hard. But still the EOF symbol is likely
> >> to be the longest symbol and the last symbol. Why use it at
> >> all. But if you can't see a reason then by all means you can
> >> use it.
> >
> >Since the whole tree is unknown, how does the opponent
> >identify the eof, even if he knows it is longer than
> >the rest?
>
> Gee I guess he looks at the end of file for a clue
What kind of clue?? Please show an example.
>
> >BTW, does your program deals with also word or block
> >boundary in addition to byte boundary?
> Check my site out. I doubt you would belive me if I told
> you so I will not.
If you wouldn't provide that simple information, it
means either the answer is no or you yourself don't
know that exactly.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Date: Sun, 24 Sep 2000 19:08:22 +0200
"SCOTT19U.ZIP_GUY" wrote:
>
> [EMAIL PROTECTED] (Mok-Kong Shen) wrote:
> >"SCOTT19U.ZIP_GUY" wrote:
> >> I am surprised you took back anything it must be a trick.
> >> But the answer above is obvious. when he said 32 he was referring
> >> to a afactor of 32 which for 5 bits is 32 = 2*2*2*2*2 in short
> >> two to the the power 5. But you must known that just as you must
> >> know that haveing an EOF symbol in a compresson of huffman or
> >> arithmetic type before the file is encrypted is a mistake.
> >
> >It was indeed my error in employing the zero fill in
> >the argument I gave, for that provides known information.
> >If I had written '5 random bits' instead, then everything
> >would have been o.k.
> >
> >Using eof in a secret Huffman scheme is not a mistake, as
> >I argue in a parallel follow-up.
> >
>
> I can see that for you use of an EOF is not a mistake.
> But it is still stupid waste of space.
Here was exactly my argument. If the percentage is
extremely small, it is negligible and doesn't warrant
to give any thought for improvement. Do you care
whether an article in shop costs 100 Dollars or 99.99?
M. K. Shen
------------------------------
** 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
******************************
