Inspiration
We wanted to explore a simple question:
Can people have more private conversations without leaving the messaging apps and typing workflows they already use?
Friends, couples, privacy-conscious users, and people occasionally sharing sensitive information often communicate through ordinary messaging apps. We were interested in creating an additional privacy layer that feels natural rather than forcing users to switch to a separate encryption tool or communication platform.
That idea led to CryptoBoard: bringing privacy directly into the keyboard and combining encrypted content with ordinary-looking cover text.
What it does
CryptoBoard is an Android keyboard-based privacy solution built around the FlorisBoard architecture.
The core workflow is:
Private message → AES-256-GCM encryption → invisible Unicode encoding → ordinary-looking cover text → normal messaging workflow
The encrypted payload can be concealed inside visible text such as:
ok 👍
The visible message appears ordinary, while the supported CryptoBoard workflow on the receiving side can detect the concealed characters, extract the encrypted payload, decrypt it, and present the private content.
The project also includes supporting functionality around local key management, recipient-side extraction, compatibility testing, and QR-based key exchange.
CryptoBoard is designed around two complementary goals:
- Steganography helps conceal the presence of the payload.
- Encryption protects the content of the payload itself.
The result is a privacy-focused communication workflow that aims to reduce the friction between everyday messaging and private communication.
How we built it
CryptoBoard is built as an Android keyboard system around FlorisBoard.
The existing prototype uses a modular architecture including:
- FlorisBoard keyboard integration
- AES-256-GCM authenticated encryption
- Invisible / zero-width Unicode encoding
- Message processing
- Local key management through Android Keystore integration
- Recipient-side payload extraction
- Accessibility-based screen scanning and overlay display
- QR-based peer key exchange
The sender pipeline processes the private message through the keyboard, encrypts it locally, encodes the encrypted payload using invisible Unicode characters, and combines it with visible cover text.
On the receiving side, the supported workflow detects the concealed payload, extracts it, decrypts it, and displays the private content.
The project is open source and currently serves as the technical foundation for the solution we propose to further develop and validate through ZERO ORIGIN.
Challenges we ran into
The biggest challenge was that privacy is not only a cryptography problem.
Invisible Unicode characters are not handled consistently across platforms. Some messaging services may sanitize or alter them, which can affect whether the concealed payload survives transmission.
The receiving workflow also introduces additional engineering challenges around accessibility services, scanning behavior, battery usage, and reliable detection.
We also had to think carefully about key management and user trust. Protecting the message content is only one part of the problem; users also need a practical way to manage and verify keys.
Finally, steganography has inherent limitations. Hidden data can potentially be detected through technical analysis, compromised devices remain a risk, transmission metadata is not hidden, and the current prototype has not undergone a professional security audit.
Accomplishments that we're proud of
We are proud to have turned the idea into a working architectural prototype rather than leaving it as a concept.
Our existing foundation includes:
- A functioning Android keyboard integration
- Local AES-256-GCM encryption
- Invisible Unicode payload encoding
- Recipient-side payload extraction and decryption
- Local key-management architecture
- QR-based peer key exchange
- Compatibility-testing functionality
- An open-source codebase
More importantly, the prototype helped us explore the complete journey from typing a private message to carrying and recovering its encrypted content through a familiar messaging workflow.
What we learned
We learned that building privacy technology is about much more than choosing a cryptographic algorithm.
A technically sound system still has to be usable, understandable, compatible with real platforms, and practical for everyday communication.
We also learned the importance of separating two different problems:
Hiding information is not the same as protecting information.
Steganography can help conceal the presence of a payload, while encryption protects the content even when the encrypted payload is discovered.
Building the prototype also showed us how much work remains in areas such as compatibility, key verification, accessibility performance, error handling, testing, and security review.
What's next for CryptoBoard
If shortlisted for ZERO ORIGIN, our goal is to take the existing architectural foundation and develop and validate the next version of CryptoBoard.
Our proposed work includes:
- Better onboarding and user experience
- Clearer error handling and status feedback
- Compatibility handling for platforms that modify or strip invisible Unicode
- Improved key verification UX
- Accessibility and battery-performance optimization
- Comprehensive multi-platform compatibility testing
- Additional security hardening and documentation
The next phase is not just about adding features. We want to validate the actual user experience, understand where privacy creates friction, test successful send-and-decrypt workflows, and learn how the system behaves across real messaging platforms.
Our long-term goal is simple:
privacy should fit into the conversation, not force the conversation to change.
Log in or sign up for Devpost to join the conversation.