Cryptography-Digest Digest #585, Volume #11 Thu, 20 Apr 00 06:13:00 EDT
Contents:
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
Re: Proving that you are who you say you are (NFN NMI L. a.k.a. S.T.L.)
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 19 Apr 2000 22:29:15 -0700
James Felling wrote:
>
> Anthony Stephen Szopa wrote:
>
> > James Felling wrote:
> > >
> > > >
> > >
> > > <Big snip>
> > >
> > > >
> > > > You want me to believe that there is a useful attack of the random digit
> > > > generator?
> > > >
> > > > You want to talk reality? Then consider this:
> > > >
> > > > If there is why do I have to give anyone the raw random digit
> > > > output directly from the random digit generator before they
> > > > can make such an attack?
> > >
> > > You don't. However, most peole are willing to spend a few days worth of computer
> > > time to proove a point, more than that and its not worth the effort. Since the
> > > dificulty of attack increases greatly without such, it becomes impractical and
> > > expensive for anyone to do so merely to allow you to see the light. Your cypher
> > > on the whole is (given the attacks against it) probably as strong as the AES
> > > candidates( but not significantly stronger). What we are discussing is
>equivalent
> > > to saying that there is a weakness in the round key generator for such a cypher.
> > > This will NOT compromise a cypher(directly), but it provides a point of attack,
> > > and can remove an algorithim from contention for serious practical usage.
> > >
> > > >
> > > >
> > > > Keep in mind that there is no way this data is going to be
> > > > available in a real life situation.
> > >
> > > Agreed to a point. It certianly is not directly exposed, but the weaknesses it
> > > posesses will result in artifacts in the stream generated that CAN be used to
>make
> > > an (admitedly academic -- it needs truly ridiculous quantities of stream data)
> > > attack against it.
> > >
> > > >
> > > >
> > > > Your questions / points of contention indicate clearly that you
> > > > do not have the software, you have not thoroughly read the Help
> > > > Files, you have not run the examples, you have not done the
> > > > tutorials.
> > >
> > > Really now? I have read your tutorials, examined the software, read what
> > > helpfiles exist, and messed with it enough to familiarize my self with its
> > > function as far as that goes.
> > >
> > > >
> > > >
> > > > You have refused to do your homework.
> > >
> > > You sir, have refused to answer my direct questions, you have accused me of
> > > neglecting to familiarize myself with the topic, and have been generally
> > > uncooperative in nearly all respects. If you are atempting to educate people
> > > about your software, you are sadly deficient in teaching skills.
> > >
> > > >
> > > >
> > > > I do not have any more time to spend with such an unmotivated
> > > > pupil.
> > >
> > > If my simple questions were answered in a satisfactory manner, I would cease to
>be
> > > a drain upon your time, and may even be an advocate. Is it possible, sir, that
> > > you cannot do so?
> > > Here they are again:
> > >
> > > Your RNG is flawed. This does not sink your algorithim, however, it does raise
> > > issues. Can you give a good expalnation as to why the flaws in the RNG do NOT
> > > result in an artifacts in the resulting stream? Or if they do can you explain why
> > > such artifacts do not comprise a security risk? Do you understand the nature of
> > > the flaw in your RNG? Do you know how to fix it?
> > >
> > > I accept that a direct attack versus the RNG while not impossible is going to be
> > > quite challenging. I will accept even for the sake of argument that you are as
> > > secure as the AES.
> > >
> > > your program needs several MINUTES to setup before encryption, while equivalently
> > > secure algorithims take at worst seconds to setup 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?
> > >
> > > PGP has a much cleaner and easier to use user interface and offers equivalent
> > > security and faster encryption, why should I use your program?
> > >
> > > Even ScottXu has had more thourough examination, and has actually had some
> > > sophisticated analisys performed upon it, has your program? If so why does the
>RNG
> > > have the weakness that it does( it is a fairly simple one that can be easily
> > > avoided by trivial modification)?
> >
> > "time to proove a point"? Prove what point? That there is a flaw
> > in the random digit generator? No flaw exists except in your own
> > imagination. The random digit generator serves a purpose. To
> > this end it has no flaw. You choose to perceive a flaw. But this
> > is because you do not comprehend the purpose of the random digit
> > generator.
>
> Your RNG has a severe flaw in that it leaks key data. Yes, your later steps in which
>the
> raw RNG data is mangled into the actual code stream will to some degree mask this,
>and
> make attack more difficult. I accept that your RNG's flaw is thereby masked.
>However,
> this still leaves your encryption weaker than it is claimed to be. Correct the flaw,
> and your algorihim's strength will increase greatly.Why not do so?
>
> >
> >
> > "without such, it becomes impractical and expensive" (To put it
> > mildly.) When the software is used according to recommended use
> > it becomes practicably impossible, is more like it.
>
> It become very dificult to nearly impossible. If I had serious money at stake then
>the
> cost in time and resources to break your code might be worth it. But I don't, and so
>I
> cannot break your code. OTOH, if I were to have something very valuable that I
>wished
> to protect your code would likely be insulficient as as with such resources a break
>may
> be achieved.
>
> >
> >
> > "This will NOT compromise a cypher(directly), but it provides a
> > point of attack" Oh? Regarding OAP-L3 this claim is completely
> > irrelevant. Again, when used according to recommended use,
> > specifically, when the original random number stream output
> > (0 - 255) is completely and irretrievably lost with subsequent
> > processing, there will be no attacks according to your pointless
> > generalization.
>
> Really? irretrivably lost, huh? I will admit the truncation adds some security, but
>the
> data leaked by the RNG is not "irretrivably gone". Given a byte B is generated as
> output after truncation then we know the following. Treat the digits as seperate
> substreams -- that is how they are generated isn't it? Then given an output value
> B=100*B1+10*B2+B3 we can conclude the following.
>
> then the actual output of the 3 streams call it S=100*S1 +10*S2+ S3 was either B,
>B+256,
> or B+512. this allows us to conclude the following
> S3= either B3, (B3 -6) Mod 10, or (B3-2) mod 10
> S2= either B2, (B2-5) mod 10, or (B2-1) mod 10
> and S1 = either B1, (B1-2) mod 10, or (B1-5) mod 10. in addition 0<=S1<=7 so we can
> always eliminate at least 1 possible form the valuse of S1, in addition since S1
> determines which values get droped any ability we get to guess at S1 also means that
>we
> get closer to guessing where the droped values fall.
>
> True, as I said with all the fiddling you do we cannot exactly predict what the input
> streams are, but we can make predictive guesses, and thus the RNG is somewhat
>exposed.
>
> >
> >
> > "will result in artifacts in the stream generated" Totally
> > ridiculous. I will give you any amount of the final OTP data
> > you think you will need and you will never ever ever deduce the
> > random digit output from the random digit generator or the original
> > MixFiles used as the random digit generator input. You cannot
> > even justify your statement other than to say that you read it
> > somewhere.
>
> Excuse me. If you are going to respond to selected quotes please do not put words
>in my
> mouth. Where in my positng did I say anything about "having read it somewhere"? You
>are
> lying here. This is a DELIBERATE UNTRUTH. Given your output stream, it is possible
>to
> build a statistical model of your Mix Files, and from that statistical model you can
>in
> turn build a model of your keying data. Yes this requires alot of data, time and
> effort, but it can be done. You have shown me nothing in your process that will
>result
> in the RNG artifacts remaining hidden or that compensates for such in even a simple
> manner, other than the truncation, which merely complicates attack, and most
>definitely
> does not render such impossible. You are correct in saying given that data I will not
> generates such -- I do not have that kind of spare time available. If I felt that
>the
> stakes were high enough to justify such an expenditure of time and effort however,
>your
> code would be comprimised.
>
> >
> >
> > You know I am correct if you have read and understand the OAP-L3
> > software, specifically regarding the processing done to the RandOut
> > files and the final generation of the OTP files.
>
> I regret to say that I spent several hours going over that morras of print data you
> claim sulfices as documentation
>
> >
> >
> > "messed with it enough" Clearly not enough.
>
> Perhaps, perhaps not.
>
> >
> >
> > Can any one of you imagine when you were in the university, a
> > student telling his professor that he "messed around" with his
> > homework "enough"? "Yeah, teach. I messed around with your
> > homework enough..."
> >
>
> Yep, and here are the solutions to the exercises that I could solve. You know as
>well
> as I that in higher level courses, you are expected to not always be able to fully
> answer all questions on the homework. What you are doing here is attacking my
>choice of
> words, not responding to my questions. I am still waiting for your reply to any
>serious
> questions that I have presented.
>
> >
> > Then how do you explain your obvious lack of understanding about
> > OAP-L3? What kind of credibility do you bring to this discussion
> > when you admittedly (implicitly) have not done your homework
> > adequately?
>
> By the logic in that paragraph, and the fact that you have not responded to the
> questions that I have asked you have (implicitly) admitted that you are unable to
> respond to my questions in a satisfactory manner, and thereby admited that your code
>is
> inadequate to the job. Come on, be reasonable now. We both know that resorting to
>such
> debator's tricks serves only to obscure the topic at hand. Stop attacking my
>language,
> and answer my questions. Are they so difficult to respond to?
>
> >
> >
> > "Your RNG is flawed" I thought we were talking about the random
> > digit generator.
>
> We were. Sorry that my terminology is confusing. I consider the RNG to be the
>portion
> of the code used to generate the Mix files. Any time that I have refered to such
>that
> is what I have meant. (What you have meant I can only guess, but I have been assuming
> that we were talking about the same thing.) Your documentation regretably lacks
>useful
> labels for the various subsections of the code.
>
> > If you insist: the random number generator
> > outputs the random numbers found in the OTPs. Are you now talking
> > about the OTP random numbers or are you fantasizing about some other
> > numbers. You really must decide what you want to discuss. You
> > are ridiculous if you think there is a flaw in the OTP random
> > numbers. You still have given us no proof of this: not even a
> > plausible glimmer.
>
> The flaw in the generated output stream which you persist in calling "OTP random
> numbers" exists. Follow the data back through the cycle, you can and will see its
> origins.
>
> >
> >
> > Your insistence borders on the insane, and we can be sure of this.
>
> Can we now? I have asked you a set of simple questions that you have yet to respond
> to. All I want is an answer to my questions. If that makes me insane then so be it,
>but
> I think you cannot reply to my questions in a way that makes you look good, so you
> refuse to do so. Here they are again:
>
> Your RNG is flawed. This does not sink your algorithim, however, it does raise
> issues. Can you give a good expalnation as to why the flaws in the RNG do NOT
> result in an artifacts in the resulting stream? Or if they do can you explain why
> such artifacts do not comprise a security risk? Do you understand the nature of
> the flaw in your RNG? Do you know how to fix it?
>
> I accept that a direct attack versus the RNG while not impossible is going to be
> quite challenging. I will accept even for the sake of argument that you are as
> secure as the AES.
>
> your program needs several MINUTES to setup before encryption, while equivalently
> secure algorithims take at worst seconds to setup 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?
>
> PGP has a much cleaner and easier to use user interface and offers equivalent
> security and faster encryption, why should I use your program?
>
> Even ScottXu has had more thourough examination, and has actually had some
> sophisticated analisys performed upon it, has your program? If so why does the RNG
> have the weakness that it does( it is a fairly simple one that can be easily
> avoided by trivial modification)?
>
> >
> > The only flaw is in your illogical thoughtless position.
>
> Name calling -- always the sign of a man who is in possession of all the facts, and
>with
> superior logic on his side.
>
> > There is
> > absolutely no flaw in the theory, processes, and procedures of
> > OAP-L3.
>
> Bullshit. The mix file generation has huge flaws in it.
>
> > Show us how you intend to break the OTPs.
>
> Analisys of stream data will yeild good models of the mix files, and from those the
>10
> digit user permutation may be attacked directly, and the other permutes, etc. will
> fallout thereafter.
>
> >
> >
> > Consider the probabilities inherent in the recommended use of
> > OAP-L3 software. Then give up.
>
> Why shoud I quake in my boots in fear of a broken piece of software?
>
> >
>
> >
>
> >
>
> >
> >
> > FACE IT: YOU HAVE BEEN BEATEN BY AN ALGORITHM!
> >
>
> Yep, I have --hundreds of times. There are many algo's that I cannot hope to attack.
> OAP-L3 is NOT one of them however.
>
> >
> > And consider this: you and your phony cronies in this news group
> > are just about out of time.
>
> I have no "cronies" as you claim. I am merely one man voicing one man's opinions. I
>am
> NOT selling anything -- you are, and I'm growing increasingly less likely to buy your
> story.
>
> >
> >
> > Version 4.3 is about to be released. And version 5.0 has been
> > spec'ed out.
>
> >
> >
> > In fact, I have had a working prototype of version 5.0 running for,
> > let me look... over three months now.
> >
> > Version 5.0 will blow everyone away with its variability and power.
> >
> > Isn't this really why you and your phony cronies in this news group
> > are so unnaturally concerned about OAP-L3?
> >
>
> All I asked were some simple questions, and you accuse me of being part of some sort
>of
> "crypto cabal"? Get a clue man, all I want are answers. Give them to me and I will
> either go away, or I will become an ally, is that so hard to understand?
>
> >
> > I think so.
> >
> > You asked me to write a paper. Guess what? There are probably
> > a dozen papers already written on OAP-L3. One is at NSA, another
> > at MI 6, one is in Moscow, another in Tokyo, ... But don't hold
> > your breath waiting for one of these to be published.
>
> You are delusional. What you have done is neither revolutionary nor terribly
>original,
> I strongly doubt the existence of any real analisys of your algoritim -- even by you.
>
> >
> >
> > Perhaps someone else will get around to publishing one. They
> > would certainly get much attention from the experts in the field.
>
> >
> > It would be great publicity for someone. But I recommend they wait
> > until Version 5.0 is released.
> >
> > Here is a suggestion: why don't you write one and highlight your
> > supposed flaws in OAP-L3. Now that would take some guts on your
> > part. Are you not sure enough of your position? I don't think
> > you are. The experts will slaughter you (and your phony cronies as
> > well.) Be sure of it.
>
> Perhaps if I get a few spare hours in the next few days I will.
"Your RNG has a severe flaw in that it leaks key data." Support
this statement with facts if you can.
You do not offer any, I notice. Then you proceed to build upon
this unsupported assumption to build this fantastic hypothesis
that there are these flaw artifacts, etc.
This is clearly the result of delusional thinking I have not seen since
most dramatically demonstrated by Humphrey Bogart in the
"Caine Mutiny."
I can hear you clicking those steel balls between your fingers
from here.
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Wed, 19 Apr 2000 23:01:10 -0700
Tom St Denis wrote:
>
> Anthony Stephen Szopa wrote:
> > "time to proove a point"? Prove what point? That there is a flaw
> > in the random digit generator? No flaw exists except in your own
> > imagination. The random digit generator serves a purpose. To
> > this end it has no flaw. You choose to perceive a flaw. But this
> > is because you do not comprehend the purpose of the random digit
> > generator.
>
> You have yet to prove that there cannot exist any bias. We can for
> example state that LFSR's are good bit generators [albeit not secure]
> since we know there period and have tested them in action. Those are
> facts. Nothing like 'oh my rng is good cuz I say so'.
>
> > Can any one of you imagine when you were in the university, a
> > student telling his professor that he "messed around" with his
> > homework "enough"? "Yeah, teach. I messed around with your
> > homework enough..."
> >
> > Then how do you explain your obvious lack of understanding about
> > OAP-L3? What kind of credibility do you bring to this discussion
> > when you admittedly (implicitly) have not done your homework
> > adequately?
>
> Because you are a crank and just trying to sell some crappy software.
> For starters who in their right mind would by a rng?
>
> > "Your RNG is flawed" I thought we were talking about the random
> > digit generator. If you insist: the random number generator
> > outputs the random numbers found in the OTPs. Are you now talking
> > about the OTP random numbers or are you fantasizing about some other
> > numbers. You really must decide what you want to discuss. You
> > are ridiculous if you think there is a flaw in the OTP random
> > numbers. You still have given us no proof of this: not even a
> > plausible glimmer.
>
> For starters it's not an OTP so stop saying that you crank. It's a prng
> at best.
>
> > Your insistence borders on the insane, and we can be sure of this.
> > The only flaw is in your illogical thoughtless position. There is
> > absolutely no flaw in the theory, processes, and procedures of
> > OAP-L3. Show us how you intend to break the OTPs.
>
> No flaw? Cuz you say so.
>
> >
> > Consider the probabilities inherent in the recommended use of
> > OAP-L3 software. Then give up.
> >
> > FACE IT: YOU HAVE BEEN BEATEN BY AN ALGORITHM!
>
> Technically not so. At best we have been beaten by your enormous
> understandings of such complex ideas as "processes" and "mixfiles".
>
> > And consider this: you and your phony cronies in this news group
> > are just about out of time.
>
> Out of time for what?
>
> > Version 4.3 is about to be released. And version 5.0 has been
> > spec'ed out.
>
> What was wrong with 4.3, 4.2 or 4.1, or 4, or 3 or 2 or 1? Obviously
> there is areason why you are updating your software.
>
> > In fact, I have had a working prototype of version 5.0 running for,
> > let me look... over three months now.
> >
> > Version 5.0 will blow everyone away with its variability and power.
>
> Whoopy. What is wrong with 4?
>
> > Isn't this really why you and your phony cronies in this news group
> > are so unnaturally concerned about OAP-L3?
> >
> > I think so.
>
> Nah we just like having a good laugh at someones [yours] expense.
>
> > You asked me to write a paper. Guess what? There are probably
> > a dozen papers already written on OAP-L3. One is at NSA, another
> > at MI 6, one is in Moscow, another in Tokyo, ... But don't hold
> > your breath waiting for one of these to be published.
> >
> > Perhaps someone else will get around to publishing one. They
> > would certainly get much attention from the experts in the field.
> > It would be great publicity for someone. But I recommend they wait
> > until Version 5.0 is released.
>
> Yeah, i'll bet. And they probably have taps on you too right now. Um
> no.
>
> > Here is a suggestion: why don't you write one and highlight your
> > supposed flaws in OAP-L3. Now that would take some guts on your
> > part. Are you not sure enough of your position? I don't think
> > you are. The experts will slaughter you (and your phony cronies as
> > well.) Be sure of it.
>
> Um no. For starters I am a stupid-ass when it comes to abstract algebra
> so even if I wanted to I probably could not break it. But that doesn't
> mean others can't. Second, you have yet to publish the details of your
> wonderfull rng.
>
> Lastly, what is with this '100,000 bit key' thingy you state on your
> page. That's an obvious sign of snake oil.
>
> Tom
Was it you who actually suggested that OAP-L3 may be as strong as
the AES candidates? Someone in these news groups did very recently.
I thought it was you.
What a let down: "For starters I am a stupid-ass when it comes to
abstract algebra..."
I guess your opinions carry little weight in this news group. I
never gave them much weight any why simply because you never
supported any of your positions. What did you expect?
This is all so richly comical.
Was it you who also suggested that the posters in this news group
could help me work out "flaws" in OAP-L3?
So what makes you think I would want or accept your help or anyone
else's help with OAP-L3? Nearly none of you really seems to
understand the software anyway.
I want to assure you that I know what questions to ask regarding
OAP-L3 and I have probably already asked them. I am completing
Version 4.3 now.
I have also mapped out in detail Version 5.0, Version 5.1, and even
a subsequent version. All more powerful and more secure and more
versatile.
Version 5.0 will be an evolutionary leap. Here is a table I
included in a paper I wrote describing the fundamental concept
of Version 5.0 and subsequent versions. I am posting it here
(without any explanation) to put on record that I have already
done it. For those interested in brain teasers, this could be an
enjoyable one to figure out what is going on.
When I release Version 4.3, then I will post this entire document
describing the fundamentals of Version 5.0 (including this table)
on my web site.
Table 1 -
Usg IIP MixFile1 MixFile2 MixFile3 Digit
5 8 6327491805 5382460791 1352094678 9
1 3 7246301598 6153704298 7801354926 3
6 5 7845069213 4019682573 2184065379 4
2 9 1904735268 4273860915 8670159423 7
4 1 0819374256 6421935087 9710324865 9
3 7 3145682790 8601534279 8523419670 4
1 2 1495638027 4139708562 8642375190 4
4 0 6712958403 9152743860 7618943205 5
6 4 1093865724 6491830725 2705941368 6
2 6 8610273495 3091268475 1846327095 8
5 8 7568421390 6729480531 0876925413 8
3 1 9310845672 0567483192 0835974162 9
Usg = usage
IIP = initial index pointer
------------------------------
From: [EMAIL PROTECTED] (NFN NMI L. a.k.a. S.T.L.)
Subject: Re: Proving that you are who you say you are
Date: 20 Apr 2000 06:27:10 GMT
<<closed, proprietary protocol.>>
Gaaach!
<< I need some mechanism to insure that only _my_ client talks to the server.>>
So, only one computer can talk to the server. Okay.
<<In other words, although the protocol will not be documented>>
Yeck!
<<I want to guard against the possibility that someone will reverse engineer
the protocol using a packet sniffer and write an alternative client that
emulates my real client and talks to the server.>>
So, the Adversary gets to monitor all server-client communications, but does
_not_ get physical access to the client, nor can he break into the client and
look at its files?
<<Obviously, there is going to have to be some kind of authentification
handshake in the protocol in which my client identifies itself as being the
real McCoy before the server starts talking.>>
Yes.
<<I assume the best way to do this is to use RSA encryption, i.e., the client
transmits some data that is encrypted with a private key and the server
decrypts it with a public key.>>
Pro'lly something like that.
<< However, I'm concerned about two things. First, if I
distribute an application with a key,>>
Whoa, back the truck up. This is for multiple server-client pairs? Okay.
<<won't it be rather easy for a person with malicious intentions to get ahold
of the key and then spoof being the real client?>>
Only if you do something stupid like have a hardcoded key embedded in every
application.
Here's what _I_ would do, and I know hardly anything about programming.
First, document your work. Duh! Next, your Adversary _cannot_ get access,
physical or otherwise, to the client in any way. If the Adversary gets a copy
of its files or gets to mess with it, all is lost. Period. No amount of "copy
protection" or semi-clever hiding tricks will stop a determined cracker. Now,
it's okay if the communications between the server and the client are tapped
and bugged. Now, you'll need to generate a big RSA keypair, actually two of
them. Probably something like 4096 bits, if you want to be real nice and
paranoid. Give the server the public client key, and give the client the
public server key. Do this physically, because you don't want to bother with
man-in-the-middle stuff. (Or have your users physically do this with diskettes
between the systems. Don't hardcode the keys, obviously). All messages sent
from the client to the server should be encrypted to the server and signed by
the client, and vice versa. Only messages signed by the client will be noticed
and acted upon by the server, and only messages signed by the server will be
noticed and acted upon by the client. (Due to the nature of your one-to-one
setup, there's no real difference between server and client except in what they
do.) Just sign and encrypt everything.
That ought to work.
-*---*-------
S.T. "andard Mode" L. ***137***
STL's Wickedly Nifty Quotation Collection: http://quote.cjb.net
------------------------------
** 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
******************************
