Cryptography-Digest Digest #860, Volume #12 Fri, 6 Oct 00 22:13:00 EDT
Contents:
Re: Q: does this sound secure? (Thomas Wu)
Re: On block encrpytion processing with intermediate permutations (Mok-Kong Shen)
Re: NSA quote on AES (Mack)
Re: Storing an Integer on a stream (Joke) ("William A. McKee")
Re: CRC vs. HASH functions (Mack)
Re: NSA quote on AES (Bill Unruh)
Re: one time pad using a pseudo-random number generator (Bill Unruh)
Re: Choice of public exponent in RSA signatures (Bob Silverman)
Re: Rijndael test vectors (Mack)
Re: what is wrapped PCBC? (Mack)
Re: Getting best available security without knowing which cipher to use (Mack)
----------------------------------------------------------------------------
From: Thomas Wu <[EMAIL PROTECTED]>
Subject: Re: Q: does this sound secure?
Date: 06 Oct 2000 18:00:50 -0700
"William A. McKee" <[EMAIL PROTECTED]> writes:
> So ... I scrapped my first attempt and use SRP instead. A very nice package
> but it took a while to get the config.h right for WIN32. A big "Thank You"
> goes to Tom and his team. (To Tom: If your interested in the diff, and there
> were a few minor changes to make the code compile "clean" with MS VC++ 6.0,
Certainly - we'll discuss the platform-specific stuff via e-mail.
> please email me. Also, I made some changes to the Java to make it 1.2/1.3
> compliant.) The problem is that java.security.SecureRandom takes forever the
> first time it is called so I replaced it with the good old java.util.Random.
> Does this make the SRP weaker? If so, in what way?
Potentially, it may weaken the security if the random values have
insufficient entropy. For example, if the client secret "a" has a
limited number of possible values, an attacker might be able to
guess it from g^a that is sent.
> Also, why is SRP safe against password guessing attacks? Seems like it
> suffers from the same problem I had originally in my first attempt.
No it doesn't - the first attempt you described allowed an attacker who
eavesdropped on an authentication session to verify guessed passwords
against the exchanged messages. This attack doesn't work against SRP
because of the random secrets generated by the client and server. The
NDSS paper (available from the SRP Web site) explains the protocol in
more detail.
> Thanks again,
> Will McKee.
> [EMAIL PROTECTED]
--
Tom Wu * finger -l [EMAIL PROTECTED] for PGP key *
E-mail: [EMAIL PROTECTED] "Those who would give up their freedoms in
Phone: (650) 723-1565 exchange for security deserve neither."
http://www-cs-students.stanford.edu/~tjw/ http://srp.stanford.edu/srp/
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On block encrpytion processing with intermediate permutations
Date: Sat, 07 Oct 2000 03:26:55 +0200
Bryan Olson wrote:
>
> Mok-Kong Shen wrote:
>
> > Bryan Olson wrote:
> > >
> > > Mok-Kong Shen wrote:
> > > [...]
> > > > Now please tell me what if there is no permutation
> > > > at all and you have before you the original block cipher
> > > > and you use a chosen ciphertext on it. Would that involve
> > > > less work or more work than in the case with permutation as
> > > > I described? I like to have a definite answer and a tiny
> > > > bit explanation for that.
> > >
> > > If you think your question is so important, why are you
> > > unwilling to work on it? I think it's nonsense, based on not
> > > studying the issues. How much work is it to break an
> > > unspecified block cipher? Have you even thought about whether
> > > the question is well-formed enough to make sense?
> >
> > Since you seem to claim that with permutation is poorer
> > than without (i.e. with the original block cipher) that
> > clearly would interest me (for the usefulness of the
> > scheme). Since you are the 'author' of the attack you
> > conceived, you are the person that can at least give
> > some useful information, isn't it?
>
> Seem to claim? Give some useful information? I posted
> it. It's been right there in front of you.
Why can't you say clearly with one short sentence here
whether my scheme is difficult to handle or easier to
handle than the normal case where the block cipher is
used without permutations? If may be that I am, for
whatever reason (good or bad), not aware of what you
have already said. But what I am requesting is only one
short sentence, and should cause you less effort than
the two lines above, I firmly believe. Why didn't you
do that? But I think I can tell the reason why you have
constantly avoided to give the answer through diverse
maneuvres: Because on the one side (understandbly) you
dislike to admit that it takes more work to crack my
scheme than the normal scheme. But on the other side
you also can't claim the opposite, because that's
impossible, as can be simply explained from 'first
principle', i.e. from a very general point of view. For
the block cipher, when used in the normal way, has a
certain measure of strength against any given attack,
including the one that you invent. Now you need, as you
wrote previously, to have a certain large number of
blocks to be processed together in order to realize your
method. This is a 'constraint', while in the original
case, i.e. without permutation, you are free and don't
have that constraint (you can deal with one single block
or any number of blocks you like). It is well-known from
solution of optimization problems that one gets a less
favourable optimum when there are constraints. Thus the
work of the analyst with my scheme must be higher (and
can never be lower) than in the case with the original
block cipher (without permutation). One can look into
the matter in another way: Suppose the total effort to
crack my scheme is less than cracking the original
scheme. That would mean that my scheme combined with
your method constitute a new and better method of
attacking the orginal cipher! (For, if I use in my
scheme always the identity permutation, then the scheme
degenerates to the case of using the block cipher in
the common way.) Do you think that that could ever be
true?
>
> > Having said the above,
> > why do you think it is not well-formed? Could you
> > elaborate that? I want to know whether there is
> > reduction or enhancement of strength. Is this issue
> > not well-formed? Where?
>
> See my rhetorical question on breaking an unspecified
> cipher.
Well-formedness is a syntactic issue, not semantic or
otherwise. So which part of my question is not
well-formed?
>
> > > > Please do answer my question this
> > > > time. If you really want to 'laugh', as you indicated in
> > > > the following part that I snipped, you can do that much
> > > > much better later on, if indeed you succeed to win your
> > > > arguments. I am not used to discussions where people don't
> > > > express their direct opinions. We are discussing science,
> > > > not politics or theology, etc.
> > >
> > > I see nothing in your writing that qualifies as science. I
> > > explained one way your system fails as directly as I could in
> > > my very first post in the thread. I later provided further
> > > detail when it seemed unclear to you. I see no evidence that
> > > you made any serious attempt to understand either what I wrote
> > > or the subjects you brought up yourself. In one case, I
> > > believe you deliberately played dumb, claiming that you could
> > > not understand my language.
> >
> > I described my scheme and you even attempted to work
> > out a method of attack. If you call that not science,
> > what was the nature of your own work?
>
> Look more carefully at what I called not science.
You claimed that nothing in my writing is science. Now
you have previously attempted to work out something to
deal with my scheme. Since my scheme is, according to
your opinion, not science, isn't it clear that your work
was consequently also not science?
>
> > If you think
> > that others in this group is not doing work at a level
> > as high as yours, then you need not deal with them, nor
> > even subscribe to the group. Simply claiming that others
> > are at lower level doesn't automatically lead you to
> > a higher level per se.
>
> I thought I was entirely clear about what I think: the level
> that is inadequate is not your level of knowledge but your
> level of effort. You don't look into the attack. Instead you
> act as if you cannot figure out what exposing the key says
> about your suggestion.
As I argued above, the attack in any case causes more work
than in the case without permutation. 'Exposing the key'
means a crack or a part of it, of course. But see below.
>
> I've learned not to make your questions the center of my
> efforts. I posted proofs in
> http://x56.deja.com/[ST_rn=ps]/getdoc.xp?AN=636649064
> that you yourself requested in
> http://x56.deja.com/[ST_rn=ps]/getdoc.xp?AN=636497466
> You then incorrectly brushed it off as having some bug. Had
> you worked to understand the material, you would not have been
> mislead by what you thought was a counter-example. I can tell
> you that getting the proof to the point that it did not have
> that "bug" took me a while.
I never claimed bugs. If you spend 'enough' resource to
attack with your method, then I suppose that it should
function. However, it is the AMOUNT of the work of doing
your attack that matters. I was thus posing the question
of whether permutation diminishes or enhances the security.
This was in a formulation that I believed to sound better.
Actually I could simply ask you to 'confirm' that there is
more work in attacking my scheme than in the case where
no permuation is present and one has simply the block
cipher as such to deal with.
>
> > > The point is that the scheme inevitably loses synchronization
> > > even in the absence of any attack. How would you handle two
> > > simultaneous streams? If we have some stored ciphertext, how
> > > would we know what state to use to decrypt? If we backs up
> > > keys, how would we restore the PRNG state? If you need a
> > > different state for each message or session, you can either
> > > describe the mechanism that provides it or state that the
> > > system depends on an outside means.
> >
> > The state of the PRNG at the start of a session (the
> > first if many sessions to be used with the same secret
> > material) is given by the secret seed. At the end of
> > the session the current seed can be stored for use
> > in the following session (if there are many sessions).
> > So unless there are attacks of your kind, there is
> > no problem in synchronization.
>
> But there are such attacks. Note that your explanation
> answers zero of the three questions above.
I thought that my statement has made it clear of what I
do with the PRNG and that should have been sufficient
for the questions. O.k., let me deal with them directly
in the following.
What do you mean by two simultaneous streams? There is
one sender and one receiver. Normally there is only one
channel. Messages are send sequentially in it. If there
are more than one channel, why can't we deal with these
independently? There will then be one PRNG for each channel
and the PRNGs may even be different. Of course, the seeds
will also be different. There can be no interference
between the channels at all. (The transmission protocol
separates these.)
The two PRNGs, one at the sender, the other at the receiver,
have at the very beginning the same state (the secret seed).
The first message needs, say, m numbers. After sending,
the sender's PRNG gets a new state. When the message is
processed by the receiver, his PRNG has to generate also m
numbers to process it. So the receiver's PRNG also gets
the same new state. For successive messages, the same thing
happens. So the PRNGs are always automatically sychronized.
Do you mean that some blocks could be lost? I assume that
a high level transmission protocol is used which ensures
the correct delivery of entire messages. Only after a
whole message is received can the receiver start to work as
I described. On the other hand, your attack means insertion
of messages at the receiver side which uses up extra random
numbers and hence causes the states of the PRNGs at both
sides to differ, i.e. loss of synchronization. But this
leads to detection of the attack as I said in a previous
post.
As said above, I assume a high level protocol that
guarantees the correct delivery of messages. So there is
no need of any backup. I thus don't yet understand why you
want to back up keys. If I know the situation you mean,
I'll attempt to answer to that point. Note that both the
sender and the receiver, if necessary, can keep record
of (i.e. store for later reference) the state of the PRNG
at the beginning and/or the end of processing of each
and every message.
M. K. Shen
=================================================================
Was sich ueberhaupt sagen laesst, | Whatever can be said
laesst sich klar sagen; | can be clearly said;
und wovon man nicht reden kann, | and silence must be kept
darueber muss man schweigen. | on what one cannot tell.
|
Ludwig Wittgenstein | (a translation)
(1889 - 1951)
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: NSA quote on AES
Date: 07 Oct 2000 01:12:09 GMT
>
>"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
>> Brian Gladman <[EMAIL PROTECTED]> wrote:
>> : "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote:
>> :> [EMAIL PROTECTED] (David Crick) wrote in <[EMAIL PROTECTED]>:
>>
>> :> >"The National Security Agency (NSA) wishes to congratulate the
>National
>> :> >Institute of Standards and Technology on the successful selection of
>an
>> :> >Advanced Encryption Standard (AES). It should serve the nation well.
>In
>> :> >particular, NSA intends to use the AES where appropriate in meeting
>the
>> :> >national security information protection needs of the United States
>> :> >government."
>> :>
>> :> These are weseal words if nothing else. To say they will use it
>> :> where its appropraite does not mean anything at all. They may
>> :> only use it in the sense of decoding messages. And they don't say
>> :> where its appropriate for them to use. But I guess it is to much
>> :> to expect an honest anwser from them.
>>
>> : Once again we can see that accuracy and objective analysis are not among
>> : your stronger abilities.
>>
>> : You see 'where appropriate' as a 'let out' clause but you fail to notice
>> : that the statement also says that NSA intends to use the AES in meeting
>the
>> : national security ***information protection*** needs of the United
>States
>> : government".
>>
>> : There are none so blind as those who will not see.
>>
>> The get-out clause reduces the positive statement about intended use
>> to meaninglessness.
>
>What you mean is that *you* see this statement as meaningless because you
>judge that NSA is being insincere in making it.
>
>I take a different view, namely that this is a sincere statement of support
>and that NSA does intend to use the algorithm for protecting some US
>national security information. Their policy does not surprise me since
>there are very good reasons for doing this.
>
> Brian Gladman
>
Certainly AES is appropriate for sensitive non-classified data. After the
Skipjack fiasco the NSA is being much more careful.
But I don't see the NSA using a public algorithm for classified data.
Security by obscurity is still an added layer of security. If it is
only a thin veil it may be all that is necessary to prevent some
information from falling into the 'wrong' hands.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
Reply-To: "William A. McKee" <[EMAIL PROTECTED]>
From: "William A. McKee" <[EMAIL PROTECTED]>
Subject: Re: Storing an Integer on a stream (Joke)
Date: Sat, 07 Oct 2000 01:20:47 GMT
Bahahahaha! Good one.
--
William A. McKee
[EMAIL PROTECTED]
Asia Communications Quebec Inc.
http://www.cjkware.com
"We're starfleet: weirdness is part of the job." - Janeway
Ichinin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> "If one store an Int on a Stream, won't it _Float_ away?"
>
> Now - i'd like to apollagise for my joke, but i could not
> resist - besides, some people needs to be cheered up once
> in a while :o)
>
> -Ichinin
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: CRC vs. HASH functions
Date: 07 Oct 2000 01:25:38 GMT
>There is a body of literature that discusses relationships between coding
>theory
>and message authentication.
>
>For example, many MACs are constructed using 2-universal hash functions
>composed
>with some type of cryptographic hash. The idea is to use the hash function
>to
>operate on the full message, and produce a small tag, and then apply the
>cryptographic construct to this smaller tag. This approach (hopefully) saves
>time
>since the cryptographic work is done on a small tag.
>
>UMAC is one such approach. A number of other universal hash function
>constructions have been proposed, and many of them are based on constructions
>from
>coding theory.
>
>Whether a CRC is "better" than a hash function is not well defined until you
>specify what you mean by "better." If you're interested in message
>authentication
>or integrity, for example, a CRC by itself is not enough.
>
>Zulfikar
>
No one is arguing that if security is desired then a CRC is useless.
That was point 3 of my original post. However if there is no security need
then a CRC is 'better'. Generally if an MAC of some type is being constructed
there is a security need and a CRC is not appropriate.
CRC's are generally best for:
1) compressing entropy free from outside influence.
2) Hashing data for table lookups or other non-security oriented
identification.
3) Random single bit error detection and burst error detection.
>Scott Fluhrer wrote:
>>
>> Mack <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]...
>> > Having been working hard and not here for a while
>> > the topic of CRC vs. HASH functions
>> > came up in a thread.
>> >
>> > 1) CRC are faster than HASH functions of
>> > comparable size. That is a fact. Many
>> > hash functions use a CRC like layer at the
>> > top to mix in data linearly. SHA-1 is no exception.
>> > A table driven 256 bit hash function requires 4 32-bit word
>> > lookups/byte, four 32-bit word XORs, a shift and an XOR
>> > to add data.
>> >
>> > A 16-bit lookup uses fewer lookups but much bigger
>> > tables.
>>
>> However, if you are willing to use a MAC rather than a HASH (which may be
>> appropriate depending on why you are summarizing the file in the first
>> place), there are MACs which can be even faster than CRC. Examples of this
>> would include UMAC (http://www.cs.ucdavis.edu/~rogaway/umac/) and hash127
>> (http://cr.yp.to/hash127.html)
>>
>> --
>> poncho
>
>--
>
>--Zully
>
>-------
>Zulfikar Ramzan (AKA Zully)
>Laboratory for Computer Science, MIT
>NE43-311, (617) 253-2345
>http://theory.lcs.mit.edu/~zulfikar/homepage.html
>
>
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: NSA quote on AES
Date: 7 Oct 2000 01:35:01 GMT
In <AapD5.32676$Cl1.682791@stones> "Brian Gladman" <[EMAIL PROTECTED]> writes:
]"Tim Tyler" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...
]> Brian Gladman <[EMAIL PROTECTED]> wrote:
]> : "SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote:
]> :> [EMAIL PROTECTED] (David Crick) wrote in <[EMAIL PROTECTED]>:
]>
]> :> >"The National Security Agency (NSA) wishes to congratulate the
]National
]> :> >Institute of Standards and Technology on the successful selection of
]an
]> :> >Advanced Encryption Standard (AES). It should serve the nation well.
]In
]> :> >particular, NSA intends to use the AES where appropriate in meeting
]the
]> :> >national security information protection needs of the United States
]> :> >government."
]> :>
]> :> These are weseal words if nothing else. To say they will use it
]> :> where its appropraite does not mean anything at all. They may
]> :> only use it in the sense of decoding messages. And they don't say
]> :> where its appropriate for them to use. But I guess it is to much
]> :> to expect an honest anwser from them.
]>
]> : Once again we can see that accuracy and objective analysis are not among
]> : your stronger abilities.
]>
]> : You see 'where appropriate' as a 'let out' clause but you fail to notice
]> : that the statement also says that NSA intends to use the AES in meeting
]the
]> : national security ***information protection*** needs of the United
]States
]> : government".
]>
]> : There are none so blind as those who will not see.
]>
]> The get-out clause reduces the positive statement about intended use
]> to meaninglessness.
]What you mean is that *you* see this statement as meaningless because you
]judge that NSA is being insincere in making it.
]I take a different view, namely that this is a sincere statement of support
]and that NSA does intend to use the algorithm for protecting some US
]national security information. Their policy does not surprise me since
]there are very good reasons for doing this.
Well, I also see it as a statement like the famous reference
"You will be fortunate indeed to get this person to work for you."
It can be interpreted in various ways. Their statement can be interpreted in a
way so as state that they regard it as weak
It should serve the nation well.= The biggest danger facing the nation is
people hiding their nefarious activities from enforcement agencies. This
standard should serve the nation well in aleviating that danger.
In particular, NSA intends to use the AES where appropriate= It is appropriate
where the communication should appear to be secure, but not be.
in meeting the national security information protection needs =We need open
and transparent government.
Ie, this is hardly an unambiguous statement of support. Now, it may just be
the statement of a bureaucrat who no longer knows how to make definite
unambiguous statements.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: one time pad using a pseudo-random number generator
Date: 7 Oct 2000 01:38:26 GMT
In <[EMAIL PROTECTED]> "William A. McKee" <[EMAIL PROTECTED]> writes:
>Is using a strong pseudo-random number generator (2^19937) as a one-time pad
>a good way to encrypt data? If not, why?
Depends on your definition of strong. Some cryptosystems are just that (eg
RC4). Some random number generators are terrible for crypto, though wonderful
for random simulations.
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Choice of public exponent in RSA signatures
Date: Sat, 07 Oct 2000 01:30:54 GMT
In article <8rb472$174$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Paul Schlyter) wrote:
> In article <[EMAIL PROTECTED]>,
> Roger Schlafly <[EMAIL PROTECTED]> wrote:
<snip, snip>
> Testing for divisibility with 3 may be fast, but generating a new
> prime if p-1 turns out to be divisible by 3 is much slower.
You are ALL wrong.
Select a random integer x. Let S = {2,3,5,7,11....p_n} be the
set of the first n primes. Compute x mod p_i for all p_i \in S.
Then sieve x,x+1,x+2,.... x+h for some reasonable sized h with
all the primes in S. Then sieve out those integers such that (e,p-1)
!= 1. This sieving is FAST. Those numbers in [x, x+h]
are then tested for primality. The probability that a random
number that survives the sieve isn't prime has been reduced by
1 - exp(-gamma)/log(p_n) [Mertens' thm]
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Rijndael test vectors
Date: 07 Oct 2000 01:41:16 GMT
>"John Savard" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> On Tue, 3 Oct 2000 23:11:41 +0100, "Brian Gladman"
>> <[EMAIL PROTECTED]> wrote, in part:
>>
>> >A world I hope we can remove by getting the specification right on such
>> >matters.
>>
>> I'm still miffed that the specification for Rijndael - even the
>> current version - does not exhibit the S-box. That it happens to be
>> the multiplicative inverse on GF(2^8) followed by a bitwise matrix
>> multiply is very nice background material, but prospective
>> implementers ought not to be expected to jump through hoops of
>> advanced mathematics.
>
>I am uncertain of your concern here.
>
>I had no problem implementing from the specification in this area (except
>for the fact that the first report got the bit order inverted).
>
>In what form do you think it should be presented?
>
> Brian Gladman
>
Tabular form is always nice. The bit ordering confusion might still
exist though. The average programmer is not necessarily familiar with
the intracacies of GF(2). For easy implementation both should have
been included.
Similarly the MDS is nice but a practical description could have accompanied
the
mathematical description. There are good reasons for including both however
the only good reason for leaving out the practical description is space and
time
to develop it. I suspect the time to develop a practical description was
lacking.
On the reverse side, I can't think of any reason not to include a mathematical
description of something new. If they had used the table from Square however
I think a reference would have sufficed and a practical description.
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: what is wrapped PCBC?
Date: 07 Oct 2000 01:49:13 GMT
>[EMAIL PROTECTED] (Mack) wrote in <20001006000832.15659.00000334@ng-
>fd1.aol.com>:
>
[snip]
>>
>>wrapped PCBC is basically a form of chaining similar to CBC and PCBC.
>>It uses multiple passes over the text wrapping the last block to the front
>>
>>It is a form of AONT. If the encryption function is unbreakable wrapped
>>PCBC is unbreakable.
>>
>>example
>>
>>P1 P2 P3 P4
>>E1=f(P4^P1^P2)
>>E2=f(E1^P2^P3)
>>E3=f(E2^P3^P4)
>>E4=f(E3^P4^E1))
>
> However in scott19u E1 does not overlay P1 there is a 9 bit shit
>so that the file rotates 9 bits each pass.
Interesting but it complicates the nice description. I can see the use
but it slows it down.
>
>>
>>now here is where it gets interesting
>>
>>second round produces what we will call G
>>G1=f(E4^E1^E2)
>>G2=f(G1^E2^E3)
>>G3=f(G2^E3^E4)
>>G4=f(G3^E4^G1)
>>
>>notice that this is invertible
>>
>>In scott19u and relatives the second xor is changed to a +.
>>
>>It must be decrypted last block first to unwind it.
>>In particular scott19u uses large tables for f and round keys.
>>
>>This prevents 'the Onions attack' by Paul Onions which is
>>a form of Slide attack. It is interesting that it isn't mentioned
>>in David Wagner's paper on Slide attacks. I believe David may have
>>been around a bit when that attack was introduced.
>>
>
> Well at the time David Wanger brought up his slide attack
>he made a grand statement that it was the death of my cipher
>until someone tried it and mentioned some of the problems it
>caused for the slide attack. Wagner in only one small post
>admitted that the slide attack may well not work against it
>but that he did not really understand what my code did.
>I guess having the complete source code that compiles was just
>to hard for him to follow.
> Actually I suspect he never looked at it at all and was just
>spouting BS out his mouth. Most people who attend Berkeley are
>quite arrogant. I konw I have met many of them and one of my siblings
>went there for 3 years. But then again there are a few rare
>good ones from there.
>
Yes but you think he would have given Paul some credit.
>
>>I posted a paper about it a long time back in sci.crypt.research
>>I introduced IS8, RS8 and M8 of those only M8 had round keys
>>and is still unbroken. It is in the north american crypto archive
>>as X8.ZIP
>>
>
> I remeber but for some reasom I thought your name was Maack
>but then again I can't spell worth shit.
>
No the account I was using then was [EMAIL PROTECTED]
>>
>>
>>Mack
>>Remove njunk123 from name to reply by e-mail
>>
>
>
>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:
>
>
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
From: [EMAIL PROTECTED] (Mack)
Subject: Re: Getting best available security without knowing which cipher to use
Date: 07 Oct 2000 01:51:56 GMT
>
>Ray Dillinger wrote:
>>
>> It is possible to split messages into multiple parts and transmit
>> the parts -- so that the message may be reassembled only when all
>> of the parts are present.
>
> Obviously, if you're only missing 128 bits of the message, it can't be
>harder than 2^128 to recover the whole message.
>
> DS
>
>
That is a pretty big only ....
Mack
Remove njunk123 from name to reply by e-mail
------------------------------
** 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
******************************
