Re: Ang. juks

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

> En av grunnene til at vi ikke vil laste ned hele verdenen til klienten i
> en smell er at dette vil kunne kreve fryktelig mye plass paa
> klientmaskinen. Derfor er det oenskelig at en har mulighet for aa hente
> ned objekter litt mere dynamisk. Dette problemet blir vel mindre og
> mindre, og jeg kunne godt tenke meg et cache system som er saapass
> fleksibelt at klienten selv kan sette stoerrelsen paa det.

Det vil kreve mye plass, men det er grunner til at jeg synes det i det
minste boer vaere mulig.

Som jeg husker fra Grimne-spilling, saa er det ofte slik at en "raser
gjennom verden" for aa komme seg fra A til B der en har tenkt til aa
gjoere et eller annet. Slikt kommer det nok til aa bli her ogsaa, selv om
det selvsagt begrenser seg hvor raskt en kan reise.

Hvis en har skaffet seg (gjennom en diger quest eller whatever) en feit
pegasus aa reise med, maa en regne med at nye objekter/textures stroemmer
paa ganske fort mens en farer gjennom lufta.

En magiker som teleporterer seg fra A til B har plutselig masse nye
objekter aa forholde seg til paa det nye stedet, en kan ikke ha en
situasjon der magikeren dukker opp, saa "fryser" i tre minutter paa grunn
av nedlasting og muligens er doed naar han faar kontakt med spillet igjen.

Jeg synes loesningen maa vaere at saa mye som mulig ligger nedlastet, det
skal hvertfall vaere mulig, og at de objekter som trengs umiddelbart
lastes foerst. Saa kan heller resten lastes ned i bakgrunnen.

Et ankepunkt mot individualt krypterte objekter er at en klient ikke vil
kunne gjenbruke objekter som tilhoerer en annen spiller. Ved naermere
ettertanke kan det vaere at en kan faa til dette likevel ved aa gi
klienten noen noekler, det maa jobbes litt mer med fra min side.

> Et annet problem er at den eksisterende informasjonen fra tid til annen
> maa oppdateres. Dermed vil en kunne risikere en god del tid for nedlasting
> og synkronisering av data en aldri vil trenge foer hver session. Dette
> problemet blir stoerre for en fri og dynamisk MUD der wizards fikser og
> oppdaterer jevnlig.

Nye data maa hentes ned uansett, spoersmaalet er naar. Dersom en gir
klienten mulighet til aa spille med usynkroniserte data, men aa "henge
den" naar nedlasting av noe trengs, og ellers synkronisere i bakgrunnen
via overfloedig baandbredde, er det det beste, tror jeg. Det kan uansett
ikke bli mer hakkete for klienten enn om alt som dukker opp av nye ting
maa lastes inn (lite/ingen ting lagret).

> Det siste problemet er at noekler per klient ikke gir deg noe videre
> sikkerhet i seg selv. Du kan ikke hindre at den som kopierer hele bunken
> med objekter ogsaa kopierer noekkelen. Det som vil gi litt sikkerhet er
> per session random genererte objekt ID numre. Om vi har dette trenger vi
> vel neppe aa kryptere noe i det hele tatt.

Du kan godt forhindre at noekkelen blir kjent for brukeren. Korriger meg
hvis jeg tar feil paa noe av dette, men jeg er ganske sikker paa at det
jeg sier her stemmer.

En krypterings-algoritme som f.eks. IDEA er en bijeksjon fra en mengde S
inn i mengden S. Denne bijeksjonen er en funksjon av en krypteringsnoekkel
N.

Kall krypterings-funksjonen e og invers-funksjonen (dekrypteringen) d. Aa
kryptere et element s er daa aa utfoere k = e(s;N) , aa dekryptere er aa
gjoere d(k;N), dvs. generelt er s = d(e(s;N);N). Hele poenget er at en kan
gjoere dette uten at N blir kjent.

Min ide er aa gjoere som foelger (eller noe lignende),

o  La spilleren ha intern id i paa serveren. For spilleren er ogsaa
   registrert to krypterings-noekler K og L.

o  Naar spillet skal kommunisere et objekt O med id o og innhold I
   til en spiller, gjoeres det ved at

   - Objektet overfoeres med id e(o;K)

   - Innholdet krypteres med noekkel e(o;L), _denne er unik for dette
     ene objektet_!

