Cryptography-Digest Digest #75, Volume #10 Thu, 19 Aug 99 11:13:02 EDT
Contents:
Re: Encryption and Authentication (Gabriel Belingueres)
Re: CRYPTO DESIGN MY VIEW (Mok-Kong Shen)
Re: Do I have a problem with semantics? (Nicol So)
Re: Definition of cracked? ([EMAIL PROTECTED])
Re: NIST AES FInalists are....
Re: CRYPTO DESIGN MY VIEW (SCOTT19U.ZIP_GUY)
Re: Blowfish algorithm - Is it foolproof? (John Winters)
Re: Q. a hash of a hash ... (Anton Stiglic)
Where to find (Preditor31)
Re: Q. a hash of a hash ... (Anton Stiglic)
Re: Q. a hash of a hash ... (John Myre)
Re: Q. a hash of a hash ... (Anton Stiglic)
Future Cryptology (Anonymous)
Re: LFSRs in a5 (Tom St Denis)
Re: New encryption algorithm (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: Gabriel Belingueres <[EMAIL PROTECTED]>
Subject: Re: Encryption and Authentication
Date: Thu, 19 Aug 1999 11:35:08 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (D. J. Bernstein) wrote:
> Gabriel Belingueres <[EMAIL PROTECTED]> wrote:
> > In the later, I can authenticate first, and if the MAC not the same,
I
> > can save a decryption.
>
> Right. A flood of fake packets will waste lots of CPU time if you have
> to decrypt before checking the authenticator.
I agree.
> On the other hand, this really doesn't matter for SSL, since there are
> much easier ways to destroy SSL service.
I agree too (specially in SSLv2). But generally, in a secure message
transport protocol:
Why "typically" the former schema is used anyway? Maybe for a historical
reason?
Both schemas provides the same security, right?
Gabriel
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Thu, 19 Aug 1999 12:42:00 +0200
wtshaw wrote:
>
> I feel that algorithms are best explained in non-cryptic format; a
> specific implementation of an algorithm may be written in differenct forms
> of source code, yet remain equivalent in ciphertext produced as long as
> the same principles and formulae are followed.
>
> Being able to simply plug in sourcecode and make it work has no
> requirement on the user that it be understood; whereas, writing from a
> description mandates a complete understanding of the algorithm.
>
I want to add that all algorithms (crypto and others) are discussed
in science based on (abstract) descriptions not on specific (concrete)
codes in one particular programming language. One can never be
absolutely sure whether a programmer does not err and introduce bugs
in a large program. Reading a large program and trying to extract
from it the algorithm is unquestionalbly a difficult task, espetially
if the program logic is pooly or not documented. Even if a program
is well written, the task is comparable to reading a long novel and
then try to tell someone in one minute what it is about. It is a
very uneconomical way of doing things and has nothing to do with
laziness or not as Scott would like to suggest. On the other hand,
the normally short description of an algorithm can be looked upon and
examined in one's mind with little difficulty. One needs only to look
into the journals of algorithms (there are quite a few currently) in
order to see this point. One never finds there C codes or codes in any
other practical programming languages!!
M. K. Shen
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: Do I have a problem with semantics?
Date: Thu, 19 Aug 1999 08:02:45 -0400
rosi wrote:
>
> ... Let me go an (kind of)
> indirect route: If a mf, first (sorry to be a bit picky) it runs against
> your
> definition of 'provably secure' in some sense. There is nothing to prove,
> for one; there is no conjecture the prove depends on, for another. So I
> may appear to be twisting things by asking, what is this 'provably secure'
> again? Then if we say it is the process that can be proven to be secure,
> then there is a bit 'semantics'. The '4-5' should not be in the picture as
> you never need to prove that. But let me have my reservations about the
> '4-5'. Secondly, without quantumn we have (kind of) quantumn (remember
> your own words MF, i.e. no assumption)? I can say I believe it, but do you
> think that is too much against intuition? Thirdly, assume the def. for 'ps'
> does not change, where is the conjecture (for the proof of the process/
> protocol)? Please do not think I want an argument for its own sake. Do I
> have it that you did read Paper?
Actually I did read the paper when I posted my first message in this
thread, but I read it kind of fast and I didn't want to attribute any
misunderstanding of mine to the author, so I didn't want to *claim* to
have read it.
Let's deal with the term "provably secure" first. A cipher is provably
secure if its security (according to some precise definition) can be
demonstrated with a mathematical proof. That's what most people would
come to expect when they see the words "provably secure".
To understand the significance of it, you need to realize that the vast
majority of ciphers have NOT been proved secure according to any
mathematical definition of security. Many ciphers have been subjected
to analysis, sometimes quite extensive, and have some of their
mathematical properties discovered/measured. However, there is a lack
of *rigorous* connection between the analysis results on one hand, and
formalized notions of security on the other.
In other words, we may know some mathematical properties about the
ciphers, and may be able to make very precise claims about them, but we
just don't know for sure whether what we know has anything to do with
security. This is NOT provable security. This is heuristic reasoning,
at best.
So... when somebody is able to "prove" the security of a cipher
mathematically, it would be a huge improvement over the unsatisfactory
state of knowledge for most other ciphers--or so you would think.
Several things can be wrong with a "provably secure" cipher.
First, the mathematical definition of security may not correspond very
well with practical security. But more often, the problem is that the
proofs rely on unproven conjectures. So the results boil down to: "if
this well-known but unproven conjecture A is true, then cipher C is
secure in the sense of S; BUT if A is false, this claim really says
nothing". So although the results (theorems) are rigorous, they could
be true only by virtue of the second part of it ("BUT if A is
false...").
The involvement of unproven conjectures is NOT an essential ingredient
of provably security, but (unfortunately) it is a common ingredient of
may "provable" results.
The unconditional secrecy of one-time pad is provable without relying on
any unproven conjecture.
As for the phrase "mathematical fact", which I used rather casually, it
just indicates something is true, and known to be so to me (because I
know of ways to prove it). But it does not mean something that can be
or should be accepted on faith.
Now let's go back to "Secret Key Agreement by Public Discussion". The
web pages are a very good exposition of the ideas. I'm not sure if I
can explain it any better, but I'll try to explain things from a
slightly different angle.
Some key facts:
1. The channel between Alice and Bob, as well as the one between Alice
and Eve, is noisy.
2. The bits Bob receives agree with what Alice sends, most of the time,
but not always. Same for Eve.
3. The noise on the Alice-Bob channel is uncorrelated to that on the
Alice-Eve channel.
4. (Important) The subset of bits the Bob receives correctly is
different from the subset that Eve receives correctly.
So... the bits that Alice sent fall into the following (disjoint)
categories:
1. Alice, Bob, and Eve all have the same version (because the bit was
received correctly by both Bob and Eve).
2. Alice and Bob have the same version, but Eve's was corrupted.
3. Alice and Eve have the same version, but Bob's was corrupted.
4. Bob and Eve have the same version, but it is not what Alice sent.
Now, the goal is to "distill" the entire bit string into a much shorter
one, which depends on all the original bits. Because of the bits in
category 2, if we do it right, Eve will get a very different version of
"distilled" bit string than Bob. We do it by dropping bits.
Now, the question is: how do Alice and Bob drop the right bits (and not
too many of the ones in category 2)? The answer: by coordinating with
each other through a conversation. BECAUSE EVE DOES NOT PARTICIPATE IN
THE INTERACTION, THE BITS DROPPED BY ALICE AND BOB WILL BE "WRONG" FOR
EVE. A disproportionate number of bits will be dropped from category 3
compared with category 2.
You can verify this fact easily: after one round of interaction, the
probability that Alice and Bob share the exact same shortened string is
improved (significantly). For Eve, the improvement is much more modest.
Eventually, Alice and Bob will reach a much shortened version of bit
strings than they started with. The two strings will agree with
overwhelming probability. For Eve, her version will disagree with
Alice's and Bob's in a number of positions (depending on how noisy the
Alice-Eve channel is). Essentially, Eve is wrong about an known subset
of the bits that Alice and Bob share.
The last step in the process is to further distill these bits into the
final string which reflect the amount of *ignorance* on the part of
Eve. This is done via a publicly known class of universal hashing
functions. THESE FUNCTIONS NEED NOT BE ONE-WAY, and they generally
aren't. The important qualities are that (1) each hash value
corresponds to (approximately) the same number of inputs, and (2) that a
randomly chosen function from the class is "uncorrelated" with the
distribution of strings being hashed.
The result does not depend on any unproven conjecture, and is provable.
I hope this helps you understand the paper.
Nicol
P.S. As you can probably tell, trying to explain something clearly
often takes a lot longer than learning something yourself. If you
cannot understand my explanation, even after reading it carefully
several times, I would suggest getting help from a live tutor.
Continuing the discussion on-line will probably take too much
time/work. Happy learning.
> Back in original focus: It is NOT whether from 4-5 one can get to 5-5.
> It is: how do you get this 4-5 in the VERY FIRST PLACE? and guarantee
> it? Please consider a concrete example at the point you can 'almost'
> guarantee it. I think I gave a hint: ask the author(s) how the bits were
> obtained. What do you think they were obtained? I sense I have a high
> probability of guessing (i.e. your answer(s)) right.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Definition of cracked?
Date: Thu, 19 Aug 1999 12:27:44 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (D. J. Bernstein) wrote:
> James Andrews <[EMAIL PROTECTED]> wrote:
> > Which event defines the cracking of an encryption process?
>
> Let's say you have a bit generator G that stretches a short seed into
a
> 1048576-bit string. The standard meaning of ``G is broken'' is that
> there's a practical test for which these two percentages are
noticeably
> different:
>
> (1) the percentage of seeds x such that G(x) passes the test;
> (2) the percentage of 1048576-bit strings that pass the test.
>
> For example, SEAL 1.0 was broken by Handschuh and Gilbert. There's a
> test that runs in a few seconds for which percentage #1 is measurably
> higher than percentage #2.
>
Speaking of SEAL, do you know where I can find more information on it?
I looked at IBM and found nothing.
> > Is a system considered broken if it is beaten by a brute force
method?
>
> Yes. For example, any fast generator with a 40-bit seed is broken. The
> test ``is this equal to G(s) for some s?'' is practical, since it can
be
> checked with only 2^40 evaluations of G; for this test, percentage #1
is
> 100%, and percentage #2 is almost exactly 0%.
>
> This is why conservative designers use much larger seeds.
>
> ---Dan
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: NIST AES FInalists are....
Date: 19 Aug 99 13:16:43 GMT
Douglas A. Gwyn ([EMAIL PROTECTED]) wrote:
: JPeschel wrote:
: > You gave classical ciphers as an example of
: > "real world" ciphers that the NSA has broken.
: The fact that public
: cryptographers have no clue about this would be
: one of the things that would lead me to conclude
: that they are way behind the state of the art.
: I can say that they are behind the state of the
: art, but I can't explain how I know that without
: risking damage to intelligence production.
And one doesn't have to be the DIRNSA to be acquainted with one or two
incidents or examples of where the NSA had solved something whose solution
is not publicly known.
To me, it seems quite reasonable to conclude, on a speculative basis, that
the NSA would have a level of expertise beyond what is available in the
public sector. It seems only reasonable.
However, I also suspect that if everyone who communicated in cipher or
code had access even to computer equipment to use for that purpose, even
if it was as limited as, say, a Radio Shack Color Computer (well, that
wasn't that bad, with a 6809 and even hardware multiply), and used it
properly, taking cognizance of the public state of the art, I think that
even being 10 or 20 years ahead in some areas would not enable you to read
their mail purely through cryptanalysis.
Fortunately, it may be presumed that not everyone is doing that yet, and
other attacks - compromise of key material, interception of RF leakage -
are available when warranted.
Thus, I can accept they are ahead while still not being confident that
there is an awful lot of ciphertext they are able to read.
John Savard
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: CRYPTO DESIGN MY VIEW
Date: Thu, 19 Aug 1999 14:51:53 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(wtshaw) wrote:
>In article <7pfhpg$1t9m$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
>>...Which brings up another point when I post my code for dscussion how could
>> lawyer types like you prove I violated any patent if my coding is such that
>> no one can even decipher what I did even when it is in plain site.
>>
>Einstein wrote words to the effect that if you can't explain something to
>a child, then you probably do not understand it well enough yourself.
>
>I feel that algorithms are best explained in non-cryptic format; a
>specific implementation of an algorithm may be written in differenct forms
>of source code, yet remain equivalent in ciphertext produced as long as
>the same principles and formulae are followed.
>
>Being able to simply plug in sourcecode and make it work has no
>requirement on the user that it be understood; whereas, writing from a
>description mandates a complete understanding of the algorithm.
But writting the code from scratch and makeing it work does acquire
some degree of understanding. I wrote much code at work without anyone
really understainding what it did. It is just that the code worked sure most
people can't do that without following reciepes. But there are many cooks
who just throw great food dishes together yet they can't write a book on
cooking.
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] (John Winters)
Crossposted-To: comp.lang.clipper,comp.security.misc
Subject: Re: Blowfish algorithm - Is it foolproof?
Date: 19 Aug 1999 15:01:12 +0100
In article <[EMAIL PROTECTED]>, Tom Leylan <[EMAIL PROTECTED]> wrote:
>Pradeep,
>
>Great... 3 answers none of which appear to be to the question you posted.
>Let me try and translate from English to English by asking a simple question
>of those that understand the Blowfish encryption algorithm.
>
>What "do you get" when you get an incorrect answer. Clearly Pradeep is
>asking NOT if the number he encrypted is secure from decryption but rather
>would a bogus decryption, i.e. one that was attempted and failed, return a
>number that for all intents and purposes "could" be correct. In other words
>if his function simply decrypts and he gets 67890 he is going to act on it
>not knowing it wasn't the original number. How would he know?
If you read back through the preceeding answers you'll see this question
has already been answered - possibly not in the form that you wanted, but
there is no doubt that the responders have addressed the question which
was asked.
>I can think of plenty of things I would like to know about Blowfish and
>other encryption algorithms but if nobody can understand the simple
>questions I'm not exactly sure what will happen when I ask the tough ones.
The question has been answered - perhaps the problem is not one of
comprehension of the question, but of your comprehension of the answers.
John
--
John Winters. Wallingford, Oxon, England.
The Linux Emporium - a source for Linux CDs in the UK
See http://www.linuxemporium.co.uk/
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Q. a hash of a hash ...
Date: Thu, 19 Aug 1999 10:24:26 -0400
Yes, yes, Helger Lipmaa was the one that initialy came up with this proof
in this newsgroup discussion! But I have defended it! ;)
Anton
------------------------------
From: [EMAIL PROTECTED] (Preditor31)
Subject: Where to find
Date: 19 Aug 1999 14:12:45 GMT
Where can I find an encryption and a decrytion program? Also how would I go
about learning how to break encryption?
Thomas
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Q. a hash of a hash ...
Date: Thu, 19 Aug 1999 10:12:57 -0400
> Consider the following counterexample:
> H(x) = SHA1(x_2,..,x_n) + (x_1,0,0,..,0)
> where x_j means the j-th bit of x and `+' stands for xor.
> H is likely to be collision resistant, under standard assumptions,
> yet H2 is not: letting y = x + (1,0,0,..,0), we see that
> H2(y) = H(y) + y
> = SHA1(x_2,..,x_n) + (y_1,0,0,..,0) + y
> = SHA1(x_2,..,x_n) + (1+x_1,0,0,..,0) + x + (1,0,0,..,0)
> = SHA1(x_2,..,x_n) + (x_1,0,0,..,0) + x
> = H(x) + x
> = H2(x)
> so x,y form an easy collision for H2.
Very nice!
------------------------------
From: John Myre <[EMAIL PROTECTED]>
Subject: Re: Q. a hash of a hash ...
Date: Thu, 19 Aug 1999 08:16:26 -0600
Anton Stiglic wrote:
>
> You should read his proof as follows:
>
> 1. First I proove that if I found a collision for H, I have one for H^2:
> (this is easy): if I have x!= y and H(x) = H(y), then
> of cours H(H(x)) = H(H(y)), and I have found
> a colision for H^2.
>
> 2. Then I proove that if I found a collision for H^2, I have one for H:
> if I have x!=y such that H(H(x)) = H(H(y)), then I have one
> of two cases:
> a: H(x) = H(y): in wich case I have a collison for H.
> b: H(x) != H(y): in wich case I denote x' = H(x) and
> y' = H(y). I can now say that y' != x' and H(x') = H(y').
>
> So, to conclude, if I have a collison for H, I have one for H^2 (1),
> and, the other way around, if I have a collison for H^2 I have one
> for H (2).
>
> It is a simple and nice proof, it prooves that H and H^2 are equaly
> collision resistant.
>
> Anton
I will agree that if it is computationally difficult to find
collisions for H, then it is still difficult to find collisions
for H^2. But I still have a problem with your conclusion, as
stated, and I'll try and explain why. (This will probably be
wordy - but when am I not?).
When you say "H and H^2 are equaly collision resistant", I
infer that you could say H^2 is "less" collision resistant,
or "more" collision resistant. This is reasonable, since
it is never *impossible* to find collisions for a hash,
given that it takes any length of input and produces a fixed
size output. So we could define collision resistance by
some numerical estimate of the amount of work it takes. In
this case, however, although I could accept that H^2 is
"nearly as collision resistant" as H, I do not think you
have proved that they are *equally* collision resistant.
I suspect that actually you are thinking of collision
resistance as a binary value: either a hash function *is*
collision resistant, or it *is not*. This is reasonable
also, but presents the problem of exactly how you define
it. And I think that, at the very least, you need to
somehow include the amount of work it takes to find a
collision in the definition. Then I think the proof
above will end up with a limitation of some sort, that
allows H^2 to become non-collision resistant if H just
barely qualifies.
Now on to my problem. The proof above can be repeated, by
substituting in H^2 for H, to prove that H^2 and (H^2)^2
(i.e., H^4) are equally collision resistant. Can we then
say that H and H^4 are equally collision resistant? How
can we not? It makes no sense to say "equal" for a
relation that is not transitive in this way.
Inductively, then we get that H^(2^n) and H are equally
collision resistant for *any* non-negative integer n. This
I do not think is reasonable.
I will endeavor to construct a counterexample. Suppose that
H outputs 160 bits. Then suppose we choose some random
permutation P of the integers from 0 to 2^160 - 1 from among
those thay comprise a single cycle (there are (2^159)!
permutations like that). Then we break the cycle by choosing
some F in 0 to 2^160 - 1, and setting P(F) = F. Now define H
as some random function (maybe we let God provide the True
Random Numbers we need) on inputs with more or fewer than
160 bits, and H = P for inputs of exactly 160 bits. The fact
that H as defined can't actually be implemented (short of
prayer wheels or magic or something) is not important - the
proof above doesn't say anything about how hard it is to
compute H.
(Stick with me here).
Now obviously, unless we know P somehow (that is, instead of
a "random" choice of P, we compute it using some numerical
method), it is quite hard to find collisions for H, and I
would claim that H is collision resistant. On the other
hand, H^(2^160) maps *every* input to F, and so finding
collisions is trivial! Recall that we showed above that
H and H^(2^n) must be "equally" collision resistant. So
where does this break down?
My opinion is that saying H and H^2 are "equally" collision
resistant is simply too strong of a statement. In practical
terms, I am sure that if H is a good hash function, then H^2
is still a good hash function - not quite as good, perhaps,
but still good enough. Helger's comments were applicable;
I just don't think they will stretch quite as far as your
proof goes.
John M.
------------------------------
From: Anton Stiglic <[EMAIL PROTECTED]>
Subject: Re: Q. a hash of a hash ...
Date: Thu, 19 Aug 1999 09:40:21 -0400
> I think it's worth pointing out that the difference
> in computation here is not a factor of two. If we
> can find a collision in H^2, it only takes two more
> more hashing operations and a comparison to find a
> collision if H^2. So really it's "Two easy
> operations less than an intractable amount of
> computation is still intractable".
O.k., I'll agree to that! :)
Anton
------------------------------
Date: Thu, 12 Aug 1999 11:12:03 +0200 (CEST)
From: Anonymous <[EMAIL PROTECTED]>
Subject: Future Cryptology
Hello All,
I surmise that frequently used encryption software such as PGP (Idea) , has
probably been broken by the NSA, (I have no proof of this, but then again
there is no positive proof that these algorithms are in fact still secure).
On this surmise I would like to know if there are any new developments
taking place in the civilian cryptographic world to counter this possibility
?.
I base my uneasiness on the fact that the NSA, US Government etc., have been
pretty silent on these matters of late :-) .
Yes - I am probably over paranoid :-)
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: LFSRs in a5
Date: Thu, 19 Aug 1999 14:23:33 GMT
In article <[EMAIL PROTECTED]>,
Maciej Maciejonek <[EMAIL PROTECTED]> wrote:
> I'm looking for any information about LFSRs used in a5.
> I know that this binary stream cipher consist of three short Fibonacci
> LFSRs of sizes 19,22 and 23 respectively.
I have source code for it if that helps... ask in private email.
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: New encryption algorithm
Date: Thu, 19 Aug 1999 15:55:05 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(JPeschel) wrote:
>>[EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) writes:
>
>
>> Joe I am not sure I really belive it is as easy as you say.
>
>I didn't say it was easy. I said it was tough but possible
>for a newcomer, an unknown, or a revolutionary to break
>into print no matter the genre: scientific or popular.
>
>>Suspose I wanted to submit my scott16u with a few pactches
>>such as array sizes to a Journal Where the write up is short but that
>>would contain the full source code with operation examples.
>> I would rather do examples than write. But do you honestly
>>know of one that I can do this. And would not the office have to
>>be in the US since I could not export it out legally. I would
>>be willing to do this but I don't want to pay for something
>>phony.
>
>Don't pay for publication! Generally a popluar magazine pays
>you. The Dobbs Journal, or something similar, might offer
>payment, but I've never written for them, and you've insulted
>the one fellow I know who has.
Well I still know a fellow who writes numberous articles
for Dr Dobbd. But what ammased my about Dr Dobbs. is that
they seem to make a lot of mistakes. Like the IDEA article of
several years back. But I a did contribute some stuff to Dr
Dobbs when this friend write an article on Quaterions. But
I thought even that article had some small errors but Joe
if you look you can find my name.
>
>Other academic or scientific journals might pay little, or nothing
>at all, except for contributor copies or a subscription, and prestige.
>You're going to have to decide who your target audience is, and
>where you want to get published. You'll need to read the
>publication, and, request, if available, author's guidelines about
>format and style. Could be just MLA, but you better ask.
>
What the hell is MLA remember I an not a writter and I hate
reading. I don't care who the target is. It would just be nice
to get amagizine to print the Source code. So that I can send
it freely and legally to people that ask for a copy. Also there
is a updated scott16u I would like an easy way to distribute
the updates.
>> If you like you could proof read the writting part for any errors
>>in grammer and use your name as co-writer or what ever.
>> Or if you wish go all the way and do scott19u instead
>>
>I would consider re-writing a short of description scott16u, but
>that re-write is going to entail translating it into English from the
>original Scott-ish :-)
>
>Kidding aside -- if you send me a good description of scott16u to
>re-write for you, I'll do it under a few conditions. First, lay-off
>the personal attacks. They do you and your ciphers absolutely
>no good. That means no attacks under an alias, either. :-) You should
>also make an apology to Bruce and others, here, too. Perhaps
>doing those things will help restore your credibility.
I still think Bruce owes me an apology first. A long with his
buddy David Wagner. Both of these people have attacked my stuff
saying it can't be good. Most recently David Wagner for saying that
the slide attack shows it is dead when that was a lie. SEcondly
Bruce never even had the honesty to write back when his company
use to send out all the SPAM. I don't like spammers especially when you
write to them and they don't write back. I am not very good at ass
kissing. But I am humble enough to apologise to both if they
apologise to me. I will then be nice. However nice is a realitive term
I am sure I have the gift to piss people off without really trying.
But thanks for your offer.
>
>I know this is asking a lot, but it's cheaper than paying my rates
>for a re-write. You can still be a flamboyant maverick, if you
>want, but you don't need to insult folks, especially those in
>a position to help you or to publish your stuff.
>
>Joe
>
Joe I still think you don't understand Bruce. He comes over the net
as an arrogant fellow. I am sure if I was good at ass kissing I could
have gotten on his side like Tommy boy. But I think he sees himself
as a know it all crypto god. And would do anything in his power to prevent
someone from becomming more known than he. He is not the type of
person who really want to learn outside of his views and fills threatened
by others. So he would not allow one to be come more known. You are
no threat to him since you are interested in crypto but don't plan to do
anything new in it. I am interested in making crypto better. Because I
see a world where that masses are slaves to the few elite in power unles
people can communicate freely with one another with out fear of
government destroying and controlling all creativity.
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
------------------------------
** 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
******************************
