[ENet-discuss] added encryption to enet

[Adam D. Moss]

Hi!

LoneSock wrote:
> I've modified enet to implement encryption.  I use the Block TEA 
> algorithm (supposedly decent, in the public domain, and very simple to 
> implement).  See this link I found via Google for more info:
> http://www-users.cs.york.ac.uk/~matthew/TEA/TEA.html

Nice idea (though the page does say that there is an analytical
attack for Block TEA - I implemented XXTEA for that reason in
my ENet app, though at the application level, and I don't actually
use it - see below...)

> Both sides must have the 128-bit key.

Unfortunately I believe that's quite a weakness in symmetric
algorithms.  Perhaps someone crypto-ish can recommend a way
for ENet (or the app) to negotiate a shared secure key over
an insecure link; pretty sure there's a standard crypto way
to do that.  The absence of such a method does very much
limit the usefulness of an encrypted link.  If such negotiation
were implemented at the ENet level, it would be nice to kick off
the negotiation and then eventually for both sides to get an event
saying 'encryption now secure' or something - perhaps the connect
event can simply be postponed until the key is negotiated.

> Encryption has to happen on a 4-byte block,
>   so I modified the packet structure to have a message length, as well 
> as the actual (internally rounded up to a multiple of 4)
>   buffer size.

This isn't going to vary from the 'actual' size by more than
+3, right?  So it could be stored as a 1-byte (actually 2-bit,
so maybe packable elsewhere in the packet structure) delta based
on the actual size to save small-packet overhead.

> Does anyone see any problems with the chosen architecture

Not really, except the above concerns.  My only other reservation,
though it's fairly significant, is that without handy key negotiation,
this is something that can be very adequately and simply implemented
at the application level rather than pushing it down to the ENet
level and potentially bloating all users' packets (and code, though
I imagine the footprint change is very small - that's one nice
aspect of the TEA-ish algorithms!).

Cheers,
--Adam
-- 
Adam D. Moss   -   adam at gimp.org