Cryptography-Digest Digest #540, Volume #13 Wed, 24 Jan 01 13:13:01 EST
Contents:
Re: Snake Oil (" ink")
Re: TSEPRNG, a secure RNG ? (Benjamin Goldberg)
Re: Creating a self extracting encrypted exe? (Kent Briggs)
Re: Dynamic Transposition Revisited (long) (Benjamin Goldberg)
Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks) (Taneli
Huuskonen)
Re: How many bits of security can a password give? ("Marcin")
Re: Secure game highscore server (Benjamin Goldberg)
Re: Secure game highscore server (Benjamin Goldberg)
Re: caching passwords in windows registry (Erik Runeson)
Re: Creating a self extracting encrypted exe? ("Paul Pires")
Re: Dynamic Transposition Revisited (long) (John Savard)
Patents on IDEA (Florian Eisele)
Re: Patents on modes of operation (Mok-Kong Shen)
Re: Dynamic Transposition Revisited (long) (Mok-Kong Shen)
Re: Fitting Dynamic Transposition into a Binary World (Splaat23)
Re: TSEPRNG, a secure RNG ? (Splaat23)
Re: Secure game highscore server (Splaat23)
----------------------------------------------------------------------------
From: " ink" <[EMAIL PROTECTED]>
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Re: Snake Oil
Date: Wed, 24 Jan 2001 16:23:38 +0100
"Anthony Stephen Szopa" dropped into the real world with a crash and
proclaimed...
> William Hugh Murray wrote:
> >
> > Please do not take it personally or go away mad; just go away. There
> > are probably lots of forums that will appreciate you for the great human
> > being that you are. We are not one of them. It is not personal, it is
> > just sci.crypt.
>
>
> It's 2001.
>
> You cannot lie anymore these days and not get caught.
Happens every day. Look at all the politicians.
> Take my encryption software. Give it a go. Prove to us you can
> break it. Give us your most tenuous reasonable explanation on how you
> would go about it.
This discussion got me wondering (as the ones before)... maybe nobody
wants to crack your encryption because it's just not worth it... it may be
worth giving AES a try, because there'll be so many people using it, but
no group of people worth mentioning (and I'm not talking about 10'000+
customers) is using your software.
Occam's Razor can work wonders.
Oh well... back to lurking. This is way too entertaining to just waste time
writing. Let me read more.
ink
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: TSEPRNG, a secure RNG ?
Date: Wed, 24 Jan 2001 16:08:37 GMT
Dan Parisien wrote:
>
> > Yes, similar things have been done. "TrueRand" is think is one where
> > differences between multiple timers in the system is used for
> > entropy.
> > As with many things, these can potentially be controlled by an
> > attacker and should be used with other forms of entropy.
> >
> > - Andrew
>
> How can they potentially be controlled by an attacker? If the attacker
> did have control over the system's thread scheduler, wouldn't the
> system have more serious problems than generating true randomness?
An attacker might be able to force system load to be abnormally high.
For some systems, this might result in deterministic round robin
scheduling, such that the number of instructions given to each thread
becomes known easily guessable to the attacker.
> Also, do you know where I could find information on TrueRand? A search
> to google led me to 2 different algorithms, neither of which fit the
> description of TSEPRNG and have weaknesses that the TSEPRNG doesn't
> (like requiring user input for keystrokes).
I'm not sure what TrueRand function he's talking about, but I would
guess it's one that follows the following pseudocode:
const integer target = 50000;
static integer timer-a = 1000;
local integer timer-b = 1;
set-system-alarm( timer-a )
while( not alarm-went-off() )
++timer-b
timer-a = timer-a * target / timer-b
return hash( timer-a, timer-b ) & 0xFF;
The system alarm is a hardware timer, timer-b is a software timer. How
many times timer-b gets incremented depends on thread scheduling.
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Creating a self extracting encrypted exe?
Date: Wed, 24 Jan 2001 16:23:47 GMT
Paul Pires wrote:
> That being said, check out Kent Brigs' site (Brigsoft)?
Puffer will make self-extracting, encrypted exe's in 16-bit DOS code. Puffer
itself is a 32-bit Windows app. It does not have a batch mode operation
however.
http://www.briggsoft.com/puffer.htm
--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Wed, 24 Jan 2001 16:25:02 GMT
Mok-Kong Shen wrote:
>
> John Savard wrote:
> >
> > [EMAIL PROTECTED] (Terry Ritter) wrote, in part:
> [snip]
>
> > But you appear to be claiming that the availability of every
> > possible bit transposition provides some important fundamental
> > property, and that it challenges the OTP. These are indeed the kinds
> > of claims that, if true, might well induce people to accept a 2.5%
> > bandwidth penalty.
> > But I haven't seen these claims justified in a way that will win
> > general acknowledgement. Worse than that, I still believe these
> > claims to be mistaken, and I feel that others will do so as well -
> > to the extent they even deign to investigate.
>
> Elsewhere I said that there cannot exist any magic that
> turns something predictable (the best PRNG is not 'absolutely'
> unpredicatble) to something (absolutely) unpredictable.
> This suffices to convince one that, while DT might be
> extremely good so as to be practically very very secure, it,
> like all other 'real' algorithms, can't attain the goal of
> 'perfect' security, which is neither possible nor truly
> necessary (to attempt) to attain (with all prices) in
> practice.
This is true of any system with a finite sized key. Since we can't have
"perfect" security, perhaps we should define some sort of "as close to
perfect as practically possible" security -- specifically, that only by
brute forcing the key can the system be broken.
Can DT satisfy this goal?
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: [EMAIL PROTECTED] (Taneli Huuskonen)
Crossposted-To: or.politics,talk.politics.crypto,misc.survivalism
Subject: Mr Szopa's encryption (was Why Microsoft's Product Activation Stinks)
Date: 24 Jan 2001 18:26:08 +0200
=====BEGIN PGP SIGNED MESSAGE=====
Hash: SHA1
In <[EMAIL PROTECTED]> Anthony Stephen Szopa
<[EMAIL PROTECTED]> writes:
[...]
>Like I am still waiting for anyone to come up with a reasonable
>suggestion on how to break my encryption software.
>One person tried to make a show of it but in effect was demanding
>the key once removed and then claiming that with it he could break
>the encryption. I think not. You cannot have the key or the key
>once removed.
I guess you're talking about me, even though your description is less
than accurate.
I claimed that the raw digit stream from your pseudorandom digit
generator is predictable under certain conditions. I was prepared to
back up my claim by predicting some digits, given a long enough sample
of the output of the pseudorandom digit generator. I never got the
challenge sample from you, though, so I presume you aren't contesting my
claim per se, only its relevance to the strength of your encryption. I
concede that you may be right, for all I know, but still, IMAO, you
should address this issue on your Web site and explain your reasons for
believing that the predictability of the pseudorandom digit stream
doesn't weaken the encryption.
Taneli Huuskonen
=====BEGIN PGP SIGNATURE=====
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBOm8B1V+t0CYLfLaVEQL7kgCgl/+SsX6467PCdv0mt6eeWivA+E8An0/L
+GtL8/5ijjiDBXfA1+AQ+bcO
=KPYV
=====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/
------------------------------
From: "Marcin" <[EMAIL PROTECTED]>
Subject: Re: How many bits of security can a password give?
Date: Wed, 24 Jan 2001 11:36:48 -0800
I would take a look at those first.
http://www.stack.nl/~galactus/remailers/passphrase-faq.html
http://world.std.com/~reinhold/dicewarefaq.html
The section from The passphrase FAQ #4 "How strong is my passphrase?" is
good for some quick hints, but read the entire document.
- Marcin Kurzawa
"Erik Runeson" <[EMAIL PROTECTED]> wrote in message
news:94mn7a$27r$[EMAIL PROTECTED]...
> I'm doing some analysis on how many bits of security a password can
> provide.
>
> For instance, if we take a password with 8 random characters (all lower
> case to simplify a bit), it is easy to assume that it would mean:
> 8*8=64 bits of security (since each character is 8 bits).
> However, since there are only 26 lower case letters, the actual figure
> is:
> log2( 26^8 ) = 37.6 bits
>
> Of course, the whole issue gets a lot more complicated when you add
> upper case letters, numbers and other characters, as well as dealing
> with the fact that users rarely choose random passwords.
>
> Does anyone know any articles or other studies in this area?
>
> - Erik Runeson
>
> ---
> Disclaimer: This post represent my personal views,
> not those of my employer.
>
>
> Sent via Deja.com
> http://www.deja.com/
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Secure game highscore server
Date: Wed, 24 Jan 2001 16:44:13 GMT
graywane wrote:
>
> In article <1yrb6.2635$[EMAIL PROTECTED]>, Robert Larsen
> wrote:
> > I am developing game applets that sends highscore data back to the
> > server. How can I do that in a secure way ? It should not be
> > possible to grap the highscore data and send it again. Also it
> > should not be a problem if someone decompiled the applet.
> > Is this possible ?
[snip]
> The only way to maintain the integrity of your high score data is to
> have the users connect to a server where the game is actually played.
> Of course, then you get into the issue of whether or not your server
> is secure.
If it's turn based game [such as a puzzle], it might be possible to have
the client send the entire game history to the server, which would then
validate that all the moves were legal, and calculate the score itself.
> If you look at every popular network game that maintains such a high
> score list, part or all of the game is always played on the company
> server. For the reasons listed above, trusting the client program is
> the same as trusting the user -- and you can't trust those users :)
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Re: Secure game highscore server
Date: Wed, 24 Jan 2001 16:59:04 GMT
Robert Larsen wrote:
>
> Hello
>
> I am developing game applets that sends highscore data back to the
> server. How can I do that in a secure way ? It should not be possible
> to grap the highscore data and send it again. Also it should not be a
> problem if someone decompiled the applet.
> Is this possible ?
Your requirements seem a bit fuzzy, so I'll rephrase what I think you
mean:
1) The user cannot capture a client-sending-high-score-to-server packet,
modify it, and resend it. (Not modifying it would be pointless.)
2) The user cannot create his own client-sending-high-score-to-server
packet, with an artificially high high-score.
What you said was (1), but I think that what you meant was (2).
The only ways to prevent this is to either have all or part of the game
played on the server, or else send the server a transcript of the game.
The first is usually done anyway in the case of multiplayer games, since
the client is not trusted to not cheat [make his vehicle/whatever
invincible]. In this case, it is trivial to make it so that the server
keeps track of scores, too.
The second can only easily be done in the case of turn based games
(usually puzzle games). The server knows the rules, and checks each
move for being legal, and calculates the score. If there is a timer
involved in the score, there is no garuntee that this part won't be
fudged by the client, but the moves themselves can still be validated.
If the user decompiled the puzzle game, and wrote an AI player to find
the highest score solution, this can't be detected by the server, no
matter what.
Similarly, if it's a network game, nothing prevents the user from
decompiling, and making a client which plays perfectly, or as close to
perfectly as possible. This could be especially probelmatic if the
client program normally gets more info than is displayed to the player
(like where everybody is, even if they're off the map, what weapons they
have, etc).
--
Most scientific innovations do not begin with "Eureka!" They begin with
"That's odd. I wonder why that happened?"
------------------------------
From: Erik Runeson <[EMAIL PROTECTED]>
Subject: Re: caching passwords in windows registry
Date: Wed, 24 Jan 2001 16:48:02 GMT
If I understand you correctly, you are using CryptoAPI to encrypt the
password you want to store in the registry. I believe that, just like
with the (practically useless) Encrypted Filesystem in Win2k, your data
is protected with a key which is derived from your password.
I think the CryptoAPI is only available for Win2k.
- Erik Runeson
---
Disclaimer: This post represent my personal views,
not those of my employer.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: Creating a self extracting encrypted exe?
Date: Wed, 24 Jan 2001 09:00:22 -0800
Kent Briggs <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Paul Pires wrote:
>
> > That being said, check out Kent Brigs' site (Brigsoft)?
>
> Puffer will make self-extracting, encrypted exe's in 16-bit DOS code.
Puffer
> itself is a 32-bit Windows app. It does not have a batch mode operation
> however.
>
> http://www.briggsoft.com/puffer.htm
>
> --
> Kent Briggs, [EMAIL PROTECTED]
> Briggs Softworks, http://www.briggsoft.com
>
My apologies for: A, miss-spelling your name and
B, for poorly writing my own post. In re-reading it,
now it sounds like I'm calling you a snake oil peddler.
That was not my intent. I had an opportunity to evaluate
many different self extractors and I was impressed with
the quality and function of Puffer.
On the other hand, just about every other one I looked
at was enough to gag a maggot.
Brown Bag by UBE.
FineCrypt.
Norton Secret Stuff.
And the all time favorite. WinZip.
I hope I set this straight. Forgive me?
Paul
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Dynamic Transposition Revisited (long)
Date: Wed, 24 Jan 2001 16:55:14 GMT
On Wed, 24 Jan 2001 15:00:42 GMT, Benjamin Goldberg
<[EMAIL PROTECTED]> wrote, in part:
>Another way of looking at things:
>DT creates a permutation of N items to N items.
>DES creates a permutation of 2^64 items to 2^64 items.
>It is easy to pick N and the PRNG so that DT produces any of the N!
>permutations for it's first output. It is [nearly?] impossible to pick
>a PRNG [and some number of rounds] to use with DES to produce any of the
>2^64! permutations as it's first output.
This is true enough, but essentially I am saying that it's no good
using that comparison to claim that DT does some fantastic thing that
a cipher based on DES, but with different subkeys for each block,
couldn't possibly do.
Because it's ultimately comparing apples to oranges.
>From the viewpoint of the overall security of the system against
cryptanalysis, what matters is that a substitution cipher takes blocks
from a set of (2^64) to blocks from a set of (2^64),
and n-bit Dynamic Transposition takes input blocks from a set of
n!/((n/2)!(n/2)!) to a set of n!/((n/2)!(n/2)!).
Simply because "transposition" is usually thought of as a class of
ciphers in itself, distinct from "substitution", doesn't mean that a
cryptanalyst is going to concede it any special privileges on that
account.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: Florian Eisele <[EMAIL PROTECTED]>
Subject: Patents on IDEA
Date: Wed, 24 Jan 2001 18:22:33 +0100
Does anyone know if I would have to pay the owners of the IDEA patent in
order to legally decrypting (not encrypting) IDEA encrypted files for
commercial use?
Florian
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Patents on modes of operation
Date: Wed, 24 Jan 2001 18:19:49 +0100
Ulrich Kuehn wrote:
>
> I would like to know if there are any patents that cover the standard
> modes of operation as specified in FIPS 81 for DES.
>
> While the FIPS was published in 1980, any patents covering its contents
> should be expired by now. But then, I am not too familiar with patent
> law and for how long a patent is granted exactly. (HAC speaks about 20
> years from filing or 17 from granting date, and that before 1995 a
> different rule applies.) Are there some specific pointers?
>
> A web search turned up only that FIPS 81 says that there may be patents,
> US or foreign, that apply. But I could not find a definitive negative
> answer.
I don't know. Patents make indeed an inpenetrable jungle
for the outsiders and present possibly essential troubles
also for the professionals. Hitachi was e.g. able to patent
rotation, which is a basic operation quite often used by
earlier assembler programmers. With apparently the
possibility to have such trivialities patentable (this is
aggravated by the situation that in US patent applications
don't have public review periods as compared to the
practice in Europe) one has to be very very careful in doing
crypto designs that are to be actually used in practice.
M. K. Shen
============================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Wed, 24 Jan 2001 18:19:54 +0100
Benjamin Goldberg wrote:
>
> Mok-Kong Shen wrote:
> >
> > John Savard wrote:
> > >
> > > [EMAIL PROTECTED] (Terry Ritter) wrote, in part:
> > [snip]
> >
> > > But you appear to be claiming that the availability of every
> > > possible bit transposition provides some important fundamental
> > > property, and that it challenges the OTP. These are indeed the kinds
> > > of claims that, if true, might well induce people to accept a 2.5%
> > > bandwidth penalty.
> > > But I haven't seen these claims justified in a way that will win
> > > general acknowledgement. Worse than that, I still believe these
> > > claims to be mistaken, and I feel that others will do so as well -
> > > to the extent they even deign to investigate.
> >
> > Elsewhere I said that there cannot exist any magic that
> > turns something predictable (the best PRNG is not 'absolutely'
> > unpredicatble) to something (absolutely) unpredictable.
> > This suffices to convince one that, while DT might be
> > extremely good so as to be practically very very secure, it,
> > like all other 'real' algorithms, can't attain the goal of
> > 'perfect' security, which is neither possible nor truly
> > necessary (to attempt) to attain (with all prices) in
> > practice.
>
> This is true of any system with a finite sized key. Since we can't have
> "perfect" security, perhaps we should define some sort of "as close to
> perfect as practically possible" security -- specifically, that only by
> brute forcing the key can the system be broken.
>
> Can DT satisfy this goal?
With my very limited knowledge I would say that DT is an
interesting approach, especially in its property of covering
up the frequency distribution of the original bit sequence,
and as such could well be a viable valuable component for
combination with other components, e.g. those using
substitutions, to further complicate the job of the opponent
to a degree of 'practical' extreme infeasibility. (It has
been my personal opinion that it's a good idea to have
a PRNG-controlled encryption employing techniques of both
stream and block ciphers.) The design of such systems is in
my humble view akin to that of drinks (cf. Coca Cola) and
the optimum is likely to dependent on many factors (that
are partly external at least).
M. K. Shen
===========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Fitting Dynamic Transposition into a Binary World
Date: Wed, 24 Jan 2001 17:26:10 GMT
I assume the problem you would have with the 158->162 conversion is
that the conversion back would not be guaranteed because there are more
162-bit balanced strings than there are 158-bit binary strings.
However, if you intend to implement some sort of dynamic transpositon
in between the conversions, you can simply, at the end of the
transposition, check to see if the result has a binary version. The
likelihood of getting an invalid block is not high, but exists. If the
block isn't a "valid" balanced block, then simply repeat the
transposition (assuming it is not it's own inverse) until you get a
valid 162-bit balanced string. This (as far as I can tell, IANA good
cryptographer) should not compromise security.
- Andrew
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (John Savard) wrote:
> On 24 Jan 2001 05:41:18 GMT, [EMAIL PROTECTED]
> (Kenneth Almquist) wrote, in part:
>
> >This means that your encoding is effectively variable length. For
each
> >160-bit sequence, you need to transmit an indication of whether it
> >has been encoded as a 164-bit balanced sequence, or some other way.
> >This wastes communication bandwidth (though not a lot) and also
> >complicates the encoding because the indication cannot be transmitted
> >in the clear (or you leak information). Might I suggest coding 158-
bit
> >arbitrary sequences as 162-bit balanced sequences?
>
> Yes, I'm aware of that, however, you have mistaken my intention.
>
> The reason I went two bits over the optimal point for total encoding
> of binary sequences is that my aim was a perfect encoding.
>
> Essentially, what I intended to do overall was this:
>
> Take the 160-bit sequences, and after converting most of them to
> 164-bit balanced sequences, and enciphering the 164-bit balanced
> sequences using Dynamic Transposition, convert them *back* to 160-bit
> sequences.
>
> So my overall cipher works like this: 160-bit binary sequences in,
> 160-bit binary sequences out.
>
> I supplement Dynamic Transposition with other encryption on binary
> sequences, and perform two Dynamic Transposition steps with a
> different choice of which 160-bit binary sequences are chosen as the
> left-over ones, to avoid weakness from not encrypting a small group of
> sequences.
>
> John Savard
> http://home.ecn.ab.ca/~jsavard/crypto.htm
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: TSEPRNG, a secure RNG ?
Date: Wed, 24 Jan 2001 17:36:18 GMT
I only read about TrueRand a while back, but that pseudocode looks
familiar. There are many occasions that an attacker has _access_ to a
computer without total access. Just many people have been in the realm
of Windows 95 so long they forget that many machines have multi-user
access. Even one's that don't have other ways an attacker can control
them to a degree.
A good attack would be the use of a DoS attack on a machine in order to
decrease the entropy of a session key it is generating for
communications with a third computer. The attacker can potentially use
this to break the session key and hijack the connection after
authentication. This is a _very_ serious problem for many protocols
that do one-time authentication with the belief that the session key
guarantees security. This attack amplifys the impact of a DoS
tremendously - what was only a nuisance is now a security breach.
Again, this attack applys to many methods of entropy gathering that is
automatic (requires no user intervention). Just another reason to use
true random sources if available, or at least user-generated randomness.
- Andrew
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Dan Parisien wrote:
> >
> > > Yes, similar things have been done. "TrueRand" is think is one
where
> > > differences between multiple timers in the system is used for
> > > entropy.
> > > As with many things, these can potentially be controlled by an
> > > attacker and should be used with other forms of entropy.
> > >
> > > - Andrew
> >
> > How can they potentially be controlled by an attacker? If the
attacker
> > did have control over the system's thread scheduler, wouldn't the
> > system have more serious problems than generating true randomness?
>
> An attacker might be able to force system load to be abnormally high.
> For some systems, this might result in deterministic round robin
> scheduling, such that the number of instructions given to each thread
> becomes known easily guessable to the attacker.
>
> > Also, do you know where I could find information on TrueRand? A
search
> > to google led me to 2 different algorithms, neither of which fit the
> > description of TSEPRNG and have weaknesses that the TSEPRNG doesn't
> > (like requiring user input for keystrokes).
>
> I'm not sure what TrueRand function he's talking about, but I would
> guess it's one that follows the following pseudocode:
>
> const integer target = 50000;
> static integer timer-a = 1000;
> local integer timer-b = 1;
>
> set-system-alarm( timer-a )
> while( not alarm-went-off() )
> ++timer-b
> timer-a = timer-a * target / timer-b
>
> return hash( timer-a, timer-b ) & 0xFF;
>
> The system alarm is a hardware timer, timer-b is a software timer.
How
> many times timer-b gets incremented depends on thread scheduling.
>
> --
> Most scientific innovations do not begin with "Eureka!" They begin
with
> "That's odd. I wonder why that happened?"
>
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Splaat23 <[EMAIL PROTECTED]>
Subject: Re: Secure game highscore server
Date: Wed, 24 Jan 2001 17:49:22 GMT
In summary, you can't stop an expert user from doing anything he wants
with anything on his system - that includes you software. Basically,
nothing will stop the expert hacker. However, almost anything will stop
_most_ people, so you may have to be content with that. 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.
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.
Anyway, I'm just brainstorming.
- Andrew
In article <[EMAIL PROTECTED]>,
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> Robert Larsen wrote:
> >
> > Hello
> >
> > I am developing game applets that sends highscore data back to the
> > server. How can I do that in a secure way ? It should not be
possible
> > to grap the highscore data and send it again. Also it should not be
a
> > problem if someone decompiled the applet.
> > Is this possible ?
>
> Your requirements seem a bit fuzzy, so I'll rephrase what I think you
> mean:
>
> 1) The user cannot capture a client-sending-high-score-to-server
packet,
> modify it, and resend it. (Not modifying it would be pointless.)
>
> 2) The user cannot create his own client-sending-high-score-to-server
> packet, with an artificially high high-score.
>
> What you said was (1), but I think that what you meant was (2).
>
> The only ways to prevent this is to either have all or part of the
game
> played on the server, or else send the server a transcript of the
game.
>
> The first is usually done anyway in the case of multiplayer games,
since
> the client is not trusted to not cheat [make his vehicle/whatever
> invincible]. In this case, it is trivial to make it so that the
server
> keeps track of scores, too.
>
> The second can only easily be done in the case of turn based games
> (usually puzzle games). The server knows the rules, and checks each
> move for being legal, and calculates the score. If there is a timer
> involved in the score, there is no garuntee that this part won't be
> fudged by the client, but the moves themselves can still be validated.
>
> If the user decompiled the puzzle game, and wrote an AI player to find
> the highest score solution, this can't be detected by the server, no
> matter what.
>
> Similarly, if it's a network game, nothing prevents the user from
> decompiling, and making a client which plays perfectly, or as close to
> perfectly as possible. This could be especially probelmatic if the
> client program normally gets more info than is displayed to the player
> (like where everybody is, even if they're off the map, what weapons
they
> have, etc).
>
> --
> Most scientific innovations do not begin with "Eureka!" They begin
with
> "That's odd. I wonder why that happened?"
>
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
******************************