o  Naar spillet skal "laase opp" et objekt O, gjoeres det ved at

   - Id'en e(o;K) overfoeres sammen med noekkelen e(o;L)

   - Klienten kan naa laase opp innholdet med d(I;e(o;L)) uten
     aa kjenne K eller L. Lokal id til objektet er fortsatt kjent so
     e(o;K)

o  Naar klienten skal gjoere noe med et objekt,

   - Sender den id e(o;K) til spillet. Serveren kan da finne ut hvilket
     objekt det gjelder vha. d(e(o;K);K)

   - Annen informasjon paa et eller annet gunstig format, det viktigste er
     at spillet naa vet hvilket objekt det gjelder, uten at klienten
     paa noe tidspunkt har faatt kjennskap hverken til noeklene K og L
     eller objektets interne id o

Dette hindrer selvsagt ikke at en klient kan sammenligne med annen klient
sin base og trekke noen slutninger vha. stoerrelser paa objekter etc., men
det blir usannsynlig kronglete, og i tillegg kan en gjoere en del grep for
aa gjoere dette vanskeligere.

Ved aa gjoere noen triks med e og d, tror jeg det skal vaere mulig for en
spiller (person i RL) aa ha flere rollepersoner, og kunne oversette
objekt-id'er og innhold mot en eneste base klienten har for MUD'en.

> Det jeg ser for meg er at GOS faar oppgitt spillerens celle fra GS. GOS
> setter saa opp den statiske verdenen paa en slik maate at alle objekter
> faar et random id nummer. Dette objektet vil inneholde data som forteller
> hvilke rene grafiske objekter som benyttes for aa tegne det. Disse dataene
> behoever en ikke aa endre fra gang til gang da de kun viser til rene
> grafikkdata uten koordinater i den store verden. Klienten henter saa ned
> objektdata for de cellene den er i og har omkring seg. Etter som klienten
> flytter seg fra celle til celle, saa genererer GOS nye random objektnumre
> for de cellene klienten beveger seg mot. De id numrene som allerede er
> generert beholdes til de aktuelle cellene er saa langt vekke fra klienten
> at de slettes fra klientens cache. Neste gang klienten kommer dit, faar
> objektene nye numre. Fordelen er at den grafiske representasjonen av ting
> godt kan ligge permanent paa klientens disk.

En mulighet, absolutt, men jeg tror ikke det er noedvendig aa legeg paa en
overhead med random id'er dersom hver klient vha. kryptografiske metoder
kan faa en unik id for hvert objekt, og for alle praktiske hensyn er denne
"random", det er litt av poenget med en sterk kryptografisk funksjon.

Om en kan faa til at flere rollepersoner kan dele samme disk, det maa nok
klusses litt med.

> Bottom line naar det gjelder kryptering er vel at ting maa dekrypteres en
> gang og da kan hvem som helst lagre de dekrypterte dataene eller
> noeklene for senere bruk. Dermed vet jeg ikke om det er bryet verd.
> (Spesielt i lys av alle de rare reglene mhp. kryptering som ble paapekt.)
> Dessverre kan det vel fort bli til at vi trenger en del kryptering i
> forbindelse med autentisering uansett.

Det er riktig at dekrypterte data forblir dekryptert og kan leses. Men
naar noe er lastet ned til klienten "for snarlig bruk", maa det _uansett_
forbli dekryptert, dvs. dette er et problem uansett. Naar en har alle
dataene klienten noensinne vil kunne faa om et troll (textures, rutiner
for "slaa-noen-hardt-i-hodet bevegelsen) etc., kan en lagre disse paa et
eller annet format, samme hva en gjoer.

Det en oensker aa gjoere, er aa gjoere det vanskelig/umulig for noen aa
lage en base av slik informasjon og koble mot en klient som ikke skulle
visst denne informasjonen. Det er nettopp det en gjoer ved aa lage unike
objekt-id'er som jeg har skissert over. For alt klienten vet, saa lenge L
og K er ukjent, er det _ingen som helst_ sammenheng mellom objektene i de
to basene, to objekter kan foerst identifiseres som "like" naar det er
kjent i begge de to basene. Og selv da vet en ingenting om K og L, saa
alle objekter en senere skal faa vite noe om, maa faa et klarsignal fra
serveren for aa laases opp.

Jeg synes ogsaa kryptografiske teknikker boer brukes til hvem-kan-gjoere-
hva og autentisering av informasjon i andre deler av serveren/klienten,
men det er en egen diskusjon.



- Tore