Cryptography-Digest Digest #102, Volume #10 Tue, 24 Aug 99 07:13:03 EDT
Contents:
Re: How Easy Can Terrorists Get Strong Encrypt? (Eric Lee Green)
Re: The Reversal of NetNanny (Eric Lee Green)
Re: Quadibloc VI Taking Shape
Re: One-time pad encryption. (Tom St Denis)
RE: MUM (Gary)
Re: Blowfish algorithm - Is it full proof? ("Bruce Christensen")
Standarts documents and sample code ... (JAVA) (Stefan Dobrovolny)
Re: Crypto 1981-1997 CD-ROM fix (Eric Hambuch)
Re: How Easy Can Terrorists Get Strong Encrypt? (David A Molnar)
Re: One-time pad encryption. (Tony L. Svanstrom)
Re: question regarding number of keys possible. . . (John Savard)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
----------------------------------------------------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: How Easy Can Terrorists Get Strong Encrypt?
Date: Mon, 23 Aug 1999 22:24:55 -0700
Tom St Denis wrote:
> BTW, does anybody actually read his posts for intellectual content or
> do they get a good chuckle as well?
I tend to skip them, because they are invariably whines about how he's
being maltreated by the Crypto God Conspiracy Who Are All In Cahoots
With The NSA. On the other hand, I do occasionally get a tidbit of
information out of his messages, though sometimes not what he intended.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: The Reversal of NetNanny
Date: Mon, 23 Aug 1999 22:39:32 -0700
Keith A Monahan wrote:
> It's nice to see practical real world application of all this theory
> we talk about soo much here.
Interestingly enough, it was similar reverse-engineering (though not to
such good purposes) which led me to the knowledge that the weakness of
cryptography is not the algorithms themselves, but, rather, the systems
into which they are embedded. That is the hard part -- key distribution,
making sure keys aren't left lying around on disk, erasure of cleartexts
in a way such that they cannot be easily recovered, etc. I'll let Bruce
and etc. handle the math part, thank you.
I recently wrote a license manager. I came to the conclusion, based on
my experience, that the bogons will break it anyhow since they have
direct physical access to the code on both sides of the connection, so I
did not bother using strong encryption. Just a case of knowing where
cryptographic techniques get you benefit, and where they don't --
MD5'ing the contents of the license file (with a semi-secret added in)
was enough to keep the script kiddies out, while not irritating the real
elite too badly. Doing full 256-bit TwoFish would have just been a waste
of execution time here.
--
Eric Lee Green http://members.tripod.com/e_l_green
mail: [EMAIL PROTECTED]
^^^^^^^ Burdening Microsoft with SPAM!
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Quadibloc VI Taking Shape
Date: 24 Aug 99 05:09:59 GMT
[EMAIL PROTECTED] wrote:
: At
: http://www.ecn.ab.ca/~jsavard/co040709.htm
: is a description of Quadibloc VI
A variant with 16 regular rounds (from one point of view, only four
rounds) instead of eight is now described, and an additional error in the
key schedule is fixed.
John Savard
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: One-time pad encryption.
Date: Tue, 24 Aug 1999 05:50:10 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Tony L. Svanstrom) wrote:
> My reasoning is that using the OTP twice shouldn't weaken this based
on
> the fact that the second time it's being used it's used on a "text"
that
> has been randomly picked and that contains no words or any other
> information that could be compared to the known to be a text part of
the
> message (where the known to be text-part has been located by knowing
the
> basic structure of this method).
A OTP is a RNG that is xor'd against the plaintext/ciphertext to
encrypt/decrypt. If you ever ever ever reuse the RNG output it is no
longer random, and no longer a OTP. That simple.
> Is this the best possible way to implement OTP in a everyday situation
> where you want to send secure messages?
The best way to use a OTP is not too.... The OTP is so impractical
that I haven't heard of any major crypto program that even thinks of
it...
Tom
--
PGP 6.5.1 Key
http://mypage.goplay.com/tomstdenis/key.pgp
PGP 2.6.2 Key
http://mypage.goplay.com/tomstdenis/key_rsa.pgp
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Gary <[EMAIL PROTECTED]>
Subject: RE: MUM
Date: Tue, 24 Aug 1999 04:29:02 -0400
Nice crack, I really need to brush up on me linear algebra :)
Gary
>===== Original Message From [EMAIL PROTECTED] (David Wagner)
=====
>A clever idea, but this can be easily cracked.
>
>Write Sa = A + mL, where m is an integer and LC = 0. Given SaC and C,
>we can solve for an A of this form with linear algebra (but we can't find L).
>
>Similarly write Sb = B + nR, where CR = 0, and solve for B.
>
>Note that SaCSb = (A+mL)C(B+nR) = ACB + nACR + mLCB + nmLCR = ACB, by
>the choice of L and R. (For example, nACR = nA(CR) = nA(0) = 0.)
>
>In other words, to derive the session key, we only need to know A and B;
>the exact values of Sa and Sb don't matter. But A and B are easily
>calculated by a passive eavesdropper. Therefore, the protocol is insecure.
>
>
>
>
>In article <[EMAIL PROTECTED]>, Gary <[EMAIL PROTECTED]> wrote:
>> Let [Sa], [Sb] and [C] be 2X2 Matrices (Mod 2 to the power of 32).
>> (Each matrix is 128 bits long)
>>
>> Let [Sa] and [Sb] be invertible.
>> (Determinants not equal to 0 and odd (relatively prime to 2 to the power of
>> 32))
>> Let [C] be uninvertible.
>> (Determinant equal to 0)
>>
>> [Sa] & [Sb] are generated using 128 bit random numbers.
>> They can be re-chosen until passes invertible check.
>> [C] uses 2 randomly generated 32 bit numbers. Their product is factorised.
>> This is used to create the 2 other 32 bit numbers to yield a 0 determinant.
>>
>> Public key sender broadcasts the pair [C][Sb] and [C].
>> (using matrix multiplication [C][Sb]=[C]X[Sb] (mod 2 to the power of 32))
>>
>> Replier sends back [Sa][C].
>>
>> Both can generate [Sa][C][Sb] as a secretly shared key.
>> (Replier uses [Sa] multiplied by public key senders [C][Sb])
>> (Public key sender uses replier's [Sa][C] multiplied by [Sb])
============================================================
Get your FREE web-based e-mail and newsgroup access at:
http://MailAndNews.com and http://MailAndNews.co.uk
Create a new mailbox, or access your existing IMAP4 or
POP3 mailbox from anywhere with just a web browser.
============================================================
------------------------------
From: "Bruce Christensen" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.clipper,comp.security.misc,alt.politics.clinton
Subject: Re: Blowfish algorithm - Is it full proof?
Date: Tue, 24 Aug 1999 02:34:57 -0600
Kill this thread, it does not belong in this newsgroup.
Dave Hazelwood <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ha ha. I guess you just don't get it? Look all over the net and you
> will see references to Klinton and the Klintonista's.
>
> Try any of the alt.?.clinton groups for starters.
>
> Check this out too for a laugh. Yes, he has degraded his office and
> all of us along with it so much that we can laugh at such things
> because he deserves them.
>
> http://www.geocities.com/Baja/Trails/3110/ccworld/cc06.gif
>
> Now, we are even getting in the issue of politicians using cocaine!
> How far have we fallen? The press is attacking Bush like crazy
> but what about Klinton? It is common knowledge that he is a user
> so why is the press protecting him again? Huh???
>
> As voters we need to rid Washington and all our capitols (notice I got
> the correct spelling) of this trash.
>
> This is off topic here and I apologize for that. let's move it to
> alt.politics.clinton.
>
> "Harlan Carvey, CISSP" <[EMAIL PROTECTED]> wrote:
>
> >
> >Who is this "Klinton" and why is he so evil? You seem to be referencing
> >events the President...you may not be the nut case you mention, but you
> >sure as heck can't spell.
> >
>
------------------------------
From: Stefan Dobrovolny <[EMAIL PROTECTED]>
Subject: Standarts documents and sample code ... (JAVA)
Date: Tue, 24 Aug 1999 10:36:59 +0200
Hello!
I am quite newbie in part of cryptography and I have to integrate our
software (written in JAVA) with standard softwares using public key
signing. I can use JCE library similar to SUN's, made in TU Graz (IAIK).
I want to produce senceful files usable in other party soft. products.
This library can produce PKCS formats and so on. But I don't realy
understand this standarts ..
1. Can somebody point me to the more useful docs on web? I have read
docs from RSA labs. Some example code can be the best way.
Is there some references to documents, about formats of files used by
other soft. For example: I want to create signed file (plain text and
signature in one), public key and use other soft to verify this
signature. For example Netscape, IE, PGP ...
Sorry if my message is little bit confused ... My english is not so
good :-). I will grateful for any answer.
best regards Stefan
=====BEGIN PGP PUBLIC KEY BLOCK=====
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
mQGiBDfBUKkRBADSBRDiB/VwOto0+sjUqphAmKaegsSLBBfnrMEHq2j1bJzOgwmh
RXS4vk7BZZpjP9bTIMWVFBNn2iZXljPbT+1Cn/Doqtq+l42yfREi7+pFuesItycu
P0s8N4ZqSDSK5XgSQjzpc6jQipaFmbAkLT8o4pks7xoi3Qtza6RW9XNC3QCg/+3q
Rz+QfBwxQsOaZKGCGMLKvYsD/3Wq6bxAnRZ1tarMdfNRtRWX/hbi5gD/5dtq0bRL
Lr2hr9vB1cJ2vybmS0WNS6+o7aZk7hhYXKJOSdthhtSvwzPsC3YtWqozzxb2aSlF
u964OzLnz939TPFoSR/JJEDT0b6kKso9MSsXN4lXlHvp/WapSoFTVY/h+vdxOgLv
jmgVA/9M4f4fno/EOG4yveu+mfaKVrCmqY5Pix7a7XJuNrqhCbVZEZ/PYi2Ovinx
0cBcU/cztfBefamsTjqaMi1svDxS4pmZsXLFccp+VDgL55fjZCyjv4JP0KiA+nfb
MXI3NLmjEY8IIdvfvMUJUd14wdFVytk2qbx3QP5tdG0R5ga+z7QxTWdyLiBTdGVm
YW4gRG9icm92b2xueSA8c3RlZmFuLmRvYnJvdm9sbnlAc3doLnNrPokATgQQEQIA
DgUCN8FQqQQLAwIBAhkBAAoJEMo8CuFGYaNIe3IAn3ceY1W3BzJAZjKMkRjpEtUA
P0xGAJ9ow04Yl3ZdQQGtdBU5VV/TOBLMCbkBjQQ3wVCpEAYA+PVZX9x2Uk89PY3b
zpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarTW56NoKVyOtQa8L9G
AFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kjwEPwpVsYjY67
VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnIByl6ypUM
2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpWHxHAAICBf9pV+rIzgPU
yqoVuK/eP5yLOINThWfW/u+HQg0NuNJ5OrkbFfzWJAhNGvTSRNQKlKvqa+jp6w2c
xkYGn471zKz4aFXmkL4cpa98GcQUu7bZSjGCuvo/PyT8PEq8d5D5XQYtBfva9Jkw
LLIZuxGFQcP98WpDVMigKYcXObZ1KMhpnJae/QRAqIM7+BfZoW5yxjlHEtDTrmiz
bDVDLBZ0zbprZln+d5Ugstg/7+PGefd0GjsU9mIv4jICWo4xU5ix+heJAEYEGBEC
AAYFAjfBUKkACgkQyjwK4UZho0iPjQCg5Q3Bjj4Enwsb6dO7SOapze8PBp0AnRGW
I62Ib5qr0u/uRkSWOgm8V1Zb
=OtHr
=====END PGP PUBLIC KEY BLOCK=====
------------------------------
From: Eric Hambuch <[EMAIL PROTECTED]>
Subject: Re: Crypto 1981-1997 CD-ROM fix
Date: Tue, 24 Aug 1999 10:31:32 +0200
Medical Electronics Lab wrote:
>
> lcs Mixmaster Remailer wrote:
> >
> > Springer-Verlag has now released the CD-ROM with the entire proceedings
> > of the Crypto and Eurocrypt conferences from 1981-1997. These were for
> > sale at Crypto 99 this week.
>
> How much? Can I order from Springer New York? What's the ISBN?
>
Look here:
http://www.springer.de/cgi-bin/search_book.pl?isbn=3-540-65069-5
Price: 158,-- DEM (about 75 USD ?)
ISBN 3-540-65069-5
and for EUROCRYPT 99
http://www.springer.de/cgi-bin/search_book.pl?isbn=3-540-65889-0
Eric Hambuch
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: How Easy Can Terrorists Get Strong Encrypt?
Date: 24 Aug 1999 07:39:30 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
> Can someone please do a mass kill on him? Get him out of here...
> byebye.
Why don't you put him in *your* killfile? Why do I have to deal with what
you want ?
> I would love to see two things in my crypto life
> 1) He proves his method is secure
> 2) He proves AES algorithms are weak....
Seconded.
> BTW, does anybody actually read his posts for intellectual content or
> do they get a good chuckle as well?
Tom, relative to sci.crypt I think that any post which simply speculates
on someone else's lack of "intellectual content" doesn't have any. Yours,
David's, David's, or mine.
You can take that as an invitation to define intellectual content and try
to show that David Scott's postings don't have it...but honestly, there
are **much** better things we could all be doing with our time. For
example, have you looked at the proposed anonyous membership scheme yet?
I'm sorry to go on at this length. It's just that your comment here really
ticks me off. More explanation via _e-mail_ if you happen to want it.
Please let's not continue this thread in sci.crypt .
Thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Subject: Re: One-time pad encryption.
Date: Tue, 24 Aug 1999 10:13:53 +0200
Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Tony L. Svanstrom) wrote:
> > My reasoning is that using the OTP twice shouldn't weaken this based
> > on the fact that the second time it's being used it's used on a "text"
> > that has been randomly picked and that contains no words or any other
> > information that could be compared to the known to be a text part of
> > the message (where the known to be text-part has been located by knowing
> > the basic structure of this method).
>
> A OTP is a RNG that is xor'd against the plaintext/ciphertext to
> encrypt/decrypt. If you ever ever ever reuse the RNG output it is no
> longer random, and no longer a OTP. That simple.
True; but if you ingore the exact meaning of it and simply looked upon
the situation as described by my earlier post, how would the security be
weakened (ie what possible attacks are there) based on it.
> > Is this the best possible way to implement OTP in a everyday situation
> > where you want to send secure messages?
>
> The best way to use a OTP is not too.... The OTP is so impractical that I
> haven't heard of any major crypto program that even thinks of it...
I have... no, wait... it failed on the "major" part. ;)
/Tony
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---���---���-----------------------------------------------���---���---
\O/ \O/ �1999 <http://www.svanstrom.com/> \O/ \O/
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: question regarding number of keys possible. . .
Date: Mon, 23 Aug 1999 19:25:13 GMT
[EMAIL PROTECTED] (John Savard) wrote, in part:
>[EMAIL PROTECTED] () wrote, in part:
>>Wesley Horton ([EMAIL PROTECTED]) wrote:
>>: Did anyone ever come up with an effective method of generating such
>>: wirings (interval wiring) of rotors on a computer?
>>A table of output from these programs, combined with the odd-order numbers
>>from another source, is on my web page. A link to it is present at
>>http://www.freenet.edmonton.ab.ca/~jsavard/roto02.htm
>The exact link is:
>http://www.freenet.edmonton.ab.ca/~jsavard/ro020302.htm
And, thanks to your question, I found a mistake on that page: the
number of wirings for 8-contact rotors was eight times too small.
John Savard ( teneerf<- )
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Tue, 24 Aug 1999 12:16:57 +0200
SCOTT19U.ZIP_GUY wrote:
>
> >> >> In article <[EMAIL PROTECTED]>, Mok-Kong Shen
> >> > <[EMAIL PROTECTED]> wrote:
> >> >> >
> >> >> >To be exact, you can't say how many input symbols are obtained from
> >> >> >the x's. For instance, it could be that there are Huffman codes
> >> >> >that occupies only 3 x positions. All one knows (by our assumption)
> >> >> >is that the last 9 bits of the original output file constitute one
> >> >> >single Huffman code and therefore these 9 bits will be decompressed
> >> >> >to one input character (which, if it is 8 bit ASCII, occupies a byte).
> >> >> >But this fact is unimportant for the present discussion.
> >> >> What are you thinking I thought the x's where a single token.
> >> >> Look it is obvious you are lost and don't know what I mean. PLEASE
> >> >> ASK SOMEONE ELSE FOR HELP.
> >> >
> >> >Eh?? What was wrong?? There were 7 x's, each being a bit position,
> >> >so it could well be that 3 of the bits consitute one Huffman code.
> >> >That each x represent a bit in the output file (compressed file)
> >> >should have been entirely clear to you in all the discussions up
> >> >till now!!!!!
> >> Get real the 7 x's where only one token. Your are the one who just
> >> said maybe 3 of the x's are part of a token and the 7'x could be more than
> >> one token. You don't have a clue.
> >
> >What are your understanding of a binary file????? I listed only the
> >last 2 bytes without specifying whether these are 0 or 1. The last
> >Huffman code had, by assumption, 9 bits and hence was represented
> >by 9 y's. The x's represent bits from any (unspecified) number of
> >Huffman codes. If I were to describe the last 5 bytes, I would
> >have written as follows:
> >
> > xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxy yyyyyyyy
> I realy doubt you understand what is going on but i will give it another
> shot. What you have is not necessarily the form that my program
> compresses too. There fore it might not decompress to the file
> that you expect. The reason is that my compression/decompression
> program addresses the end of file in a specail way. I have modifed
> it to be "one to one" which I have defined to you several times. But
> you still don't get it. When compressing the last huffman code may
> or may not be written out. But again you don't understand do you.
> I wish you would ask you ask what happens with real (but you can't)
> example. giive me a file as HEX like "ff 00 ff" and I will tell you what
> it compress to or decompresss to. Is this to hard for you since I see
> absoultely no other way to communicate with you since I you don't
> have the foggegst idea what i am saying. Is concrete examples to
> hard for you?
I have put much energy in a previous post to illustrate my example.
I'll repeat here, since you have evidently overlooked my essential
points. No matter what your modifications of the Huffman algorithm
at the end of input processing is, from the begining of the
compression process up to the vicinity of (not including) the end
part of the input file you are certainly following the normal
(unmodified) Huffman algorithm, aren't you??? (If not, please
clearly say so!!) Now let's say we have already encoded n input
symbols according to the normal (unmodified) Huffman algorithm and
the bits obtained till present can be represented as follows:
........ xxxxxxxx xxxxxxxx xxxxxxx
where .... represent some bytes and the first 16 x's here are bits
occupying two bytes and the following 7 x's are bits occupying the
following byte which at this time point is not yet full, there being
one bit position free. (All these bits come from encoding the n
input symbols. Nothing(!) is said about which Huffman codes occupy
which positions in the ensemble of bit sequences denoted above.)
Now the process comes to encode the n+1 th input symbol. By my
assumption this symbol has a Huffman code of 9 bits, so afterwards
we have
........ xxxxxxxx xxxxxxxx xxxxxxxy yyyyyyyy
To be concrete, let's assume a specific Huffman code, so we have
a situation like this
........ xxxxxxxx xxxxxxxx xxxxxxx0 10110010
By assumption of my example this n+1 th symbol terminates the input
file. Thus the output bits from the (normal) Huffman scheme exactly
fills the last byte, the last output bit is (in our special case)
exactly at the byte boundary. Now I repeat also the questions I asked
in a previous follow-up: Are you (with your modifications of the
Huffman algorithm) going to append anything to the output file,
i.e. add something after the bit sequence shown above??? (If yes,
please say that and explain why!! I am convinced that it would be
foolish if you would add anything in this case to the bits already
obtained. You said you want to have the compressed file as short as
possible and not to have any waste, didn't you?) Are you going to
delete anything from the above sequence??? (If yes, please say that
and show those bits that you delete!! I am convinced that you
couldn't do any deletion. The reason is that there could be another
possible Huffman code that also has 9 bits, e.g. 0 10110011. If you
delete any of the bits occupying the last byte shown above, you
wouldn't be able, on decompressing, to correctly recover the original
file, because the program wouldn't know whether the last symbol of
the input file is the one corresponding to 0 10110010 or the one
corresponding to 0 10110011 or something else. This is exactly
because the Huffman code has the so-called prefix property.) Now,
assuming that your answers to the above two questions are 'no', it
follows that the output file is EXACTLY as given above, there being
neither additions nor deletions, even though in your modifications
of the Huffman algorithm there are certain mechanisms that could
append or delete bits at the end of the output file in certain more
general situations. In other words, I have 'purposedly' constructed
my example in such a way that the mechanisms provided in your
modifications don't get activated in my special case. Is the above
now finally very clear to you??? If not, please kindly indicate
which point or points I have not clearly stated or what is exactly
wrong in the lines I have written above!!
Now assuming that you have no counter-arguments to my claim above
that the end of a correct output (compressed) file can be of the
form shown above, I'll construct a 'wrong' file by simply deleting
the last byte of the 'correct' file. So the bit sequence of the
'wrong' file is as follows:
........ xxxxxxxx xxxxxxxx xxxxxxx0
Do you agree?? Assuming 'yes', let's start at the SAME time two
Huffman decompression processes, one working on the 'correct' file
and the other working on the 'wrong file', and compare step by step
what they are doing. Evidently for processing the bits represented by
........ xxxxxxxx xxxxxxxx xxxxxxx
both processes do exactly the same, i.e. both decoding to the same
n input symbols, as expected. Now both processes pick up a 0 bit.
But 0 alone is not a valid Huffman code, because by our assumption
the 9 bits 0 10110010 constitute a valid code and hence (due to
the prefix property of the Huffman code) any valid code beginning
with 0 must have a length longer than 1. (Do you agree??) Now let's
see what the two processes presently continue to do. The process
handling the 'correct' file goes on to pick up further bits. It does
not find a valid code until it picks up 8 more bits in our example.
(Do you agree??) At this time point it can decode the whole bunch
of 9 bits and obtain the n+1 the symbol of the original input file.
It has done its job correctly and, since the end of the file being
processed is reached, it terminates entirely normally. Am I right??
Now examine closely what the other process which handles the 'wrong'
file will do!! (Please kindly pay attention here, because this is
the CENTRAL point of our dispute!) Like the first process it has
picked up the 0 bit. Because 0 alone is not a valid code (as
explained above), it similarly wants to pick up more bits in order
to obtain a valid code so that it can decode. But unfortunately it
can't do that because it has reached the end of the file processed
by it and there are no more bits available. Now what should this
process do??? According to normal software engineering practices,
the program should be written such that in such a situation an
error message is given to the user, saying that the process
has encountered a premature (unexpected) end of file without being
able to complete its work normally, and possibly also showing a
certain number of the the last bits that had been processed (a dump
in common jargon) at that time point with the exact reason (or an
error code) why it was unable to terminate normally. Now in a
previous follow-up, you said that in this case one simply gets on
decompression a file that is one byte less than the original input
file. (You remember that??) But what does THIS assertion of yours
mean??? It is MY understanding that this clearly means that you
have written your program in such a way that, if it ever encounters
situations like what I have described above, it simply terminates
quietly without giving any error message to the user. (If I am wrong
here, please clearly say so and in particular detail what the
behaviour of your program exactly is in the above situation!!
But remember what I have just cited from your previous post!) That
means your program fails to report abnormal situations (at least
the one situation I sketched). Am I right????? Now, coming back to
arguments further back in this discussion thread, you claimed that
your program has been designed (through your modifications to the
Huffman algorithm) such that, even if it is fed with wrong files,
the decompression does not lead to any abnormalities (which you
said could be effectively utilized by the analyst to determine
whether he has used the correct key in decryption or not). But,
as I have shown, your program simply suppresses the error message
that it should have reported according to basic requirments of
software engineering. This is however entirely different from the
question of whether abnormalities CAN be detected or not by the
analyst. If your program (purposedly) suppresses the error message,
it does not serve any useful purpose. The analyst is certainly not
an unintelligent guy. He can either write a program himself
(incorporating also your modifications to the Huffman algorithm),
but does not suppress the error message, or else does some trivial
fixes to your program for that.
Now I have expanded what I wrote previously very very much and every
line should be, I am almost convinced, crystal clear to you in
meaning presently. (Should it nevertheless not be case, please say
so!) Now tell me in which point I am mistaken!!!!! Please take time to
write your response in a clear-cut way and as unambigiously as I have
done above. Don't simply argue that one has to run your program and
see what comes out of that, because (1) the above arguments evidently
can be excercised very trivially with paper and pencil alone and
(2), what is more important, we are in fact arguing here whether your
program is correct. (One can't utilize the output of a program to
prove the correctness of that very same program. Am I right??)
The ball is now at your side! Please be kind engough not to employ
'sentimental' phrases or words that are, according to my humble
knowledge, not generally deemed appropriate for scientific
discussions. To presuit scientific investigation is to attempt to
find the truth, no more and no less. One can and should do it with
a 'cooled' state of the mind and be as patient as possible.
Otherwise, everything would be rendered obscure by 'subjectivity'
and one does not achieve the goal that one wants to arrive at.
In short, please don't throw in sentences that are (by nature of
the topic) not relevant to (and hence don't help) the process of
truth finding. Thank you very much beforehand.
[ To the general readers of this thread I apologize for having
written the above stuffs in a very very 'lenghty' way and repeated
a lot of what was contained in previous follow-ups. But I hope that
it is understandable that I have barely any alternative way of
properly carrying on the present discussion, given the situation
as it currently is. ]
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
******************************
