Cryptography-Digest Digest #251, Volume #10      Thu, 16 Sep 99 23:13:03 EDT

Contents:
  Re: What is XOR? ("entropy")
  Re: What is XOR? (SkoZombie)
  Re: Sources of randomness (Scott Nelson)
  Re: Mystery inc. (Beale cyphers) (Curt Welch)
  Re: crypto export rules changing (SCOTT19U.ZIP_GUY)
  Re: Okay "experts," how do you do it? (SCOTT19U.ZIP_GUY)
  Re: Okay "experts," how do you do it? (SCOTT19U.ZIP_GUY)
  Re: SCOTT19U.ZIP_GUY/Questions Please ("Douglas A. Gwyn")
  Re: Cyrpto-sell-o (David A Molnar)
  Re: Mystery inc. (Beale cyphers) ([EMAIL PROTECTED])
  Re: Beale (was: Mystery inc.) (sha99y00000)
  Re: Okay "experts," how do you do it? (JPeschel)

----------------------------------------------------------------------------

From: "entropy" <[EMAIL PROTECTED]>
Subject: Re: What is XOR?
Date: Thu, 16 Sep 1999 21:18:35 -0400

=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1

thanks, I appreciate the explanation.

- --

a.


:::entropy:::
ktheory.com

SkoZombie <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> John Savard wrote:
> >
> > "entropy" <[EMAIL PROTECTED]> wrote, in part:
> >
> > >Sorry for the newbie-esque question, but what is XOR?
> >
> > Binary addition without carries:
> >
> > XOR    0   1
> > -------------
> >  0     0   1
> >  1     1   0
> >
> > John Savard ( teneerf<- )
> > http://www.ecn.ab.ca/~jsavard/crypto.htm
>
> I agree 100%, but just to make things a little clearer, here's a
> futher example.
>
> Say you have two binary numbers, A = 01100101 and B = 10101001. To
> XOR them together, you simply do it quite literally, bit by bit. So
> ...  A XOR B
>
> 01100101 XOR
> 10101001
> --------
> 11001100 [Using table above]
>
> As this is a binary operation, it normally quite quick.
>
> And, If i am not mistaken, the XOR symbol is a plus in a circle ...
> like (+) if you close the circle :)
>
> Hope it helps!
>
Sko

=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>

iQA/AwUBN+GW6OlLHfp8d083EQJQPQCfVdXu6pwfKHw6cbyrzGU++ZIhjpIAoKWo
CEbXCBSYveOzocSgrZANwIwt
=aj4E
=====END PGP SIGNATURE=====




------------------------------

From: SkoZombie <[EMAIL PROTECTED]>
Subject: Re: What is XOR?
Date: Fri, 17 Sep 1999 10:22:05 +1000

John Savard wrote:
> 
> "entropy" <[EMAIL PROTECTED]> wrote, in part:
> 
> >Sorry for the newbie-esque question, but what is XOR?
> 
> Binary addition without carries:
> 
> XOR    0   1
> -------------
>  0     0   1
>  1     1   0
> 
> John Savard ( teneerf<- )
> http://www.ecn.ab.ca/~jsavard/crypto.htm

I agree 100%, but just to make things a little clearer, here's a futher
example.

Say you have two binary numbers, A = 01100101 and B = 10101001. To XOR
them together, you simply do it quite literally, bit by bit. So ...  A
XOR B

01100101 XOR
10101001
========
11001100 [Using table above]

As this is a binary operation, it normally quite quick.

And, If i am not mistaken, the XOR symbol is a plus in a circle ... like
(+) if you close the circle :)

Hope it helps!

Sko

------------------------------

From: [EMAIL PROTECTED] (Scott Nelson)
Subject: Re: Sources of randomness
Reply-To: [EMAIL PROTECTED]
Date: Fri, 17 Sep 1999 00:45:15 GMT

On 16 Sep 1999 08:55:10 +0100, Paul Crowley
<[EMAIL PROTECTED]> wrote:

>[EMAIL PROTECTED] (Scott Nelson) writes:
>> There's a tradeoff here between wasting computing power 
>> and source bits.  Both resources are remarkably cheap, 
>> and if you can, then waste them both.  In my experience tough, 
>> source bits have always been "cheaper."  YMMV.
>
>I think your experience is unusual here.  Especially bearing in mind
>that Panama is ludicrously, blindingly fast, especially on newer
>processors.  Are you sure your LFSR approach is faster at all?
>

