Cryptography-Digest Digest #480, Volume #14 Thu, 31 May 01 02:13:00 EDT
Contents:
Re: differential oddity (JPeschel)
Re: James Felling: Sorry to break your bubble (Jim Felling)
Re: RSA's new Factoring Challenges: $200,000 prize. ("Michael Brown")
Re: Turbo Small Public Key Cryptosystem ("Michael Brown")
Re: taking your PC in for repair? WARNING: What will they ("Michael Brown")
Re: Good crypto or just good enough? (David Wagner)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (JPeschel)
Date: 31 May 2001 03:44:50 GMT
Subject: Re: differential oddity
"Tom St Denis" [EMAIL PROTECTED] writes, in part:
>Hmm, well perhaps I will order the preceedings...
Try:
http://adonis.ee.queensu.ca:8000/sac/sac97/papers/paper1.ps
Joe
__________________________________________
Joe Peschel
D.O.E. SysWorks
http://members.aol.com/jpeschel/index.htm
__________________________________________
------------------------------
From: Jim Felling <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: James Felling: Sorry to break your bubble
Date: Wed, 30 May 2001 22:59:21 -0500
Anthony Stephen Szopa wrote:
> Kt wrote:
> >
> > HiEv wrote:
> >
> > > First of all, the phrase is "burst your bubble" not "break your bubble".
> >
> > HiEv, this guy is one of life's embittered losers. Let him be.
> >
> > Kt
> > --
> > http://www.althacker.org
> > Web: http://kt.althacker.org
> > PGP Fingerprint: 75B2 6525 A47D 7B5B B68B 4141 CAD9 8985 504B 580D
> >
> > "Two fonts walk into a pub and the barman says, 'Sorry, we don't serve your
> > type here.'"
>
> (I posted this 24 & 48 hours ago but don't see it here so I've
> posted it again.)
>
> Actually I did post this reply to his post in the original thread.
> I posted it here as well because I know that some readers haven't
> been following that original thread.
>
> (Be sure to read the last 5 lines of this reply post.)
>
> I am not going to go back and pull out my politeness handbook but he
> is the one who came up with the "nasty" flaw comment. When you start
> horse playing around with a gorilla I would expect the play to get a
> little rough.
>
> I think it is significant when someone says that I have egg on my
> face then gives me a suggestion to fix or improve my design then
> come to find out that his suggestion is so completely bogus as to
> nearly defy description although I did manage to describe why his
> suggestion is all washed up.
>
I in no way claimed that the generic family that mix a mix file came from was a
'superior' method. I claimed your method was flawed and that there was a simple
fix.
Here is the first fix I found.In Mix a mix file is make the permutation take 14
numbers between 1 and 15( there is one number excluded) This will make Mix a Mix
file significantly better as a mixing method. It still has some of the flaws of
its antecedent -- namely a tendency to keep the first few bytes of the file up
front, but it is substantially better than Mix a mix file as it now stands.
Annother fix is a variable offset to the permutation(i.e. starting from a
different point in the file based on an input 15'th number. This is not quite as
good, but is OK.
Do you understand why the first is better than the second?
>
> So with my stunning proof that he doesn't know what he is talking
> about with his own suggestion as to what I should do or how he has
> come up with a better mouse trap, how can you continue to blindly
> give his original comments anything but skepticism?
>
Because they exhibit an understanding of the way your system works.
> <snip>
>
> I responded that his fixed point argument is immaterial. When a
> different process is run these fixed points are no more.
Of course the poor mixing resulting therefrom is still present. to use my
shuffle analogy -- it is a poor shuffle. Just because I can fix it in annother
way does not change that fact. This is like saying. My car has one cylinder in
the engine that does not work, but the other cylinders are all working, so I
don't need to have them all work, it still goes. To which I say yes it does, but
it would go better if they all worked. And since a good fix to the problems is
really simple( analagous to conecting the spark plug to the distributor cap with
the proper wire), the fact that it is in this condition makes me suspicious about
the condition that the whole assembly is in.
>
>
> If his point(s) is/are valid then when the final OTPs are generated
> then you can surely point out to us where and how and why these
> alleged "flaws" have affected the OTP output where you can determine
> something, anything, etc. (keep hoping) that you can claim has
> compromised the output.
No I freely admit that I cannot break the output of your algorithim when it is
properly setup. However, I also cannot break RC4 with a keying the length of
this sentence. And I think that key would be easier to remember and use than your
program.
>
>
> To claim there is a flaw requires that one be able to point it
> out. Point out any flaw in the final OTP output as a result of these
> (immaterial) "flaws."
I however am not a true professional, and I feel that a true pro would have
better attacks than I and substantially better resources both in terms of
computing resources and espionage capabilities.
> If they are immaterial then they are not
> "flaws." Perhaps a better phrase would be inconsequential anomalies
> or immaterial peculiarities of OAP-L3.
I would call them flaws. Look at FROG it had a weakness even less glaringly
significant than yours, and it was totally disqualified from being considered as
a seroius method because of it. If your method is a serious one hold it to
professional standards sir.
>
>
> If you are saying that these "flaws" are material to the final OTP
> output then I will ask you as I ask everyone: prove it in the
> slightest sense. Give us a clue. Give us something to chew on.
I do not have the time or resources. Perhaps others do.
>
>
> The recommended use of OAP-L3 is to randomly choose the processes to
> run and randomly choose what order to run them in and to input
> random data into each process.
>
>
> Check this out. Here are the first 105 permutations from the file
> after I have run this particular process ten times with random
> input for each run. Now compare this output to what JF suggested.
First off what is it I suggested again? I don't recall making a suggested
improvement. I merely pointed out a flaw and said I knew a better method existed.
>
>
> Array number: 0 0 1 2 3 4 5 6 7 8 9
> Array number: 1 0 1 2 3 4 5 6 7 9 8
> Array number: 2 0 1 2 3 4 5 6 8 7 9
> Array number: 3 0 1 2 3 4 5 6 8 9 7
> Array number: 4 0 1 2 3 4 8 9 6 7 5
> Array number: 5 0 1 2 4 5 9 7 8 3 6
> Array number: 6 0 1 2 4 6 3 5 8 9 7
> Array number: 7 0 1 2 4 6 3 8 9 7 5
> Array number: 8 0 1 2 5 4 3 6 8 7 9
> Array number: 9 0 1 2 5 6 3 4 8 7 9
> Array number: 10 0 1 2 7 5 9 6 4 3 8
> Array number: 11 0 1 3 4 5 7 8 2 9 6
> Array number: 12 0 1 3 4 6 2 9 5 8 7
> Array number: 13 0 1 3 4 6 2 9 7 5 8
> Array number: 14 0 1 3 8 6 5 9 2 7 4
> Array number: 15 0 1 4 3 2 7 5 6 9 8
> Array number: 16 0 1 4 3 2 8 6 7 5 9
> Array number: 17 0 1 4 3 6 5 7 2 8 9
> Array number: 18 0 1 5 2 3 9 6 8 4 7
> Array number: 19 0 1 5 2 3 9 7 6 4 8
> Array number: 20 0 1 5 2 6 3 7 4 8 9
> Array number: 21 0 1 5 3 7 2 9 4 8 6
> Array number: 22 0 1 5 4 9 6 7 8 2 3
> Array number: 23 0 1 5 4 9 8 3 2 6 7
> Array number: 24 0 1 6 7 4 8 9 2 3 5
> Array number: 25 0 1 6 7 4 8 9 2 5 3
> Array number: 26 0 1 6 7 4 8 9 3 2 5
> Array number: 27 0 1 6 9 8 4 5 3 2 7
> Array number: 28 0 1 6 9 8 7 2 3 4 5
> Array number: 29 0 1 7 2 8 6 9 4 3 5
> Array number: 30 0 1 7 3 6 2 8 4 5 9
> Array number: 31 0 1 7 6 2 3 9 5 4 8
> Array number: 32 0 1 7 6 2 4 5 9 8 3
> Array number: 33 0 1 7 6 2 4 8 3 9 5
> Array number: 34 0 1 7 6 4 2 3 9 8 5
> Array number: 35 0 1 7 6 4 2 5 3 8 9
> Array number: 36 0 1 7 8 3 2 6 9 5 4
> Array number: 37 0 1 7 8 3 4 5 9 6 2
> Array number: 38 0 1 8 2 9 4 5 3 7 6
> Array number: 39 0 1 8 3 2 6 9 5 4 7
> Array number: 40 0 1 8 3 2 7 4 6 5 9
> Array number: 41 0 1 8 4 5 6 2 3 9 7
> Array number: 42 0 1 9 7 5 3 4 8 2 6
> Array number: 43 0 1 9 7 5 3 4 8 6 2
> Array number: 44 0 1 9 7 5 3 6 2 4 8
> Array number: 45 0 1 9 8 5 7 2 3 4 6
> Array number: 46 0 2 1 5 6 4 9 8 3 7
> Array number: 47 0 2 1 5 6 7 8 9 4 3
> Array number: 48 0 2 1 6 5 8 3 7 9 4
> Array number: 49 0 2 1 7 9 6 8 3 4 5
> Array number: 50 0 2 1 7 9 6 8 3 5 4
> Array number: 51 0 2 1 9 3 7 6 5 8 4
> Array number: 52 0 2 1 9 4 5 3 8 7 6
> Array number: 53 0 2 1 9 4 5 6 8 7 3
> Array number: 54 0 2 1 9 5 7 8 6 3 4
> Array number: 55 0 2 4 1 6 3 9 8 7 5
> Array number: 56 0 2 4 3 1 7 5 9 6 8
> Array number: 57 0 2 4 3 1 7 6 8 9 5
> Array number: 58 0 2 4 3 1 7 9 5 8 6
> Array number: 59 0 2 4 3 5 9 7 6 1 8
> Array number: 60 0 2 4 3 6 5 8 1 7 9
> Array number: 61 0 2 4 9 5 1 7 6 8 3
> Array number: 62 0 2 4 9 5 1 7 8 3 6
> Array number: 63 0 2 4 9 5 1 7 8 6 3
> Array number: 64 0 2 4 9 5 1 8 3 6 7
> Array number: 65 0 2 4 9 6 3 8 7 5 1
> Array number: 66 0 2 5 1 7 6 4 8 9 3
> Array number: 67 0 2 5 3 9 8 4 7 6 1
> Array number: 68 0 2 5 4 9 8 6 3 7 1
> Array number: 69 0 2 6 1 9 5 7 8 3 4
> Array number: 70 0 2 6 9 3 1 8 7 4 5
> Array number: 71 0 2 6 9 3 1 8 7 5 4
> Array number: 72 0 2 6 9 3 4 1 8 7 5
> Array number: 73 0 2 7 1 6 5 8 3 9 4
> Array number: 74 0 2 7 1 6 5 8 4 3 9
> Array number: 75 0 2 7 1 6 5 8 4 9 3
> Array number: 76 0 2 7 1 6 5 8 9 3 4
> Array number: 77 0 2 7 1 9 8 5 4 6 3
> Array number: 78 0 2 7 3 1 8 4 9 5 6
> Array number: 79 0 2 8 3 6 4 1 9 7 5
> Array number: 80 0 2 9 4 3 8 6 7 5 1
> Array number: 81 0 2 9 4 8 6 7 5 3 1
> Array number: 82 0 2 9 4 8 7 1 3 5 6
> Array number: 83 0 2 9 4 8 7 1 3 6 5
> Array number: 84 0 2 9 4 8 7 3 1 5 6
> Array number: 85 0 2 9 6 1 3 7 8 5 4
> Array number: 86 0 2 9 6 1 5 3 7 4 8
> Array number: 87 0 2 9 6 1 5 3 7 8 4
> Array number: 88 0 2 9 6 1 8 7 5 4 3
> Array number: 89 0 2 9 6 3 4 5 8 1 7
> Array number: 90 0 2 9 8 6 5 1 3 4 7
> Array number: 91 0 2 9 8 6 5 1 3 7 4
> Array number: 92 0 3 1 8 4 6 9 2 7 5
> Array number: 93 0 3 1 8 5 7 4 2 6 9
> Array number: 94 0 3 1 8 5 7 4 6 9 2
> Array number: 95 0 3 1 8 5 7 9 4 2 6
> Array number: 96 0 3 1 8 9 7 2 4 5 6
> Array number: 97 0 3 1 9 5 6 2 8 7 4
> Array number: 98 0 3 4 6 9 5 1 7 8 2
> Array number: 99 0 3 4 8 1 7 5 6 2 9
> Array number: 100 0 3 4 8 5 7 2 9 1 6
> Array number: 101 0 3 4 8 5 9 6 1 2 7
> Array number: 102 0 3 4 8 5 9 6 1 7 2
> Array number: 103 0 3 4 8 6 2 1 5 9 7
> Array number: 104 0 3 4 9 2 5 6 1 7 8
If this is the first 10 ouputs of your method after mix a mix file has run 10
times. I would like to point out a few things. ~1% of the time ther is no mixing
in the first 10,~2% of the time ther is no mixing of the first 8, ~4% of the time
there is no mixing of the first 7, ~5% no mixing of the first 5, ~10% no mixing
of the first 3, and ~44% of the time there is no mixing of the first 2. And this
is after 10 successive aplications of your method. I sure feel confident now.
>
>
> JFs suggestion will never ever even come close to this. Every
> single one of his 105 permutation groups will always have the first
> 5 or 6 digits exactly the same no matter how many times he runs
> his process.
How do you figure?
>
>
> I seem to have concretely defended my position. If it is not clear
> enough then tell us a problem you have with OAP-L3 and I will address
> it further for you.
>
> JFs suggestion that my groups are 105 permutations is misleading.
> Technically this is true when you look only at one specific running
> of the process. But the effect is cumulative over the entire
> 3,628,800 permutation set. The more the process is run the more the
> effected group is expanded: the entropy over the entire permutation
> set increases.
If you understood permutations this would be so much easier on both of us. Your
mix a mix file views the 3,628,800 0-9 set file as a set of many groups each 105
sets long.
>
>
> His suggestion was exactly 105 permutations long and remained so no
> matter how many times he ran the process. The entropy was confined
> within each 105 permutation group within the entire permutation set.
As is Mix a mix file.( examine the method and you will see why.)
>
>
> As you said, my process also shows some redundancy. This is inherent
> in this process. But it does add entropy over the entire permutation
> set. You can quantify the entropy. You know exactly where you
> stand.
I know where I stand with your method. You sir, seem to have little clue.
>
> When you randomly run processes and input random data in each process
> you can calculate what the output entropy is. And each process
> increases the entopy over the entire permutation set.
True to a degree.
>
>
> At first glance you may not be too impressed with the above 105
> permutations. Keep in mind that since you are randomly running each
> process it is unlikely that you will run the Mix a Mixfile process 10
> times in a row. But when you do run it it will add the usual
> entropy
> to the output file.
> And it makes a big difference in what sequence
> or order you run the processes in.
>
Sure it does.
>
> And keeping in mind how the permutations transform each other and
> index or reference each other to generate random digit output you
> will realize that the cumulative entropy and inherent inefficiency
> designed into OAP-L3 will result in very good random number
> distributions.
Agreed, but inputing half that much data into a small set of modern stream
cyphers and looking at that stream after mixing that set through a combiner. will
be substantially better.
> There are utility programs that come with OAP-L3
> that allow you to quantify the random number output distribution.
> The random output numbers are excellent.
No argument there. But try getting good results with say 300characters of input
to your program. You simply cant.
>
>
> No single process was designed to randomly shuffle the entire
> permutation set. Each was designed to add a modest amount of
> entropy. And in combination all the processes were designed to at
> least effectively reach enough of the possible key space to make
> OAP-L3 practicably unbreakable: quite so.
>
> Now keep in mind that this is just the first half of the overall
> process. Once you use three thoroughly and randomly shuffled
> MixFiles to generate random digits and only use about a random 70%
> of these digit triplets you further thoroughly reprocess these
> random number (000 - 255) files.
>
> If you can even reasonably suggest any possibility of some sort of
> flaw in the final OTP files generated, again, we would all like to
> hear of it.
>
> By the way, I wouldn't put it past JF to have made his post knowing
> all along that his suggestion was bogus. He might just have wanted
> to see if I was intelligent enough to see through it.
>
> But in so doing he has heard from many of you, as well.
>
> Cheers.
>
> (Get a sense of humor.)
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: RSA's new Factoring Challenges: $200,000 prize.
Date: Thu, 31 May 2001 17:01:45 +1200
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I have no doubt that something along these lines can work,
> in the sense that in principle the factors are always obtained,
> although I can't yet vouch for this particular algorithm.
> The main unresolved question seems to be, how many operations
> can we expect for finding a typical N-bit prime factor?
If you are referring to my algorithm (hopefully :P), then there are x^3 - x^2 -
x boxes to complete, where x is the number of digits in the maximum prime. As
for how many operations this involves, I would have no idea, but I would guess
the limit would be around about 4 times this. Just a guess based on doing ones
on paper though.
If you weren't referring to mine, then never mind :)
Michael
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Subject: Re: Turbo Small Public Key Cryptosystem
Date: Thu, 31 May 2001 17:05:56 +1200
Since the fastest DES implementation is long gone, who's up for the challenge of
writing the smallest one? I reckon a few incredibally convuluted lines of
assembler would do the trick :)
Michael
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Ok this is just for fun (so keep that in mind)
>
> I wrote a really super small PK system for *NIX today (in about 1.5 hrs)
>
> It uses DH and RC4 to encode/decode messages. It doesn't do signatures
> (what's the point?). It's very compact... in linux it builds to about
> 32kb in size and is very fast.
>
> It doesn't do ascii armor or silly headers etc. (So it's probably very
> vulnerable if you try to decode /dev/urandom as a message). I've barely
> tested it (it does encrypt/decrypt afaik).
>
> http://tomstdenis.home.dhs.org/tc.zip
>
> This is by no means a replacement for PGP since it lacks alot (say
> signatures, key'ids and such, but I feel those are meaningless anyways!)
>
> The source is not commented but it's very easy to follow. It's mostly
> modular and somewhat organized (comes with a makefile that installs it
> in /usr/local/bin/)
>
> Tom
------------------------------
From: "Michael Brown" <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy,alt.privacy.anon-server
Subject: Re: taking your PC in for repair? WARNING: What will they
Date: Thu, 31 May 2001 17:08:00 +1200
<SNIP>
> For speed, the only thing faster than C/C++ is assembly language. I
> don't think any of us are THAT masochistic!
*** guitily raises hand after writing an entire Windows Explorer style program
in ASM ... ***
Michael
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Good crypto or just good enough?
Date: Thu, 31 May 2001 05:48:13 +0000 (UTC)
Joseph Ashwood wrote:
>Well then let me change it a bit. We have two cases, the first case is where
>the first and second key are the same, the result is straight DES.
>
>The second case is where the first and second key are different, this
>results in a construct of the form DES followed by something. If that
>something weakened DES the something could be applied by an adversary, so
>DES can be no stronger than 3DES.
>
>Those are complete cases, and in both cases it was proven that DES cannot be
>stronger than 3DES. Therefore 3DES must be at least as strong as DES.
Your conclusion is valid, but your proof technique is, I think, not.
Consider the following `proof' that 3DES no more secure than DES:
Let K1,K2,K3 be the DES keys used in 3DES. There are 2^112
cases for the value of K2,K3 (0,0; 0,1; 0,2; and so on). In
each case, one can decrypt by K3, then by K2, to get a ciphertext
for DES. Therefore, in every possible case, 3DES is no more secure
than DES. Therefore, 3DES must be no more secure than DES.
Obviously this proof is incorrect, and the reason is that the adversary
can't tell which case he is in.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
