Send Other Socials

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

Type a message

Encrypt files and text

Share with friends

Communicate privately

✨ What the encryption & private messaging app can do:

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.

1

🛡️ Deterministic & Non-deterministic Encryption Modes:

● Deterministic (Free) - the same text always produces the same ciphertext. Useful for predictability and searching through encrypted data.
● Non-deterministic (Pro) - each time produces a different ciphertext with the same input and key. More unpredictability = stronger
2

🚀 Text Encryption with Emojis / Chinese Characters:

➤ Send a friend a phrase encrypted with emojis - to others it’s just a cute set of icons, but for you it’s a secret message.
➤ Encrypt a document and upload it to the cloud or send it via messenger - even if leaked, it can’t be opened without the key.
3

⚡ Why this Encryption Approach is Different:

✔ Original text disguise (emoji/Chinese characters) + classic file protection.
✔ Simple and fast: enter text / choose file → encrypt → send.
✔ Only you control the key - no third-party "magic."
4

💎 Flexible ways to unlock full functionality:

● Free: watch ads and use advanced features.
● Pro version: no ads, no limits, maximum features.
About the Encryption & Privacy App

✦ 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.

SendOtherSocials: Android encryption app with Threefish-1024 and emoji/Chinese character cipher

Contacts

How it works & Technology

The app combines several unique components: a fast file encryptor, a text-to-symbols transformation, and multi-layer interface protection.

  • Fast File Encryption
    At its core is the Threefish-1024 block cipher with a 128-byte block size. Each block uses its own tweak counter to prevent repetition. The final block is padded with 0x7F.
    The key is derived from a password using PBKDF2-HMAC-SHA256 (300k iterations) and then expanded with cSHAKE256 to 128 bytes. Unlike Argon2, this approach was chosen because the app targets devices with widely varying resources - many of which cannot spare even 8 MB of memory for a KDF.
    Implementation details:
    ➤ all data is packed into a ZIP archive and then encrypted;
    ➤ the file extension does not affect decryption;
    ➤ arrays of keys, tweaks, master keys, and passwords are securely wiped after use;
    ➤ keys are never stored as String-only char[] or byte[] are used.
  • Symbol Encryption
    A key feature is converting text into a sequence of Chinese characters or emojis. To an outside observer it looks like an ordinary message, but it actually carries encrypted data.
    The method ensures that any feasible attack reduces exclusively to brute-forcing the password. The transformation is strictly reversible (1:1) with no control bytes or auto-substitutions.
    Two modes:
    ➤ Deterministic - the same text and password always produce the same sequence of symbols.
    ➤ Non-deterministic - the same text and password yield a different result each time.
    For secure input, a custom keyboard (Russian and English layouts) is provided, with an option to randomly shuffle key positions.
  • Interface Protection Against Clickjacking
    A custom SecureLayout (extending LinearLayout) overrides onFilterTouchEventForSecurity.
    ➤ With full window overlay (FLAG_WINDOW_IS_OBSCURED), the event is blocked.
    ➤ With partial overlay (FLAG_WINDOW_IS_PARTIALLY_OBSCURED, Android 10+), a soft mode applies:
    ▸ text input (IME, paste, menus) remains functional for usability,
    ▸ a warning toast is displayed with throttling to avoid spam.
    App-originated toasts are excluded from triggering protection via an internal flag.
  • Password Strength Evaluation
    A built-in algorithm evaluates password strength directly from char[], avoiding string creation. It checks for:
    ➤ repeating blocks (e.g., aaa, ababab);
    ➤ keyboard patterns (qwerty, йцукен);
    ➤ numeric sequences (12345, 9876);
    ➤ dictionary words in multiple languages;
    ➤ use of special symbols, emojis, and mixed alphabets.
    The result is shown in the UI, for example: “Strong”, BFA · PAR = 1000 · Med. (50%): est. ≈ 2.3 years
    All arrays are wiped after analysis.
  • Extended Character Set Support
    Passwords may include letters from any alphabet, digits, special symbols, emojis, and spaces.
    ➤ Latin alphabet only - ~26 variations per character,
    ➤ with digits and specials - about 90,
    ➤ with Cyrillic, emojis, and others - hundreds of thousands.
    The vast search space makes brute force the only viable attack method.
  • Memory Protection and Input Handling
    No input data is stored as String. Instead, SecureStringManager with internal SecureString objects is used:
    ➤ data is immediately encrypted in a temporary Threefish-512 buffer,
    ➤ stored in a DirectByteBuffer outside the heap to reduce leakage or swapping risk,
    ➤ arrays and buffers are securely wiped multiple times using SecureWipeUtil,
    Thread safety is ensured with striped locks, synchronizing on each key individually. Access is only possible via char[], which is erased immediately after use.
    Wiping can be performed per key or as a full reset of the entire storage on exit. Sensitive data is cleared not only from the heap but also from method stacks, preventing leaks through memory dumps and reducing post-execution analysis risk. Sensitive data is cleared not only from the heap but also from method stacks.
  • Conclusion
    SendOtherSocials combines a powerful Threefish-1024 file encryptor, innovative text-to-symbols encryption, and advanced interface protection. Sensitive data is secured at every stage-from input to storage, from memory operations to the user interface.

Comprehensive Technical Description of the Symbol Encryption Algorithm

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 setssymbolsOfOriginalForSpaces.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.
          

Private Messaging & Encryption Use Cases

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.

  • chat control: you decide who can read messages; keys never leave your device.
  • Brand variants: Send Other Socials, SendOtherSocial, Send Other - all refer to this app.
  • Русский: шифрование текста и файлов локально; без аккаунтов и серверов.