Well, yes, it does seem likely that my experience is different 
from others on sci.crypt.  I often deal with embedded systems 
and micro controllers.  Luxuries like multiply and 16-bit add
are not always available, and have to be simulated in software.
(Fortunately, the compiler usually does it for me automatically.)

And yes, I'm quite sure that an LFSR is faster and smaller than 
_any_ secure hash, including Panama.  It's also a lot easier to 
build in hardware.  However, that's really beside the point.
As someone pointed out to me privately, if you have the cycles 
to burn then it doesn't really matter if the computer is 
spending 75% of it's time idle or 30%.  He.net reports that their
servers are disk bound, not compute bound, and their processors 
are not state of the art by any means.  Since secure server code
is likely to have a secure hash function for other reasons, 
it makes sense to use it, rather than a separate function, 
for random number generation/collection as well.


Note: when I said source bits were cheap, I meant _extra_ bits
from the source, not finding a source of bits in the first place.  
These sources are almost by nature platform dependant, and are 
often quite expensive to find, especially in terms of software 
development time.  

Scott Nelson <[EMAIL PROTECTED]>


------------------------------

Subject: Re: Mystery inc. (Beale cyphers)
From: [EMAIL PROTECTED] (Curt Welch)
Date: 17 Sep 1999 00:17:14 GMT

[EMAIL PROTECTED] (Roger Fleming) wrote:
> Hmm. Given the current discussion about the possible bogosity or
> otherwise of the Beale Ciphers #1 & #3, it is interesting to read the
> text of #2 with a slightly skeptical eye. To me, even without looking at
> Beale #1 and #3 the cleartext of Beale #2 looks like a good candidate for
> a hoax! Consider:

Love your points!  Throwing in historic facts makes your argument much
stronger.

> 2. Transportation. I don't know where Bufords/Bedford are,

Present day Montvale VA.  A long way to go with such a heavy load.

> Can anyone think of
> any other good reason to have three separate documents, in different
> ciphers?

Sure, I can make up a story to explain it.

People weren't creating these "documents" on word processors.  They were
writing them on paper by hand.  I'm guessing (but haven't tried this) that
if you take a typical size of letter paper from those days and write this
down, it will fill up a sheet of paper.  So it may be very natural for this
much text to be split across multiple pages.

Beale may have first recorded the location of the gold on one sheet of
paper.  Then in getting ready to return for more, he decided to leave it
with the innkeeper and created #2 to explain what it was about and #3 to
document who should get the gold.

Then instead of just leaving the locked chest with these documents he
decided it would be better if he encrypted them.  This type of sequence can
explain why #2 is #2, and not #1.

For some reason he starts with #2.  Maybe he decided to encrypt the paper
with the location, and then wrote #2 to complete the package before
starting the encryption process.  Since he just wrote #2, he then decided
to encrypt it first?

With that done (could have taken many hours (over more than one day) to
number a DOI and encrypt the cleartext), he then thinks about the next one.
It seems very possible that he could then decided it would be more secure
if he used a different key for the next paper.  But maybe he didn't have
easy access to any other common/well known document to use as a key - so
instead decided to create his own key.

If he had been recording the numbers used for #2 as he encoded it, this
makes even more sense.  He has that sheet of numbers in front of him and
realizes he doesn't even need the DOI to decode #2.  The sheet of numbers
is all that's needed.  So, instead of finding another public document to
encode #1 with, he just makes up another sheet of numbers - or somehow
labels the sheet he already has and uses that as the key for #1 as well.

The Gillogly strings give strong evidence that this sheet of numbers
existed (in both the hoax and non-hoax theories).  To get those alphabetic
runs, either the person who created #1 had to intentionaly encode the
"ABCDE.." clear text, or it had to happen by accident from the way #1 was
created.  If it was done intentionally, then this is a hoax.  If it's a
hoax, why would they have intentionally encrypted "ABCDE"? That would only
server to expose the hoax.  So I feel very strongly that the strings showed
up by accident -- i.e. the person creating #1 didn't realize the side
effect of what he was doing.  This is very typical when someone trys to
create their "own" encryption system. It's always much weaker than they
realize and there are "cracks" in the sytem which expose it's inner
workings.

