This is the single reference for how Sentinel Obscura is designed, encrypted, operated and disclosed. Everything here is stated plainly — no absolute claims, only what we actually do.
Last reviewed July 2026
The way software is designed decides how secure it can ever be. These are the principles Sentinel is built on — the rules we apply before a single feature is written.
Security by design
Security is a design constraint, not a later addition. Each feature is assessed for its impact on confidentiality and integrity before it ships.
Privacy by design
The private state is the default. We start from collecting nothing and add data only where a feature genuinely cannot work without it.
Zero trust
No component is trusted implicitly. The relay is treated as an untrusted network: it only ever handles ciphertext it cannot read.
Least privilege
Every service, process and person is granted the minimum access required to do its job — and nothing more. Access is scoped and reviewed.
Minimal attack surface
Fewer network-facing features, fewer dependencies and less retained data mean fewer places for something to go wrong.
Open standards
We build on well-reviewed, public cryptographic standards rather than proprietary secrecy. Security should not depend on hidden design.
Sentinel protects conversations with modern, well-reviewed cryptography. We describe primitives by their guarantees; exact algorithms and versions are documented with each release.
End-to-end encryption
Messages are encrypted on your device and decrypted only on your recipient’s. The relay carries ciphertext it cannot read.
Forward secrecy
Session keys evolve as a conversation continues. Compromising one key does not expose the messages that came before it.
Key exchange
Peers establish shared secrets through an asymmetric key exchange. Public keys are exchanged directly between devices.
Session keys
Traffic is protected with per-session keys derived from the exchange, so long-term identity keys are never used to encrypt messages directly.
Local key storage
Private keys are stored on the device that generated them and are never transmitted to Sentinel’s servers.
Key rotation
Message keys are rotated as conversations progress, limiting how much traffic any single key ever protects.
Cryptographic randomness
Keys are generated from the operating system’s cryptographically secure random source — never from predictable or home-grown generators.
Message authentication
Every message carries an authentication tag, so tampered or forged ciphertext is rejected rather than shown to you.
Post-quantum readiness
PlannedPost-quantum key exchange is on our research roadmap. We are tracking standardized post-quantum primitives and plan a hybrid approach that preserves today’s guarantees while adding resistance to future quantum attacks. This is a planned direction, not a current claim.
Specific algorithm details and versions are documented with each release, so the description always matches the software you actually run.
A message passes through a small number of well-defined layers. Select any layer to see what it does — and, just as importantly, what it never sees.
Device
Everything begins and ends on your device. Plaintext, identity keys and message keys exist here and nowhere else. If it isn’t on your device, it isn’t recoverable.
Honest security means being precise about the edges. Sentinel protects the channel between people — it cannot protect a device that is already turned against you.
Inside the channel
- Network interception of message contents
- Metadata reduction across the relay
- Device separation through isolated Personas
- Encrypted individual and group conversations
Beyond the channel
- A device that is already compromised
- Screenshots or screen recording of your chats
- Malware running on the endpoint
- Mistakes made by the people in a conversation
A threat model is only useful if it names the attacker. These are the adversaries Sentinel is explicitly designed to withstand, and how each is addressed.
Network eavesdropper
Anyone observing the network path sees only ciphertext. Message contents and private keys never travel the wire in the clear.
Hostile or seized relay
The relay is assumed untrusted. It routes ciphertext it cannot decrypt and holds minimal metadata, so compromising or seizing it does not expose conversations.
Curious operator or insider
No key exists on our side that could decrypt your messages. Full infrastructure access still does not grant the ability to read them.
Tampering in transit
Authenticated encryption means altered or forged ciphertext is rejected rather than displayed. Modified messages fail their integrity check.
Later key compromise
Forward secrecy and key rotation limit exposure: a key recovered at one moment does not decrypt the messages that came before it.
Trust assumptions
- Your device and its operating system are not already compromised.
- The Sentinel build you run is the genuine, unmodified application.
- You and the people you talk to keep your devices under your own control.
- The operating system’s cryptographic random source is sound.
- The party you exchanged keys with is the person you intend to reach.
Security boundaries
- Plaintext and private keys never leave your device.
- The relay boundary carries only ciphertext and minimal routing data.
- Each Persona is a separate cryptographic identity; one cannot reach another.
- Data at rest is encrypted under keys the device holds.
- Trust ends at the endpoint — a compromised device is outside the boundary.
Data you never hand over cannot be leaked, subpoenaed or sold. Sentinel is built to know as little about you as a working messenger allows.
The minimum to function
- The license tied to your purchase, so the app can be activated
- The minimal routing data the relay needs to deliver a message, kept only as long as needed
- Anything you deliberately send us, such as a support request
What we refuse to hold
- The contents of your messages
- Your contacts or phone address book
- A phone number or SIM identity
- Advertising or behavioral profiles
- Third-party trackers or analytics SDKs
- Your private keys
End-to-end encryption
Messages are encrypted on your device and decrypted only on your recipient’s. The relay carries ciphertext it cannot read.
Local identity generation
Your identity keys are generated on your device the first time you open Sentinel. They are never created for you on a server.
Personas are isolated
Each Persona is a separate identity with its own keys and contacts. One Persona reveals nothing about another.
No phone number required
There is no SMS step and no number to verify. Nothing ties an account to a SIM, a carrier, or a real-world line.
No advertising profile
Sentinel builds no behavioral profile and runs no ad or analytics SDKs. There is no interest graph to sell.
No address book upload
Your contacts stay on your device. Sentinel never uploads, hashes, or scans your phone’s address book to find people.
The relay and supporting services handle ciphertext, but they still deserve serious operational security. These are the controls that protect the infrastructure we run.
Transport encryption
All connections to our services use current TLS with strong cipher suites, so traffic is protected in transit even before end-to-end encryption applies.
Server hardening
Servers run a minimal footprint, receive security updates promptly and expose only the ports and services strictly required to operate.
Secrets management
Credentials and signing material are held in managed secret stores, scoped to the services that need them and never committed to source control.
Access control
Administrative access is limited, individually attributed and protected with strong, multi-factor authentication. Access is granted by role, not by default.
Network isolation
Internal systems are segmented so that a fault in one component does not open a path to the rest of the infrastructure.
Monitoring & logging
Operational events are monitored for anomalies. Logs are designed to aid reliability and incident response without retaining message content.
Incident response
We maintain a defined process for triaging, containing and communicating security incidents, with named owners and clear escalation paths.
DDoS protection
Edge protection and rate limiting absorb volumetric and application-layer floods so availability holds up under pressure.
Backup & recovery
Operational data required to run the service is backed up and encrypted, with restoration tested so recovery is a practiced routine, not a hope.
Secure software is the result of a disciplined process, not a final review. These are the engineering practices that govern how Sentinel is written and released.
Code reviews
Changes are reviewed by another engineer before they merge, with security-relevant code receiving closer scrutiny.
Dependency audits
Third-party dependencies are kept deliberately few, pinned, and monitored for known vulnerabilities so supply-chain risk stays visible.
Static analysis
Automated static analysis runs against the codebase to catch entire classes of defects before code ever runs.
Dynamic analysis
Running builds are exercised and tested to surface issues that only appear at runtime, complementing static checks.
Secret scanning
Commits and history are scanned for credentials and keys, so secrets never reach a repository unnoticed.
CI/CD security
Builds run in controlled pipelines with scoped permissions, so the path from source to release is consistent and auditable.
Signed releases
Release artifacts are cryptographically signed so you can verify that a build genuinely came from us and was not altered.
Responsible release process
Security fixes follow a defined release path, and each release is documented so you know what changed and why.
Reproducible builds
Reproducible builds — letting anyone rebuild our binaries from source and confirm they match — are a planned goal, not a current claim.
A live, honest snapshot of our security posture. Placeholder values are shown where a milestone has not yet occurred — we would rather state that plainly than imply otherwise.
Sentinel Obscura is currently in active development and has not launched publicly. This Trust Center documents the security architecture, cryptography and processes ahead of public release; the status above will be updated as those milestones are reached.
Independent verification is how trust is earned rather than asserted. Below is the real state of each review. Nothing is marked complete until it genuinely is.
Internal reviews
Security-relevant changes are reviewed internally as part of our standard development process.
Independent audit
A third-party audit of the client and protocol is planned. The results will be published here.
Penetration testing
External penetration testing of our services is planned ahead of production launch.
Mobile security review
A dedicated review of the mobile client against the OWASP MASVS is a future goal.
Cryptography review
An independent review of the cryptographic design and implementation is planned.
Trust is easy to assert and hard to earn. As Sentinel matures, this is where we will publish the record — openly, and on a predictable schedule.
Transparency reports
Periodic summaries of any legal requests received and how we responded — including reporting when there is nothing to report.
Security advisories
Clear notices for vulnerabilities that affect you, with severity, impact and the versions that contain the fix.
Incident reports
Honest post-incident write-ups covering what happened, what was affected, and what we changed as a result.
Release security notes
Security-relevant changes called out with each release, so upgrading is an informed decision.
Cryptographic change log
A record of the primitives and versions in use, updated whenever the cryptography changes.
Product changelog
A public history of what changed across versions, kept in plain language.
This is where security advisories, release security notes and bulletins will be published. When a fix ships for an issue that affects you, the details will appear here.
No advisories published yet
There are no published advisories at this time. When one is issued it will appear here with its severity, the affected versions and the release that resolves it — including a CVE reference where applicable.
Found something? Tell us.
If you are a security researcher and believe you have found a vulnerability, we want to hear from you. Report it privately first and give us reasonable time to investigate and fix before any public disclosure. We do not pursue legal action against good-faith research conducted under these terms.
Once published, the fingerprint and a downloadable key will appear here. Until then, contact the security team directly and we will coordinate secure exchange.
Reporting guidelines
- Report privately to our security address before any public disclosure.
- Include clear steps to reproduce, affected versions and platforms, and the impact.
- Give us reasonable time to investigate and ship a fix before disclosing.
- Only test against accounts and devices that belong to you.
- Do not access, modify or exfiltrate data that is not yours.
- Avoid automated scanning that degrades the service for other people.
Scope
- Sentinel desktop applications (Windows, macOS, Linux)
- The relay and account / identity services
- The cryptographic protocol implementation
- This website and its checkout and licensing flow
- Social engineering of our staff or of users
- Physical attacks against facilities or hardware
- Volumetric denial-of-service flooding
- Automated tool output without a demonstrated impact
- Vulnerabilities in third-party services we do not operate
Expected response
We acknowledge every good-faith report within three business days, then triage by severity and keep you updated until the issue is resolved.
A trust center should show direction, not just a snapshot. This is an honest view of what is done, what is underway and what is planned.
End-to-end encryption by default
CompletedEvery conversation is end-to-end encrypted out of the box, with no setting to turn it off.
On-device identity & keys
CompletedIdentity and message keys are generated and kept on your device, never on a server.
Registration without a phone number
CompletedAccounts require no SMS and no number, so nothing ties an identity to a SIM.
Independent security audit
In progressWe are preparing for a third-party review of the client and protocol, with results to be published.
Public security whitepaper
In progressA detailed whitepaper on the architecture and cryptography is being written for release here.
Verifiable signed releases
In progressSigned release artifacts with published verification instructions are being rolled out.
Public transparency reports
PlannedRegular, scheduled transparency reporting — including when there is nothing to report.
Coordinated bug bounty
PlannedA structured bug bounty program to reward good-faith security research.
Reproducible builds
PlannedLetting anyone rebuild our binaries from source and confirm they match what we ship.
Post-quantum key exchange
PlannedEvaluating a hybrid post-quantum key exchange to stay ahead of future threats.
We hold ourselves to established security and privacy frameworks. The labels below describe how each one guides our engineering. They are design and process statements — never a claim of certification.
GDPR
In practiceDesigned with the GDPR’s data-minimization principles in mind for the limited data we process. This describes our design approach, not a certification.
OWASP ASVS
In practiceFollowing the OWASP Application Security Verification Standard as a best-practice benchmark for application security.
OWASP MASVS
In practiceFollowing OWASP MASVS guidance for hardening the client application.
NIST CSF
In practiceAligned with the functions of the NIST Cybersecurity Framework across our security program.
ISO 27001
Future goalFuture goal: aligning our information-security management with ISO/IEC 27001. Not certified.
SOC 2
Future goalFuture goal: working toward SOC 2 readiness. Not audited or certified.
These statements describe the standards and practices that guide our engineering. They are not certifications. Any certification will appear here only after it has been independently issued and verified.
So that trust rests on public standards and mathematics rather than on trusting our servers. Keys are generated and held on devices, the relay only ever handles ciphertext, and forward secrecy limits the damage of any single key compromise. It is an end-to-end design because that is the only model where the operator genuinely cannot read your messages.
As each document is finalized it will be published here for you to read, archive and verify. We would rather ship these right than early.
Security whitepaper
Architecture whitepaper
Cryptography overview
Privacy overview
Security policy (security.txt)
PGP public key
Our security team reads every message. Whether you are reporting an issue or evaluating Sentinel for your organization, reach out and we will get back to you.