Why SMEP Exists

Many communication services combine message security with an identity account, application ecosystem, or centralized storage layer. SMEP separates the encryption step from the transport channel. You encrypt the content first, then move the encrypted package through email, SMS, chat, a document, or another channel.

The privacy benefit is narrower and more precise than “total anonymity”: the transport provider does not need access to the plaintext in order to carry the package. The provider may still observe communication metadata.

How to Encrypt and Share a Message

1. Create a long unique secret, or use Generate Strong Key.
2. Enter the message and select Encrypt Message.
3. Copy the resulting SMEP package and send it through any convenient communication channel.
4. Give the recipient the secret key through a separate trusted channel when practical.
5. The recipient opens SMEP, chooses Decrypt, enters the key and package, and decrypts locally.

Key Handling

The secret is the most important part of the system. A short human-chosen phrase can be guessed even when AES-256 itself is strong. SMEP 3.0 therefore includes a cryptographically random key generator and applies PBKDF2 to human-entered secrets before deriving the AES key.

• Prefer the generated key or a long passphrase that is not reused anywhere else.
• Do not send the key beside the ciphertext when a separate channel is available.
• Do not store secrets in public notes, shared cloud documents, or screenshots.
• Lost keys cannot be recovered by SMEP. There is deliberately no password-reset service.

Technical Design — SMEP 3.0

Backward Compatibility

Existing SMEP 2.0 messages used AES-256-GCM with PBKDF2-HMAC-SHA-256 at 100,000 iterations and an unversioned JSON package containing ciphertext, salt, and iv. SMEP 3.0 preserves a legacy decryption path for those packages while using the stronger versioned format for new encryption.

Open Science, Open Tools, Open Challenge

SMEP intentionally uses standard cryptographic primitives rather than a proprietary cipher. The purpose is auditability: security researchers and developers should be able to inspect the implementation, test assumptions, identify weaknesses, and improve the tool.

The useful claim is not that any implementation is “unbreakable.” The useful claim is that SMEP exposes a small, inspectable attack surface built on established browser cryptography, and invites practical attempts to find implementation weaknesses.

Information-Physics Connection

Within Creation Unified’s informational-physics framework, SMEP is an application example of separating information transformation from transport ownership. The ciphertext can be carried by infrastructure that does not need the secret required to reconstruct the plaintext. This is a framework interpretation of the architecture; the security of the implementation still depends on standard cryptographic analysis and operational key handling.

Practical Uses

SMEP can be useful when people want an additional content-encryption layer across incompatible communication systems—for example research collaboration, confidential business notes, source protection, personal messages, or transferring sensitive text between parties who have already established a secret.

Frequently Asked Questions