Cryptography-Digest Digest #544, Volume #13 Wed, 24 Jan 01 23:13:00 EST
Contents:
Re: Fitting Dynamic Transposition into a Binary World (John Savard)
Re: DES check values (58)
Another Microsoft lawsuit on the horizon (Re: Why Microsoft's Product Activation
Stinks) (Matthew Montchalin)
Re: finding inverses and factoring (David A Molnar)
Differential Analysis of "A + (B xor X)" ("Alexis Machado")
Re: finding inverses and factoring (David A Molnar)
Re: Secure game highscore server (graywane)
Re: Snake Oil (phil hunt)
IPsec export and PFS ([EMAIL PROTECTED])
Re: IPsec export and PFS (graywane)
Re: finding inverses and factoring (Splaat23)
Knots, knots, and more knots (Matthew Montchalin)
Re: Random stream testing. (long) ("Douglas A. Gwyn")
Re: Secure game highscore server (Splaat23)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Fitting Dynamic Transposition into a Binary World
Date: Thu, 25 Jan 2001 00:10:44 GMT
On Wed, 24 Jan 2001 20:56:25 GMT, [EMAIL PROTECTED] (Terry Ritter) wrote,
in part:
>Is there some reason why you could not use the algorithm in my
>"revisited" article?
I'm sure that I'm the only one who really finds that method inadequate
for his purposes.
As I understand it, your algorithm is:
Given a block size of N bytes:
take N-1 bytes of data. If that data has 7 or fewer excess 1s or 0s,
add an appropriate last byte.
If the excess is more than that, use only the first N-2 bytes, and
rectify the excess in the last two bytes.
I suppose you could use alternating all ones and all zeroes bytes in
the case where the excess is all in the last byte.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: 58 <[EMAIL PROTECTED]>
Subject: Re: DES check values
Date: Thu, 25 Jan 2001 00:31:52 GMT
In article <94n9t1$ktv$[EMAIL PROTECTED]>,
Splaat23 <[EMAIL PROTECTED]> wrote:
> Could you please clarify
> exactly what you need?
Sure. Let me start by defining some conventions so I don't get too
confused.
1) The clear key is the unencrypted form. It is 16 hexadecimal
characters.
2) The Cryptographic Key (crypto key) is similar in function to PGPs
private or public keys: it is upon which the encryption or decryption
is based. We call it a master key. It is 16 hexadecimal characters.
I can't tell you who we are or what we do, but... My company uses DES
exclusively. So do all of our clients, as well as all of our business
associates. The value being checked is a clear key, which is used to
encrypt digital transmissions over a semi-secure network. The clear
key is used as a crypto key for these transmissions.
When we ship this clear key to our clients (or receive it from them),
often times it's been transcribed and is not a photocopy, or the
photocopy is of poor quality, so a check value is included with it.
The clear key is then entered into the the system (an SIU or other
security processor), which spits out a check value. Matching the check
means the clear key was correctly entered.
The check value is created by encrypting the clear key, but the crypto
key is all zeros. This way, the encryption is unique only to the clear
key. We and our clients also maintain a private crypto key which is
not released to anyone, and anything encrypted with it is also kept
secure in house (in the security processor, really).
I guess, what I'm looking for is a DES encryption program, but in it's
most simple form. The crypto key would be all zeros, and there would
be no variants applied. I would prefer that the program NOT decrypt,
or I would have to declare it to my risk manager.
Thanks,
Larry
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism,us.misc
Subject: Another Microsoft lawsuit on the horizon (Re: Why Microsoft's Product
Activation Stinks)
Date: Wed, 24 Jan 2001 16:50:20 -0800
On Wed, 24 Jan 2001, Splaat23 wrote:
|He doesn't consider XORing two files together to be significant.
|That's easy! He considers XORing two files together, one of which
|happens to be generated by a PRNG to be significant. Innovation,
|what a sight! I wish I had his foresight to create a slow, unwieldy
|stream cipher that has no market to acquire and no use.
But it is a smoking gun if the technique employed by Microsoft
just happens to require using a couple pages of text out of the
guy's diary, (diaries are very admissible as evidence) and his
name and picture, together as a single cryptographic key,
suitably XOR'd into something less recognizable? Geeeze,
Microsoft probably didn't even have the presence of mind to
use some other cryptographic key...
But I say, if he *can* prove that Microsoft "took the easy road"
rather than the one less traveled, then let him go ahead and
prove it. My hat's off to him if he can. (Lord knows why Microsoft
would not have bothered to independently develop their OWN code to
do the same thing, let alone why they figured they could rip him
off!) If they did what he alleges, for whatever reason, then he
has a duty to go through with the suit.
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: finding inverses and factoring
Date: 25 Jan 2001 01:19:08 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
> Not exactly trivial. The method I know of is much like the
> Miller-Rabin test. While raising a random base to e*d-1, see
> if you get a non-trivial square root of 1 along the way. If so,
> take the gcd(n, square_root1 + 1) and that's a factor. If not,
> repeat.
Oh, duh. (Well, not "duh" exactly, but "I had all the information I needed to
derive this, but just didn't know it - so I should have figured it out.")
(This is the mark of a good explanation.)
Thanks much for the explanation!
You can make this faster by picking random composite bases, I think - not
that it matters much.
I wish I'd asked this earlier; I'm a teaching assistant for a cryptography
class in which we hammered home the point about "two distinct square roots
factor" several times. This might have made a good problem, given suitable
hints. Maybe next year...
> Below is Python code for the algorithm. (Python has arbitrary
> size long integers built in.)
Thanks much for this too. I've noticed you give Python source for several
other queries; looks like a language to pick up.
>> Suppose I publish n, g1 a generator of some subgroup in n, and g2 a
>> generator of some subgroup of "the exponents mod n", which have order
>> phi(n). Further I publish g1^(g2^x) and g2^x. The value n is made
> public,
>> but phi(n) is not revealed. Can phi(n) be feasibly determined?
> I assume you mean choose a random x and publish g2^x mod phi(n).
> Without x that doesn't seem very helpful. With x, I don't know.
Yes, x random. Thanks.
I think splaat23's argument for g2 alone is fairly convincing - if knowing g2
alone helped you, that would give you an attack on RSA. The only point is how
g2 is picked, because it's picked by someone who knows phi(n).
(Note that g2 picked randomly mod n is almost certainly relatively prime to
phi(n) or phi(phi(n)). So maybe the right thing to do is to pick g2
randomly and try again if you get massively unlucky.)
So if x is picked randomly, because exponentiation is a permutation, if g2 is
random, then g2^x is random as well. So without knowledge of x, g2^x should
be no more helpful than g2.
The devil, of course, is if you have g2, x, and g2^x - you just learned
something about the structure of Z_phi(n)^*. Whether it's enough...I don't
know.
Thanks!
-David
------------------------------
From: "Alexis Machado" <[EMAIL PROTECTED]>
Subject: Differential Analysis of "A + (B xor X)"
Date: Wed, 24 Jan 2001 23:50:11 -0200
Hi,
I'm studying the function "F(X) = A + (B xor X) (mod 2**n)" differential
properties.
My current results are in the paper
http://www.meubrfree.com.br/~gauss-inf/analise/difadd.pdf
Comments and suggestions are welcome.
Alexis Machado
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: finding inverses and factoring
Date: 25 Jan 2001 02:22:07 GMT
Splaat23 <[EMAIL PROTECTED]> wrote:
> Really fascinating. Thanks for the clarification: now that I look at
> it, I wonder why my brain decided to shut off. ;)
No problem.
> Let me disagree with you agreeing with me now. Looking at it, I do not
> think knowledge of a generator of (Zn*)* would help, because if it did
> it would prove to be a new attack on RSA. Let me elaborate:
> phi(phi(n)) is close to n for most n. Therefore, any guess in Zn has a
> very high chance of being in Zn*, and has a very high chance of being
> in (Zn*)* (I hope that terminology is correct, or else I really sound
> like an idiot).
Well, I suppose I'm easily convinced (not a good thing) because this seems
fair as well. Besides, if it's not in Z_N^*, you factor N.
> Actually, the algebra doesn't seem right - just missing parens. It
> should read:
> F(x) = g1^(g2^x) mod n
> F(x + y) = F(x)^(g2^y)
> = (g1^(g2^x))^(g2^y)
> = g1^(g2^x * g2^y)
> = g1^(g2^(x + y))
Glad to see it still comes out to the same. Thanks for being careful. I've
messed up here before...
OK, so *if* everything works so far, then I think we can let
HINT(x) = g2^x mod phi(n) ;; needs secret key to compute
F(x) = g1^(g2^x) mod n
COMBINE(F(x), HINT(y)) = F(x)^(g2^y) = F(x + y)
and then it seems that the function COMBINE( , ) is
1. Something like associative:
COMBINE(COMBINE(F(x), HINT(y)), HINT(z))
= COMBINE (F(x+y), HINT(z))
= F(x + y + z)
= F(z + y + x) ;; + is commutative
= COMBINE(F(z+y), HINT(x))
= COMBINE(COMBINE(F(z), HINT(y)), HINT(x))
It's not exactly associative because of all the F() and HINT() functions
lying around.
2. One-Way - from F(x+y) it seems infeasible to derive x, F(x), y, HINT(y)
F(y) or HINT(x). This because taking
roots mod n and discrete logs when
phi(n) unknown is hard.
That is, given
F(x+y) = g1^(g2^(x+y)) mod n
we could try to compute any of
HINT(x) = g2^x mod phi(n) , needs DL to find g2^(x+y), and even then it's
not clear how to find g2^x from g2^(x+y)
HINT(y) = same
x = even if you can take DL twice, you end up with x + y, don't know y.
y = same
F(x) = g1^(g2^x) -- you need g2^{-y} and don't know y. Or phi(n).
F(y) = same
3. "Strong" One-Way - from F(x+y) AND x, HINT(x), F(x)
it seems infeasible to determine any of
y, HINT(y) or F(y). And vice versa.
This is because phi(n) is unknown, so it
is difficult to compute (g2^x)^-1 or
(g2^y)^-1 mod phi(n).
So if all of this works out, then it looks like COMBINE() is a strong, almost
associative one-way function. The only "problem" is that HINT() is hard to
compute without knowing phi(n). This means that it won't work as is for the
strong associative one-way function constructions (which require picking
random elements and applying the strong AOWF to them), but maybe there will
be other uses...
...or maybe it doesn't work/isn't secure after all. Probably the next thing
to ask is whether information about phi(n) is leaked by all these g2^x and
g2^y running around. i.e. "Given access to a black box which returns g2^x mod
phi(n) for your choice of x, how long does it take to recover phi(n)?"
> Anyway, enough said. If you have an IQ > 50, you'd be good to take
> anything I post with an industrial-size can of salt.
Same applies at least as much to me. :-)
thanks,
-David
------------------------------
From: [EMAIL PROTECTED] (graywane)
Subject: Re: Secure game highscore server
Date: Thu, 25 Jan 2001 02:34:05 GMT
In article <94n4it$fmd$[EMAIL PROTECTED]>, Splaat23 wrote:
> There are ways
> to disperse a secret key in an executable so it is hard to find, then
> use it to encode the high score. That should take minimal effort on
> your part but take maximal effort on the attackers part.
Although it is not as easy as you make it out to be. Most people trying this
take the naive approach. They store the key all over the executable but then
stick it into one memory location before encryption. It is then trivial to
read the key with your debugger. Unless you distribute the encryption as
well as the key then you usually end up collecting the distributed key into
one location which defeats the purpose.
> Someone should do a comprehensive study on this, actually. Now that I
> think about it, in the age of the Internet, we should be able to
> invisibly auto-update the software at a given rate that exceeds the
> capabilities of most hackers. The key is to maximize a (hacker work) /
> (programmer work) ratio, then estimate the amount of time, given the
> degree of protection, it would take a hacker to break it.
Most users have reacted badly to "invisible auto-update" software in the
past. It is also difficult to manage this auto-update in a fashion that
won't let users auto-update their neighbors with bad code.
The only way to prevent cheating is to play with people who don't cheat.
Sad but true.
------------------------------
From: [EMAIL PROTECTED] (phil hunt)
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Snake Oil
Date: Thu, 25 Jan 2001 01:43:34 +0000
On Wed, 24 Jan 2001 04:21:49 -0800, Anthony Stephen Szopa <[EMAIL PROTECTED]> wrote:
>
>It's 2001.
>
>You cannot lie anymore these days and not get caught.
>
>Take my encryption software. Give it a go. Prove to us you can
>break it.
What's the URL for the source code, then?
> Give us your most tenuous reasonable explanation on how you
>would go about it.
--
*****[ Phil Hunt ***** [EMAIL PROTECTED] ]*****
"An unforseen issue has arisen with your computer. Don't worry your
silly little head about what has gone wrong; here's a pretty animation
of a paperclip to look at instead." -- Windows2007 error message
------------------------------
From: [EMAIL PROTECTED]
Subject: IPsec export and PFS
Date: Thu, 25 Jan 2001 02:35:15 GMT
Hello all,
I was wondering what will it take to develop an IPsec
implementation that can be exported to France as well as
other non-US government agencies where export (from US)
restrictions still apply?
As I understand, if I use DES (40bit) for symmetric encryption
and RSA-DSA (512 bit) for asymmetric encryption its OK
for French as well as other non-US government agencies.
The only open issue right now is about the IKE PFS groups. IKE
uses Diffie-Hellman to negotiate the keys. PFS group specifies the
size of the prime number to use to generate the key
PFS1 is 768 bit prime
PFS2 is 1024 bit prime
etc...
Now even though the key generated out of these PFS primes may
be less than the export restrictions, we are not sure if using PFS (and
hence IKE) violates the export laws of French (and US: for non-US govt
agencies export law).
The question: if the clauses of the export law (see the snippet blow)
2 and 3 are applicable to PFS groups.
attaching the export law snippet
=================================
Export control applies to symmetric
algorithms employing a key length in excess of 56 bits, and asymmetric
algorithms where security is based on:
1. Factorization of integers in excess of 512 bits (e.g. RSA)
2. Computation of discrete logarithms in a multiplicative group of a
finite
field of size greater than 512 bits (e.g. Diffie-Hellman over Z/pZ)
3. Discrete logarithms in a group other than above in excess of 112 bits
(e.g. Diffie-Hellman over an elliptic curve).
==================================
thanks
-ajay
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (graywane)
Subject: Re: IPsec export and PFS
Date: Thu, 25 Jan 2001 03:01:42 GMT
In article <94o3d3$ct6$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> I was wondering what will it take to develop an IPsec
> implementation that can be exported to France as well as
> other non-US government agencies where export (from US)
> restrictions still apply?
Use OpenBSD (www.openbsd.org). Ships with IPsec and other strong crypto.
Also has good IPv6 support.
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: finding inverses and factoring
Date: Thu, 25 Jan 2001 03:12:56 GMT
Given that black box (basically, a chosen-text attack), I could see an
attack against phi(n).
Please excuse lack of precision, got more work to do tonight:
First get g2 = g2^1 mod phi(n). Estimate the lower bound for the length
of phi(n) base g2, and set = x. Ask the oracle for g2^x, g2^(x+1), g2^
(x+2), ... until the value decreases. Let the x value that does that =
y. Then, g2^y - k * phi(n) = g2^y mod phi(n) where k is small. You know
g2^y, g2^y mod phi(n), therefore you know phi(n). Lession: you must
protect that function against chosen-text attacks.
- Andrew
In article <94o2kf$7r4$[EMAIL PROTECTED]>,
David A Molnar <[EMAIL PROTECTED]> wrote:
> Splaat23 <[EMAIL PROTECTED]> wrote:
> > Really fascinating. Thanks for the clarification: now that I look at
> > it, I wonder why my brain decided to shut off. ;)
>
> No problem.
>
> > Let me disagree with you agreeing with me now. Looking at it, I do
not
> > think knowledge of a generator of (Zn*)* would help, because if it
did
> > it would prove to be a new attack on RSA. Let me elaborate:
>
> > phi(phi(n)) is close to n for most n. Therefore, any guess in Zn
has a
> > very high chance of being in Zn*, and has a very high chance of
being
> > in (Zn*)* (I hope that terminology is correct, or else I really
sound
> > like an idiot).
>
> Well, I suppose I'm easily convinced (not a good thing) because this
seems
> fair as well. Besides, if it's not in Z_N^*, you factor N.
>
> > Actually, the algebra doesn't seem right - just missing parens. It
> > should read:
>
> > F(x) = g1^(g2^x) mod n
>
> > F(x + y) = F(x)^(g2^y)
> > = (g1^(g2^x))^(g2^y)
> > = g1^(g2^x * g2^y)
> > = g1^(g2^(x + y))
>
> Glad to see it still comes out to the same. Thanks for being careful.
I've
> messed up here before...
>
> OK, so *if* everything works so far, then I think we can let
>
> HINT(x) = g2^x mod phi(n) ;; needs secret key to
compute
> F(x) = g1^(g2^x) mod n
> COMBINE(F(x), HINT(y)) = F(x)^(g2^y) = F(x + y)
>
> and then it seems that the function COMBINE( , ) is
>
> 1. Something like associative:
>
> COMBINE(COMBINE(F(x), HINT(y)), HINT(z))
> = COMBINE (F(x+y), HINT(z))
> = F(x + y + z)
> = F(z + y + x) ;; + is commutative
> = COMBINE(F(z+y), HINT(x))
> = COMBINE(COMBINE(F(z), HINT(y)), HINT(x))
>
> It's not exactly associative because of all the F() and HINT()
functions
> lying around.
>
> 2. One-Way - from F(x+y) it seems infeasible to derive x, F(x), y,
HINT(y)
> F(y) or HINT(x). This because taking
> roots mod n and discrete logs when
> phi(n) unknown is hard.
>
> That is, given
>
> F(x+y) = g1^(g2^(x+y)) mod n
>
> we could try to compute any of
>
> HINT(x) = g2^x mod phi(n) , needs DL to find g2^(x+y), and even then
it's
> not clear how to find g2^x from g2^(x+y)
>
> HINT(y) = same
>
> x = even if you can take DL twice, you end up with x + y, don't
know y.
> y = same
>
> F(x) = g1^(g2^x) -- you need g2^{-y} and don't know y. Or phi(n).
> F(y) = same
>
> 3. "Strong" One-Way - from F(x+y) AND x, HINT(x), F(x)
> it seems infeasible to determine any of
> y, HINT(y) or F(y). And vice versa.
> This is because phi(n) is unknown, so it
> is difficult to compute (g2^x)^-1 or
> (g2^y)^-1 mod phi(n).
>
> So if all of this works out, then it looks like COMBINE() is a
strong, almost
> associative one-way function. The only "problem" is that HINT() is
hard to
> compute without knowing phi(n). This means that it won't work as is
for the
> strong associative one-way function constructions (which require
picking
> random elements and applying the strong AOWF to them), but maybe
there will
> be other uses...
>
> ...or maybe it doesn't work/isn't secure after all. Probably the next
thing
> to ask is whether information about phi(n) is leaked by all these
g2^x and
> g2^y running around. i.e. "Given access to a black box which returns
g2^x mod
> phi(n) for your choice of x, how long does it take to recover phi
(n)?"
>
> > Anyway, enough said. If you have an IQ > 50, you'd be good to take
> > anything I post with an industrial-size can of salt.
>
> Same applies at least as much to me. :-)
>
> thanks,
> -David
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Matthew Montchalin <[EMAIL PROTECTED]>
Subject: Knots, knots, and more knots
Date: Wed, 24 Jan 2001 19:08:50 -0800
Imagine you have this very long rope, and you've got this machine
with two holes, where you feed the rope completely through the
machine, and before it comes out, it will either be knotted, or
unknotted, depending on the state of a punch-card (ahem) that has
been inserted into the machine in advance. Let us further assume
that the machine does not stretch the rope longer than it was
to start with, and does not shorten it in any way.
Starting with this simple setup, is it reasonable to describe
complexity by the knots per unit length of rope, multiplied by
the operations specified on the punch card?
In my previous discussions of a simple encryption algorithm
(check http://www.deja.com to see the source code, it was
about seven months ago, I think), I mentioned that the complexity
of the punch card is what ought to be looked at first. If the
punch card has a set number of states, and future states depend
upon previous states, it may be convenient to think of the
time it takes for a punch card to permutate itself before
returning upon itself, regardless of the length of the rope
fed into the machine. It is the punch card that is the most
interesting part of this setup. I also suggested that states
be looked at as though binary, either 1 or 0, or alternatively,
either white or black. An ideal punch card, whatever it is,
will therefore return to its original state sooner or later.
Back in, um, uh, I think it was June, I noted that initial
states of the randomizing engine seemed to perform best if
the punch card or seed had exactly 50 percent 1 bits, and 50
percent 0 bits. If the bits alternated 10101010*** I called
it a 'light grey' but if the bits alternated 01010101*** I
called it a 'dark grey.' By turning the machine on, (for
instance, feeding a very long length of rope through the
machine and back around to the input hole, and tying the
rope together), and then waiting through the endless
permutations that are to be expected, one could turn the
machine off if the rope ever returned to its original state.
This gives the researcher an idea of the average cycle from
light grey to light grey (this being a complete cycle), or
from light grey to dark grey (being an alternative cycle).
The length of cycles to repeat, can be denoted by a term, L.
Randomizing engines can be described, then by a tendency to
go 'grey' or go 'dark' depending on how long the various
terms L(1) * * * L(n) take to run to their preferred states.
So long as I am approaching this thought experiment from
the perspective of a researcher feeding rope into an
imaginary machine, it might also be useful to consider
whether a knot is tied "under" or tied "under" and whether
there is some way to count out which way the machine likes
to operate on the rope the most.
I prefer describing randomizing engines by color, but it
might be useful to describe them in other ways, such as
3-dimensional knotting tendencies.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: sci.crypt.random-numbers
Subject: Re: Random stream testing. (long)
Date: Thu, 25 Jan 2001 03:23:10 GMT
Paul Pires wrote:
> First off, the notion that this is testing the randomness
> of the data. It seems obvious to me that it is only
> comparing the results to an expectation of how
> random data would look according to very narrow
> criteria. It say's nothing about the data's randomness
> per se but only how it compares to a theoretical result,
> according to a very limited criteria. No test can detect
> randomness.
Randomness is not a property of data but rather of the
process that generates the data. What can be properly
tested is the hypothesis that the generator draws a
uniform random sample (or from some similar specified
theoretical source). Testing can contribute evidence
for or against that hypothesis.
The best way to make use of such evidence is to accrue
it a la Turing, Good, Kullback, et al. ("weight of
evidence") and evaluate it as asymptotic chi-square.
> Second, the notion of evaluating a single test result
> seems bizarre. The documentation for these tests
> invariably say something like "A value of 99% is an
> indication that it is most probably not random"
> How could this be? If it is a comparison to a random
> expectation and if random is unbounded, then any
> result value could be the result of a random process.
A priori (without looking at the data) one can compute
the likelihood that a particular test threshold will be
met *if* the hypothesis is true. (Easy enough, since
the hypothesis is of a certain exact theoretical model.)
> The results could only be meaningful when a large
> population of results are evaluated against an expected
> distribution.
But a single test already includes a reasonably large
sample from the parent population; the test statistic
is a random variable which, if the hypothesis is true,
has definite computable properties.
> Take, for example, Chi square test expressed as a percentage
> that a random population would give similar results.
> "A value of 25 - 75% is good, 5-10% and 90 - 95% are
> probably bad and 0-5% and 95 - 100% are most certainly
> bad." Nonsense!
That's not how chi-square is evaluated. One can take
the given value of observed chi-square and degrees of
freedom and look up the likelihood that the observed
value would be at least that large *if* the hypothesis
is true. Absent any other evidence and without any
a priori expectation one way or the other, it is then
reasonable to take that likelihood as one's first cut
at betting for or against the hypothesis.
> ... Terry Ritter has made a convincing argument
> that data sets should be examined for any deviation from
> a random expectation including the case were the results
> are "too good".
A *consistently* too-tight fit upon repeated tests is
suspicious, because the second-order distribution does
not agree well with the expected results (assuming the
hypothesis). If only one measurement of the test
statistic is available, however, one cannot judge the
second moment and thus the first-order likelihood is
all one has to work with.
> K-S tests and P values don't help much as they are a
> blind alley.
So-called "P values" may be stupid, but the K-S test
is legitmate and meaningful when properly applied.
> I've almost worked myself into a paradox here. Single
> results are meaningless and group results are
> incomprehensible. What's left?
I suppose you could go off and study statistics a while
to figure out what error led you to the contradiction.
> Many say that RNG output is better quality than PRNG output
> but I have never seen a demonstration of such an evaluation.
Just read one of the papers that shows how a PRNG version
of "one-time pad" has been successfully cryptanalyzed via
a ciphertext-only attack. Obviously a true uniform RNG
version would not be susceptible to such an attack.
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Secure game highscore server
Date: Thu, 25 Jan 2001 03:26:55 GMT
Quite true. I am a gamer and I have seen cheating at its best (or
worst). Encryption would have to be very careful, but its still minimal
effort if you know what you're doing. Auto-update can work, though, if
you sign the code updates. An by "invisible update" I really meant
unobstrusive updating, as in small size and single click.
- Andrew
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (graywane) wrote:
> In article <94n4it$fmd$[EMAIL PROTECTED]>, Splaat23 wrote:
> > There are ways
> > to disperse a secret key in an executable so it is hard to find,
then
> > use it to encode the high score. That should take minimal effort on
> > your part but take maximal effort on the attackers part.
>
> Although it is not as easy as you make it out to be. Most people
trying this
> take the naive approach. They store the key all over the executable
but then
> stick it into one memory location before encryption. It is then
trivial to
> read the key with your debugger. Unless you distribute the encryption
as
> well as the key then you usually end up collecting the distributed
key into
> one location which defeats the purpose.
>
> > Someone should do a comprehensive study on this, actually. Now that
I
> > think about it, in the age of the Internet, we should be able to
> > invisibly auto-update the software at a given rate that exceeds the
> > capabilities of most hackers. The key is to maximize a (hacker
work) /
> > (programmer work) ratio, then estimate the amount of time, given the
> > degree of protection, it would take a hacker to break it.
>
> Most users have reacted badly to "invisible auto-update" software in
the
> past. It is also difficult to manage this auto-update in a fashion
that
> won't let users auto-update their neighbors with bad code.
>
> The only way to prevent cheating is to play with people who don't
cheat.
> Sad but true.
>
Sent via Deja.com
http://www.deja.com/
------------------------------
** 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
******************************