I'm not saying that #1 isn't random numbers, but I'm saying that the sheet
of numbers probably existed, because to get the Gillogy strings as an
accident, someone had to be working with a list of number/letter pairs from
the DOI which had been sorted by the letters in the pairs.  And the most
likely form of that paper seems to me to be a table where the letters are
written either down the side or across the top, and the numbers are then
recorded either in the proper row or column.

Then, he just does the same for #3.  i.e., makes up yet enough "key" and
goes to work encoding the document.

So this could very well be three different keys, one for each paper, but
the same "encryption" algorithm for each.  And all three keys might be
created from the same table of numbers.

But another weakness of course is why encode #3 at all?  Maybe after doing
#2 and #1 he just felt it would be safer to hide everything so anyone
finding it before they should have would not be able to guess the
importance of the papers???

> (OK, limiting ciphertext under one key; but do we really claim
> the cipherer knew that sort of stuff?)

He might not have known it when he started but it's not that far of a
stretch (in my mind) to believe he could have figured it out in the
processes.

> Note that any explanation will
> also need to explain why document #2 needed to explicitly state that the
> location was to be found in #1, when a legitimate recipient would have
> found that out before he even read #2.

Yes, people have always pointed that out as being odd.  One possibility is
that the last line, "paper number one describes thc e_act locality of the
varlt so that no difficulty will be had in finding it", was not part of the
original beale #2 cipher.  It could have been added later by one of the
parties to make it a better story when it was published (and to justify a
lifetime spent trying to break #1 :)).

I don't know if anyone has looked at the numbers used for that last line
and see if there's any possible indication that it was encoded at a
different time than the rest of the document.

> All in all, I would be gravely skeptical of the Beale ciphers even
> without the alphabet runs being found in Beale #1. It might be possible
> to explain the alphabet runs without hoaxing, but in conjunction with the
> general dubiousness of Beale #2 it is most likely they are just what they
> seem - the hoaxer getting tired, or lazy.

The cover up of the "real" author as the story goes is another sore point.
If you really wanted to make the matter public, you would have released the
original Beale papers to the public as well.  The fact that all we have
is a published story is more support for the hoax theory.  There is no type
of physical evidence to back up the story.  And if you really wanted to see
the thing solved, releasing the physical evidence would have made the story
much stronger.

There is a lot of evidence that makes this look like a hoax.  And if you
were a treasure hunter, I'm sure there's a lot of other lost treasures
that would serve as better candidates for your time.

But it's still an unsolved mystery.  To me, that's what's fascinating about
it.  We have a cipher that no one has been able to break. Even if it's a
hoax, there's still a chance that the cipher is real, and that #1 and #3
both may contain real (and very interesting) cleartext messages.  And
even with all the hoax possibilities, there's still a chance that there
is gold (or some type of treasure) at the end of this search.

If it was a simple hoax by Ward for the purpose of getting rich selling
pamphlets, then I would expect the other ciphers to be random numbers (he
wouldn't want anyone to ever solve them).  The Gillogly strings in
my mind show that there's real hope that this isn't the case.

The strings seem to be seen by many people as "proof" that the #1 cipher
doesn't contain a real message.  But what does it really show?  All it
shows is that the cipher was somehow constructed from the same DOI used for
#2.

The #1 cipher can still be random numbers, but at least we know the
DOI numbers were somehow used as part of the random number generation
process.  And the cipher can still contain a valid cleartext message, as
demonstrated by the table theory.  So though the Gillogly strings do tell
us more about #1, and limit the search for an answer to the mystery, it
doesn't solve the mystery.

It does however remove one possible explanation of the "hoax".  Before the
Gillogly strings where known, it was possible that the #1 and #3 documents
were real ciphers which led to some treasure known only by Ward.  He could
have made up the story, and the #2 cipher just to make it all a "good"
story and to encourage people to help him break the #1 and #3 ciphers.  But
the Gillogly strings show that whoever encoded #2 is also very likely to
the one which created #1 (either as random numbers or a real cipher).

So, if there are problems with the story in #2 (like what Roger has just
talked about here), it would indicate that these problems came from the
person who created #1 as well.

But you know, here's yet another (far fetched) possibility.  There might be
a "real" #2 that we have never seen.  Ward could have taken the
numbers/letter pairs used in the "real" #2 and made up the #2 we know about
(and made up the rest of the story as well of course).  This would allow
one to separate the "problems" in the #2 story, from the fact that the
numbers were somehow used to create #1.

The point being simply that yet again, even if the story in #2 is bogus,
and we "know" the numbers used to encode #2 were somehow used with #1, that
doesn't prove #1 is "bogus".

The only way I can think of to prove that the ciphers contain no valid
cleartext message is to discover a simple algorithm for generating the
cipher text.  Or to find some lost document which explains "the truth"
behind the ward publication in such a fashion that it would be hard to
dispute (like a document from Ward explain why and how the ciphers and his
publication was created).

Without proof like this, the ciphers will remain a mystery.  The
inconsistencies certainly reduce the probability that there's gold at the
end of this rainbow, so I can understand why people will loose interest in
the hunt.  But I continue to be drawn to the problem because of the shear
mystery of it.  Being the person to solve the mystery would in itself be
enough reward for me.

-- 
Curt Welch                                            http://CurtWelch.Com/
[EMAIL PROTECTED]                          Webmaster for http://NewsReader.Com/

------------------------------

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Crossposted-To: talk.politics.crypto
Subject: Re: crypto export rules changing
Date: Fri, 17 Sep 1999 02:52:14 GMT

In article <7rrb4k$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Rubin) wrote:
>A big liberalization of export rules is supposed to be announced
>today, but apparently there will also be some key escrow provisions.
>
>http://www.sjmercury.com/breaking/headline1/024676.htm

  It the same old crap in a different bag. "Wired" had an article
