Cryptography-Digest Digest #598, Volume #11 Fri, 21 Apr 00 16:13:01 EDT
Contents:
Re: Problems with NTRU (Tom St Denis)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (James Felling)
Re: New version of MIRACL (Mike Andrews)
Re: Primality Test-how many iterations suffice for n digit number ? (David A Molnar)
Re: OAP-L3: Secure, but WAY more dificult to use than other equally (James Felling)
Re: New version of MIRACL (Tom St Denis)
Re: The Illusion of Security ("Douglas A. Gwyn")
Re: OAP-L3: Semester 1 / Class #1 All are invited. ("Douglas A. Gwyn")
new idea for symmetric cipher construction (Tom St Denis)
Re: OAP-L3: Semester 1 / Class #1 All are invited. ("Joseph Ashwood")
Re: The Illusion of Security ("Joseph Ashwood")
Re: Problems with NTRU (lordcow77)
Re: New version of MIRACL ("Dann Corbit")
Re: new Echelon article ([EMAIL PROTECTED])
Re: The Illusion of Security (Tom St Denis)
Re: New version of MIRACL (Tom St Denis)
----------------------------------------------------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: Problems with NTRU
Date: Fri, 21 Apr 2000 19:19:31 GMT
Paul Koning wrote:
>
> Tom St Denis wrote:
> >
> > I don't like the way NTRU presents themselves. Knocking RSA, ECC and
> > Elgamal as bad, slow and insecure....
> >
> > Somethings fishy.
> >
> > Plus they push the idea that you should encrypt data directly with their
> > algorithm instead of a hybrid-system. Is NTRU really that fast?
>
> Someone else said here some time ago that NTRU actually does
> have valid work, it's just hidden underneath amazingly bad
> marketing. It's too bad they haven't fixed that yet.
> Having someone go down for marketing snake oil is fine,
> but going down for doing snake-oil style marketing on what
> is actually a legitimate product would be rather a distressing
> mistake!
>
> paul
Oh I don't doubt there are people going around knowing what is what, but
their website is really bad. They should advertise it on it's true
merit and not cuz it's better then RSA... if that's possible.
Tom
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 14:22:25 -0500
Anthony Stephen Szopa wrote:
> James Felling wrote:
> >
> > > <giant snip>
> > >
> > > I will prove you do not know what you are talking about by you
> > > simply answering this question:
> > >
> > > The OAP-L3 encryption software uses a random number generator.
> > > Now which of the following is the most correct and most
> > > comprehensive description of this random number generator that
> > > it uses: which is the description that results in the random
> > > numbers used in the encryption process?
> >
> > >
> > > 1) The process that outputs the random digits from the MixFiles, or
> > >
> > > 2) the process that results in the OTP files?
> >
> > Well the best way to answer that is "neither"( or "both" -- depends upon how I
>look at it). I
> > agree that the stream data is generated primarially by process #2. However it
>still uses
> > data from process #1 to produce the mix files which are then used by process #2.
>If one
> > examines the crypto literature you will find many algorithims that have
>comentaries by skilled
> > people along the line of "this section of the algorithim is weak -- it does not do
>X properly
> > -- I have found no attack to exploit this property" and this is enough to withdraw
>the
> > algorithim from serious consideration. Why should your program be judged upon a
>different
> > standard?
> >
> > >
> > >
> > > Now define precisely what your supposed flaws are and what is the
> > > exact nature of these "artifacts" you allege?
> >
> > Ok since you have obviously not done even a textbook analisys of your mix file
>generation
> > process I will.
> > I am using your own names for the subprocesses.(P.S. this is not an exhaustive
>list of what I
> > have found, but it is simply the result of a half hour of simple kindergarten
>cryptoanalisys)
> >
> > We start with a file F of all possible 1 to 10 sequences.I shall number them
>F(1),F(2),
> > ....,F(10!)
> >
> > 1) Scramble -- since all other mixing ops are external( they affect the order in
>which the
> > F(i)'s are presented) Scramble is effectively orthogonal to all other MixFile
>creation
> > steps.This means we can effectivly treat all other steps as modifying the set S=
> > Scramble(F(1)), Scramble(F(2)), ....., Scramble(F(10!))
> >
> > 2) Mix -- The "Mix" operation doesn't do a very good job of it. M(i)= the ith
>sequence of
> > Mix(S) has the following properties M(j+105*n)= S(j+105*n) with probability .
>(n>=0, and j=
> > first mix value). Since there are further steps this is less bad than it seems.
> >
> > 3) Redistribute -- This creates 14 files I will denote them as T(1) to T(14), and
>then T(k,m)
> > = themth member of Tfilek.
> > This is aparently accomplished as follows T(k,m)= M( (k-1)*259200 + m ).
> >
> > 4) Shuffle. This Permutes the Tfiles, then data are taken from them in the
>permuted order to
> > generate the mixfile.call this permutation p(x).
> >
> > Attack vs mix file generation.
> >
> > Sincej>=1, T(1,1)= Scramble(F(1)) , and T(8,1)=Scramble(F(1814401)) this meand
>that within
> > the first 14 sequences in the Mix files we have two sequences that are known, this
>will occur
> > regularly within the mix file where within 14 digits at easily computable points
>in the file 2
> > sequences (Scrambled) with known chjaracter exist. Because of this we have very
>good odds of
> > recovering both scramble, and some very good information on P(x) in addition.
>Further, if
> > j>1 we will easily recover scramble as T(1,2) will occur 14 spots later in the
>file and will
> > be a single rearangement swap different from T(1,1)
> > .
> >
> > As you can see the Mixfile.otp has a significant amount of exploitable structure
>-- enough to
> > allow recovery of its generating keys in comparitively short order. Since this is
>the case,
> > it seems likely to me that at least some of this structure could be exploited by
>an analyst
> > working the whole key backward.
> >
> > >
> > >
> > > Let me end with this:
> > >
> > > The accepted test of the security of an encryption process is not
> > > what Mr. Huuskonen has asked for. The accepted test is that it is
> > > assumed that the cracker knows every thing there is to know about
> > > the algorithm, and that the cracker has a substantial amount of
> > > plain text and the corresponding encrypted text. From this
> > > it is demanded that the cracker use this information and knowledge
> > > to crack the software. This is hardly what Mr. Huuskonen is asking
> > > for: he is essentially asking for the key once removed.
> >
> > Yes, to a degree he is. But the same structures that allow him to attack your mix
>file will
> > exist, to a lesser degree in the final output. My guess is that the Mix files
>provide about
> > 20-30 bits of randomness per each(assuming my attack cannot be refined). This puts
>the
> > randomness of your code somewhere in the neigborhood of a 90 to 100 bits( tops)
>when you
> > factor it all in. I will be generous and say you are as secure as 3DES(112 bits).
>Why should
> > we use your code in prefrence to 3DES?
>
> This is nothing but BS and I think you know it.
>
> Let's keep it simple then build from there.
>
> Let's say we start with the original encryption data file: the
> 3,628,800 ten-digit permutations consisting of the digits 0 - 9
> with no repeats. In this original encryption file the permutations
> are arranged in ascending order.
>
> Let's just run the Shuffle process once. The first 259,200 arrays
> are read from the original encryption data file and written to
> TFile1. The next 259,200 arrays are read and written to TFile2.
> The next 259,200 arrays are read and written to TFile3, etc. until
> there are TFile1 - TFile14.
>
> The user then inputs a true random 14 number sequence of the
> numbers 1 - 14 with no repeats. For your information there are
> 14! = over 87 billion possible unique sequences of the numbers
> 1 - 14.
>
> Then these 14 TFiles are interleaved one array at a time according
> to this 14 number sequence.
>
> The resulting output file, we'll call it, MixFile1, is one of over
> 87 billion possible.
>
> You say it will be easy to guess the order of the permutations in
> this MixFile1? How will you do it? There is only one way to do
> it: trial and error by using all the 87 billion 14 number
> sequences. (Because the input was true random you cannot get around
> this by any other means.)
>
> So, after you have produced each of these over 87 billion possible
> MixFile1's you store them confident that you have certainly produced
> the correct MixFile1 among the over 87 billion you have generated and
> stored.
>
> Okay.
>
> Now let us run the Shuffle process again on MixFile1 using another
> true random 14 number sequence of the numbers 1 - 14 with no repeats
> and call the output again, MixFile1. As above, there are over 87
> billion possible sequences.
>
> But there are now over (87E9)^2 possible 28 number sequences of two
> sequences of 14 numbers 1 - 14 in a row.
>
> So now you have to produce and store over (87E9)^2 MixFile1's but
> you can still be certain that at least one of these (87E9)^2
> MixFile1's is the correct one.
>
> Let's say I repeat the process 50 times in total. This means that I
> have shuffled the original encryption data file 50 times using one
> of over 87 billion 14 number sequences with each shuffle. Thus the
> total user input is 50 true random 14 number sequences of the numbers
> 1 - 14.
And therefore enter(a minimum -- strictly for shuffles) 19*50=950 charachters of
input. I agree that
this will provide very high security. But since we use 3 mix files the user inputs
3*950= 2850
characters of input. I accept that your algorithim can be made highly secure by
running multiple
passes across the raw mix file, and if this is done, I also accept that this deals
with the SPECIFIC
objection that I have raised. I had however assumed a comparable amount of input on
the user's part
in comparing the software. ( And its these unseen asumptions that catch you every
time.) I still
feel that your MixFile generation processes have poor diffusion, and any given pass
adds only a
minimal amount of difusion, but if used as you suggest here -- a methodology that is
NOT specificly
suggested in your documentation (and unless this or something similar is specificly
suggested, I
think it very highly likely that the user will NOT do so) -- the resulting MixFile is
highly
resistant to any attack that I can concieve of.
I retract fully my objection given that something to the effect that the user should
use at least 15
seperate processing passes, including at least 1 of all atomic ops is added somewhere.
You have my
apology for misinterpreting your intent there.
I still have some questions/ issues though
1)your program needs several MINUTES and extensive typing to setup before encryption,
while
equivalently
secure algorithims take at worst seconds to setup, and much less of a personal time
investment on an
equivalent machine -- Why should I use it? What benefit does it offer that justifies
the time
investment?
your program generates stream data much slower than, oh say, RC4 for example, why
should I use it in prefrence to other stream algorithims? ( If I enter a comparable
amount of data ,
I could make 6 to 10 seperately keyed 128+bit RC4 passes over my data, and it would
still consume
less of my time-- and unless I am transmitting the sum total of human knowlege any
difference in the
bias level would be beyond notice)
PGP has a much cleaner and easier to use user interface and offers equivalent
security and faster encryption, why should I use your program?
>
>
> This means that there are over (87E9)^50 possible 50 true random 14
> number sequence sequences in a row and that the actual input used is
> only one of these over (87E9)^50 sequences.
I still feel you are exagerating the amount of security provided here. My impression
is that with
the characteristics that you provide 15 passes with 3 mix files will be roughly
equivalent to a
256bit cypher.
>
>
> For you to determine the final MixFile array sequence after 50 runs
> of the Shuffle process with absolute certainty that at least one of
> the MixFiles is the actual one, you will have to produce over
> (87E9)^50 MixFiles, and store them.
>
> Let's see, if each MixFile is over 18MB you will need enough storage
> for 18E6 * (87E9)^50 = 1.5E459 bytes.
>
> But you can at least be sure you have the right sequence somewhere
> among them all.
>
> Your problem now is: which one is it?
>
> Let's say you need three such MixFiles and that the user uses their
> last MixFile1 after 50 Shuffle runs to begin 50 more shuffle
> processes to produce a MixFile2, then run 50 more processes on this
> last MixFile2 to produce a MixFile3.
>
> Similarly as shown in the Theory and Processes Help Files, the odds
> of duplicating MixFile1 with certainty is one in (87E9)^50.
>
> But for duplicating MixFile2 it is one in ((87E9)^50)^2 = (87E9)^100.
>
> For duplicating MixFile3 it is one in ((87E9)^50)^3) = (87E9)^150.
>
> And finally, to guess with certainty, all three MixFiles it would be
> (87E9)^50 * (87E9)^100 * (87E9)^150 = (87E9)^300.
>
> Tell us how you are going to guess the one chance in (87E9)^300 of
> getting the correct three exact MixFiles? (Not to mention store all
> of them.)
>
> We really want to know?
>
> Give up?
>
Yes. The construction you suggest is secure.(vs. me)
>
> Give up.
>
> And we haven't even considered subsequent processing of the random
> binary number files produced from the MixFiles.
>
> Now, what is it you don't understand about unbreakable?
>
> (I bet you would you like me to sneak you the key right about
> now, eh?)
>
> See, how plain it is in layman's terms. This is why I say that the
> entire software package is understandable by anyone with average
> intelligence.
Perhaps, but the documantation manages to hide many of the useful characteristics of
the program.
In addition I think that there is substantial improvement available in the processes
selected, the
methodology used, and the documentation. It has been said that with enough
differently keyed
rounds, even the worst(non- auto inverting) cypher will become secure. This is a
clasic example of
this.
>
>
> Now what exactly don't you understand?
>
> (And whatever it is you'd like to say can you say it in laymen's terms
> so everyone can understand you?)
I will when you do.
>
>
> Thank you.
>
> (All of this is just as simply explained in the Help Files at
> http://www.ciphile.com)
------------------------------
From: [EMAIL PROTECTED] (Mike Andrews)
Subject: Re: New version of MIRACL
Date: Fri, 21 Apr 2000 19:30:26 GMT
Tom St Denis <[EMAIL PROTECTED]> wrote:
: Dann Corbit wrote about problems getting MPI to compile:
[snip lots of make output]
:> Quite frankly, I don't think it holds a candle to MIRACL or FreeLip, for
:> that matter.
:>
:> However, for whatever UNIX platform it was built on, I'm sure it does an
:> adequate job.
: That's because you don't know how to use your tools. In three seconds I
: can compile mpi.c to mpi.o with GCC. True you have to configure it (i.e
: not use the logtab) but after that one minor change it works flawlessly
: with me.
Tom, rather than putting someone down for not knowing how to use his
tools, why not try some education. If you tell him how, then he'll
have the information there to use next time. If you _post_ the how-to,
then we'll _all_ have the information. It might just come in handy to
someone else at some time in the future.
--
Telstra is the cesspool of the South Pacific.
@Home is the cesspool of the Americas.
Get it straight. There is more than one cesspool.
-- Steve Sobol, in nanae
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: Primality Test-how many iterations suffice for n digit number ?
Date: 21 Apr 2000 19:21:58 GMT
Francois Grieu <[EMAIL PROTECTED]> wrote:
> I believe (I have no reference) using the small primes 2,3,5,7,11,
> 13,17,19 as test values [or random distinct small primes to
> guard against someone even attempting to forge a counterexample]
> will gives robustness at least equivalent to random values, and
> further simplifies the test.
Along these lines : in Maurer's article on fast generation of prime
numbers[1] it mentions a preprint due to Mauer and Bleichenbacher in
which they show that a Miller-Rabin test with the primes 2, 3, 5, 7, 11,
13, and 23 is guaranteed to be correct for numbers less than 10^16.
Anyone know if the proof ever appeared? I skimmed over Bleichenbacher's
thesis (which has a chapter on pseudo-primes perhaps relevant to this
discussion, btw) but didn't see it; did I overlook something, or am I
supposed to develop it myself from the results there?
Thanks,
-David
[1]
"Fast Generation of Prime Numbers and Secure Public-Key Cryptographic
Parameters"
J. Cryptology 8:3 p.123-156 1995
ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/Prime_Generation.abstract
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Secure, but WAY more dificult to use than other equally
Date: Fri, 21 Apr 2000 14:32:39 -0500
This program is a clasic example of the assertion that any algortihim that
does not form a group over its keys can if reiterated enough be made
arbitrarially secure.
I have withdrawn any criticisms that I have in re: the security of this
program provided that the Mix files are generated by a sulficient number of
passes of his processes.
I now wish for him to adress the severe usability and documentational
issues that his program possesses.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: New version of MIRACL
Date: Fri, 21 Apr 2000 19:40:57 GMT
Mike Andrews wrote:
>
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> : Dann Corbit wrote about problems getting MPI to compile:
>
> [snip lots of make output]
>
> :> Quite frankly, I don't think it holds a candle to MIRACL or FreeLip, for
> :> that matter.
> :>
> :> However, for whatever UNIX platform it was built on, I'm sure it does an
> :> adequate job.
>
> : That's because you don't know how to use your tools. In three seconds I
> : can compile mpi.c to mpi.o with GCC. True you have to configure it (i.e
> : not use the logtab) but after that one minor change it works flawlessly
> : with me.
>
> Tom, rather than putting someone down for not knowing how to use his
> tools, why not try some education. If you tell him how, then he'll
> have the information there to use next time. If you _post_ the how-to,
> then we'll _all_ have the information. It might just come in handy to
> someone else at some time in the future.
Sorry about that. I was a bit rude. Basically I changed the #ifdef
logtab thing to ignore it. Then I just do
gcc -O2 -Wall -c mpi.c -o mpi.o
And it works it's magic.
Tom
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Fri, 21 Apr 2000 18:06:17 GMT
Tom St Denis wrote:
> Of course of all the ciphers used since the 70's none of them have yet
> been broken.
What makes you think that?
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 18:26:29 GMT
Anthony Stephen Szopa wrote:
> Tell us how you are going to guess the one chance in (87E9)^300 of
> getting the correct three exact MixFiles?
If your entire security argument lies in the excessively large number
of possibilities, then why not choose a simpler, faster, and smaller
system such as most of the AES candidates, which share this property?
Of course, it is a basic fact that such a proprty is *necessary* in
order to foil brute-force searching attacks, but it is not
*sufficient*, as many historical cryptosystems were defeated despite
claims of their inventors/sellers based on combinatorial arguments.
Tell us why cryptanalysis of OAP-L3 cannot proceed without knowing
(or guessing) the MixFiles in advance. I still think the fastest-
moving MixFile should be relatively easy to reconstruct, along with
a static equivalent for the remaining combination of MixFiles, by a
chaining method similar to those used in the cryptanalysis of rotor
systems.
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: new idea for symmetric cipher construction
Date: Fri, 21 Apr 2000 19:45:46 GMT
Basically you take the input (say 32 bytes) put it into two square
matrices (4x4 each) called L and R. then you do something like
for r = 0 to rounds do
A = A + F(K[2r] * B)
B = B + F(K[2r+1] * A)
Where K is an array of square matrices that hold the round keys. The F
function can do any re-ordering and substitions required.
I don't know what it would have over a normal feistel, but it sure does
look cool.
One thing for sure is that F function will have todo some permutation of
the input (just speculation, but it may not have to). The
multiplication of the round key could be done modulo a prime (say 257).
More food for thought.
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 12:30:22 -0700
Crossposted-To: talk.politics.crypto
> Then these 14 TFiles are interleaved one array at a time
according
> to this 14 number sequence.
I believe this point is the start of the problem. I can
think of more than a dozen interleaving algorithms just off
the top of my head, you will have to be more specific.
Joe
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Fri, 21 Apr 2000 12:48:11 -0700
> Of course of all the ciphers used since the 70's none of
them have yet
> been broken. So that's a good track record so far....
That's where I think you're quite wrong. Just looking at the
opening round of AES several of the proposals were quite
effectively broken. Looking on this ng we have seen several
proposed ciphers, and for quite some time, not a single one
hasn't had massive amounts of progress made against it. The
finalists for AES are only 5 of thousands that have been
thought of in the same time period. While I agree that the
breaking of an AES finalist in the next few years is
unlikely, unbreakability against an infinite future is at
best laughable.
Joe
------------------------------
Subject: Re: Problems with NTRU
From: lordcow77 <[EMAIL PROTECTED]>
Date: Fri, 21 Apr 2000 12:46:14 -0700
Their web site has very well written introductions on the basic
structure and implementation of their algorithm as well as
detailed, technical, analyses of the performance and security
parameters. Their documentation on their truncated polynomial
ring cryptosystem is as good as Certicom's on eliptic curve
cryptography. I'm not seeing much to complain about. It's
definitely not snake oil.
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Subject: Re: New version of MIRACL
Date: Fri, 21 Apr 2000 12:59:20 -0700
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
>
> Mike Andrews wrote:
> >
> > Tom St Denis <[EMAIL PROTECTED]> wrote:
> >
> > : Dann Corbit wrote about problems getting MPI to compile:
> >
> > [snip lots of make output]
> >
> > :> Quite frankly, I don't think it holds a candle to MIRACL or FreeLip,
for
> > :> that matter.
> > :>
> > :> However, for whatever UNIX platform it was built on, I'm sure it does
an
> > :> adequate job.
> >
> > : That's because you don't know how to use your tools. In three seconds
I
> > : can compile mpi.c to mpi.o with GCC. True you have to configure it
(i.e
> > : not use the logtab) but after that one minor change it works
flawlessly
> > : with me.
> >
> > Tom, rather than putting someone down for not knowing how to use his
> > tools, why not try some education. If you tell him how, then he'll
> > have the information there to use next time. If you _post_ the how-to,
> > then we'll _all_ have the information. It might just come in handy to
> > someone else at some time in the future.
>
> Sorry about that. I was a bit rude. Basically I changed the #ifdef
> logtab thing to ignore it. Then I just do
>
> gcc -O2 -Wall -c mpi.c -o mpi.o
>
> And it works it's magic.
I made the same change (as I already stated) and it still won't compile.
The diagnostics issued by GCC show that it's a chummy hack, anyway. I'll
stick with stuff that works right out of the box.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Reply-To: [EMAIL PROTECTED]
Date: Fri, 21 Apr 2000 19:34:38 GMT
On Fri, 21 Apr 2000 12:01:29 -0700, Diet NSA <[EMAIL PROTECTED]>
wrote:
>You might want to read this brief news story which mentions a
>possible link between U.S. intel agencies, IBM, & Microsoft
>regarding access to encrypted data:
>
>http://www.theregister.co.uk/000412-000020.html
Thx, I've seen that.
Some things to cogitate on:
1. The U.S. requires that _all_ materials with a strategic defense
purpose be second-sourced. Because Windows is on so many DoD computers
(and every other agency), and on so many computers of companies who
supply the DoD, it legitimately would be a product with a strategic
defense purpose. But Mr. Gates' company got an exception to the second
sourcing rule and there it no second source required for Windows.
Curious.
2. The (Baltimore) Sun today is running an article where the Russian
Federal Sercurity Service is requiring ISPs in Russia to buy bugging
equipment so the FSS can spy on the ISPs customers. The brouhaha is
that the FSS can't afford the bugging equipment and wants its victims
to pay for it. Isn't this what Uncle Sam tried to do with the Clipper
chip? And I'm thinking to myself, well it's kind of like being forced
to buy "bundled" Windows with a "bundled" backdoor, isn't it?? The
spooks are passing along the cost. Just keen business sense, right
Mr. Deutch? Gotta keep the GAO happy. Curious. Freaking Russian
spooks can't be creative at all; just stealing ideas from Uncle Sam.
URL to Sun story on FSS:
http://www.sunspot.net/content/cover/story?section=cover&pagename=story&storyid=1150330204743
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Fri, 21 Apr 2000 20:06:24 GMT
Joseph Ashwood wrote:
>
> > Of course of all the ciphers used since the 70's none of
> them have yet
> > been broken. So that's a good track record so far....
> That's where I think you're quite wrong. Just looking at the
> opening round of AES several of the proposals were quite
> effectively broken. Looking on this ng we have seen several
> proposed ciphers, and for quite some time, not a single one
> hasn't had massive amounts of progress made against it. The
> finalists for AES are only 5 of thousands that have been
> thought of in the same time period. While I agree that the
> breaking of an AES finalist in the next few years is
> unlikely, unbreakability against an infinite future is at
> best laughable.
> Joe
I meant used. The lastest used ciphers are 3des, cast128 and idea, all
of which have had considerable analysis put against. Of course anybody
can make a cipher that is trivial breakable. But those that have
survived all our known tests, are secure.
Tom
------------------------------
From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: New version of MIRACL
Date: Fri, 21 Apr 2000 20:07:31 GMT
Dann Corbit wrote:
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> >
> >
> > Mike Andrews wrote:
> > >
> > > Tom St Denis <[EMAIL PROTECTED]> wrote:
> > >
> > > : Dann Corbit wrote about problems getting MPI to compile:
> > >
> > > [snip lots of make output]
> > >
> > > :> Quite frankly, I don't think it holds a candle to MIRACL or FreeLip,
> for
> > > :> that matter.
> > > :>
> > > :> However, for whatever UNIX platform it was built on, I'm sure it does
> an
> > > :> adequate job.
> > >
> > > : That's because you don't know how to use your tools. In three seconds
> I
> > > : can compile mpi.c to mpi.o with GCC. True you have to configure it
> (i.e
> > > : not use the logtab) but after that one minor change it works
> flawlessly
> > > : with me.
> > >
> > > Tom, rather than putting someone down for not knowing how to use his
> > > tools, why not try some education. If you tell him how, then he'll
> > > have the information there to use next time. If you _post_ the how-to,
> > > then we'll _all_ have the information. It might just come in handy to
> > > someone else at some time in the future.
> >
> > Sorry about that. I was a bit rude. Basically I changed the #ifdef
> > logtab thing to ignore it. Then I just do
> >
> > gcc -O2 -Wall -c mpi.c -o mpi.o
> >
> > And it works it's magic.
>
> I made the same change (as I already stated) and it still won't compile.
> The diagnostics issued by GCC show that it's a chummy hack, anyway. I'll
> stick with stuff that works right out of the box.
Why don't you email the author directly. It may be a trivial problem.
I don't think you should call it a hack, cuz well it works well in all
environments I have seen it in. Either case you like miracl better
whoopy a number is a number is a number.
Tom
------------------------------
** 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
******************************
