[DGD] 1.2.53

[Felix A. Croes]

"Christopher Allen" <ChristopherA at skotos.net> wrote:

> "Felix A. Croes" <felix at dworkin.nl>"
> > On my 867 Mhz Mac, raising a 1024-bit number to a 1024-bit power with
> a
> > 1024-bit modulus takes .1 seconds if the code is compiled with -O3 --
> > in portable code without host-specific optimizations.  This means that
> > implementing RSA encryption in LPC should now be feasible.
>
>
> Cool!
>
> <dreams of DGD SSL>
>
> ;-)

My goal is to make SSL in DGD at least feasible, though not necessarily
very efficient.  SSH version 1 should already be doable (-c none); I
don't think you'll need more than RSA, SHA-1, and CRC-32 for that?

I'm going to start with providing basic DES encryption as a kfun.  That
should suffice to implement all the different DES modes (ECB, CBC, 3DES CBC,
etc.) in LPC.  I intend to wrap it in a general kfun, like this:

    prepared_encrypt_key = encrypt("DES key", key);
    encrypted = encrypt("DES", message, prepared_encrypt_key);

    prepared_decrypt_key = decrypt("DES key", key);
    message = decrypt("DES", encrypted, prepared_decrypt_key);

with

    string encrypt(string cipher, string mesg_or_key, string keys...)
    string decrypt(string cipher, string mesg_or_key, string keys...)

For unsupported ciphers, the kfuns would return nil.  This way, it would
be easy to make optional encryption packages that could be added or
removed without breaking dumpfile compatibility.  The kfuns could also
be masked, for example in the implementation of 3DES CBC:

    string encrypt(string cipher, string mesg, string keys...)
    {
	switch (cipher) {
	case "3DES CBC key":
	    return ::encrypt("DES key", mesg) +
		   ::decrypt("DES key", keys[0]) +
		   ::encrypt("DES key", keys[1]));

	case "3DES CBC":
	    encrypted = "";
	    keylen = strlen(keys[0]) / 3;
	    while (strlen(mesg) >= 8) {
		keys[1] = str = asn_xor(mesg[.. 7], keys[1]);
		str = ::encrypt("DES", str, keys[0][.. keylen - 1]);
		str = ::decrypt("DES", str, keys[0][keylen .. 2 * keylen - 1]);
		str = ::encrypt("DES", str, keys[0][2 * keylen ..];
		mesg = mesg[8 ..];
		encrypted += str;
	    }
	    if (strlen(mesg) != 0) {
		keys[1] = str = asn_xor(mesg, keys[1]);
		str = ::encrypt("DES", str, keys[0][.. keylen - 1]);
		str = ::decrypt("DES", str, keys[0][keylen .. 2 * keylen - 1]);
		str = ::encrypt("DES", str, keys[0][2 * keylen ..];
		keys[1] = str = asn_xor(str, keys[1]);
		encrypted += str;
	    }
	    return encrypted;

	default:
	    return ::encrypt(cipher, mesg, keys...);
	}
    }

... where asn_xor() is also on my list of things to implement :)  It
wouldn't be very efficient, but it wouldn't be very slow, either; the
cost of processing input and output this way would be a minor fraction
of the overall cost of execution.

What I want to avoid is adding a huge library of crypto functionality
to DGD itself, or to make the vanilla source dependent on a third-party
crypto library such as OpenSSL, which may not work on every platform
that DGD runs on.  This is why I'm considering using IPsec to handle
encryption, with RSA for initial authentication and exchanging the
keys.

Even with IPsec, there would be a use for having at least some basic
encryption functionality as a kfun: it would be required for occlusion,
where the server sends information to the client as part of the normal
information stream, but without telling it what it means.  For example,
the server sends information about all players in your current sector
to you, but only gives you the key to encrypt (part of) that information
when those player(s) become visible to you.  This would avoid transmission
bursts when many things suddenly become visible, while also defeating
traffic snooper tools that give the player a bigger view than he is
supposed to have.  In this case, encryption only has to be strong enough
to make on-the-fly cryptanalysis impossible.

Regards,
Dworkin
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd