SecureChatAnywhere ESP32 project

[modrobert]

Up

4

Down

::

I’m working on a hardware project to be able to use a smartphone to send and receive encrypted messages manually based on my old SecureChatAnywhere project for desktop computers (Java):
https://github.com/modrobert/SecureChatAnywhere

SecureChatAnywhere is a lightweight program written in Java with the purpose of making it easy to encrypt and decrypt any kind of text messages using AES-128/CBC symmetric encryption. The graphical user interface (GUI) is designed as a convenient “copy & paste tool” for computers to manage encryption and decryption stand-alone, in other words without relying on any kind of external communication.

Optimistically I trust desktop computers dealing with plaintext, but not smartphones since they are compromised by design (the cryptographic keys are in control by the vendors). The idea is that the smartphone only handles ciphertext since it is not trusted.

I’m using an ESP32S3 dev kit for the implementation of SecureChatAnywhere for use with a browser on smartphones (e.g. Android or IOS).

Here’s the C programming progress so far:
[✓] AES-128/CBC with PKCS#7 padding
[✓] http server for ciphertext input and output viewed via browser on the smartphone
[✓] Bluetooth BLE 5.2 HID keyboard host with power save support (this took a lot of time)
[✓] USB 2.0 HID keyboard host
[✓] esp32 I2C display support
[   ] PCB design

All software parts have been tested working individually, I’m now at the stage of combining the software to work together as one. Eventually I will design a PCB and get a suitable case for the project.

[bonerboy69]

Up

1

Down

::

Isn’t it better with a custom app on the phone instead of using a browser?

[modrobert]

Up

1

Down

::

Isn’t it better with a custom app on the phone instead of using a browser?

I was looking into developing a custom app for Android to see if there was some way to avoid “copy & paste” but turns out the clipboard is heavily protected in Android. The only way to access the clipboard is to register the app as a keyboard handler which will probably be too much to ask of a user (kind of a hassle to change that back and forth).

Besides, a browser based solution will give the benefit if making this usable with any kind of smartphone or pad regardless of operating system, and no need to maintain several apps.

[modrobert]

Up

0

Down

::

I’m testing a larger display LCD2004A (still via I2C), this one is 4 lines, 20 chars each line.

The purple bleed as seen is where the current test program is drawing the new chars. Looks very clear when viewed in person.

[Author]

Posts