Cryptography-Digest Digest #68, Volume #13 Wed, 1 Nov 00 13:13:00 EST
Contents:
Re: BENNY AND THE MTB? (James Felling)
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: A new paper claiming P=NP (Timothy Chow)
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: BENNY AND THE MTB? (SCOTT19U.ZIP_GUY)
Re: Is RSA provably secure under some conditions? (John Myre)
Re: 3-dimensional Playfair? (Mok-Kong Shen)
Re: RSA Multiprime (Francois Grieu)
Re: A new paper claiming P=NP (Eric Cordian)
Emacs hack for OpenSSL encryption (David Rush)
Re: frequency analysis (JPeschel)
Re: Is RSA provably secure under some conditions? (SCOTT19U.ZIP_GUY)
Re: BENNY AND THE MTB? (Richard Heathfield)
Re: Give it up? (Tom St Denis)
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Date: Wed, 01 Nov 2000 10:22:37 -0600
Richard Heathfield wrote:
> Tim Tyler wrote:
> >
> > Richard Heathfield <[EMAIL PROTECTED]> wrote:
> > : "SCOTT19U.ZIP_GUY" wrote:
> >
> > :> They are still laughing when they get the first message to
> > :> decyrpt. Since it is only a byte long. Some of the boys don't
> > :> even want to try to turn the quantum computer on. One byte they
> > :> say. How many possible messages could that decrypt to.
> >
> > : 2^CHAR_BIT
> >
> > : In other words, usually 256.
> >
> > A better upper bound would be 2^KEY_BIT - i.e. approx 2^128 in this
> > context.
> >
> > This figure may contain a few duplicated messages under different keys.
<snip>
given Pi= D(M,Ki) then given M is fixed. the space of possible P's is going
to be roughly equivalent in size to the space of possible K's. Yes there may
be some duplicate encryptions, and most of them will be nonsense, BUT there
will be a valid decryption in every case.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BENNY AND THE MTB?
Date: 1 Nov 2000 16:28:53 GMT
[EMAIL PROTECTED] wrote in <8tp9rp$tqd$[EMAIL PROTECTED]>:
>Whether you like it or not, no matter how good your bijective compressor
>with any AES or your own scott19 cipher...you are still dependent on a
>PK cryptosystem like RSA to cover your tracks...Try and answer that
>one...If MTB can lick your RSA key and get your session key...your
>cipher is worthless...no matter how good it is... Well start thinking
>about that then...
>
You are absoultely correct. If your dependent on a Public Key
crypto system to communiacate to a stranger where you can't exchange
keys in public. Your are at the mercy of the tecknique used for
the public key encryption like RSA. But It like driving a car if
your car has firerstone tires ( the bad ones) and you have to wait
months to get safe ones. Should you drive with out your seat belts
since if the tires blows and you in a vehicle with the proven rolloiver
factor of a two wheel drive ford explorer you have a good chance of
dying. No you should do what one can do to reasonablely protect ones
self. Maybe some day there will be safe public key encryption. Does
that mean we ignore what we can do correctly now.
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:
------------------------------
Crossposted-To: comp.theory,sci.math,sci.op-research
Subject: Re: A new paper claiming P=NP
From: [EMAIL PROTECTED] (Timothy Chow)
Date: Wed, 01 Nov 2000 16:25:52 GMT
In article <caNL5.196$If6.8753@insync>,
Eric Cordian <[EMAIL PROTECTED]> wrote:
<In comp.theory Timothy Chow <[EMAIL PROTECTED]> wrote:
<
<>>The people supposedly giving the prize made a not-quite-trivial mistake
<>>regarding Poincare's Conjecture on their site.
<
<> What is this mistake?
<
<One mistake is that while the .pdf file correctly describes the
<conjecture, the layman's blurb incorrectly describes it to be a
<demonstration that S(3) is simply connected.
It looks to me that the layman's blurb asks, "Does simple connectivity
*characterize* the 3-sphere?" This may be slightly more sloppy than
asking, "Is S^3 the only compact simply-connected 3-manifold?" but is
not really "incorrect."
--
Tim Chow tchow-at-alum-dot-mit-dot-edu
The range of our projectiles---even ... the artillery---however great, will
never exceed four of those miles of which as many thousand separate us from
the center of the earth. ---Galileo, Dialogues Concerning Two New Sciences
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: BENNY AND THE MTB?
Date: 1 Nov 2000 16:45:32 GMT
[EMAIL PROTECTED] (Richard Heathfield) wrote in
<[EMAIL PROTECTED]>:
>Tim Tyler wrote:
>>
>> Richard Heathfield <[EMAIL PROTECTED]> wrote:
>> : "SCOTT19U.ZIP_GUY" wrote:
>>
>> :> They are still laughing when they get the first message to
>> :> decyrpt. Since it is only a byte long. Some of the boys don't
>> :> even want to try to turn the quantum computer on. One byte they
>> :> say. How many possible messages could that decrypt to.
>>
>> : 2^CHAR_BIT
>>
>> : In other words, usually 256.
>>
>> A better upper bound would be 2^KEY_BIT - i.e. approx 2^128 in this
>> context.
>>
>> This figure may contain a few duplicated messages under different keys.
>
>(That's what I like about Mr Scott. Despite his best efforts, useful
>information sometimes results from his articles.)
If you would learn to read what is trying to be communicated
you would know that my gaol is to get people to think instead of
swallowing suger coated lies from others. I realize Mr tyler is
far my patetient than I am with people who I think are lying and
trying to confuse new people learning. I think cyprto on this site
has many messages that are just plain sugar coated shit. I guess
people find that kind of BS easier to take.
>
>Now, Mr Tyler, you have succeeded in engaging my interest. Please
>remember that, although I like to flatter myself that I am quite bright,
>I am nevertheless no mathematician - and that, as you know, is a great
>defect. I am of the rather simple-minded and foolish opinion that one
>octet (if we can both use that word unambiguously?!) can contain any one
>of 256 different possible values. Now, I am quite prepared to accept
>that there may well be a 128-bit key lurking in Bob's drawer, which he
>can apply to this octet in, no doubt, arcane and mystical ways, but I do
>not understand how Alice's octet can communicate anything to Bob except
>in the following ways:
While I am pracatically a mathematican I was on a acedemic shloarship
when in college for math. The problem is in this backward country
math is in the liberal arts deparmetn of the university and to be
a mathematican you don't really take or study much math you need
more socail sicences and english crap. So if ones strong point is
math you swtich and end of second year to electrical engineering
in my case the study of fields and waves. that way you get more
more class then someone getting a degree in mathematics.
>
>256 different bit patterns
>fact of transmission
>time/date of transmission
>pattern of prior and subsequent transmissions
>similar traffic-related information
>
>I think we have to disregard all of those except the first, since we
>cannot objectively and portably discuss the other ways (or am I wrong
>about that?).
>
So far so good.
>
>So, Mr Tyler - I recognise you to be a regular contributor to this
>newsgroup, and a man who is capable of stringing together entire
>paragraphs of highly useful, informed, and intelligible information,
>without feeling the need to resort to expletives and oddball accusations
>of deceit and incompetence. Since I cannot conclude from this profile
>that you are necessarily mistaken, it follows that I am probably
>mistaken, and must have misunderstood something. I would, therefore,
>appreciate enlightenment from you (or from some other comparably clueful
>and polite source of information) with regard to this messagespace
>question.
>
>
I did not answer more since though Tim and I are totally different
people and don't see eye to eye on many things. I realize that he is
one of the few who has a grasp of what is going on. So I have to admit
you will learn far more from him than me. I also suspose Mr BS and
Wagner are not as dumb as they prestend on this subject. But my
understanding is Mr BS has great hate for me and so I doubt he would
give a honest opinion of the topic other than to discourage you.
He might have one od his attack dogs make so lying misleading
comments about it though. As Mr Wagner did when I publicly stated
scott19u was dead by his slife attack. Of course it was a fucking
lies as others tried it on mine. But that still marked it as snake
oil in the acedemic world where they want to only pat each other on
the ass.
But to be fair it may be that MR BS is under some constrants by
certain groups of my government. But again I state you will learn
more form Tims commesnt. I think he writes some what better than me.
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: BENNY AND THE MTB?
Date: 1 Nov 2000 16:55:28 GMT
[EMAIL PROTECTED] (James Felling) wrote in
<[EMAIL PROTECTED]>:
>
>
>Richard Heathfield wrote:
>
>> Tim Tyler wrote:
>> >
>> > Richard Heathfield <[EMAIL PROTECTED]> wrote:
>> > : "SCOTT19U.ZIP_GUY" wrote:
>> >
>> > :> They are still laughing when they get the first message to
>> > :> decyrpt. Since it is only a byte long. Some of the boys don't
>> > :> even want to try to turn the quantum computer on. One byte they
>> > :> say. How many possible messages could that decrypt to.
>> >
>> > : 2^CHAR_BIT
>> >
>> > : In other words, usually 256.
>> >
>> > A better upper bound would be 2^KEY_BIT - i.e. approx 2^128 in this
>> > context.
>> >
>> > This figure may contain a few duplicated messages under different
>> > keys.
>
><snip>
>given Pi= D(M,Ki) then given M is fixed. the space of possible P's is
>going to be roughly equivalent in size to the space of possible K's.
>Yes there may be some duplicate encryptions, and most of them will be
>nonsense, BUT there will be a valid decryption in every case.
>
>
And by valid it means that if that nonsense looking message was
the actaul message. When ran though Matt program to be encrypted it
goes back to that same message. The whole idea of a fully bijective
compression encryption packaage is that every key works equally as
well. But this is not possilbe with the compression encryption
setup used in something like PGP since even if a random file is
compressed and encrypted it is very like only one such key
exists that is valid in that you could decrypt with it and reencrypt
it back it the same encrypted file.
anyway in case it is not obvious. i AGREE WITH YOU. Sometimes
for what ever reason people think I am arguing when I agree.
But many times when I agree people still get the wrong idea of
what I am agreeing to.
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: John Myre <[EMAIL PROTECTED]>
Subject: Re: Is RSA provably secure under some conditions?
Date: Wed, 01 Nov 2000 09:56:03 -0700
Shai Halevi wrote:
><snip>
> Our experience from everyday life, tells us that usually there isn't
> much else you can do with such code. Sure, you can take the code, view
> it as a bit string, and hash it, or do whatever, but that will not give
> you anything particularly useful. Problem is, we do not understand this
> phenomena. Why is it that for "natural" systems, seems like the only
> sensible thing to do with the code is to run it? What property do
> "natural" systems have, that renders any other form of processing the
> code useless for an adversary.
<snip>
I think this is a reasonable insight, but it puts me in mind
of the opposite perspective: what useful things can we do if
the code is more data-like? The LISP and AI folks have worked
on this a lot, and gotten some quite interesting results. Did
you ever encounter "Godel, Escher, Bach", by Hofstadter?
(I wonder if this means I should be wary of cryptosystems that
are implemented in LISP?)
JM
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: 3-dimensional Playfair?
Date: Wed, 01 Nov 2000 18:08:16 +0100
Daniel wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >
> >Has Playfair ever been (in modern times) practically applied
> >to an alphabet of 256, i.e. 8-bit values? I am just curious.
> There are a few problems with a 256 bytes Playfair square :
>
> 1) Choose an appropriate key.
> Say I would choose a key which is only 20 bytes long. This means that
> (256 - 20) bytes will almost be numerically ordered. Therefore a key
> must be lengthy/random enough to mix the Playfair-square to a maximum.
>
> 2) The PlainText must have an equal number of bytes.
> If I would like to encrypt a Word-document which contains 19999 bytes,
> I should add an extra byte. If not, I will not be able to define the
> last bigram of the CT! Adding a single byte to an executable or some
> other form of binary document, will cripple this document. Thus how
> will this info be added into the CT?
>
> 3) It would be very difficult to implement a "double playfair" of this
> kind :-)
>
> The idea of a Playfair was that there was this single key to be
> learned by heart. Everything else could be done by hand. This way an
> agent didn't have to carry "extra material" which would make him even
> more vulnerable...
You oversaw my '(in modern times)' which was intended to
mean implicitly that one has computer aid and the Playfair
is understood to be a very compact scheme of a 16-bit to
16-bit substitution (a specific substitution) that would
otherwise (in case of a general substitution) take up too
much storage space. Hence one can e.g. use a PRNG with a
short seed to generate the matrix. As to your second
point, what do you do when you have a classical case
of Playfair with the small matrix and you have an odd
number of Englich characters? You have to devise a way out
anyway or else exclude the application of the method. My
original question was intended to simply know whether
anybody has thought of employing a large Playfair matrix
(16*16) at all in cases where it could be conveniently used.
M. K. Shen
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: Re: RSA Multiprime
Date: Wed, 01 Nov 2000 14:01:26 +0100
[EMAIL PROTECTED] (Scott Contini):
> I am very much against adding new possible avenues for
> attacking cryptosystems in order to get speed improvements.
Point taken. I now better understand your argument that an
improvement on ECM-like factoring could endanger 3-primes-RSA
while 2-prime-RSA would still be safe, say for 3*256 vs 2*384
bit public key. And I wrongly though today's ECM is entirely
powerless against 3*192 bits, when it is realy quite close to
this level.
> (you would be able to perform an Elliptic Curve signature) much
> faster than you would be able to do a signature with RSA on a
> typical 8-bit smartcard CPU without a coprocessor, according
> to my experience.
Agreed entirely. RSA signature on an 8 bit Smart Card without a
coprocessor
- is too slow: like 10s even for 2*256 bits, growing in n^3;
- saves too little cost compared to a coprocessor;
- is too unsafe: sensitive to timing and power analysys attacks.
However RSA signature verification is indeed realistic.
Francois Grieu
------------------------------
From: Eric Cordian <[EMAIL PROTECTED]>
Subject: Re: A new paper claiming P=NP
Crossposted-To: comp.theory,sci.math,sci.op-research
Date: Wed, 01 Nov 2000 17:23:46 GMT
In comp.theory Timothy Chow <[EMAIL PROTECTED]> wrote:
> It looks to me that the layman's blurb asks, "Does simple connectivity
> *characterize* the 3-sphere?" This may be slightly more sloppy than
> asking, "Is S^3 the only compact simply-connected 3-manifold?" but is
> not really "incorrect."
To a non-mathematician, "essentially characterized" will not be a rigorous
term, and will probably be translated into an assertion that the object
has the property described, rather than the more subtle notion that the
property is possessed only by that object.
So the explanation is a bit obtuse, if one interprets it as ordinary
English.
--
Eric Michael Cordian 0+
O:.T:.O:. Mathematical Munitions Division
"Do What Thou Wilt Shall Be The Whole Of The Law"
------------------------------
From: David Rush <[EMAIL PROTECTED]>
Subject: Emacs hack for OpenSSL encryption
Date: 01 Nov 2000 17:22:17 +0000
This is just a quick hack I banged out to use OpenSSL's encryption
capabilities to maintain a few secure files. I suppose that I'd be
better off using crypt++.el, but 1) I didn't find it until after I
wrote this and 2) The complexity of crypt++ worries me. This package
is very straightforward since it doesn't try for extensive integration
with other emacs packages or magical deduction of
encryption/compression methods. It attempts to be emacsly well-behaved
by using the smallest functional footprint possible.
2 functions:
ssl-find-file ; behaves just like find-file
ssl-write-file ; behave-alike for write-file
ssl-find-file installs a write-file-data-hook and disables auto-saving
for the encrypted file so that we never let it get to disk in the
clear. The only real security weaknesses come from caching keyphrases
inside emacs and using the openssl command line to pass the
keyphrase. The latter is the serious one, but is only vulnerable to a
(IMHO fairly) determined attacker as its only visible for the amount
of time it takes to actually encrypt/decrypt. I can reduce this
vulnerability by running openssl through a pty, but I just don't have
the time to go to that level of implementation complexity.
I find it dismaying how little free (speech) software exists for
securing files (as opposed to email). Here's my US$0.02. I'm hoping
that someone finds it useful.
david rush
==========
The Torah is written in black fire inscribed upon white fire - fire
mixed with fire, hewn out of fire and given from fire
-- 3rd Century Palestinian Merkavah Haggadah
;;; openSSL hacks
(defvar ssl-program "openssl")
(defvar ssl-pass-phrases '())
(defvar ssl-encoding "bf")
(defun ssl-pass-phrase (file)
(let* ((xfile (expand-file-name file))
(ssl-metadata (assoc xfile ssl-pass-phrases)))
(read-passwd "SSL passphrase: " nil
(if ssl-metadata (cdr ssl-metadata) nil))))
(defun ssl-add-write-hook ()
(if (not (member 'ssl-write-file-data-hook
write-file-data-hooks))
(setq write-file-data-hooks (cons 'ssl-write-file-data-hook
write-file-data-hooks))))
(defun ssl-find-file (file)
(interactive "fFind encrypted file: ")
(let* ((xfile (expand-file-name file))
(ssl-metadata (assoc xfile ssl-pass-phrases))
(pass-phrase (read-passwd "SSL passphrase: " nil
(if ssl-metadata (cdr ssl-metadata) nil))))
(if ssl-metadata
(setcdr ssl-metadata pass-phrase)
(setq ssl-pass-phrases (cons (cons xfile pass-phrase) ssl-pass-phrases)))
(let ((buffer (or (find-buffer-visiting xfile)
(create-file-buffer xfile))))
(call-process ssl-program xfile buffer t
"enc" "-d" (format "-%s" ssl-encoding)
"-k" pass-phrase)
(switch-to-buffer buffer)
(set-visited-file-name xfile)
(setq buffer-auto-save-file-name nil)
(ssl-add-write-hook)
(set-buffer-modified-p nil)
(goto-char (point-min))
)))
(defun ssl-write-file (file)
(interactive "FWrite encrypted file: ")
(let* ((xfile (expand-file-name file))
(pass-phrase (ssl-pass-phrase xfile))
(ssl-buffer (get-buffer-create "*SSL Output*")))
(if (not (equal xfile (expand-file-name (buffer-file-name))))
(set-visited-file-name xfile))
(cond ((not
(= 0
(call-process-region (point-min) (point-max)
ssl-program
nil ssl-buffer t
"enc" "-e" (format "-%s" ssl-encoding)
"-k" pass-phrase
"-out" xfile)))
(switch-to-buffer-other-window ssl-buffer)
nil)
(t
(setq buffer-auto-save-file-name nil)
(ssl-add-write-hook)
(set-buffer-modified-p nil)
t))
))
(defun ssl-write-file-data-hook (file)
(let* ((xfile (expand-file-name file)))
(and (assoc xfile ssl-pass-phrases)
(ssl-write-file xfile)
)))
------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: frequency analysis
Date: 01 Nov 2000 17:24:47 GMT
Richard Heathfield [EMAIL PROTECTED] writes, in part:
>Okay, that's it. I'd appreciate the opinions of the clueful on whether
>this is any use for elementary cryptanalysis, or whether it should be
>relegated to rec.puzzles.
Yes, I think it's useful, and it's a good
start.
The program, though, has problems displaying
large files, or maybe I just haven't figured
out to do it. Here's what I mean. The display
of a large ciphertext or plaintext file, or
both files scrolls off the screen. I'd like
to see the program pause, by default, after
20 or so lines. I tried /p and piping MORE,
but those tries didn't work. Additionally,
you might want to include an option to display
specific ciphertext-plaintext lines.
It might be good to make the program capable of
re-directing things like FREQ, MATCH, and
LOOKUP to a file.
*******************************************************
I think one of the first things the program should
try to determine is whether the cipher is
monoalphabetic. As it is, the user could
determine that from the single-character
frequencies by looking for matching peaks
and valleys. But you could have the program
calculate the IC. Given enough ciphertext
the IC is reliable at determining monoalphabeticity.
MATCH is a fairly good way to solve ciphers where
word divisions are apparent. I would, though,
like to be able to preserve the character
substitutions I've already made, and, then
be able to do a match.
A quick way to solve shift ciphers might be
added.
I see you plan to use digraph, trigraph,
and tetragraph analysis -- good idea.
I'd try to keep the program interactive rather than
make it a fire-and-forget program -- unless
you are planning on writing a genetic or
hillclimbing algorithm.
*******************************************************
If your news server gets alt.sources.crypto,
you might want to post your code there, too.
It would be nice to make that news group
more popular, or at least keep it alive.
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Is RSA provably secure under some conditions?
Date: 1 Nov 2000 17:19:03 GMT
[EMAIL PROTECTED] (John Myre) wrote in <[EMAIL PROTECTED]>:
>Shai Halevi wrote:
>><snip>
>> Our experience from everyday life, tells us that usually there isn't
>> much else you can do with such code. Sure, you can take the code, view
>> it as a bit string, and hash it, or do whatever, but that will not give
>> you anything particularly useful. Problem is, we do not understand this
>> phenomena. Why is it that for "natural" systems, seems like the only
>> sensible thing to do with the code is to run it? What property do
>> "natural" systems have, that renders any other form of processing the
>> code useless for an adversary.
><snip>
>
>I think this is a reasonable insight, but it puts me in mind
>of the opposite perspective: what useful things can we do if
>the code is more data-like? The LISP and AI folks have worked
>on this a lot, and gotten some quite interesting results. Did
>you ever encounter "Godel, Escher, Bach", by Hofstadter?
>
>(I wonder if this means I should be wary of cryptosystems that
>are implemented in LISP?)
Having had the unfortunate experince to take a class in LISP
and to use it for a while. It seemed to be a very poor language
for anything. It was very very slow. I thought the AI folks got
wise and there using somthing such as C or C++ or something like PROLOG
or something like that I am not sure there is good crypto in
LISP. I wonder if they can even get a version of Rijndael to run
under LISP.
But of cource my LISP use was years ago. So maybe they made
so imporvement but I would not hold my breath.
>
>JM
>
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:
------------------------------
Date: Wed, 01 Nov 2000 17:30:03 +0000
From: Richard Heathfield <[EMAIL PROTECTED]>
Subject: Re: BENNY AND THE MTB?
Tim Tyler wrote:
>
<snip>
>
> Not so. Could it be that you are aauming that a 8 bit cyphertext need map
> to an 8 bit plaintext? It need not - and indeed in Matt's code, it
> typically does not - an 8-bit byte cyphertext typically maps to a much
> longer plaintext.
I can see how the 8-bit ciphertext could effectively be the equivalent
of a code-book header entry, and that the plaintext would be in the body
of that entry. But I don't think that's what you mean, so I'm baffled.
>
> I don't think "256 messages" comes into it. The interceptors have
> received a *particular* byte. They are not considering what messages
> could be transmitted by *any* single byte value, but the message that is
> *actually* transmitted by one specific byte - the one they have
> intercepted.
If this is only one byte out of many, then I withdraw my bafflement -
it's just a partial ciphertext, and that puts a completely different
complexion on things.
>
> There are probably almost as many possible messages that could be
> represented by that single bye as there are keys; since almost every
> key is likely to lead to a different message.
Okay, my layman's reasoning is that there are 2^128 keys and 2^8
ciphertexts, so there are a total of 2^136 possible messages. If we are
dealing with a specific key, however, then I can only see 256, no matter
how long the key is.
Perhaps my source of confusion is a relativistic one.
>From Bob's point of view, the incoming byte can only convey one of 256
messages (if it is indeed a complete ciphertext - obviously, if it's a
partial ciphertext, this doesn't apply).
>From Eve's perspective, however, I can easily see that there are 2^136
/potential/ messages within that byte - but, again, only if it's part of
a longer ciphertext.
If it's on its own, there are only 256 different states which it can
have. This is my stumbling block, I'm sure of it. You seem to be saying
that you can encode > 256 states within an 8-bit byte, and I'm just not
seeing it. Should I give up and go home?
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Give it up?
Date: Wed, 01 Nov 2000 17:17:33 GMT
In article <[EMAIL PROTECTED]>,
Pascal JUNOD <[EMAIL PROTECTED]> wrote:
> > This is sci.crypt not "sci.post.whatever.you.want.crypt"
>
> That's funny to read this from you...
>
> A+
Hey joker, most of my posts are on topic (my ciphers I propose, my
analysis of some others, etc...) you guys just don't respond to my
positive posts at all.
Tom
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
** 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
******************************
