Re: Ang. juks

[Tore Skaug <toresk@pvv.ntnu.no>]

> En kan med kryptering beskytte enkeltobjekter helt til de blir pakket opp.
> Da kan klienten undersøke logisk innhold og lage kataloger. Hvis klienten
> da ikke hele tiden skal bli foret med nye krypterte versjoner av samme
> objekter så kan klienten etter hvert ha nesten fulstendige kataloger. Så
> min overbevisning er at vi ikke kan oppnå noe mer en å gjøre det
> vanskligere å jukse. Hvorfor da bry seg, vi kan jo lage sosiale regler og
> true med å svarteliste og svarteliste de som blir en plage. Dessuten har
> du først hatt kontakt med et monster så kan deg jo være kult å studere det
> i en browser som viser hvordan det beveger seg.

Som jeg tidligere nevnte, informasjonene som blir "dekryptert" maa uansett
gjoeres tilkjenne for klienten paa det tidspunkt da det blir dekryptert.
Alternativet er aa sende det i klartekst, mens kryptering tilbyr
muligheten til allerede aa ha sendt objektet, for saa aa kun trenge aa
levere en enkelt noekkel for aa laase det opp i det oeyeblikket det
trengs.

Muligheten til aa lage kataloger er altsaa den samme enten en bruker
kryptering eller ikke, det kan en vaere enig om.

Forskjellen er at dersom hvert objekt faar en unik id hos hver enkelt
spiller, kan ikke andre spilleres kataloger brukes direkte ettersom
id-rommene er forskjellig. Spiller A kan ha et objekt med id 12 i sin
katalog som hos spiller B har id 23874623.  Katalog-bruk for direkte
integrasjon i klienten maa i saafall noeye seg med aa proeve aa hente ut
informasjon ved aa bruke kjennskap til stoerrelser paa objekter og delvis
kjente objekter, noe som er langt mindre trivielt.

Litt av poenget er at denne funksjonaliteten kan en faa "gratis", det er
lett aa utfoere de operasjonene jeg beskrev i tidligere mail.

> Er det stor forskel i oppbygging av nettverks delen om en skal ha
> kryptering eller ikke? Kan kryptering vente til et meget senere stadium
> uten å skape for store problemer?

Ingen forskjell, men det er ett problem: symbolene som krypteres blir lett
ganske lange, dvs. lengre enn 32 bits. Hvis jeg ikke husker feil, opererer
DES med 64-bits symboler kryptert om en 56-bits noekkel (sikkert feil :),
og jeg husker ikke hva Blowfish gjoer (vi boer vel bruke noe som er
"fritt"). Men sannsynligheten for at et objekt vil referere til (over
nettverket) et objekt det har referert til for kort tid siden er vel stor,
og dermed skulle det vaere muligheter til aa lage smarte, dynamiske koder
for aa gjoere det billig aa aksessere slike objekter, slik at situasjonen
ikke er fullt saa dyster.

Altsaa: saa lenge vi lager implementasjonen slik at det er lett aa endre
id-stoerrelsen og evt. en smart koding av id, er det trivielt aa endre
dette. Antageligvis lettes aa gjoere ved at en lager sendId() og getId()
metoder for TCP-forbindelsen mellom klient og server, og saa skriver om
disse senere. sendObject() og getObject() kan da bruke sendId() og
getId(), og ellers velge om det skjer kryptering/dekryptering eller ikke,
i foerste omgang ikke.

> Det kunne kansje tilogmed være artig med et leksikon som har alle
> objektene? Da ville det jo ikke lengre være noe hemlighet hvordan de ser
> ut.

En ting er aa gi opp kampen mot juksemakerne, men aa _hjelpe_ dem! ;-)
Men ideen er forsaavidt god, hvis vi venter at noen vil gjoere det
uansett, kan vi like godt lage et bra leksikon i utgangspunktet.

> Vil man jukse og miste noe av atmosfæren ved å bli overrasket av et
> monster rundt et hjørne så greit for meg, men jeg vil alltid foretrekke å
> bli skremt slik at jeg nesten hopper av stolen samtidig som jeg fortvilt
> prøver å sende beskyttmegmotdetfarligemonstrekommandoen.

Det er i grunnen sant, spillere som velger aa faa en maksimal opplevelse
vil la vaere aa jukse.



- Tore