it means nothing to the average guy writting crypto. But for companes
as long as they kiss ass subject to a one time review they can export
there stuff provided it meets the concerns of Law ENforcement. Its hype
so that silicon valley will think the Democrats want looser crypto anad maybe
they will give Gore Money.



David A. Scott
--
                    SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
                    http://www.jim.com/jamesd/Kong/scott19u.zip
                    http://members.xoom.com/ecil/index.htm
                    NOTE EMAIL address is for SPAMERS

------------------------------

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Okay "experts," how do you do it?
Date: Fri, 17 Sep 1999 03:08:57 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Okay, "putup or shaddup ..."  :-) :-)
>
>I see lots of articles, written by experts, who say that only experts
>can evaluate the quality of a cipher ... if they have the time, which
>they usually don't unless there's a research paper in it.  Yada, yada,
>yada.
>
>Okay, experts, "put up or shaddup" :-) :-) ... how do you do it?
    They check to see how wrote it. If it is some one they don't know
they say it is weak and go on since they are afraid of there own
shadows. Or like mine they say lies like the SLide Attack would make
mince meat of it. But then they have to admit they can't read C code.
Of course they can point to the ciphers that seem to get invernted over
and over again that are know weak. But if it is not one of the old reinvented
ones they never reallt look. They just hope it goes away.
>
>How DO you determine that a cipher is or isn't a good one?  How DO you
>conclude that it is or isn't snake oil?  What IS it that you've learned
>that makes you qualified to pass judgement on a crypto-algorithm that no
>one else can do the same??
>
>:-)



David A. Scott
--
                    SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
                    http://www.jim.com/jamesd/Kong/scott19u.zip
                    http://members.xoom.com/ecil/index.htm
                    NOTE EMAIL address is for SPAMERS

------------------------------

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Okay "experts," how do you do it?
Date: Fri, 17 Sep 1999 03:22:49 GMT

