February 2000
- datagram protocol design theory? (Question about multithreaded servers) Ola Fosheim Grøstad
- Library error J C Lawrence
- Semi-OT: Linux support in commercial MUDs? Ola Fosheim Grøstad
- From the Apache Referrer logs J C Lawrence
- From the Apache Referrer logs Kris Van Hees
- good muds for ai programming? Robert Zubek
- good muds for ai programming? J C Lawrence
- Event Scheduling Phillip Lenhardt
- Event Scheduling J C Lawrence
- Event Scheduling cg@ami-cg.GraySage.Edmonton.AB.CA
- Event Scheduling J C Lawrence
- Event Scheduling Phillip Lenhardt
- Event Scheduling J C Lawrence
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- Event Scheduling Miroslav Silovic
- Event Scheduling Jp Calderone
- Event Scheduling Ola Fosheim Grøstad
- Event Scheduling Miroslav Silovic
- Event Scheduling J C Lawrence
- Event Scheduling Cynbe ru Taren
- Event Scheduling Hans-Henrik Staerfeldt
- IO Speed Suggestions Christopher Kohnert
- IO Speed Suggestions J C Lawrence
- Couple of articles Koster, Raph
- Couple of articles Dr Richard A. Bartle
- OT: Soliciting advice from Canadians Alex Oren
- MUD Specific Building pages MichelleThompson
- MUD Specific Building pages J C Lawrence
- Embedding Python icecube@ihug.co.nz
- Embedding Python icecube@ihug.co.nz
- Embedding Python J C Lawrence
- Embedding Python Todd McKimmey
- Embedding Python Oliver Jowett
- Embedding Python Todd McKimmey
- ADMIN: List post rejections J C Lawrence
- distributed objects Kevin Littlejohn
- distributed objects Vijay Weasel Prabhakar
- distributed objects Brandon J. Rickman
- distributed objects J C Lawrence
- distributed objects Koster, Raph
- distributed objects Vijay Weasel Prabhakar
- distributed objects David Bennett
- distributed objects Phillip Lenhardt
- distributed objects cjones@one.net
- distributed objects F. Randall Farmer
- distributed objects Ola Fosheim Grøstad
- distributed objects Kevin Littlejohn
- distributed objects J C Lawrence
- distributed objects Gary Whitten
- distributed objects Balthazaar
- distributed objects J C Lawrence
- distributed objects Ola Fosheim Grøstad
- distributed objects Eli Stevens {Grey}
- distributed objects Jon A. Lambert
- distributed objects Charles Hughes
- distributed objects Caliban Tiresias Darklock
- distributed objects Charles Hughes
- distributed objects J C Lawrence
- distributed objects J C Lawrence
- distributed objects Charles Hughes
- distributed objects Charles Hughes
- distributed objects Laurent Bossavit
- distributed objects Kevin Littlejohn
- distributed objects markm@caplet.com
--<cut>--
Note: This message was written via the list web archives. There is
no guarantee that the claimed author is actually the author.
--<cut>--
Original message: http://www.kanga.nu/archives/MUD-Dev-L/2000Q1/msg00378.php
On Wed, 16 Feb 2000 21:42:28 -0800
Kevin Littlejohn <darius@connect.com.au> wrote:
> > ... don't the solutions outlined at www.erights.org for
> > implementing secure "purses" also fit the bill for combat systems ?
>
> For anyone who hasn't read it:
> http://www.erights.org/elib/capability/ode/ode-capabilities.html#simple-money
>
> Neat system.
Thanks.
> There's still reliance on a bunch of things, that may not be immediately
> evident, though, to achieve this security. One of them that doesn't apply
> in Moebius (nor, I believe, in any distributed architecture, where the 'bad
> guys' have total control over the objects)
I'm not sure I understand your security assumptions, or that you understand
ours. Please read the "Cypherpunk Reference Scenario" (and variant #3 if you
wish) at http://www.erights.org/elib/capability/conspire.html#revokability .
Briefly, Alice is assumed to have total control over the objects running on
Alice's machine, and Bob is assumed to have total control over objects
running on Bob's machine, but Alice only has control over objects on Bob's
machine to the extent that objects on Alice's machine have been given such
control. See also
http://www.erights.org/elib/capability/ode/ode-protocol.html#subj-aggregate .
In a decentralized mutually suspicious world, beware of statements about
"*the* bad guys" or "*the* objects". There are only particular bad guys and
particular objects.
> is a certain non-mutability of objects.
If the code expresses a non-mutable object, as in our example, then we still
assume that Alice may mutate objects running on Alice's machine, but she
may not mutate objects running on Bob's machine -- unless, of course, Bob
wishes to enable her to do so.
> When you've instantiated an object in E, you can't go back and
> change it's methods - what they bind to, what their source code is, etc.
> If you could do that, you'd instantiate a purse, then change it's decrement
> method. Presto - you can hand out a decrement that's sealed by the right
> thing, works fine, and does exactly what you want - purse of holding,
> anyone? ;)
The bank, being the owner of the machine the purses run on, can indeed
modify the purses in this way, and by so doing, corrupt the bank logic. This
is why we explicitly state that the system presented relies on the bank's
customers having mutual trust in the bank. However, given this trust, the
bank's customers can use this money to securely transact with each other
without having to trust each other.
All crypto-money protocols that require less than full trust in the bank are
much more complicated than the protocol presented here. For money, this
extra complexity is worthwhile. That's why we explicitly present this protocol
only as an example of protocol definition using capabilities, and not as a
serious proposal for a secure money.
> Ok, so the sealer performs some security checks on the method. In a
> distributed world, those security checks are going to be _extremely_
> interesting - and valid only until the checks stop being performed (at
> which time, the holder of the object will switch methods on you).
The sealers and unsealers run on the bank's computers along with the purses.
The bank's clients have remote references to some of these objects (in fact,
only to the purses), but are not hosting any of these objects themselves.
Therefore they are not subject to tampering by the bank's clients, though they
are (as stated) subject to tampering by the bank. I submit that the required
checks in a distributed world are indeed very simple, and are already described
in our paper.
> End result - you drag more and more stuff back to the server for
> verification, until you end up driving the objects data and methods on the
> server from a remote point.
Yup. That's what we do. It works. But it doesn't centralize any more than
any other working on-line secure money protocol does. If you know of a way
to do secure money with a less centralized protocol, that'd be worth a paper
at FC01 ;)
> Caveat: I may be wrong, but I can't see where... As EQ and others have
> demonstrated, people will quite happpily step "out of band" to break these
> systems
Please show me an out of band attack that threatens E. I'm not saying there
aren't any, but I'd like to understand what kind of attack you have in mind.
> I thought replacing the tiles with transparent ones was good, but
> staggering lag on packets back to the server boggles me.
I haven't read the thread -- only the above message -- so this last comment
boggles me ;). If it's relevant to our current discussion, please explain
or point me at something. Otherwise, feel free to drop.
Hope this clarifies things. - distributed objects KevinL
- distributed objects markm@caplet.com
- Distributed Objects Justin Rogers
- Security J C Lawrence
- commercial muds and cable TV (was code base inquiry ) Sellers, Michael
- commercial muds and cable TV (was code base inquiry ) Matthew Mihaly
- commercial muds and cable TV (was code base inq uiry ) Sellers, Michael
- commercial muds and cable TV (was code base inq uiry ) Matthew Mihaly
- business models Matthew Mihaly
- business models Daniel.Harman@barclayscapital.com
- business models Vincent Archer
- business models Dave Rickey
- a shrinking pool of players? Johan J Ingles-le Nobel
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? Bryce Harrington
- a shrinking pool of players? Travis S. Casey
- a shrinking pool of players? PartyG2816@aol.com
- a shrinking pool of players? J C Lawrence
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? Sellers, Michael
- a shrinking pool of players? PartyG2816@aol.com
- a shrinking pool of players? Ryan P.
- a shrinking pool of players? J C Lawrence
- a shrinking pool of players? Koster, Raph
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Koster, Raph
- a shrinking pool of players? Chris Turner
- a shrinking pool of players? Matthew Mihaly
- a shrinking pool of players? Chris Turner
- a shrinking pool of players? Draymoor
- a shrinking pool of players? Koster, Raph
- The Endeavour Map and MUD Applications Michael Hohensee
- The Endeavour Map and MUD Applications Ted Milker
- The Endeavour Map and MUD Applications David Bennett
- The Endeavour Map and MUD Applications Ted Milker
- The Endeavour Map and MUD Applications John Bertoglio
- The Endeavour Map and MUD Applications Justin Rogers
- The Endeavour Map and MUD Applications Eli Stevens {Grey}
- The Endeavour Map and MUD Applications John Bertoglio
- The Endeavour Map and MUD Applications Koster, Raph
- The Endeavour Map and MUD Applications Lo, Kam
- The Endeavour Map and MUD Applications Justin Rogers
- The Endeavour Map and MUD Applications Joel Dillon
- The Endeavour Map and MUD Applications Justin Rogers
- Next gen MUD wishlist Bryce Harrington
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist Bryce Harrington
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist J C Lawrence
- Next gen MUD wishlist Chris Jones
- Next gen MUD wishlist adam@treyarch.com
- Next gen MUD wishlist Sellers, Michael
- Next gen MUD wishlist adam@treyarch.com
- Next gen MUD wishlist Bruce
- Next gen MUD wishlist Bryce Harrington
- Codebase Ideas punitac@prodigy.net
- Codebase Ideas Bryce Harrington
- Codebase Ideas Aaron Mitchell
- OT: Money as motivator (was code base inquiry ) J C Lawrence
- OT: Money as motivator (was code base inquiry ) Matthew Mihaly
- Guide Applicant : Player Ratio Geoffrey A. MacDougall
- Guide Applicant : Player Ratio Matthew Mihaly
- MUD-Dev digest, Vol 1 #286 - 13 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #286 - 13 msgs Caliban Tiresias Darklock
- MUD-Dev digest, Vol 1 #286 - 13 msgs Koster, Raph
- voice vs. text Matthew Mihaly
- voice vs. text Justin Rogers
- voice vs. text John Bertoglio
- voice vs. text Lovecraft
- voice vs. text Lo, Kam
- voice vs. text Hans-Henrik Staerfeldt
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Koster, Raph
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Justin Rogers
- Client side prediction Ola Fosheim Grøstad
- Client side prediction Koster, Raph
- Client side prediction Ola Fosheim Grøstad
- Dynamic help files, was code base inquiry Richard Woolcock
- OpenSource licenses for game rules? J C Lawrence
- To all the devoted! (fwd) J C Lawrence
- Newbies Johan J Ingles-le Nobel
- MUD-Dev digest, Vol 1 #288 - 9 msgs Dr. Cat
- (fwd) Commercial-use Restrictions on Code Bases (was: help me find 100% free graphical mud) J C Lawrence
- (fwd) ADMIN: "A Classification Of Muds" [was 'In defence of stock muds...'] J C Lawrence
- Distribution Geir Harald Hansen
- player persistence Matthew Mihaly
- [Off-topic] GDC-2000 Derek Snider
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 Justin Lockshaw
- [Off-topic] GDC-2000 Christopher Allen
- [Off-topic] GDC-2000 Matthew Mihaly
- [Off-topic] GDC-2000 Joe Andrieu
- [Off-topic] GDC-2000 Kristen L. Koster
- [Off-topic] GDC-2000 Richard A. Bartle
- [Off-topic] GDC-2000 Bruce
- [Off-topic] GDC-2000 David Bennett
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] GDC-2000 J C Lawrence
- [Off-topic] AAAI symposium (was: GDC-2000) Robert Zubek
- MSP Richard Ross
- Privateer-style mu*? Bobby Bailey
- Minimum community sizes Dan Root
- Minimum community sizes Koster, Raph
- Minimum community sizes Dan Root
- Minimum community sizes adam@treyarch.com
- Minimum community sizes Matthew Mihaly
- Minimum community sizes David Bennett
- Minimum community sizes Matthew Mihaly
- Pike codebase Daniel Podlejski
- chil@gate.net Joel Kelso