Create your own end-to-end encryption - no servers, no registration, everything stays locally on your device
Text & File Encryption App - Emoji / Chinese Character Cipher
Turn text into chains of
emojis or Chinese characters that look like harmless messages, but can
only be read with the key.
Files (photos, documents, archives, and more) are securely encrypted
locally, so you can safely share them anywhere.
✦ Text encryption in two styles:
emoji / Chinese characters. Turn any message into a set of emojis or Chinese
characters. A simple phrase like "Hello!" becomes a mysterious chain of
symbols that no one can understand without the key.
✦ Encryption of any file type. Protect photos, documents, archives, and
any other data. Even when sent via messengers or social networks, they
remain fully secure.
✦ End-to-end in your hands: only you and the recipient know the key.
✦ 69+ interface languages - convenient worldwide.
✦ Use the built-in keyboard for safe message input without third-party
analysis (available in Latin and Cyrillic).
✦ The key is your imagination: text in any language, symbols, or
favorite emojis.
✦ No accounts, no servers - everything works locally on your device.
Executive Summary The application uses a unique character-based encryption algorithm developed over several years and tested on millions of key/message combinations. The design was built from scratch with the known weaknesses of classical solutions in mind and augmented with properties that standard algorithms (AES, ChaCha20) do not provide out of the box. The algorithm is a hybrid character stream cipher with deterministic and non-deterministic modes, a large alphabet (= 20,941 characters - Chinese characters (the description of this mode is provided below); = 1,641 characters - Emoji characters), multi-layer permutations and shifts, random message splitting, run-length camouflage (repeat suppression/obfuscation), masking noise, strict memory hygiene, and several cryptographically robust PRNGs (SP800-90A DRBG and a keyed BLAKE3-PRNG). Goals ● High cryptographic strength ● Concealment of structure/frequencies ● Equality search in a database without decryption (determinism) ● Non-recoverability upon loss of any ciphertext fragment ● Post-quantum resilience comparable to classical primitives 1. Threat Model (for experts) An attacker can view any volume of ciphertexts, perform statistical/frequency analysis, compare lengths, and corrupt/delete fragments. An encryption oracle is absent by default; if available, access is quota-limited and audited. Security objectives ● Confidentiality without the key ● Concealment of structure/repetitions and approximate concealment of length ● In deterministic mode - only equality leakage (intentional); other leakages are minimized ● Upon loss of any ciphertext fragment - non-recoverability of the original message (by design, intentional) 2. Primitives, Alphabets, Constants 2.1 Character Dictionaries ● Total alphabet size: 20,941 - Chinese characters ● Main working subset for shifts: 8,000 characters ● Upper bound for markers/indicators: 16,000 characters ● Final substitution range: 18,000 characters Binary sets ● symbolsOfOriginalForSpaces.bin - a shuffled “original” dictionary ● listOfChineseCharacters.bin - the “encryption” dictionary Performance notes (fastutil) Use Char2CharOpenHashMap, Char2IntOpenHashMap, Int2CharOpenHashMap for intermediate char storage, not allowing unmanaged memory growth without cleanup to avoid array reallocations; plus direct/reverse indices and proper defaultReturnValue to reduce extra branching. 2.2 Cryptographic Hashes and KDF ● BLAKE3 - key processing, building deterministic permutations, Blake3Prng (keyed + domain tags). This is a non-standard implementation (not the upstream library). Hash and KDF functions are built on our own BLAKE3 implementation (Blake3 class), supporting: • normal mode • keyed hash (32-byte key) • derive-key with context (domain separation via DERIVE_KEY_CONTEXT / DERIVE_KEY_MATERIAL) • streaming output of arbitrary length (expandable output) • state save/restore • memory wiping (zeroing keys, blocks, stacks) Internals close to the BLAKE3 specification: IV; flags (CHUNK_START, CHUNK_END, PARENT, ROOT, KEYED_HASH, DERIVE_KEY_*); dimensions (BLOCK_LEN=64, CHUNK_LEN=1024); 64-bit chunk counter; permutation MSG_PERMUTATION; 7 compression rounds with the G function and final xorshift mixing of state/chains. Output is LE (little-endian). Interoperability note. Although compatible by design, this is not the upstream library. We validate against official test vectors and use differential tests to ensure bit-level parity and constant-time behavior in sensitive paths; all sensitive buffers are wiped. ● SHA-512 - seed normalization; DRBG (SP800-90A) in FastSeededRandom and SP800SecureRandom. 2.3 PRNG/DRBG Stack (three independent sources) ● FastSeededRandom FastSeededRandom is a high-speed pseudorandom number generator built on the NIST SP 800-90A Hash_DRBG (SHA-512). To strengthen security, it employs personalization (DRBG_PERSONALIZATION = "FSR-v1"), which prevents the reuse of identical random streams. Initialization can use various input types (int, long, char[], byte[]); the input is first normalized by SHA-512 into a 64-byte seed. The generator is thread-safe (via an internal lock), ensuring correct operation in a multithreaded environment. There is no bias when producing bounded integers: a fast path is used for power-of-two bounds, and rejection sampling is applied otherwise to maintain uniformity. ● SecureRandomProvider SecureRandomProvider is responsible for generating cryptographically secure random numbers within the algorithm. It uses a thread-isolated mechanism (ThreadLocal), so each thread has its own RNG instance with no contention or locks. The provider is built on NIST SP 800-90A Hash_DRBG (SHA-512) backed by an entropy source (BasicEntropySourceProvider). Initialization is performed using SP800SecureRandomBuilder, ensuring correct parameterization and avoiding weaknesses caused by misconfiguration. As a result, the application obtains a reliable stream of cryptographically secure randomness that meets security requirements and remains resistant to prediction even during long-term use. ● Blake3Prng (keyed) Blake3Prng is a cryptographically secure random number generator built on the BLAKE3 function in keyed mode with a 32-byte key. It operates in two domains (B3PRNG-KDF and B3PRNG-STREAM), separating key derivation from the streaming output of randomness. Each call to refill() returns a new 64-byte block of random data and rotates the key, providing forward secrecy and backtracking resistance. The generator uses a lightweight little-endian counter (ctrLE) with no additional allocations, and the fromIntSeed(...) factory splits the input key into secret and context, applying a domain-separated KDF tag for uniqueness. RNG defense-in-depth. If any source degrades, the design does not collapse: distinct subsystems draw from independent RNGs (no single point of failure). Health checks and fail-closed behavior prevent silent bias propagation. 3. Key Lifecycle and Initialization Keys arrive as char[], are copied once, and the original is wiped immediately. We derive a mixed dictionary (key- and hash-driven permutations) and retain only a BLAKE3-derived key representation in memory. All intermediate bytes/chars are wiped in 1–3 passes (configurable). Concurrency and orderly teardown are coordinated via Phaser. 4. Building Keyed Permutations/Shifts Combination of BLAKE3(key), index functions (secureHashOfChar), positional values, and RNG (FastSeededRandom / Blake3Prng). Two mixing stages: 1. across the entire alphabet (20,941); 2. across the working subset (8,000) used for substitution. Swaps - via EncryptionUtils.secureSwap with a single-char temp buffer and immediate wipe. Final artifacts: orig→enc and enc→orig maps plus index tables for O(1) access. 5. Message Splitting and Shuffling (Structural Camouflage) Message splitting and shuffling is one of the key mechanisms for camouflaging text structure in the algorithm. Its goal is to break the linearity of the original text, make substitution independent of position, and sharply increase the resulting entropy. ● Splitting (splitMsgIntoParts) First, the message is divided into fragments of random length in the range from 1 to ≈8000. The algorithm attempts a series of “chaotic” adjustments so that the sum of lengths exactly matches the length of the original text and all parts have unique sizes. If adjustment fails, a fallback strategy is applied: GREEDY (even splitting with correction of adjacent equals) or DP (dynamic programming). For large messages, protection against explosive complexity is enabled (when k>25 or totalLen>2500, DP is replaced by GREEDY). The result always covers the entire text, but the splitting remains unpredictable and is additionally shuffled (shuffle). ● Repeat Elimination (replaceRepeatsInCharArrayList) After splitting, each part undergoes separate processing: all repeating characters are replaced with a special pair of codes. Instead of a sequence like “aaaaa,” the ciphertext contains two markers: – a shifted character (original index + SIZE_OF_MAIN_PART_OF_ENCRYPTION, normalized to the range [SIZE_OF_MAIN_PART_OF_ENCRYPTION .. SIZE_OF_HIGH_BOUND]), – a repeat counter (a character taken from the main part of the alphabet). An additional shift exponent is introduced, which increases dynamically (extraShift) and is normalized modulo 8,000. Thanks to this, identical repeating sequences are encoded differently each time, depending on context and position. This technique breaks frequency analysis: familiar runs and patterns disappear, replaced by noise-like codes that have no direct correspondence to the original text. All intermediate structures are securely wiped from memory. 6. Masking Noise and Re-randomization ● Non-deterministic mode: before permutation, dynamic noise is embedded (length derived from shift), characters from randomList[0..7999]. ● Deterministic mode: noise is generated deterministically from the hash (hexdigestCustomWithIgnoreSymbolChar), without spaces, for exact reproducibility. Afterwards - sorts, permutations, and multiple substring moves (moveSubstring) with a seed from the hash of the final sequence: auxiliary markers (shift, number of spaces, etc.) are scattered across pseudo-random positions. 7. Computing shift and the Role of RNG The hasSpaces flag (or manual mode selection) defines the strategy: ● NON_DETERMINISTIC: shift ← SecureRandomProvider.get().nextInt(8000) plus noise from Blake3Prng. ● DETERMINISTIC: shift ← FastSeededRandom seeded from BLAKE3(message) (exact reproducibility). ● AUTO: determined by the presence of spaces. shift affects noise length, indexing, repeat markers, exponents, and movement positions. 8. Two Security Modes 8.1 Deterministic Equivalent to deterministic encryption: identical plaintexts under the same key → identical ciphertext. Purpose: database equality index (search/JOIN/unique keys) without decryption. Intentional leakage: fact of equality. Countermeasure: separate the “index” and the “data”. 8.2 Non-deterministic Every encryption produces a different ciphertext; optimal for storage/transport, reduces linking and re-observation risks. 9. Non-recoverability upon Loss of Ciphertext Due to splitting, substring moves, repeat markers, shift determinants and their relocation, as well as dependencies via pseudo-random offsets, the loss of even a small portion of characters breaks the recovery chain. Practical effect: partial decryption is impossible - all or nothing. 10. Memory and Thread Management ● Wiping: multi-pass zeroization ofbyte[], char[], builders/buffers, and fastutil collections. ● Concurrency:Phaser ensures orderly shutdown before clearResources(). ● Locking:Striped Lock(512) for fine-grained synchronization of instance maps; background disposal via CachedThreadPoolExecutor. ● Side-channels: hot paths use branch-reduced logic and O(1) table lookups; “safe defaults” replace exceptions on missing keys; mapping tables are warmed to stabilize cache behavior. Timing-sensitive data is never used to decide control flow when avoidable. 11. Mappings and Fast Tables Mappings and fast tables provide instant access to character transformations during encryption and decryption. Several structures are formed: mappingCrypt (original character → encrypted), mappingDecrypt (reverse transformation), as well as indexing maps symbolToIndex* and indexToSymbol*. All character ↔ index conversions run in O(1) without unnecessary branching, which reduces the risk of leaks via timing attacks. This approach allows the algorithm to process large volumes of text at high speed without sacrificing security. After completion, all structures are securely cleared (wipe / clear) to prevent any data leakage from memory. 12. Post-quantum Resilience (claim, not certification) Classical brute force is unrealistic: the space includes not only the key, but also permutations, splits, markers, noise, and positional shifts. Grover’s algorithm (√N) does not make the combined task practically feasible - N is multiplicatively large. BLAKE3/SHA-512/DRBG have no practical quantum weaknesses today, beyond the standard quadratic brute-force speed-up. 13. Comparison with AES / ChaCha20 - a candid comparison AES and ChaCha20 are battle-tested standards of byte-level encryption. They are ideal when pure symmetric cryptography for byte streams is needed, with AEAD modes, hardware acceleration, formal security models, and decades of public analysis - the foundation of the industry. Our algorithm addresses a different problem: it operates at the character level, natively masks the shape of the message (structure, repetitions, length), can be deterministic for database search (intentional equality leakage), and also supports a non-deterministic mode for storage/transport. Where standards require add-ons (padding, masking, separate indexes, etc.), ours builds these into the architecture: splitting into unique fragments, repeat destruction, noise, pseudo-random substring permutations, and strict memory hygiene. In addition, we deliberately introduce an "all or nothing" property: loss of part of the ciphertext renders the original unrecoverable - a principled defense against partial attacks, whereas classical schemes typically allow reading preserved blocks. Simply put: in terms of structure concealment and operational capabilities (search without decryption, non-recoverability upon loss), our approach provides what standards do not offer out of the box. In terms of external audit and time-proven status, the classics lead - and that is an honest statement. We therefore position our algorithm not as a replacement for AES/ChaCha20, but as a specialized tool for use cases where masking of form and operational convenience matter, without compromising confidentiality. 14. "Can it be cracked?" Even with full algorithm disclosure, without the key, recovery entails an infeasible search over keys × permutations × split structures × repeat markers × noise × positional shifts. Quantum speed-up (√N) does not make the task practical: the combined search space remains beyond feasibility. Loss of ciphertext fragments, by design, makes the original message unrecoverable. 15. Limitations and Transparent Disclaimers ● Maximum input size: governed by memory and configured limits; streaming API available for large texts. ● Determinism intentionally reveals value equality. ● The algorithm is non-standard: to achieve a status comparable to AES/ChaCha20, an external crypto audit and formalization of security models are required (IND-CPA-like for the non-deterministic mode, a separate definition for the deterministic mode). ● Irrecoverability warning: any missing ciphertext fragment prevents decryption by design. 16. Conclusion We implement a multi-layer character cryptosystem with strong randomness, structure masking, repeat destruction, deterministic indexing for databases, and strict memory hygiene. In several practical properties (structure concealment, non-recoverability upon loss, search without decryption) the system surpasses classical standards; in audit history, they currently lead - and that is normal and honest. With the addition of authentication (MAC/SIV/AEAD) and an external crypto audit, the solution positions itself as industrial-grade protection with unique capabilities.
SendOtherSocials is a privacy app for private messaging and text & file encryption. You can encrypt message and paste it into any chat. Our character cipher hides content using emojis/Chinese characters.