Cryptography-Digest Digest #418, Volume #11 Sat, 25 Mar 00 08:13:01 EST
Contents:
Re: OAP-L3: Answer me these? (Anthony Stephen Szopa)
Re: OAP-L3: Answer me these? (Anthony Stephen Szopa)
Re: OAP-L3: Answer me these? (Anthony Stephen Szopa)
Re: OAP-L3: Answer me these? (Anthony Stephen Szopa)
Re: OAP-L3: Answer me these? (Anthony Stephen Szopa)
Re: what is a 2048 bit cipher? ("Tom St Denis")
Re: OAP-L3: Answer me these? ("Tom St Denis")
Re: OAP-L3: Answer me these? ("Tom St Denis")
Re: Download Random Number Generator from Ciphile Software (Anthony Stephen Szopa)
Re: OFB, CFB, ECB and CBC ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Sat, 25 Mar 2000 02:49:31 -0800
Joseph Ashwood wrote:
>
> Let's analyse your claims.
> Claim 1) Someone intelligent is busy analyzing your theory
> Reality 1) You have revealed virtually nothing about your
> theory.
>
> Claim 2) We have chosen to ignore your theory
> Reality 2) See Reality 1
>
> Claim 3) We attack only your implementation
> Reality 3) Your implementation is the only reference for you
> method, since you theory claims are totally worthless
>
> Claim 4) We are unintentionally giving you credibility
> Reality 4) That may be the case for a very small number of
> people, while the majority will actually read what has been
> said, and realize that what has been said is that without
> further knowledge we can only assume that your method is
> worthless.
>
> Claim 5) 01234567890123456789... is biased
> Reality 5) Each output digit will occur an exactly equal
> number of times making a bias of exactly zero
>
> Claim 6) By adding a new process you inherently add ability
> to "mix things up even more"
> Reality 6) That is simply not the case a trivial example is
> to use 2 functions (what you call processes) where the
> second is the inverse of the first, regardless of the
> functions chosen this makes for a very weak stream.
>
> Joe
I will not accuse you of being a liar.
I will not accuse you of being an idiot.
I will not accuse you of being stupid.
Although a case could be supported for each of the above.
1) CASE: liar. You say the theory, and specification of the
procedures and processes have not been made available. Not true.
The theory, and specification of the procedures and processes have
been available for some time now at http://www.ciphile.com
2) CASE: idiot. "01234567890123456789... Each output digit will
occur an exactly equal number of times making a bias of exactly
zero." Not quite. Bias refers to any patterns that can be
discerned and exploited cryptoanalytically. There is clearly a
pattern here, the sequence is predictable, etc.
3) CASE: stupid. "By adding a new process you inherently add
ability to "mix things up even more." That is simply not the
case..." Oh, really? In the popular state lotteries or in the
gambling game of keno, you may pick six numbers. Six of eighty
ping pong balls numbered 1 - 80 are randomly selected. Let's
say you bet one dollar for your pick six. If I decide to add
80 more ping pong balls making a total of 160 and keep your
potential winnings the same, will you now bet two dollars?
You admit to not having read the Help files or insist that
you are unable to understand them, you have not gotten the
software: in other words, you don't know what you are talking
about yet you seem to be an authority on OAP-L3. Incredible!
Have I really gotten to you? I have, haven't I?
I really get satisfaction knowing that my work has gotten to you.
Can't refute the facts can you. There is a very real encryption
software package here to address. It's tangible.
Explain why you have not gotten the software, read the Help Files,
or made any substantive criticism with factual support based upon
the theory, and specification of the procedures and processes?
All this is available to you yet you piddle around.
This is quite amusing, indeed.
Again, you can BELIEVE in any reality you wish. You may even find
a few friends who wish to share your beliefs.
But I am afraid nearly everything you have said to date has been
unscientific, insupportable or unsupported, and without merit.
By the way, I have had tremendous traffic at my web site where many
many copies of the OAR-L3: Original Absolutely Random Level3 random
number generation software has been being downloaded.
As I mentioned, Version 4.3 of OAP-L3 will be out in a week or two.
When this update is finished, where I'll be adding 6 more MixFile
processes, I will make available for download a new generation
program with data files.
You will be able to see that I can generate 1.4E20 random digits
using only 3540 data bytes with a security level having only one
exact key in well over 4E830. This process can be greatly
optimized further but I'll talk about this later.
What this indicates is that with a very small number of data
bytes you can accomplish secure encryption. With this level
of efficiency this encryption theory may soon be considered
a potential alternative to existing SET systems.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Sat, 25 Mar 2000 03:14:33 -0800
Boris Kazak wrote:
>
> Quote from your Web site:
>
> Major software components:
> 1) Random Number Generator
> 2) XOR Routine (!?!)
> 3) File Management
> 4) Utility Programs
> 5) Help Files including Tutorials
>
> Two observations:
> a) XOR is just an elementary processor instruction,
> somebody elevating it to the status of "Routine" and
> listing it as a "Major software component"
> immediately sounds illiterate to the extent of total
> incomprehension. If this is so, it is a real problem.
>
> b) Still there is no mentioning of algorithm description
> or source text files. Tutorial is the documentation for
> a driver, what people here are asking for is the manual
> for a detailer-repairman. If you don't comprehend it,
> then see (a).
>
> Additional note: Do not expect people to analyze and to
> reverse-engineer your OAP stuff - nobody in his right mind
> will do it for free. They just reasonably assume that this
> encryption might be weak - using it without knowing what
> is happening inside is just a gamble with unknown odds.
>
> Finally, there is an old adage - you keep your source code
> secret only if you are ASHAMED of it. Sic...
>
> Best wishes BNK
> ------------------------------------
>
> Anthony Stephen Szopa wrote:
> >
> > Joseph Ashwood wrote:
> ***
> > > First we need to see your algorithms, but you don't want to
> > > reveal those.
> > > ***
> > > Joe
> > *******
> > You are sure a great talker. I wonder how many of you are busily
> > studying OAP-L3 theory, and procedures and processes all the while
> > "dissing" OAP-L3 and evading the software publicly? I think some
> > of you should be suspicious. When opportunity knocks there are
> > those who know enough to answer the door. Some disperse smoke
> > screens to confuse others. Bill Gates jumped on an opportunity
> > while nearly everyone else remained clueless. How many of you are
> > CHOOSING to remain clueless?
> >
> > It appears that you (and most others) have willfully chosen not to
> > address the theory, and specification of the procedures and
> > processes. This should be noted by all readers to this news group.
> *************
> > http://www.ciphile.com
> >
> > Original Absolute Privacy - Level3 Encryption Software Package
XOR is an important point. People want to know the mechanism of
the encryption process. It is a major component of great
significance. Yes it is simple and well known.
The Help Files are highlighted here, and are there in the Table of
Contents. All you need to do is look them over. I think they are
rather good: complete, concise, fairly well written. Everything
you always wanted to know but were REALLY afraid to ask all about
OAP-L3. Yessiree.
Thank you for a critique of my web site.
I am glad to say that lots of people from the US and Canada have
gotten the OAP-L3 software, and now many people from all over the
world have gotten the OAR-L3 software, too.
They just emailed me or pointed and clicked. Didn't bitch once
about the web site. Just made a decision and got the software.
It's all very simple and straight forward. It's easy when you
know what you want.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Sat, 25 Mar 2000 02:59:02 -0800
James Felling wrote:
>
> Anthony Stephen Szopa wrote:
>
> > It is quite clear that both Mr. Hetzer and Mr. Ashwood are seriously
> > disoriented. The theory, and specification of the procedures and
> > processes, have been available at the web site in the posted Help
> > Files for some time now and this fact has repeatedly been stated in
> > these news groups.
> >
> > You can believe in any personal "reality" you want to fantasize. Some of
> > you can share your fantasies. Have fun.
> >
> > Volker Hetzer <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Anthony Stephen Szopa wrote:
> > >
> > > > You are sure a great talker. I wonder how many of you are busily
> > > > studying OAP-L3 theory,
> > > Everybody who has *access* to that theory. Which is -- nobody.
> > >
> > > > It appears that you (and most others) have willfully chosen not to
> > > > address the theory, and specification of the procedures and
> > > > processes. This should be noted by all readers to this news group.
> > > Tell us the theory, then we'll address it.
> > >
> > > > It appears that the attack has admittedly been chosen to be an
> > > > attack on the implementation. No other options?
> > > Nobody has bothered to "choose" an attack. The goal is to point
> > > out weaknesses. If you want it for free, provide the source code.
> > >
> > > > I thank many of you for unintentionally giving me such credibility
> > > > (short-lived or not.)
> > > This is not a chatroom, y'know? People take their time to follow
> > > threads and look up references (and funny patents). So, forget it.
> > >
> > >
> > > > By the way, OAP-L3 Version 4.3 will be available in about a week
> > > > or so. Six new processes are being added to mix things up even
> > > > more.
> > > Wow! The more "processes", the more secure. I'm impressed.
> > >
> > > Volker
> > > --
> > > Hi! I'm a signature virus! Copy me into your signature file to help me
> > spread!
> > >
>
> To quote your web site sir:
>
> "Each of these files must
> be thoroughly shuffled. That is to say, the permutation order must be
> randomly rearranged in each file. There are several processes the
> software uses to shuffle the permutation order in each MixFile(X)
> individually, and one that shuffles the MixFile(X)s all together. "
>
> This is useless as an algorithim description. "There are several processes"
> well this could be anything from a secure PRNG stream to a simple modular
> arithmetic PRNG, to picking a spot in the file and starting from there. This
> paragraph is the sole source of information about this( that I could find)
> and provides no useful details as to what the nature of such "processes"
> are. This is the core of your algorithim -- the only part that will add
> randomness to your output stream, and thus far you have not replied to our
> questions.
>
> I ask you now sir: What are the "processes" involved, and how are they
> applied?
>
> If you can not or will not answer this question, no meaningful conclusions
> about your program's quality may be drawn. Until I have seen such data, I
> will have no confidence in your program. Given also your claims that this is
> an OTP, and other misleading statements made I am inclined to give your
> program a great deal of scepticism, and doubt it's quality. If the actual
> data was on the table, then an objective analisys could be made, and real
> conclusions drawn.
I believe you posted a reply to one of my posts some time ago. I
recognize your style of writing. It is good to hear from you again.
I will be happy to help you out and give you some encouragement.
I encourage you to just continue to read down past the first three
fourths of the Theory Help file where you will see:
"At this time, go to the Processes Help Files #2 and #3 and learn
about the various processes used to shuffle the encryption data
files. Afterwards, return here where the discussion continues."
You might get right to it without having to visually look for it by
using the Edit/Find option of your web browser or the equivalent.
I hope this helps.
Good day.
http://www.ciphile.com
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Sat, 25 Mar 2000 03:19:14 -0800
"Trevor L. Jackson, III" wrote:
>
> Anthony Stephen Szopa wrote:
>
> > OAP-L3: Answer me these?
> >
> > Where is the bias in any of the procedures and processes in OAP-L3?
> >
> > Where is any bias introduced into any of the procedures and processes
> > found in OAP-L3 when used according to recommendations?
> >
> > What conclusions can we draw if there are no biases in any of the
> > procedures and processes, and no biases introduced in
> > any of the procedures and processes used in OAP-L3?
>
> The more important conclusion is drawn from the fact that you refuse to
> provide sufficient information for an objective observer to determine whether
> biases exist or not. But I'll offer an inducement that you may find useful as
> an endorsement. I'll put up $1,000.00. You put up $10,000.00, and publish
> all of your source code. If no one finds any flaws in your product within 60
> days you keep my money, and you get to advertise the fact that you software is
> flawless. Otherwise I'll split your money with the people who find the flaws
> in your software.
>
> Now if you are are right about the quality of OAP-L3 you stand to make a quick
> grand. You _do_ believe in your software don't you?
Your assertion, again, is not true. The theory, and specification
of the procedures and processes are available in the Help Files at
the web site.
http://www.ciphile.com
I am beginning to believe some people really shouldn't have guns.
You'd certainly shoot yourself in the foot.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Sat, 25 Mar 2000 03:28:02 -0800
Volker Hetzer wrote:
>
> Anthony Stephen Szopa wrote:
> >
> > Thanks for showing us again that you are unable to address the theory,
> > and specification of the procedures and processes, and have chosen to
> > challenge the implementation.
> Hey I love that "us" part. Care to take a poll? I'd like to see how many
> those "us" are that understand your "theory" to such an extend that they
> could post a summary that convinces the rest of the listeners in this thread
> of the security of your algorithm.
>
> Greetings!
> Volker
>
> --
> Hi! I'm a signature virus! Copy me into your signature file to help me spread!
Mr. Huuskonen recited the theory pretty well. I will admit
everything he said was almost verbatim from what is said in
the help files. Yes, they are written quite well for the
average person to easily understand. Read them a few times
and you will know just about all that I know. Of course, the
depth of understanding won't come immediately with all its
implications. But the theory and procedures and processes
are so fundamentally simple that I know those who insist this
is not the case are thoroughly insincere.
Why should anyone tell you anything. You haven't listened for,
what is it now, over a year? And all you've had to do was read
a few legal size length pages from the Help Files. You sound
like a bum begging for money or a young child crying to have
its mother feed it when it is old enough to feed itself.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: what is a 2048 bit cipher?
Date: Sat, 25 Mar 2000 12:05:47 GMT
Douglas A. Gwyn <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis wrote:
> > You are so wrong. Making the keyspace large is only effective if
> > your algorithm is secure. So even a cipher with a 80 bit key would
> > be secure by todays computer standards [maybe not 20 years from now...
>
> You apparently contradict yourself. Perhaps what you mean was:
> A very long key does not in itself guarantee security, although
> a sufficiently short key (much less than 80 bits) does guarantee
> insecurity.
No I actually meant large keys are only 'more secure' when the algoriithm is
harder to attack. If you have a good algorithm and a 80-bit key, and a
crappy one with a 1024-bit key, the 80-bit one could be much more secure.
And that an 80bit keyspace is not searchable with todays technology.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Sat, 25 Mar 2000 12:14:37 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
> 1) CASE: liar. You say the theory, and specification of the
> procedures and processes have not been made available. Not true.
> The theory, and specification of the procedures and processes have
> been available for some time now at http://www.ciphile.com
Your theory on your website is not very specific. Do you have a hidden page
or something with the required info?
> 2) CASE: idiot. "01234567890123456789... Each output digit will
> occur an exactly equal number of times making a bias of exactly
> zero." Not quite. Bias refers to any patterns that can be
> discerned and exploited cryptoanalytically. There is clearly a
> pattern here, the sequence is predictable, etc.
So you are saying that if your RNG outputed a million zeros just by chance,
your rng would not be random? hmmph. ok.
> 3) CASE: stupid. "By adding a new process you inherently add
> ability to "mix things up even more." That is simply not the
> case..." Oh, really? In the popular state lotteries or in the
> gambling game of keno, you may pick six numbers. Six of eighty
> ping pong balls numbered 1 - 80 are randomly selected. Let's
> say you bet one dollar for your pick six. If I decide to add
> 80 more ping pong balls making a total of 160 and keep your
> potential winnings the same, will you now bet two dollars?
Actually with 160 balls from 1-80, 1-80 you have broken the lottery. Cuz
the next time they pick your six balls, they could get 1, 1, 2, 2, 3, 3 and
nobody would win. If you meant 1-160 that's no a new process but a
different choose operation 160! choose 6 [bah I haven't done finite so if
that's worded wrong I apologize]
> You admit to not having read the Help files or insist that
> you are unable to understand them, you have not gotten the
> software: in other words, you don't know what you are talking
> about yet you seem to be an authority on OAP-L3. Incredible!
Actually document the thing properly. Write a paper on it. Not just a
colection of web pages. Also you have to adhere to a standard. If for
example I choose to evaluate the current one, it's of no use if you keep
changing the rng.
> As I mentioned, Version 4.3 of OAP-L3 will be out in a week or two.
>
> When this update is finished, where I'll be adding 6 more MixFile
> processes, I will make available for download a new generation
> program with data files.
Why are you adding more processes? [hmm?] are the current ones broken?
> You will be able to see that I can generate 1.4E20 random digits
> using only 3540 data bytes with a security level having only one
> exact key in well over 4E830. This process can be greatly
> optimized further but I'll talk about this later.
With a LFSR I could make 1.47732893477907533568552248218e+8525 bits
(2^(8*3540) - 1) output assuming there was a primitive polynomial for that
size. So what?
> What this indicates is that with a very small number of data
> bytes you can accomplish secure encryption. With this level
> of efficiency this encryption theory may soon be considered
> a potential alternative to existing SET systems.
I could use two 1770 byte LFSR's and make a shrinking gererator, which is
secure, more analyzed and easier then your methods. Not to mention have a
longer period.
Tom
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: OAP-L3: Answer me these?
Date: Sat, 25 Mar 2000 12:16:59 GMT
Um no. No real OTP can be cryptanalyzed. You would have to either break
the RNG used to encrypt or bribe etc..
There is no such thing as a OTP bit flipping attack. You are making things
up now.
tom
Jerry Coffin <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <7iWC4.69406$[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] says...
>
> [ ... ]
>
> > Your line of thinking is flawed. An OTP is the PERFECT cipher. It
doesn't
> > need diffusion. And for the time being 128 bit keyspace is more then
> > enough, and 256 bits is excessive.
>
> His line of thinking was and is correct, as long as you restrict OTPs
> to the sort of implementation of which he was thinking. Despite
> being entirely immune to a cipher-text only attack, a one-time pad is
> a LONG ways from perfect in general. In particular, even if you
> don't know the exact plaintext, if you know the _format_ of the
> plaintext, it's subject to bit-flipping attacks.
>
> Just for example, here in the US some people were recently allowed to
> cast ballots for primary elections over the Internet. Though I doubt
> it's true, for the moment assume that ensure security the votes were
> encrypted using a OTP, implemented in the style usually discussed (a
> Vernam cipher).
>
> For example we'll assume I'm opposed to the Democratic party and I'm
> willing to be dishonest to try to make them lose. In the democratic
> party, there were basically two candidates in the primary elections:
> Bill Bradley and Al Gore. I want to ensure that the LESS popular of
> these two gets elected, so that in the final election, more Democrats
> are likely to vote FOR whoever is running against the unpopular
> Democratic candidate.
>
> Now, consider the situation for the moment: I don't particularly care
> which of these candidates anybody in particular has voted for. I'm
> not trying to find out how the election will go before it's
> officially announced. And that's just as well, because their use of
> a one-time pad will quite thoroughly prevent me from doing that.
>
> Despite this, if a particular person's vote is represented (for
> example) as a single bit, with a 0 representing a vote for one
> candidate, and a 1 a vote for the other, I can easily switch
> everybody's votes: I simply toggle the bit from whatever it presently
> is, to the other possible value. Suddenly everybody's vote is
> reversed, and the election goes to the least popular candidate
> instead of the most popular. When the final election comes around,
> the opposing party's candidate is running against somebody nearly
> nobody would intentionally vote for, and the election is a landslide
> because the legitimate opposition was eliminated before anybody could
> vote for him at all.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Sat, 25 Mar 2000 03:43:25 -0800
Eric Lee Green wrote:
>
> Anthony Stephen Szopa wrote:
> > So, now, when you try to sell this software to your superiors, in
> > the hope of adding value to the company you work for, and getting
> > that promotion, raise, and those stock options, I hope I have given
> > you enough information in all my posts to give you enough confidence
> > to make that pitch a success.
>
> Not really. The Yarrow paper (http://www.counterpane.com/yarrow/ ) gave me
> enough information to raise my confidence level, including much info about
> possible attacks and what steps were made in the Yarrow design to counter
> those attacks. If I were using the Windows platform, I would be using Yarrow
> as the random number generator. (I'm not, so I use other mechanisms, such as
> the /dev/random available on FreeBSD or Linux, or a PRNG inspired by Yarrow
> that I wrote for other Unix platforms using off-the-shelf cryptographic
> components).
>
> There are some things that I've recommended buying rather than doing inhouse
> (compression algorithms come to mind -- the good ones are patented), but
> random number generation isn't one of them. There's just too many good ones
> out there in the public domain.
>
> --
> Eric Lee Green [EMAIL PROTECTED]
> Software Engineer Visit our Web page:
> Enhanced Software Technologies, Inc. http://www.estinc.com/
> (602) 470-1115 voice (602) 470-1116 fax
What would you say if there were no attacks possible against
OAP-L3 when used according to recommendations (truly random user
input and large key length) except brute force?
I address this issue when I discuss inherent or introduced bias
either in the theory or the processes in the Theory Help file.
If there are no biases in either then there are no
cryptoanalytically exploitable characteristics.
I'm just posing a rhetorical question and making a point. I am
not trying to convince anyone of anything here.
I believe that I can prove my point mathematically. It is straight
forward probability theory. I'm working on this proof.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: OFB, CFB, ECB and CBC
Date: 25 Mar 2000 12:51:43 GMT
In a previous article, "Scott Fluhrer" <[EMAIL PROTECTED]> writes:
>(BTW: do you really think that (say) Twofish in ECB mode would "probably
>often" be more secure than DES in CBC mode? Certainly not for highly
>redundant plaintext, or plaintexts where block-swapping attacks could
>apply...)
You're right about the last part. My statement only applies to attacks on the
key. And I am not entirely convinced that Twofish and DES are applicable to
my argument, but let us assume it is. A crucial premise for my argument to be
valid is that the ciphers in question is that secure against meet in the
middle attacks and such, that security against attacks on the key more or
less _only_ depends on key size and block size.
In such case it would probably easier to extract the key from a given plain
text and DES CBC-mode cipher pair, than from the plain text and the TwoFish
EBC-mode cipher pair. As has been assumed, when discussing such attacks
everything eventually comes down to key size (including IV if it is applied)
and block size. At best CBC and CFB mode have an effect of doubling the block
size the attacker has to deal with.
Also, if the plain text is highly redundant (e.g. all 0's) the attacker will
probably not have enough information to be able to extract the key if the
cipher is in ECB mode. But enough information might have been provide if the
cipher was run i CBC mode.
----- Posted via NewsOne.Net: Free Usenet News via the Web -----
----- http://newsone.net/ -- Discussions on every subject. -----
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email [EMAIL PROTECTED]
------------------------------
** 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
******************************
