Introduction to boho
boho is a shared-key library for authentication and encryption between applications and devices under your administration. Its name comes from the Korean word for protection. Arduino C/C++ and Node.js/browser JavaScript implementations use compatible messages.
When you control both endpoint programs and can provision their keys in advance, you can build communication around a pre-shared symmetric key. boho combines SHA-256-based keystream generation, XOR, shared-key authentication, and binary packet formats.
Choosing a symmetric-key deployment model and evaluating the security of boho's construction are separate decisions. Using standard SHA-256 does not mean the complete custom protocol has the guarantees of a standard authenticated-encryption construction.
Why this library exists
Embedded communication requires more than an encryption primitive: peer authentication, provisioning, message formats, memory use, transport integration, and operational key management all matter.
boho focuses on verifying already-provisioned peers, protecting data, and sharing one implementation model across Arduino, Node.js, and browsers. Encryption is independent of transport and can be used with TCP, WebSocket, serial links, or MQTT payloads. IOSignal supplies connection management and message routing around it.
Provision keys through an existing trusted path
| Environment | Example provisioning method |
|---|---|
| Embedded devices you build | USB/serial or trusted setup tools, with a key per device |
| Your web app and personal devices | User-entered device keys or a trusted pairing procedure |
| Servers under common administration | SSH, an existing TLS connection, or a secret manager |
| A defined device/user group | Peer-specific keys with rotation and revocation procedures |
The trust remains in the provisioning path and endpoint software. Sharing one key among many devices makes it harder to distinguish senders and increases the impact of a leaked key. Public web code must be delivered safely; writing that code yourself does not make an embedded secret private.
Protection scope and limits
Connection keys protect client–server traffic. A separate E2E data key can protect payloads between final endpoints. The present construction does not automatically inherit TLS or standard AEAD guarantees and does not provide forward secrecy. Review nonce reuse, replay handling, and key management for the actual application.
See authentication setup, client API, and XOR, keystream, and packet details.