Cryptography-Digest Digest #592, Volume #11 Fri, 21 Apr 00 05:13:01 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. ("Trevor L. Jackson, III")
Re: Inverse of Permutation polynomials (Diet NSA)
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
New version of MIRACL ("Dann Corbit")
Re: OAP-L3: Semester 1 / Class #1 All are invited. (Anthony Stephen Szopa)
SSL and "man in the middle" attack (Francois Grieu)
Re: SSL and "man in the middle" attack ("Lyalc")
----------------------------------------------------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 00:07:34 -0700
Joseph Ashwood wrote:
>
> > You obviously don't have a clue what a table is for or
> what you are
> > looking for in this table or what you need to reply to let
> me know
> > that you "get it."
>
> Here's another table:
> 59 6f 75 27 72 65 20 61 20 66 75 63 6b 69 6e 67 20 61 73 73
> 68 6f 6c 2c 20 61 6e 64 20 79 6f 75 20 63 61 6e 20 74 61 6b
> 65 20 79 6f 75 72 20 61 62 73 6f 6c 75 74 65 20 6c 6f 73 65
> 72 20 61 6e 20 64 6e 63 72 79 70 74 69 6f 6e 20 61 6c 67 6f
> 72 69 74 68 6d 20 61 6e 64 20 73 68 6f 76 65 20 69 74 20 77
> 68 65 72 65 20 74 68 65 20 73 75 6e 20 64 6f 6e 27 74 20 73
> 68 69 6e 65
>
> And I think it's pretty clear about what you are to do with
> it.
>
> > Also note that you have misrepresented the random number
> generator
> > when you say the random digit generator in OAP-L3 is not
> > cryptologically secure.
>
> You have never established that your algorithm is
> cryptologically secure, it's probably a safe assumption that
> it's not cryptologically secure.
>
> >
> > You have chosen one part of the random number generator
> and made
> > this claim. The entire random number generator process
> results
> > in the random numbers contained in the OTPs, and not the
> random
> > digits from the MixFile process you address.
>
> If one part of the pRNG is insecure the entire thing is
> insecure (see complaints about original MARS key schedule).
>
> > There is only one legitimate test for determining the
> security of
> > encryption software: this test is that the cracker needs
> to know
> > all about the encryption software's inner workings, the
> cracker
> > needs to have a substantial amount of plain text, and the
> > corresponding encrypted text. From this knowledge and
> this
> > information the cracker must crack all encrypted messages.
>
> No that is not the only legitimate test, if the security of
> your pRNG has been successfully compromised without access
> to much of the information that you have not released, then
> it has been compromised.
>
> >
> > You are only asking essentially for the key to the MixFile
> / random
> > digit process and then trying to predict subsequent random
> digits.
>
> Which of course may be enough to compromise the fake
> security of your system
>
> >
> > You want this key (once removed) and expect someone to
> believe you
> > have cracked this process then you leap to the conclusion
> that the
> > entire random number generator / generation is flawed.
>
> If you don't think he can do it, give him what he asks for.
> Joe
I make a convincing logical argument in the Theory Help File why
there is no introduced bias when the software is used according to
recommendations. I make a convincing logical case why the output
is random. And I make a convincing logical case why the software
is practicably unbreakable with a sufficiently long key.
You say I haven't.
Then I say you haven't read the Help Files adequately.
If and when you read the Help Files adequately it should certainly
be easy for you to follow my arguments and point out where they are
incorrect.
If you don't understand the arguments then let me know the very
first exact sentence you don't understand, and what the nature of
your confusion is. Then we'll take it from there. I await your
pleasure.
Yes, you are right. If someone looks into your computer and gets
the key or part of it, well, I guess your encryption is certainly
compromised. You are a shining light of brilliance on this point.
The art of innuendo is amusing but not convincing.
Your position is that if I provide the key then my software is
compromised? I have no argument with that.
Tell us how you would break OAP-L3 encrypted messages.
Changing the subject:
Since I am taking the time, let me tell you how amused I was when
someone said that there are no papers written on OAP-L3 and that I
am something or other to suppose there were.
Who do you think monitors this news group and associated news groups
on encryption? All intelligence organizations worth their salt from
around the world. Also, very smart corporations. Also, competing
encryption product producers. Also, academicians involved in
encryption and mathematics. Basically, any and all those whose
business it is to know: all those in the business of knowing:
the knowledge business people. The people who are always looking,
listening, analyzing, thinking, planning. The people who really
know how to have fun.
Many of them are located in good ol' Virginia. I ought to know,
my web stats show the most organizations and the heaviest traffic
from there. Now who could they all be in good ol' Virginia?
I know who I am talking to. Many of you don't even know who is
listening.
This is why I am not wasting my time in this news group. I am
playing through most of you and addressing them.
I like them. I like them all. For better or worse.
Maybe I will tell you why some day.
------------------------------
Date: Fri, 21 Apr 2000 03:28:43 -0400
From: "Trevor L. Jackson, III" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Anthony Stephen Szopa wrote:
> "Douglas A. Gwyn" wrote:
> >
> > Anthony Stephen Szopa wrote:
> > > This is all so richly comical.
> >
> > That's because instead of conducting a technical dialogue,
> > you're just insisting that you're right and everybody else
> > is intellectually dishonest. And instead of explaining
> > the principles in terms that would make sense to a working
> > cryptologist, you simply direct us to figure it out
> > ourselves from the "help files". How about treating this
> > as a genuine technical discussion? For example, tell me
> > why my observation (based on examining the "help files")
> > that at least one of the three columns of generated "mix"
> > could be recovered by chaining is flawed (as you claimed).
> > I suspect that most cryptologists will have no real
> > interest in your system if their concerns are not addressed
> > in good faith.
>
> Real cryptologists understand my Help Files.
Excellent. Now we are making progress. Please name at least two "real
cryptologists" who understand your Help Files.
------------------------------
Subject: Re: Inverse of Permutation polynomials
From: Diet NSA <[EMAIL PROTECTED]>
Date: Thu, 20 Apr 2000 09:23:53 -0700
In article <8djg3j$gp9$[EMAIL PROTECTED]>
, [EMAIL PROTECTED] wrote:
>Reading all the messages from Tom about permutation polynomials
mod
>(2^w), I couldn't help but get interested in the subject.
I too became interested & looked for more
info on perm. polys. There are quite a few
papers written on crypto applications of
perm. polys., but I don't know what they
are because it would have taken me too
long to actually track down these papers.
Dan Ashlock gave a talk called "Matrix
permutation polynomials over the
integers (mod n)". I wonder what matrix
permutation polynomials are? (I suppose
someone could email Mr. Ashlock).
"I feel like there's a constant Cuban Missile Crisis in my pants."
- President Clinton commenting on the Elian Gonzalez situation
=======================================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 01:31:54 -0700
James Felling wrote:
>
> > <giant snip>
> >
> > I will prove you do not know what you are talking about by you
> > simply answering this question:
> >
> > The OAP-L3 encryption software uses a random number generator.
> > Now which of the following is the most correct and most
> > comprehensive description of this random number generator that
> > it uses: which is the description that results in the random
> > numbers used in the encryption process?
>
> >
> > 1) The process that outputs the random digits from the MixFiles, or
> >
> > 2) the process that results in the OTP files?
>
> Well the best way to answer that is "neither"( or "both" -- depends upon how I look
>at it). I
> agree that the stream data is generated primarially by process #2. However it
>still uses
> data from process #1 to produce the mix files which are then used by process #2. If
>one
> examines the crypto literature you will find many algorithims that have comentaries
>by skilled
> people along the line of "this section of the algorithim is weak -- it does not do X
>properly
> -- I have found no attack to exploit this property" and this is enough to withdraw
>the
> algorithim from serious consideration. Why should your program be judged upon a
>different
> standard?
>
> >
> >
> > Now define precisely what your supposed flaws are and what is the
> > exact nature of these "artifacts" you allege?
>
> Ok since you have obviously not done even a textbook analisys of your mix file
>generation
> process I will.
> I am using your own names for the subprocesses.(P.S. this is not an exhaustive list
>of what I
> have found, but it is simply the result of a half hour of simple kindergarten
>cryptoanalisys)
>
> We start with a file F of all possible 1 to 10 sequences.I shall number them
>F(1),F(2),
> ....,F(10!)
>
> 1) Scramble -- since all other mixing ops are external( they affect the order in
>which the
> F(i)'s are presented) Scramble is effectively orthogonal to all other MixFile
>creation
> steps.This means we can effectivly treat all other steps as modifying the set S=
> Scramble(F(1)), Scramble(F(2)), ....., Scramble(F(10!))
>
> 2) Mix -- The "Mix" operation doesn't do a very good job of it. M(i)= the ith
>sequence of
> Mix(S) has the following properties M(j+105*n)= S(j+105*n) with probability . (n>=0,
>and j=
> first mix value). Since there are further steps this is less bad than it seems.
>
> 3) Redistribute -- This creates 14 files I will denote them as T(1) to T(14), and
>then T(k,m)
> = themth member of Tfilek.
> This is aparently accomplished as follows T(k,m)= M( (k-1)*259200 + m ).
>
> 4) Shuffle. This Permutes the Tfiles, then data are taken from them in the permuted
>order to
> generate the mixfile.call this permutation p(x).
>
> Attack vs mix file generation.
>
> Sincej>=1, T(1,1)= Scramble(F(1)) , and T(8,1)=Scramble(F(1814401)) this meand
>that within
> the first 14 sequences in the Mix files we have two sequences that are known, this
>will occur
> regularly within the mix file where within 14 digits at easily computable points in
>the file 2
> sequences (Scrambled) with known chjaracter exist. Because of this we have very good
>odds of
> recovering both scramble, and some very good information on P(x) in addition.
>Further, if
> j>1 we will easily recover scramble as T(1,2) will occur 14 spots later in the file
>and will
> be a single rearangement swap different from T(1,1)
> .
>
> As you can see the Mixfile.otp has a significant amount of exploitable structure --
>enough to
> allow recovery of its generating keys in comparitively short order. Since this is
>the case,
> it seems likely to me that at least some of this structure could be exploited by an
>analyst
> working the whole key backward.
>
> >
> >
> > Let me end with this:
> >
> > The accepted test of the security of an encryption process is not
> > what Mr. Huuskonen has asked for. The accepted test is that it is
> > assumed that the cracker knows every thing there is to know about
> > the algorithm, and that the cracker has a substantial amount of
> > plain text and the corresponding encrypted text. From this
> > it is demanded that the cracker use this information and knowledge
> > to crack the software. This is hardly what Mr. Huuskonen is asking
> > for: he is essentially asking for the key once removed.
>
> Yes, to a degree he is. But the same structures that allow him to attack your mix
>file will
> exist, to a lesser degree in the final output. My guess is that the Mix files
>provide about
> 20-30 bits of randomness per each(assuming my attack cannot be refined). This puts
>the
> randomness of your code somewhere in the neigborhood of a 90 to 100 bits( tops) when
>you
> factor it all in. I will be generous and say you are as secure as 3DES(112 bits).
>Why should
> we use your code in prefrence to 3DES?
This is nothing but BS and I think you know it.
Let's keep it simple then build from there.
Let's say we start with the original encryption data file: the
3,628,800 ten-digit permutations consisting of the digits 0 - 9
with no repeats. In this original encryption file the permutations
are arranged in ascending order.
Let's just run the Shuffle process once. The first 259,200 arrays
are read from the original encryption data file and written to
TFile1. The next 259,200 arrays are read and written to TFile2.
The next 259,200 arrays are read and written to TFile3, etc. until
there are TFile1 - TFile14.
The user then inputs a true random 14 number sequence of the
numbers 1 - 14 with no repeats. For your information there are
14! = over 87 billion possible unique sequences of the numbers
1 - 14.
Then these 14 TFiles are interleaved one array at a time according
to this 14 number sequence.
The resulting output file, we'll call it, MixFile1, is one of over
87 billion possible.
You say it will be easy to guess the order of the permutations in
this MixFile1? How will you do it? There is only one way to do
it: trial and error by using all the 87 billion 14 number
sequences. (Because the input was true random you cannot get around
this by any other means.)
So, after you have produced each of these over 87 billion possible
MixFile1's you store them confident that you have certainly produced
the correct MixFile1 among the over 87 billion you have generated and
stored.
Okay.
Now let us run the Shuffle process again on MixFile1 using another
true random 14 number sequence of the numbers 1 - 14 with no repeats
and call the output again, MixFile1. As above, there are over 87
billion possible sequences.
But there are now over (87E9)^2 possible 28 number sequences of two
sequences of 14 numbers 1 - 14 in a row.
So now you have to produce and store over (87E9)^2 MixFile1's but
you can still be certain that at least one of these (87E9)^2
MixFile1's is the correct one.
Let's say I repeat the process 50 times in total. This means that I
have shuffled the original encryption data file 50 times using one
of over 87 billion 14 number sequences with each shuffle. Thus the
total user input is 50 true random 14 number sequences of the numbers
1 - 14.
This means that there are over (87E9)^50 possible 50 true random 14
number sequence sequences in a row and that the actual input used is
only one of these over (87E9)^50 sequences.
For you to determine the final MixFile array sequence after 50 runs
of the Shuffle process with absolute certainty that at least one of
the MixFiles is the actual one, you will have to produce over
(87E9)^50 MixFiles, and store them.
Let's see, if each MixFile is over 18MB you will need enough storage
for 18E6 * (87E9)^50 = 1.5E459 bytes.
But you can at least be sure you have the right sequence somewhere
among them all.
Your problem now is: which one is it?
Let's say you need three such MixFiles and that the user uses their
last MixFile1 after 50 Shuffle runs to begin 50 more shuffle
processes to produce a MixFile2, then run 50 more processes on this
last MixFile2 to produce a MixFile3.
Similarly as shown in the Theory and Processes Help Files, the odds
of duplicating MixFile1 with certainty is one in (87E9)^50.
But for duplicating MixFile2 it is one in ((87E9)^50)^2 = (87E9)^100.
For duplicating MixFile3 it is one in ((87E9)^50)^3) = (87E9)^150.
And finally, to guess with certainty, all three MixFiles it would be
(87E9)^50 * (87E9)^100 * (87E9)^150 = (87E9)^300.
Tell us how you are going to guess the one chance in (87E9)^300 of
getting the correct three exact MixFiles? (Not to mention store all
of them.)
We really want to know?
Give up?
Give up.
And we haven't even considered subsequent processing of the random
binary number files produced from the MixFiles.
Now, what is it you don't understand about unbreakable?
(I bet you would you like me to sneak you the key right about
now, eh?)
See, how plain it is in layman's terms. This is why I say that the
entire software package is understandable by anyone with average
intelligence.
Now what exactly don't you understand?
(And whatever it is you'd like to say can you say it in laymen's terms
so everyone can understand you?)
Thank you.
(All of this is just as simply explained in the Help Files at
http://www.ciphile.com)
------------------------------
From: "Dann Corbit" <[EMAIL PROTECTED]>
Subject: New version of MIRACL
Date: Fri, 21 Apr 2000 01:38:44 -0700
One of my favorite toys just got updated:
http://indigo.ie/~mscott/
Definitely worth a look.
;-)
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. Newsgroup http://www.dejanews.com/~c_a_p
C.A.P. FAQ: ftp://38.168.214.175/pub/Chess%20Analysis%20Project%20FAQ.htm
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Semester 1 / Class #1 All are invited.
Date: Fri, 21 Apr 2000 01:34:34 -0700
Taneli Huuskonen wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In <[EMAIL PROTECTED]> Anthony Stephen Szopa
> <[EMAIL PROTECTED]> writes:
>
> [...]
> >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
>
> Usg IIP MixFile1 MixFile2 MixFile3 Digit
> 1 8 6327491805 5382460791 1352094678 9
> 2 3 7246301598 6153704298 7801354926 7
> 3 5 7845069213 4019682573 2184065379 1
> 4 9 1904735268 4273860915 8670159423 3
> 5 1 0819374256 6421935087 9710324865 0
> 6 7 3145682790 8601534279 8523419670 6
>
> Taneli Huuskonen
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 5.0i for non-commercial use
> Charset: noconv
>
> iQA/AwUBOP7aE1+t0CYLfLaVEQIHUwCfVX4MwuwPnlYto8AJW4iZYItupEIAniEv
> BsuX8t0/6YeuufEKHuaOytQ1
> =3O5z
> -----END PGP SIGNATURE-----
> --
> I don't | All messages will be PGP signed, | Fight for your right to
> speak for | encrypted mail preferred. Keys: | use sealed envelopes.
> the Uni. | http://www.helsinki.fi/~huuskone/ | http://www.gilc.org/
You obviously don't have a clue what a table is for or what you are
looking for in this table or what you need to reply to let me know
that you "get it."
When I release OAP-L3 Version 4.3 I will make available the paper I
wrote explaining the fundamentals upon which Version 5.0 will be
based. This table will be included, of course.
Also note that you have misrepresented the random number generator
when you say the random digit generator in OAP-L3 is not
cryptologically secure.
You have chosen one part of the random number generator and made
this claim. The entire random number generator process results
in the random numbers contained in the OTPs, and not the random
digits from the MixFile process you address.
I entertained you when you suggested that you could predict
subsequent digits from the MixFile process you referred to to
see where it would lead.
Your requirements to do this only prove that the entire random number
generator process IS secure and here is why.
There is only one legitimate test for determining the security of
encryption software: this test is that the cracker needs to know
all about the encryption software's inner workings, the cracker
needs to have a substantial amount of plain text, and the
corresponding encrypted text. From this knowledge and this
information the cracker must crack all encrypted messages.
You are only asking essentially for the key to the MixFile / random
digit process and then trying to predict subsequent random digits.
You want this key (once removed) and expect someone to believe you
have cracked this process then you leap to the conclusion that the
entire random number generator / generation is flawed.
You are not in my kill file but I will only reply to honest and
intelligent posts from you in the future.
------------------------------
From: Francois Grieu <[EMAIL PROTECTED]>
Subject: SSL and "man in the middle" attack
Date: Fri, 21 Apr 2000 10:39:59 +0200
I am looking for references on the security of the SSL protocol against
the "man in the middle" attack (*) in the context of online commerce
using credit card info keyed-in by the customer.
I have heard conflicting reports, ranging from
1) SSL offers no protection against the man in the middle attack
2) a man in the middle attack can be mounted simply with knowledge of
the secret key and certified public key of any SSL server, which is
readily available to hackers; and there is no infrastructure in the
leading browsers to revoke server public key certificates [variants: no
workable/working infrastructure]
3) all browsers check the domain name in the server's certificate
matches the actual domain name reported by the DNS system, so the
attacker needs to attack the DNS protocol as well; this limits the
attack to a location close (in the network sense) to the end user.
4) and this will work only if the user does not check the server
identification info, which the leading browsers display clearly.
5) SSL is safe (source: sites using SSL :-)
Any serious study out there ?
Comments and pointers welcome.
Francois Grieu
(*) where an attacker can alter the information exchanged on the network
------------------------------
From: "Lyalc" <[EMAIL PROTECTED]>
Subject: Re: SSL and "man in the middle" attack
Date: Fri, 21 Apr 2000 18:49:32 +1000
See:
Web Spoofing: An Internet Con Game
Edward W. Felten, Dirk Balfanz, Drew Dean, and Dan S. Wallach
Technical Report 540�96 (revised Feb. 1997)
Also, there is another atttack source to add to your list:
- Modifying a hyperlink on valid web page to point to the wrong SSL address.
A subtle form defacement.
Lyal
Francois Grieu wrote in message ...
>I am looking for references on the security of the SSL protocol against
>the "man in the middle" attack (*) in the context of online commerce
>using credit card info keyed-in by the customer.
>
>I have heard conflicting reports, ranging from
>
>1) SSL offers no protection against the man in the middle attack
>
>2) a man in the middle attack can be mounted simply with knowledge of
>the secret key and certified public key of any SSL server, which is
>readily available to hackers; and there is no infrastructure in the
>leading browsers to revoke server public key certificates [variants: no
>workable/working infrastructure]
>
>3) all browsers check the domain name in the server's certificate
>matches the actual domain name reported by the DNS system, so the
>attacker needs to attack the DNS protocol as well; this limits the
>attack to a location close (in the network sense) to the end user.
>
>4) and this will work only if the user does not check the server
>identification info, which the leading browsers display clearly.
>
>5) SSL is safe (source: sites using SSL :-)
>
>
>Any serious study out there ?
>Comments and pointers welcome.
>
>
> Francois Grieu
>
>
>(*) where an attacker can alter the information exchanged on the network
------------------------------
** 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
******************************
