project scope

[Luke]

The project proposal as it stands is for marjoram to be an open-source
modular game server.

There are still some big questions to be addressed before development
can start.

What platforms to target? We should consider:
- Java (processing, android)
- Flash
- Unity3D
- C++ (OpenFrameworks, Cinder, etc.)

What sort of basic functionality? We have envisioned a modular system
but some of the core modules will prolly be developed and maintained
by us. Some to think about.
- graphic admin dashboard
- player authentication
- high scores
- matchmaking/ lobbies
- achievement systems

thoughts?

[Lucas Miller]

My major hiccup with making this a game server is still security; I
acknowledge that many users won't be needing a high security
workhorse, I'd also rather not be responsible for allowing game
hackery;

Most servers should have SSL set up prior to installing Marjor.am
(almost always an extra cost), but I want something to exist even
without SSL protection; My proposition is coming up with a way to use
RSA or some other asymmetric cipher, as it would be much more
difficult to break, even in an open-source game; My proposition is the
following:

First run of game, game generates public and private RSA key;
Game produces encrypted public RSA key using AES encryption (shared
key, known by server)
Game sends public key to server, which returns its public RSA key and
saves the game's public key in a database
Game then makes all future requests by encrypting them with server's
RSA key.


Issues:
RSA encryption does not appear to be completely functional in Unity3D,
but they may be libraries written by others, and worst case, I have
found javascript implementations of it that could be written as a
Unity script
The RSA key is locally encrypted with AES, meaning that the shared key
is visible in the source; I will need to meditate on how to get around
that

[Lucas Miller]

Note: These aren't really anti-cheating mechanisms; These are solely
for transmitting data securely;

For the purpose of updating a score or something, using a hash
checksum is much faster, and equally safe; However, there must be some
way for the game to have previously authenticated to use this, such as
the above.

For example:

(Game uses RSA handshake above, gets unique player ID)

Game can then use a hash key salted with a known secret and the player
id as a checksum:

POST: "score="+score_value+"&check="+MD5("KNOWN_SECRET"+score_value
+player_ID)

[Luke]

I agree that we should make security a priority. I think getting the
key generation systems streamlined will be crucial.
I would imagine we could basically set up the generation system to
spit out the necessary public keys as part of a setup routine so that
our gamedevs can just drop it in to the client code.

[Luke]

Should overall project scale be a factor in this security?
Will player volume be a factor? (will one of these options limit the
max number of players?)
Will any of these options limit the range of plugin applications? (eg.
will one option prevent real-time-ish game usage or something similar)

and perhaps the biggest question?
Should this sort of encryption be a plugin level thing? like should we
allow devs to choose what sort of encryption etc they want to use? Is
that even feasible from a technical perspective?

[Lucas Miller]

I think that first, a general security scheme for ALL data should be
decided upon (general secure flow);

From there, I think having individual usernames, requiring password
authentication, etc. would be options of a "user security" plugin.

Do you think there is any problem with having the app's private key be
part of the source code? There would issues with open source
applications, and decompilers, I think. I'll have to research how
other games do this...

[Luke]

Well it might be unavoidable.
I think if we used public/private key encryption with an
authentication system that would provide suitable obstacles to
malcontents. As to the opensource issue developers could either
include a binary blob from some compiled language.

I am far from expert on these matters, so I am open to any options.
 Are there any other viable options worth considering?