In article <[EMAIL PROTECTED]>, Eric 
Lee Green <[EMAIL PROTECTED]> wrote:
>Sundial Services wrote:
>> 
>> Okay, "putup or shaddup ..."  :-) :-)
>> 
>> I see lots of articles, written by experts, who say that only experts
>> can evaluate the quality of a cipher ... if they have the time, which
>> they usually don't unless there's a research paper in it.  Yada, yada,
>> yada.
>> 
>> Okay, experts, "put up or shaddup" :-) :-) ... how do you do it?
>> 
>> How DO you determine that a cipher is or isn't a good one?  How DO you
>> conclude that it is or isn't snake oil?  What IS it that you've learned
>> that makes you qualified to pass judgement on a crypto-algorithm that no
>> one else can do the same??
>
>Well, I'm not an expert (and don't pretend to be one), but what I've
>seen most of the "real" experts say is that an algorithm is strong only
>if it resists attack from a variety of other "real" experts (well, if it
>doesn't resist attack by talented amateurs or even not-so-talented
>amateurs such as myself then obviously it is crud, but resisting attack
>by me only means that total novices cannot crack it, not that the NSA
>can't read it as easily as plain text). 
>
>The basic problem is that talented amateurs invent new algorithms on a
>daily basis, and nobody could ever analyse them all. Thus algorithms
>tend to get analysed only when a) there is some kind of contest such as
>the AES contest that will result in major future sales, or b) the
>algorithm has been adopted or proposed to be a standard, or c) the
>algorithm has been adopted for a popular application or set of
>applications, and thus attracts large-scale attention. (Possibly
>unwanted attention, if the application turns out to be easily broken
>:-(  ). MSCHAP-80, for example, was broken when part (c) happened, to
>Microsoft's chagrin. 
>
>Whoops, I forgot part (d), which is when you pay the "real" experts real
>money to cryptanalyse your product prior to its release. Depending upon
>the importance of the crypto component of your product, that may be
>money well spent (or maybe not). I know that Microsoft probably wishes
>today that they'd hired Bruce to cryptanalyse MSCHAP-80 prior to its
>release...

   How do you know that didn't hire him. Do you see a list that tells which
so called experts looked at it. And it would be nice to know what the so 
called experts get paid or if that is to confidenital how many man-hours
for the method. That way as time goes on we could plot how correct the
particular person was. But I doubt if the so called experts would really want
that. Becasue its better to have a good line of BS than to really know
anything.



 


David A. Scott
--
                    SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
                    http://www.jim.com/jamesd/Kong/scott19u.zip
                    http://members.xoom.com/ecil/index.htm
                    NOTE EMAIL address is for SPAMERS

------------------------------

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: SCOTT19U.ZIP_GUY/Questions Please
Date: Fri, 17 Sep 1999 02:27:56 GMT

"SCOTT19U.ZIP_GUY" wrote:
> ... Of course the evidence if there was any was destroyed unless the
> texas rangers can provide a link.

The evidence from the Branch Davidian fiasco that I'm most interesting
in determining the fate of is the main entrance door, which seems from
the scanty remaining evidence to have had *inbound* bullet holes.
Funny that the FBI could lose something so big.  Almost as funny as
their staging a commando-style raid on a fortified compound instead
of knocking politely at the door or interviewing DK when he was out
of the compound.  But not as funny as one of the assailants shooting
himself in the leg while scaling the building.

> Don't take me wrong I think V.H. aka D.K was a very very bad sick
> person.

Well, I suppose religious fanaticism is almost by definition "sick".
But by the evidence DK wasn't a particularly bad person.  The
original claim of child abuse turned out to have been manufactured
by an estranged parent as a ploy to get the authorities to recover
her child from the Branch Davidians.  It is interesting to note that
some of the supposed FL child abuse cases that first brought Janet
Reno to national attention were later found to have been manufactured,
this time by over-zealous friends of Reno who browbeat the kids into
making accusatory statements.  Do we see a pattern here?

> ... It is a fact
> IBM was going to go with a 64 bit system but the NSA stepped in to
> make it a 56 bit sytem. Why? Because a 56 bit system is can be
> brute force searched 256 times faster. I think the old book "The
> Puzzle Palace" covers this somewhat if your interested.

I have much better information about this than found in that book.
In previous postings I explained that there was a collaboration
among NBS, NSA, and IBM, in the course of which the original design
was revised in several ways, most of them improving the security.
At the time, the estimate was that 56 bits could be cracked by brute
force with a rather large expenditure of resources and expertise
that only NSA really could muster, if they had to.  Certainly, it
was considered important to the national security that uncrackable
encryption not become widespread.  Since DES was only meant to
protect sensitive but not critical information, it only needed to
be right at the edge of crackability over the planned 10-year
design life.  (That DES would then be recertified was not foreseen.)


------------------------------

From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Cyrpto-sell-o
Date: 17 Sep 1999 02:27:59 GMT

[EMAIL PROTECTED] wrote:
> I am new to the encryption scene but I was curious.  If I were to come

"dude, it ain't about the punk. and it ain't about the scene." - a song

> up with a new mathamatical encryption method, how would I go about
> selling this?  Should I contact the NSA?  Just curious.

0. implement (by this I mean code AND description)
1. patent.
2. publish. 
3. incorporate. 



------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Mystery inc. (Beale cyphers)
Date: Fri, 17 Sep 1999 01:43:03 GMT

In article <19990916123847.453$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (Curt Welch) wrote:

> You know that either the number is wrong, or your key is wrong.  The
> problem is you don't know for sure which is wrong.

   The usual procedure is to correct as much of the plaintext as you
can by renumbering the DOI.  What you then find in the middle of a
range of corrected numbers is a single number that just misses a
correct decipherment by +/-1.   The key, the DOI, has been corrected as
much as it can be, so correcting the cipher number is the next step.
If Beale copied this number incorrectly himself and set up his
hypothetical table accordingly, then you're right that his key (i.e.
your hypothetical table) is wrong, or at least contains a different
number than it should have.

