Cryptography-Digest Digest #502, Volume #11 Thu, 6 Apr 00 20:13:01 EDT
Contents:
Re: OAP-L3: Semester 1 / Class #1 All are invited. (James Felling)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Xcott Craver)
Re: Q: Entropy (Mok-Kong Shen)
Re: Encrypt the signature? (Mike Rosing)
Re: Q: Entropy ("Trevor L. Jackson, III")
Re: OAP-L3: Semester 1 / Class #1 All are invited. ("Trevor L. Jackson, III")
----------------------------------------------------------------------------
From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Thu, 06 Apr 2000 12:04:56 -0500
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.
------------------------------
From: [EMAIL PROTECTED] (Xcott Craver)
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: 6 Apr 2000 17:04:14 GMT
Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
>I claim that you cannot successfully use a plain text attack against
>OAP-L3.
>
>Let's cut to the chase: I will give anyone as many OTP files they
>want and all they have to do is predict the next 100 random numbers
>(0 - 255) from the OTPs.
Great! Have you mailed Taneli a CD, or are you yet waiting for
his reply to your offer?
I want to see someone actually step up and take this challenge,
as mere talk doesn't seem to convince Mr. Szopa.
>Believe me, I will create a key with a security level so
>astronomical you could take LSD and not get that far out.
Well, if you choose a key completely at random, as people are
supposed to do, than all keys should have the same level of
security, right?
>I have to say it again: it is clear to me that you do not know
>OAP-L3 and therefore you do not know what you are talking about.
Okay, who, hold on: how dare you say such a thing?
Everything I said in that post was true! None of it even
had anything to do with one particular cipher, such as your
OAP-L3.
It is true for stream ciphers that, given part of the
plaintext, one can extract part of the random digit stream.
It is true that, if one can predict future stream outputs
from previous stream outputs, that there is a "partial known
plaintext" attack on the cipher.
Do you disagree with either of these two points? Because
that's all that was in my post. Perhaps you misread,
or mistook me for someone else? Explain your rude comment.
-Scott
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Date: Thu, 06 Apr 2000 19:17:45 +0200
Tony T. Warnock wrote:
>
> My point is that in practice one ignores really small probabilities. I
> stated things loosely, not as theorems.
>
> In theory a "random bit generator" could produce a long string of zeros
> for example, but in practice, we would consider the generator broken if
> it did.
>
> Complexity theory is generally more useful for cryptography than
> probability in these cases. One could use a "universal" probability
> function rather than assuming the usual probability measure on bit
> strings. Take some universal Turing machine; for each output string get
> the length of the input string that generated that output; assign a
> weight or 1/2**(length) to the output string. Except from some details
> in normalization, this will assign a measure to strings. Strings like
> 0000... or 010101010, or 011011100101110111... will have high measure.
> Unstructured strings will have lower measure. Then occurence of 00000...
> would not seem as "random" as 010010001 or such.
I mentioned in a previous post that one could probably use the
Kolmogorov complexity. Today, after doing some search in the
library, I found the following written by Li and Vitanyi in the
book J. V. Leeuwen (ed.), Algorithm and complexity, p.211
"The following Lemma, due to Levin and Gacs, and also to
Chaitin, shows that K'(x) [the self-deliminating Kolmogorov
complexity] is a symmetric measure of the information in x."
Thus, with such a measure, a sequence of all 0 has indeed less
entropy than another with rather random distribution of 0 and 1.
But the problem for the practice is, of course, that we don't have
any concrete algorithm to compute the Kolmogorov complexity,
unfortunately.
I further speculate from the above that an optimal source that
generates bit sequences of length n should generate these with
frequencies proportional to their Kolmogorov complexity. That
way, the probability of getting sequences of all 0 and the like
would be proportionately lower, which means that the one would
on the average obtain better quality of the output from the source.
M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: Encrypt the signature?
Date: Thu, 06 Apr 2000 11:20:41 -0500
[EMAIL PROTECTED] wrote:
> If I want to have a crypted signed document, have I to
> encrypt the signature ???
No, that's not necessary. You hash the message before encryption,
then use that to make the signature. The signature is independent
of the message in that sense, you can send the message encrypted
along with the signature in the clear. To check the signature you
need a hash of the message, so only the receipient can check it
since only they can decrypt the message. The hash isn't sent.
Patience, persistence, truth,
Dr. mike
------------------------------
Date: Thu, 06 Apr 2000 13:50:54 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Q: Entropy
Mok-Kong Shen wrote:
> Niklas Frykholm wrote:
> >
>
> > It is true that entropy is in the process and not in the sequence, but in
> > practice it is usually the sequence that matters, because the attacker will
>
> The following citatation, however, contradicts you claim that
> entropy is not in the sequence:
>
> Schneier, p.233: Formally, the amount of information in a
> message M is measured by the entropy of a message, denoted
> by H(M).
>
> Thus each particular sequence (message) should have an entropy.
This assumes that you can assign a probability to the message. That probability
of not an intrinsic property of the message, but an extrinsic, applied,
property. The typical origin of the applied property is the collection of
messages of which the individual instance is a member. If the collection is
actually the set of message from a source then it is the selection or generation
process that is described by the probability property rather than the individual
message itself.
Even KC is subject to this interpretation because the elements of a collection of
page-length messages are drastically more compressible if there are only a dozen
members of the collection than if the collection is all possible message a page
in length. Since compressibility is the KC metric, it applies to the elements of
a collection not the individual elements standing alone.
------------------------------
Date: Thu, 06 Apr 2000 13:59:50 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Flaming snake oil has a unique aroma!
Anthony Stephen Szopa wrote:
> [snip rationality]
> "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.
>
> "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.
>
> "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.
>
> "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.
>
> 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.
>
> "messed with it enough" Clearly not enough.
>
> 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?
>
> "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.
>
> 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.
>
> Consider the probabilities inherent in the recommended use of
> OAP-L3 software. Then give up.
>
> FACE IT: YOU HAVE BEEN BEATEN BY AN ALGORITHM!
>
> And consider this: you and your phony cronies in this news group
> are just about out of time.
>
> 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?
>
> 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.
>
> 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.
------------------------------
** 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
******************************
