Cryptography-Digest Digest #419, Volume #14 Wed, 23 May 01 20:13:01 EDT
Contents:
Re: test vectors ("Simon Johnson")
Re: New type of cryptanalysis (David Wagner)
Re: Small (not fast) RIPEMD-160 (jlcooke)
Re: Best, Strongest Algorithm ("Joseph Ashwood")
Re: Small (not fast) RIPEMD-160 (Ian Stirling)
Re: Great Free Encryption Software (Charles Blair)
Re: Great Free Encryption Software (SCOTT19U.ZIP_GUY)
Re: Best, Strongest Algorithm (SCOTT19U.ZIP_GUY)
Re: Small (not fast) RIPEMD-160 (Paul Rubin)
Re: Small (not fast) RIPEMD-160 (Paul Rubin)
Re: Best, Strongest Algorithm ("Tom St Denis")
Re: Best, Strongest Algorithm (gone from any reasonable topic) ("Tom St Denis")
Re: Ideas for project ("Jeffrey Walton")
Re: OAP-L3: "The absurd weakness." (James Felling)
----------------------------------------------------------------------------
From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: test vectors
Date: Wed, 23 May 2001 22:18:27 +0100
Delacroix Florian <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi All,
>
> Does something like standard test vectors for ciphers and message
> digests exist ? Are the ones included in OpenSSL sources what i
> might be looking for ?
>
> In brief, i m looking for some accurate way to validate that my code
> ciphers and digests correctly.
>
>
>
> Thanks
Yup.. there usually included with papers etc... of course they exist.. there
used to verify implementations.
Simon.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: New type of cryptanalysis
Date: 23 May 2001 21:22:23 GMT
Are you aware of the work on interpolation attacks?
------------------------------
From: jlcooke <[EMAIL PROTECTED]>
Subject: Re: Small (not fast) RIPEMD-160
Date: 23 May 2001 21:54:31 GMT
I have an implementation that fits into 2172b of memory, _just_ over
2k. I'm still tweaking it.
JLC - extortionist extraordinare
Ian Stirling wrote:
>
> Anyone know of any small C or perl implementation of this?
>
> I'm looking for something under the 5-10K (compiled) of ones I've found.
> Under 2K would be ideal.
> For computing a password hash, so another cipher isn't an option.
>
> --
> http://inquisitor.i.am/ | mailto:[EMAIL PROTECTED] | Ian Stirling.
> ---------------------------+-------------------------+--------------------------
> "Melchett : Unhappily Blackadder, the Lord High Executioner is dead
> Blackadder : Oh woe! Murdered of course.
> Melchett : No, oddly enough no. They usually are but this one just got
> careless one night and signed his name on the wrong dotted line.
> They came for him while he slept." - Blackadder II
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Date: Wed, 23 May 2001 14:59:36 -0700
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >1. No proof of security.
> Its RIJNDAEL implemented correctly so a secure as the
> basic block encryption of RIJNDAEL
No that's not a proof, that's a claim. A claim is something you make and
then you back it up either with evidence or a proof.
> >2. Not provably more secure then CTR mode
> ACtually shown even in the one byte output case
> CTR mode allows for only 256 possible input messages
> while BICOM even an idoit like you can create over 300
> possible input messages. But you not bright enough to
> understand that not knowing which message it can be
> giving an enemy a larger pool to select from is more
> secure.
I won't even touch this one again, except to point out that the "possible
unput messages" value has varied between 300 and 2^90 depending on when
Scott made the statement. This in itself casts doubt on the ability of
examination possessed by Scott, the least he could do is pick a value and
stick with it.
> >6. Not as simple as CTR
> only weaken the security not strengthen it,
Last time I checked there was no proof that being simpler automatically
weakened the system. If you have some proof, or even some evidence of it
(preferably something solid not the hand-waving like I called you on above)
I would appreciate seeing it. What you have apparently mistaken is
simplicity of construction, with simplicity of result. The simplicity of the
construction of CTR is a good thing, it makes implementation much easier,
and therefore is much less likely to have bugs.
> BICOM ...
> with out any overhead.
I'd like to see that trick, if I remember correctly BICOM does operations,
which immediately gives it an overhead, which violates the claim, which
means you're wrong. Now you could mean space overhead, in which case I point
to the proof that in order to shrink some strings you must enlarge others,
which means that half the time BICOM will have a size overhead also, which
again violates the claim. So please enlighten us, what kind of overhead does
BICOM not have?
Joe
------------------------------
From: Ian Stirling <[EMAIL PROTECTED]>
Subject: Re: Small (not fast) RIPEMD-160
Date: Wed, 23 May 2001 22:22:43 GMT
jlcooke <[EMAIL PROTECTED]> wrote:
>Ian Stirling wrote:
>>
>> Anyone know of any small C or perl implementation of this?
>>
>> I'm looking for something under the 5-10K (compiled) of ones I've found.
>> Under 2K would be ideal.
>> For computing a password hash, so another cipher isn't an option.
>>
>I'll write you one for $500. :)
I'll give you $30000 iDollars.
Like real dollars, but completely imaginary.
I'll even throw in a top-of-the line virtual imaginary pet. (A toad)
Ok, background.
It's for a GPLd tool to make using loopback encrypted mounts under linux
a little easier.
Ideally, it'd fit in the first block (4192 bytes), so that it can fit on
an existing ext2 filesystem, without causing problems.
Basically, the structure is:
Cleartext: 0-3500 bytes or so.
0-3000 Password hasher.
3000-3500 Optional data to hash with password, for extra security.
Ciphertext:
3500-3502 Hash % 65K of cleartext.
3502-4095 Script to run, when mounted. Or text to put on stdout.
--
http://inquisitor.i.am/ | mailto:[EMAIL PROTECTED] | Ian Stirling.
===========================+=========================+==========================
If you've been pounding nails with your forehead for years, it may feel strange
the first time somebody hands you a hammer.
But that doesn't mean that you should strap the hammer to a headband just to
give your skull that old familiar jolt. -- Wayne Throop, during the `TCL Wars'
------------------------------
Subject: Re: Great Free Encryption Software
From: [EMAIL PROTECTED] (Charles Blair)
Date: Wed, 23 May 2001 22:38:55 GMT
Just in case somebody is not aware of it, gnu privacy
guard (www.gpg.org) is a freely available (including
source) public key system and related stuff. Version
1.0.5 has just been released.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Great Free Encryption Software
Date: 23 May 2001 22:50:47 GMT
[EMAIL PROTECTED] (Charles Blair) wrote in
<3_WO6.7196$[EMAIL PROTECTED]>:
> Just in case somebody is not aware of it, gnu privacy
>guard (www.gpg.org) is a freely available (including
>source) public key system and related stuff. Version
>1.0.5 has just been released.
>
Its bad enough that they wont fix the errors or allow
a strong version but the URL you gave does not work.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best, Strongest Algorithm
Date: 23 May 2001 22:45:54 GMT
[EMAIL PROTECTED] (Joseph Ashwood) wrote in <#lenUP94AHA.297@cpmsnbbsa07>:
>
>"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
>> >1. No proof of security.
>> Its RIJNDAEL implemented correctly so a secure as the
>> basic block encryption of RIJNDAEL
>
>No that's not a proof, that's a claim. A claim is something you make and
>then you back it up either with evidence or a proof.
>
But you can check the source code yourself. Yes its a claim
but you would have to put print statements in to check this. I
don't thing you would take my word. But the source code is the
proof. Nothing I could say could prove it to you since your
two dam lazy to check yourself.
>> >2. Not provably more secure then CTR mode
>> ACtually shown even in the one byte output case
>> CTR mode allows for only 256 possible input messages
>> while BICOM even an idoit like you can create over 300
>> possible input messages. But you not bright enough to
>> understand that not knowing which message it can be
>> giving an enemy a larger pool to select from is more
>> secure.
>
>I won't even touch this one again, except to point out that the
>"possible unput messages" value has varied between 300 and 2^90
>depending on when Scott made the statement. This in itself casts doubt
>on the ability of examination possessed by Scott, the least he could do
>is pick a value and stick with it.
Actually I first stated it was 2**256 but then realized that only
one full RIJNDAEL block used so its 2**128 unless code changed to
use more. I often state 300 since most people of your skill aren't
smart enough to see that its more then 256. So I pick 300 as something
even some one as low tech as you could do. I hope I say at least
300 the point was more than 256. I never stated 2**90 thats another
one of your illusions.
>
>> >6. Not as simple as CTR
>> only weaken the security not strengthen it,
>
>Last time I checked there was no proof that being simpler automatically
>weakened the system. If you have some proof, or even some evidence of it
>(preferably something solid not the hand-waving like I called you on
>above) I would appreciate seeing it. What you have apparently mistaken
>is simplicity of construction, with simplicity of result. The simplicity
>of the construction of CTR is a good thing, it makes implementation much
>easier, and therefore is much less likely to have bugs.
>
I would call more information added prood of weakness you aren't
smart enough to see that. But if you had the balls to even look at
the case in question where both methods output a single byte.
With CTR mode the input file could only be 1 of 256. With BICOM
there are thousands of possible input messages that could have
mapped to that single file. But rather then even look at it.
You wave your wand and call it a lie. Fine be stpuid and I don't
care.
>> BICOM ...
>> with out any overhead.
>
>I'd like to see that trick, if I remember correctly BICOM does
>operations, which immediately gives it an overhead, which violates the
>claim, which means you're wrong. Now you could mean space overhead, in
>which case I point to the proof that in order to shrink some strings you
>must enlarge others, which means that half the time BICOM will have a
>size overhead also, which again violates the claim. So please enlighten
>us, what kind of overhead does BICOM not have?
OK fool here again for one of many times is what it means.
It means no information is added to file. It means that
each Key represents a mapping form the set of 8-bit binary files
to the set of 8-bit binary files. Any file can be thought of
as a compressed encrypted file or plain text file. Any output
file even those of one byte length could have been any one of
2**128 messages. So its a lot more secure than CTR. It also
means that it uses full 128 bit blocks of RIJNDEAL to get the output.
It means one isn't stuck with some random crap so that you don't
fall pray to attacks common on OTP's and etc.
Ask Wagner I'm curious if he would lie about which is more
secure. Since they both use RIJNDAEL. I think he could make an
honest statement about the two. But if my estimate of him is
correct I doubt if he will say anything.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Small (not fast) RIPEMD-160
Date: 23 May 2001 15:56:46 -0700
Ian Stirling <[EMAIL PROTECTED]> writes:
> It's for a GPLd tool to make using loopback encrypted mounts under linux
> a little easier.
> Ideally, it'd fit in the first block (4192 bytes), so that it can fit on
> an existing ext2 filesystem, without causing problems.
Why does it have to be RIPEMD-160? Interoperability with something else?
I think SHA-1 should be codeable in under 2k. I don't know about RIPEMD-160.
------------------------------
From: Paul Rubin <[EMAIL PROTECTED]>
Subject: Re: Small (not fast) RIPEMD-160
Date: 23 May 2001 15:59:55 -0700
Ian Stirling <[EMAIL PROTECTED]> writes:
> Basically, the structure is:
> Cleartext: 0-3500 bytes or so.
> 0-3000 Password hasher.
I don't see why this needs to be RIPEMD-160. Is there some standard
the encrypted FS has to conform to, that specifies RIPEM-160?
> 3000-3500 Optional data to hash with password, for extra security.
I don't understand why more than 20 bytes or so is needed for that.
> Ciphertext:
> 3500-3502 Hash % 65K of cleartext.
Hash of cleartext plus the random salt, I hope.
> 3502-4095 Script to run, when mounted. Or text to put on stdout.
OK.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Date: Wed, 23 May 2001 23:01:19 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Joseph Ashwood) wrote in <#lenUP94AHA.297@cpmsnbbsa07>:
>
> >
> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> >1. No proof of security.
> >> Its RIJNDAEL implemented correctly so a secure as the
> >> basic block encryption of RIJNDAEL
> >
> >No that's not a proof, that's a claim. A claim is something you make and
> >then you back it up either with evidence or a proof.
> >
>
> But you can check the source code yourself. Yes its a claim
> but you would have to put print statements in to check this. I
> don't thing you would take my word. But the source code is the
> proof. Nothing I could say could prove it to you since your
> two dam lazy to check yourself.
What you call proof is just a fact. Sure BICOM has this property. Nobody
denies that.
The question we are really asking. "IS BICOM ANY BETTER?"
You have to show this by proving that you have some attack on CBC or CTR
encoded messages that will not work for CTR.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm (gone from any reasonable topic)
Date: Wed, 23 May 2001 23:02:57 GMT
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> [EMAIL PROTECTED] (Joseph Ashwood) wrote in <uA#7mx74AHA.278@cpmsnbbsa07>:
>
> >
> >"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> Joe and the other phony crypto gods
> >
> >WOOOHOOOOOOO!!!!!!!!!! I've been declared a crypto god!!!!!!!!!! Now if
> >only I had a job as one.
> > Joe
> >
>
> I think you may be a ware that I am not an expert in English
> but I am not sure I raised you to the "crypto god" level
> but Since you can't anwser with facts and don't know much
> about crypto. If it gets your rocks off go ahead a think of
> yourself as a "phony crypto god" its about as close as you
> will get.
Let you in on some fact.
For all I know (no offense dudes) Wagner is some poindexter-nerd that has a
nasal voice and walks with a hunch. I don't consider him a "god". I
consider him a respectable scientist and generally all around nice poster.
You always seem to reach for extremes. Either they are stupid know-nothings
or "phony crypto gods". Nobody in your eyes is "competent".
Tom
------------------------------
Reply-To: "Jeffrey Walton" <[EMAIL PROTECTED]>
From: "Jeffrey Walton" <[EMAIL PROTECTED]>
Subject: Re: Ideas for project
Date: Wed, 23 May 2001 19:16:20 -0400
I could be wrong, but because its a thesis it will be published. Unless
of course Simon and Paul develop something very cool, Paul drops out of
college, and Simon and Paul start a new company based on the ideas :)
AFAIK, an article published in academia can't be patented. That was the
reason ElGamal was unpatented. It was someone's thesis (or
dissertation).
"Paul Rubin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
: [EMAIL PROTECTED] (Simon West) writes:
: > I am in the final few months of a Master's Degree
: > conversion course in I.T. I am currently in the initial
: > investigation stages of my final project
: > which is in the area of Web Security and data encryption.
: > So far I have acheived a general understanding of the
: > basics of symmetric and asymmetric encryption and background
: > history, legislation, etc but still have to get to grips fully
: > with the number theory underlyingthe algorithms.
: > This is acheivable.
: > What I am seeking are ideas, from those of you more
: > learned in the subject, as to suitable iteresting applications
: > which could be developed during a two month project.
: > I intend to learn Java in the course of the project.
: > My current programming skills include Ada95,
: > a little C++, HTML, XML and a little javascript.
: > Any ideas that I could consider would be very much
: > appreciated.
:
: Are you planning (or willing) to release the results as free software?
: If so, I have some ideas I could suggest and would be willing to offer
: advice along the way if that was useful. But if not, then I'd be
: basically working for you for nothing if I got involved, which doesn't
: excite me very much.
:
: Just wondering.
:
: Paul
------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: Wed, 23 May 2001 18:10:35 -0500
> <sniping my posting>
>
> You are obviously trying a little too hard to be a little too smooth.
>
> If you want to claim that I took your advice and that of others on
> this point regarding the scramble process, go ahead. But I am sure
> you will agree that OAP-L3 is basically thoroughly based on
> permutation manipulation. With this in mind you must agree that I
> most probably am quite well versed in the simplest most fundamental
> permutation transformations. If you think your claim of advising me
> on the scramble process is believable then anyone who believes this
> must be rather gullible. The transformation of permutations is
> lesson #1 in linear algebra. But if you say it is so then I have
> nothing else to say about this.
If you learned your permutation theory in linear algebre, that explains alot.
>
>
> There were design choices made. And there is a very good reason I
> chose 14. I mentioned it earlier. One reason is that the number
> lends itself to easy implementation and ease of use for a user.
> Also it provides a certain consistency within the overall program.
OK. I was just curious as to why you a composite number and that specific one.
Ease of use and programing simplicity are reasonable, I guess.
>
>
> "there is a cap upon how much randomness this permutation can
> contribute" Can you prove this or is this something we should all
> realize on its face?
This is something that is obvious on its face. Given you have n cards, you
cannot arange then in more than n! possible ways. thus there is a cap on the
randomness contributed.
> Seems to me what you are saying is analogous
> to saying that shuffling a deck of cards by splitting the deck in
> two halves then interleaving the two halves card by card from each
> half will certainly limit the outcome of the overall sequence of the
> deck as compared to some other shuffle.
A said nothing of the sort.
> Are you serious? Are you
> claiming that there is no way that one can arrive at the same final
> outcome sequence of a deck of cards if two different methods of
> shuffling them are used?
Given certian side conditions yes. Ok. you are doing a single shuffle. if you
grab n cards starting at card m out of the middle and put them on top, there is
no way that that can be duplicated by a single riffle shuffle. Given more
shuffles you will eventuall reach all possible arengements of the deck. using
either method. however. the riffle shuffle will tend to fill the space more
quickly than the n card block shuffle.
>
>
> Your arguments are ridiculous. "It will fill that space fairly
> slowly" You realize that the space for three MixFiles is about
> 1E66,000,000 and 1E22,000,000 for one MixFile.
Yes. If you are to have optimally random daty you want to fill that space as
uniformly and agressively as possible. Like the shuffling example above. The
more effective your elemental ops are at shuffling the large "decks' being used,
the faster an arbitrary permutation is reached, and the more uniformly random
the data is. If I had a huge deck of cards, I would want it shuffeld alot, and
very effectively, much more so than if I had a smaller one. would you trust a
deck of a million cards that had been riffle shuffled 7 times.( probably not).
Would you trust a standard 52 card deck that had been( probably).
>
>
> Each final output sequence occupies just one place in this entire
> space. I claim I can fill one of these spaces faster with a
> sequence of 14 numbers than you can using a sequence of 105
> numbers. Yep. While your method has to search for each number in
> 105, my process just makes two passes counting off in sequence
> either 1, or 2, or 3 or 4, etc. numbers and copying them to the
> final output file. Now think about what you just said and you will
> see that I am right.
I can do it in a single pass. simple and easy assuming I use a generic
permutation method. I do 1 loop containing 105 assigns. easy.
But that is not the claim I am making. The claim I am making is that your mix a
mixfile is a poor shuffle over the space it exists in.( 105 unit permutations)
It has a fixed point, and a tendency toward preserving the order of the first
few digits that is well worse than chance. It will never reach certian points on
the space ( It cannot reverse the order of the 105 items no matter how many
times it is itterated.( for example).) Even if you evaluate it over a reduced
subset( permutations of 105 items where the first item is fixed and the
remaining 104 are shuffled arbitrarially it will take an inordinately long time
filling that space.( It takes a long time to reach certian corners of the space
-- far longer than the numbers you bandy about would suggest.) Further, points
near the fixed point tent to remain stable as well the odds of the first n sets
being unchanged after m randomly chosen shuffles is ((15-n)/14)^m. this means
that after 16 arbitrary shuffles the odds of the first two elements being in the
same place are better than 50%. Does this sound like a good primitive to you? I
am somewhat iffy as to how well it does its job. The fact that there are better
methods that just beg to be used, methods without fixed points, and without such
islands of stablity that are simple to code and fix makes me wonder how much
time you actually put into your design of this program.
>
>
> "and unevenly"? Not so. If the user inputs a random 14 number
> sequence then each random 14 number sequence has an equal chance
> of being input as any other 14 number sequence.
true, but that does not mean that the permutation fills the space of possible
results evenly. There are arangements of data that are more likely( like the
first two items being unchanged) that happen with far greater likelyhood than in
a better arangment.
>
>
> "This means that certian permutative structures will be more common
> thatn others."
yep.
> If the user inputs a random 14 number sequence,
> after one running of the process there will be 14! = 87,000,000,000
> possible outcomes. Run the process twice using another random 14
> number sequence the second time and there will be (14!)^2 possible
> outcomes. Are you saying that as this process is repeated one per
> second in the time remaining in your lifetime that the number of
> possible outcomes will be less than (14!)^(years remaining in your
> life * 365 * 24 * 60 * 60)?
Yes. it will infact be less than (105!). Further I claim that you should know
this if you actually understand what you are doing.
>
>
> And are you saying that you know of a method to somehow determine
> what the number of times this process was run and what the random
> sequences used were in each running of the process by just examining
> the final sequence output?
No
>
>
> Or are you simply saying that you can predict how many times the
> process is run and what the input is and what the final output
> sequence of the MixFile will be before the user even generates the
> random number sequences and runs the processes?
No I am claiming that your method is suboptimal. That there are better ways of
doing things than those you have chosen
>
>
> You ARE really good:
>
> "the methods used have slow difusion, require alot of work and have
> weaknesses such as fixed points, poor mixing, and other such flaws."
>
> You must admit that all of these statements are generalities which
> completely miss the point of the purpose of OAP-L3. Primarily you
> have not quantified any of these points. And this is crucial in any
> serious critique of OAP-L3. I believe that you have intentionally
> neglected to mention these because your intention is to look good
> while feebly attempting to trash OAP-L3. To have flagrantly ignored
> any quantification to support your statements proves your intentions
> beyond any doubt.
Yep. my weak mind batters febly against your wonderful algorithim. Maybe you
should take a look at what is being said, and not smoke screen us all.
>
>
> Your flaws are figments of your imagination. Do you refute that
> running the process results in the possible outcomes such as: (14!)^
> (number of times the process is run using random input)?
Yes.
> And if not
> is it significant?
Not terribly, but why should I accept a compromise vs. other methods that do mix
efficiently?
> And why do you not mention the variety of
> processes available to a user. This one process is not recommended
> to be used exclusively. The software is to be used in its entirety.
Of course. You asked me to point out what methods and means are flawed, and now
that I have pointed at one you tell me I am being too narrow in my view of your
program. make up your mind sir.
>
>
> Here is my last shot at a fixed target. "So how would YOU fix that
> nasty fixed point issue?" (really pathetic innuendo: "nasty.")
Ok, so the official position is that is a flaw, patch around it and dont worry
about it. Acceptable, but, maybe fixing it inpalce would be good.
>
>
>
> I just told you. You use a random combination of the several other
> methods.
>
> Thanks for revealing some of what you are. Don't take that personal.
> Much of what we are is not of our own doing.
>
> You may confound some with your leaky arguments but I guess we get
> what we pay for when we read one of your posts.
I feel the same about your postings sir.
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