> On Amazon.com I find:
>
> Beale Treasure: NEW History Of A Mystery
> Peter Viemeister / Hardcover / Published 1997
> Our Price: $24.50 (Special Order)
>
> Is that the book (or an updated version of it maybe?)

   I believe this is an updated, hardbound version of his 1987
paperback version.   I didn't buy the new edition myself since I
thought I had all I needed concerning the Beale ciphers.  I believe
that any new material in the book would be speculation about who the
author of the 1885 pamphlet might have been if not James B. Ward.

> In cipher.doc I find:
>
>   { BEALE CIPHER #2:  CONTENTS OF VAULT, LENGTH = 763, VARIETY = 182 }
>   { All typographical errors in Ward's pamphlet have been corrected  }
>
> So this means the #2 in cipher.doc isn't exactly as printed but
> contains the 7 changes documented in doi.doc?  So to see exactly what
> was printed for #2 I just need to reverse those right?

   Yes, that's right.  I posted a correction, but it was a little late
in arriving.

   -- Jeff Hill


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

------------------------------

Date: Fri, 17 Sep 1999 01:33:16 +0100
From: sha99y00000 <[EMAIL PROTECTED]>
Subject: Re: Beale (was: Mystery inc.)


> No. It's all in HTML. Please stick to plain text in newsgroups.

Already noted, thank you.


------------------------------

From: [EMAIL PROTECTED] (JPeschel)
Subject: Re: Okay "experts," how do you do it?
Date: 17 Sep 1999 02:53:27 GMT

> [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:


>In article <7rrlo2$830$[EMAIL PROTECTED]>,
>[EMAIL PROTECTED] (David Wagner) wrote:
>>In article <[EMAIL PROTECTED]>,
>>Sundial Services  <[EMAIL PROTECTED]> wrote:
>>> Or, to
>>> put it another way, let's figure out what exactly it is that makes Bruce
>>> Scheirer's opinion better than anyone else's besides the fact that he's
>>> written a book.
>>
>>The whole point of the scientific process is that you _don't_ have
>>to trust Schneier's opinion any more than anyone else's.  If someone
>>has a practical attack, it doesn't matter who he is, or whether he
>>is an expert; we can immediately conclude that the cipher is insecure.

>    No that is not ture I think that you guys just publish and pat your
>selves
>on the back. You thought your attack would make mince meat out of my
>stuff my it did not. You would think that since you invented it you could
>test 
>it but you couldn't. Scott19u is better then the short block ciphers you and
>your employee can write for file portection. if NOT PROVE IT unstand of lying
>like you have done so in the past Mr Wagner.
>
>

Damn it, Dave, would you stop your bullshitting.

What Wagner says is right: if someone, even a non-expert, finds a practical
attack the cipher is broken. So what if Wagner was wrong about the "Slide
Attack" not working on Scott19u.  Everyone makes mistakes, and he corrected
his.  Remember, afterall, Dave, Paul made mincemeat and onions out of scott16.

Joe


__________________________________________

Joe Peschel 
D.O.E. SysWorks                                 
http://members.aol.com/jpeschel/index.htm
__________________________________________


------------------------------


** 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
******************************

Reply via email to