Chat and Eulora2's Communication Protocol



December 19th, 2022 by Diana Coman

This article builds up on the existing, well-iterated specification of the communication protocol, aiming to detail the new developments and to provide a place for current and relevant discussion going forwards. For the core structure of the protocol though, the linked article remains the reference and although the discussion of that part moves out of necessity here as well, I see no need at the moment to copy its content too. If your question concerns the parts that are not directly described here, simply link precisely the part you are talking about, as needed.

The first further addition to the communication protocol enables chat in Eulora2 and is currently implemented and fully working. Worth making it explicit and right from the start that the chat in Eulora2 is by default encrypted1 whenever in transit and effectively authenticated as well, as it fully benefits from the whole existing infrastructure supporting the game's world2. The WoT layer that is currently in the works will further provide the means to seamlessly keep out any automated noise, spam and the like while simultaneously enabling all users to effectively retain both control and accumulating benefits for everything that they put into participating. To the extent possible, I fully intend to further align the incentives as much as I can to support meaningful conversations that are worth re-reading, too - without any unnecessary restrictions and with fully owned responsibility as well as benefits for each participant, too. It is to my eye the only way in which having a chat capability is even worth it in the first place.

To add the chat capability to Eulora2, there are two new message types added in section 4 (Serpent packets), to request and receive chat lines, respectively, as well as one new action type added to section 7 (Character actions) describing the "Say" action. Using the same specification format, the newly added sections are the following:

4.9 Line Request

  • uint8 (type ID, =12), followed by
  • uint8 (count of lines), followed by
  • n times uint32 (id of chatroom), uint64 (lowest line number requested), uint64 (highest line number requested), followed by
  • padding to Serpent-message length

4.10 Line Info

  • uint8 (type ID, =13), followed by
  • text (line content), followed by
  • uint32 (chatroom ID), followed by
  • uint32 (speaker ID), followed by
  • uint64 (line number), followed by
  • uint64 (keccak hash of the line's content and number), followed by
  • padding to Serpent-message length

7.9 Say3:

  • uint8 (type ID, =9), followed by
  • text (line content), followed by
  • uint32 (room ID), followed by
  • uint64 (keccak hash of the line's content)

A line of chat in Eulora2 has a maximum length of 1445 characters. This is fixed and unchangeable as it is the maximum that fits in a 4.10 message (which has the least space for the line's content out of all the messages relevant to chat lines and therefore effectively decides the *maximum* allowed line length). This limit is unlikely to be perceived all that often in practice but even if it is, note that it's anyway more generous than most other existing chat protocols, irc included. Any client implementation is however entirely free to take its own approach as to how it handles this - whether it splits some user input into several lines if needed or whether it restricts input to this maximum of 1445 characters to start with, to give some concrete examples.

Beyond the above specific characteristics, for all intents and purposes chat rooms in Eulora2 are otherwise like any other game entities and thus the above additions to the communication protocol itself are both minimal and all that's truly needed for a practical, working implementation. The speakers themselves are also characters (whether player controlled or not) in the game, hence fully described otherwise through the existing messages. There is a further part related to the WoT, currently in development and thus to be described in more detail at a later date.

Feel free to ask any relevant questions in the comments section below.


  1. Serpent keys 

  2. Obviously, any of the users can otherwise make public the chat logs they have when and as they see fit but if you rely on something outside Eulora2 for that, it's strictly between you and that provider, nothing to do anymore with either Eulora2 or the support and protection it provides. 

  3. Note that this is an action and as such just a part of a 4.5 message, Client Action, where the overall message structure is specified. 

Comments feed: RSS 2.0

4 Responses to “Chat and Eulora2's Communication Protocol”

  1. Jacob Welsh says:

    Where does the 1472-byte packet size come from (equivalently, the 92 in "92 successive 128 bit chunks")? Largest UDP packet that fits without fragmentation on an all-Ethernet path (without any encapsulation or protocol option fanciness)?

    Is there an implicit byte ordering in the protocol? For instance, uint16 is said to be a 2-byte basic type but how those bytes are decoded into a number seems unstated. For another instance, a keccak hash at least in its purest conception is a bit string so there's room for confusion in how that translates to an integer type.

    Is there a canonical (or good, or at least available) reference for Serpent and its usage? I'm seeing hints that it's used here with zero overhead, which makes me wonder if there's really no initialization vectors or equivalent, something to exclude statistical attacks based on (same plaintext fragment in + reused key) -> (same ciphertext fragment out).

  2. Diana Coman says:

    Where does the 1472-byte packet size come from (equivalently, the 92 in "92 successive 128 bit chunks")? Largest UDP packet that fits without fragmentation on an all-Ethernet path (without any encapsulation or protocol option fanciness)?

    Yes, 1472 as the programmable payload in an Ethernet frame of 1500. The value was arrived at after some discussion and iteration, starting somewhere in 2017 when we were trying to figure out how to even get some use out of the relatively small payload size of Serpent and got settled almost one year later, in 2018, as the protocol and needs of the game became clearer and it was noted that the correct measurement unit for network traffic is not really the bit nor byte but the Ethernet frame.

    Is there an implicit byte ordering in the protocol?

    Yes, over the network everything is Big-endian (byte AND bit order). As far as I know, this is the usual convention and there wasn't a very good argument to break it (even despite a lot of log talk on how everyone is on little endian nowadays where local machines are considered). Not sure why it didn't become explicitly stated in the protocol's description but at any rate, it was discussed, agreed on and implemented as such, see the To_Wire and From_Wire methods in the Messages package of EuCore.

    Is there a canonical (or good, or at least available) reference for Serpent and its usage?

    The one and only relevant reference that I know of is the original paper describing and proposing Serpent for the AES competition, which is anyway the reference followed by all implementation for Eulora2, hence archived and linked from my first article on Serpent implementation. In terms of attacks and the like, the paper itself claims that breaking a Serpent key would require at the very least 2^100 known plaintexts and actually more like at least 2^256 due to their chosen S-boxes. There's also the note that "it would be prudent" to change a key "well before 2^64 blocks have been encrypted" to avoid a potential collision attack. I am not aware of anything more or even simply better than this in terms of documented Serpent usage and/or potential vulnerabilities.

    I'm seeing hints that it's used here with zero overhead, which makes me wonder if there's really no initialization vectors or equivalent, something to exclude statistical attacks based on (same plaintext fragment in + reused key) -> (same ciphertext fragment out).

    It is indeed used with zero overhead. The sort of thing you seem to be looking for is actually baked in at protocol level through the chosen structure of messages: note that even if you send repeatedly the same chat line for instance (hence presumably "same plaintext" as far as the user is concerned), what gets encrypted and therefore counts as "plaintext fragment" from Serpent's point of view is going to include that padding that is meant to be random (though the user can choose to have it fixed and repeated instead, up to them).

    Otherwise and as it is the case with any and all other symmetrical encryption schemes, it is in principle and in theory possible to make the full possible table of input/output and then use that, with the only protection against this being the cost (time esp) of producing it. Arguably the same characteristic of being faster than RSA works in this sense against Serpent but in practice and at least so far, it still seems to be prohibitive. I suppose if/when Eulora2 is worth the trouble for someone to break Serpent, it will be quite something anyway.

  3. Diana Coman says:

    Updated with footnote 3 and changes to 4.10 and 7.9.

  4. [...] as an ongoing trend, and in the envisioned future with new possibilities emerging in the nascent Eulora2 environment. [^]Speaking of automation, it looks like I could use a proper script for generating these tables [...]

Leave a Reply