A messaging/chat playground using ED25519/X25519 for encryption
Find a file
2025-08-25 02:42:38 +02:00
src get cbreak characters from stdin, prepare for commands 2025-08-25 02:42:38 +02:00
.gitmodules create src dir and add submodules to it 2025-08-12 02:14:22 +02:00
EddieChat.geany get cbreak characters from stdin, prepare for commands 2025-08-25 02:42:38 +02:00
LICENSE Initial commit 2025-08-11 14:18:08 +02:00
README.md Moving from ini files to JSON to better store peer and group lists 2025-08-25 01:28:32 +02:00
sample-eddiechat.json Switch to JSON config file 2025-08-25 01:29:52 +02:00

EddieChat

A messaging/chat playground using ED25519/X25519 for encryption

Dependencies

For MQTT transport:

apt install libpaho-mqtt-dev

For JSON style config file parsing:

apt install libcjson-dev

Build

git submodule update --init
cd src
make

Background

The ultimate goal is to use EddieChat as a base for a messaging / chat system that operates on a broadcast medium. Usually chat systems rely on a central realying and switching component, aka a server.

The goal of EddieChat is to create a messaging system that can work on a medium where every client receives all the traffic from all other clients sharing the same space, e.g. a radio frequency. All radios within range will receive any transmission of otherb clients, if these are meant for them or not.

Nevertheless the goal is to make the system as effortless but still somewhat secure, i.e. transmission of messages shall be encrypted, discovery of communication peers shall be as easy as possible and finally there shall also be commuication groups, i.e. 1-to-n messaging.

Current Concepts

Implementation Ideas

The whole system shall be as portable as possible, especially with low resources systems like micrcontrollers in mind. On the privacy / security side elliptic curve cryptography (ECC) is used for public key crypto, AES is used as symmetric transport cipher.

Crypto Remarks

To make it more light weight we will for now use AES128 as transport cipher, which can be switched to AES256 later. Since the intended purpose is to transmit small messages instead of large files and since we need to assume that transmissions might get lost, we are using AES in ECB not CBC mode. This is less secure but hopefully ore robust.

Key ad-hoc exchange will have the potential risk of man-in-the-middle attacks. This can be helped a bit when two clients meet and compare the public keys in person on their respective devices. Key exchange for group chats will be a bit harder. To be able to send and receive messages everyone taking part in the group chat needs access to the public and private key for that group, which effectively turns this into a symmetric cipher so we could share a symmetric key right from the start instead.