This document describes how Share a Secret protects sensitive information, what threats it is designed to defeat, where trust boundaries lie, and what guarantees the system can and cannot make. It is intended for technically minded users, security reviewers, and organizations evaluating Starkive for professional use.
Scope of this document
This whitepaper covers the security design of Share a Secret as a product. It does not disclose proprietary implementation details, internal key schedules, or server-side infrastructure specifics. Its purpose is to allow informed trust decisions, not to serve as a technical reference for reimplementation.
Share a Secret is a secure, ephemeral information-delivery feature built into Starkive. It allows a sender to encrypt a piece of sensitive information (text, a password, a file) and deliver it to a recipient in a way that is mathematically protected from interception, accidental forwarding, and long-term exposure.
It is not a messaging platform. It is not a password manager. It is a single-purpose tool designed to solve one specific problem: getting a secret from one person to another without leaving a persistent, readable copy anywhere along the path.
Share a Secret is a proprietary feature of Starkive, developed and maintained by DePalo Consulting LLC. It is available free of charge to all Starkive users on Windows 10 and 11, and recipients can open web-based secrets in any modern browser with no account or software required.
Share a Secret is designed to protect against the following classes of threat. Understanding what is in scope, and what is explicitly out of scope, is essential to using the system appropriately.
IN SCOPE: Threats the system defeats
Server-side compromise
The Starkive server stores only ciphertext. A full breach of the server yields no readable secrets because the encryption key (passphrase) is never transmitted to or stored by the server.
Network interception
All transmission occurs over TLS. The encrypted payload itself is separately protected by AES-256, so even a successful TLS downgrade or MITM attack exposes only ciphertext.
Accidental forwarding of the link
A share link alone is not sufficient to read the secret. The passphrase must be provided, and it is designed to travel by a separate channel. A forwarded link without the passphrase is useless.
Long-term exposure via web links
Web share links are one-time: the server destroys the stored ciphertext after the first successful access. A link that has been opened cannot be opened again.
Casual inspection of stored data
Files stored in .ssz format on disk or in cloud drives are fully encrypted. Opening the file in any standard tool reveals only opaque binary data.
OUT OF SCOPE: Threats the system does not address
Compromise of the recipient's device
Once the secret is decrypted and displayed, it is in plaintext on the recipient's screen. If the recipient's device is compromised, the decrypted content is exposed. No cryptographic system can defend against this.
Shoulder surfing and screen capture
Share a Secret does not prevent the recipient from screenshotting, photographing, or otherwise copying the revealed content.
Weak or reused passphrases
The security of any encrypted secret is bounded by the strength of the passphrase. Starkive provides a strong auto-generated passphrase; user-defined passphrases vary in quality.
Passphrase channel compromise
If the channel used to transmit the passphrase (e.g., SMS, a second email) is itself compromised, an attacker who intercepts both the link and the passphrase can decrypt the secret.
Sender device compromise
Encryption happens on the sender's device. If the sender's machine is compromised at the time of encryption, the plaintext may be exposed before or during the encryption step.
Share a Secret uses AES-256, the Advanced Encryption Standard with a 256-bit key. AES-256 is the encryption standard adopted by the U.S. National Security Agency for top-secret information and is widely regarded as the strongest symmetric cipher in practical use.
Encryption is performed entirely on the sender's device before any data leaves it. The Starkive application or browser interface handles this locally. What is transmitted to Starkive servers, when the web-link delivery method is used, is ciphertext only: a block of data that is mathematically indistinguishable from random noise without the correct passphrase.
The passphrase is never transmitted to Starkive in any form. It is entered by the sender, used locally to derive an encryption key, and then discarded. When the recipient enters the passphrase on the recipient page, the same derivation is performed locally in the recipient's browser. The Starkive server is never involved in the key derivation step.
The zero-knowledge property
Because the server only ever receives ciphertext, and the passphrase never leaves the endpoints, Starkive operates on a zero-knowledge basis with respect to secret content. A Starkive employee with full database access cannot read any secret stored on the platform. A court order compelling Starkive to produce secret contents would yield only encrypted data, unreadable without the passphrase held only by the sender.
For secrets delivered as local files (.ssz format), no network transmission of any kind occurs. The encrypted container is created entirely offline and transferred by whatever physical or digital channel the sender chooses. The encryption model is identical; the delivery path is entirely under the sender's control.
When using the auto-generated passphrase, Starkive selects four words at random from the EFF Large Wordlist, a curated list of 7,776 common English words developed by the Electronic Frontier Foundation specifically for use in high-entropy passphrases. A four-word selection from this list produces approximately 51 bits of entropy.
For context: 51 bits of entropy means an attacker attempting 1 trillion guesses per second would need on average over 10 days to brute-force the passphrase, and that assumes they already have access to the ciphertext. The Starkive server does not allow unlimited decryption attempts, further limiting brute-force viability.
The four-word format is also designed for human usability. A passphrase like orbit-maple-fence-cloud can be read aloud, typed without error, and communicated by phone, making the out-of-band passphrase delivery step practical.
Users may substitute their own passphrase. Starkive does not enforce passphrase complexity requirements, but the security of the resulting secret is proportional to passphrase strength. For high-value secrets, the auto-generated passphrase is strongly recommended.
Share a Secret supports two fundamentally different delivery paths. Their security properties differ in important ways.
Method A: Web Link (Create locally, share to web)
Method B: Local File (.ssz container)
Both delivery methods use a common internal file format: the Starkive Secure Container, identified by the .ssz extension. This is a proprietary binary format developed by DePalo Consulting LLC.
The container includes a fixed-length header followed by an encrypted payload. The header contains: a format identifier, a version indicator, a unique cryptographic token that identifies the secret (used for open-tracking in web-link mode), an integrity hash of the payload, and the payload length. None of these header fields reveal the content of the secret or the passphrase.
The integrity hash is a SHA-256 digest of the encrypted payload. This provides tamper detection: if the encrypted payload is modified in any way after creation, even by a single byte, the integrity check fails and the file is rejected before decryption is attempted. This protects against malicious modification of secrets in transit and provides assurance that what the recipient decrypts is exactly what the sender encrypted.
The encrypted payload is self-describing with respect to the encryption method: a recipient application can determine from the payload structure alone what cipher was used, without requiring that information to be stored in plaintext in the header.
When a web-link secret is opened, Starkive records that the token was accessed. The sender can see whether their secret was opened and when. This is the only information recorded: the access event and its timestamp.
Starkive does not record the IP address of the recipient. This is a deliberate design decision and a committed privacy guarantee, consistent with Starkive's terms of service. The recipient's identity, location, device, and browser are not logged. The open notification tells the sender their secret was accessed, nothing more.
For secrets delivered as local files (.ssz), no open tracking occurs. The file is decrypted on the recipient's device with no network communication of any kind. The sender has no visibility into whether or when the file was opened.
The following table summarizes what each party in the system can and cannot access.
Use separate channels for the link and passphrase
Send the share link by email, then the passphrase by SMS or phone. An attacker who intercepts only one cannot decrypt the secret.
Use the auto-generated passphrase for high-value secrets
Four EFF words provide strong entropy and are easy to communicate verbally. User-defined passphrases may be weaker.
Prefer local .ssz delivery for classified or legally sensitive content
The local file method involves no third-party infrastructure. Appropriate for medical records, legal documents, and regulated data.
Treat the passphrase itself as a secret
If the channel you use to send the passphrase is unencrypted, the passphrase is exposed. Use a channel appropriate to the sensitivity of the content.
Verify the open notification
For web-link delivery, you will receive a notification when the secret is first opened. If you receive this notification before informing the intended recipient, assume the link was intercepted and rotate the underlying credential immediately.
Share a Secret is a product of Starkive, developed and maintained by DePalo Consulting LLC. This whitepaper is published to support informed trust decisions by users and organizations considering the product for sensitive use cases.
This document will be updated as the product evolves. The version number and date at the top of the document identify the release this description applies to.
Security questions, vulnerability reports, and feedback on this document may be directed to [email protected].
Ready to share a secret securely?
Share a Secret is built into Starkive, free for all users. No subscription required.