Security & responsible disclosure

01Our approach

Most security pages describe how a company protects the data it holds. Secoryx's starting position is to hold as little as possible, so there's less for an attacker — or for us — to ever mishandle. Where we can't eliminate a piece of data, we scope what it can do: an on-device ID is only a routing address, a relay only moves bytes it can't read, and a push notification never carries plaintext.

That said, "we designed it to be safe" is not the same as "it has been proven safe." We publish this policy because we expect people to check our work, and we'd rather hear about a flaw from a researcher than read about it somewhere else first.

02Architecture summary

The full technical breakdown lives on the Technical section of the homepage. In short:

• Key exchange: X25519 (Curve25519 ECDH), generated on-device and never sent to or stored on a server.
• Message encryption: AES-256-GCM, authenticated, with a fresh nonce per message.
• Identity: no phone number, email, or account tied to your device.

If you're reviewing our cryptography specifically, we're interested in issues with key generation, nonce reuse, forward secrecy, or any deviation between what's documented here and what the app actually does.

03Reporting a vulnerability

If you believe you've found a security issue in Secoryx — the app, our infrastructure, or this website — please report it privately before disclosing it publicly.

If you need to share sensitive proof-of-concept material, ask us for a secure channel in your initial email rather than attaching it directly.

04Scope

The following are in scope for reports:

• The Secoryx Android application (encryption, key handling, storage, notification handling).
• The relay/back-end infrastructure that carries ciphertext between devices.
• This website (secoryx.app) and its associated infrastructure.

05Out of scope

• Attacks that require physical access to an already-unlocked device.
• Social engineering directed at Secoryx team members or users.
• Denial-of-service testing carried out against our production relay — please describe the theoretical issue instead of running it live.
• Issues in third-party dependencies with no demonstrated Secoryx-specific impact (report these upstream instead).
• Findings from automated scanners without a validated, working proof of concept.

06What we ask of researchers

• Give us a reasonable window to investigate and remediate before any public disclosure — we aim for 90 days, and we'll communicate if we need more time.
• Avoid accessing, modifying, or deleting data that isn't yours during testing.
• Don't run tests that could degrade the relay service for other users.
• Make a good-faith effort not to access message content that isn't yours, even if a bug makes it technically possible.

07Safe harbor

We will not pursue legal action against researchers who make a good-faith effort to comply with this policy, report issues privately, and avoid privacy violations, data destruction, or service disruption while investigating. If a third party initiates action related to research conducted under this policy, we will take reasonable steps to make clear that your activity was authorized.

08Recognition

Secoryx doesn't currently run a paid bug bounty program. Verified reports that lead to a fix are, with the reporter's permission, credited on this page. If that changes, this section will be updated first.

09Contact

For anything covered on this page, or if you're unsure whether something qualifies as a security report: