Trust Center All docs PDF
SNT ChatPrivate messaging

Public document · Trust Center

Security Whitepaper

Architecture, cryptography, threat model, and transparency for SNT Chat messaging · Android beta and E2EE roadmap.

Version
1.0.0
Date
August 6, 2026
Classification
Public · sntchat.com
© 2026 SNT Chat · Your messages. Your keys. Your @. · support@sntchat.com

Executive summary

SNT Chat is a private messaging beta (Android V1) built around @username, a public Trust Center, and an end-to-end encryption roadmap aligned with public standards (Signal Protocol, AES-256-GCM, X25519).

This whitepaper describes the intended implementation and honest product status for version 1.0.0. Missing items (full E2EE on every flow, iOS App Store, external audit) are listed explicitly.

Pillar Beta V1 / roadmap
Messaging Chats, friend requests, @username, Security Center
Message encryption Double Ratchet (Signal), progressive rollout
Attachments Client-side encryption before upload
Transport TLS 1.3 (HTTPS)
Identity Cloud authentication + SNT ID
Strong auth TOTP 2FA, passkeys (Android), OAuth
Contact verification Safety numbers, QR scan
Transparency Trust Center, diagrams, service status
GDPR Export, deletion, public policy
App attestation Device integrity checks

1. Introduction and scope

1.1 Service purpose

SNT Chat lets a user:

SNT Chat is not a generic unlimited cloud backup app: the cloud holds account data, chat metadata, and encrypted attachments, not a general-purpose drive.

1.2 Document scope v1.0.0

Included in the target Android beta:

Excluded or in progress (publicly stated):

1.3 Design principles

  1. Zero-knowledge (goal): the backend must not read message content or client-encrypted files.
  2. Defense in depth: TLS, strict cloud access rules, app attestation, short-lived signed URLs.
  3. Transparency: this document, Trust pages, changelog, automated status.
  4. Minimization: collect only metadata required for the service.

2. Threat model

2.1 Considered adversaries

Adversary Capability Mitigation
Malicious operator Cloud DB, object storage, logs access Client encryption, no private keys on server
Network attacker (MITM) HTTPS interception TLS 1.3, OS stacks
Compromised cloud account Cloud rules read UID isolation, no cross-user access
Credential phishing Email / password theft Passkeys, TOTP 2FA
Device malware Memory / key read PIN/biometric lock, E2EE model limits
Contact impersonation Wrong person Safety numbers, QR, Security Center
Unauthorized client (script) API without app App attestation (device integrity, etc.)

2.2 Explicitly out of scope

3. System architecture

3.1 Overview

[Android / iOS device]
    │ Mobile UI · local crypto / chat engines
    │ Message & attachment encryption (progressive E2EE)
    ▼
[Cloud authentication]     identity, OAuth, passkeys
[Cloud database]   conversations, messages, profiles (UID-scoped)
[Backend services]   business logic, invites, GDPR, push
[Encrypted object storage]      encrypted blobs (attachments)
[Push notifications]               generic push (no message body)
[Secure site (HTTPS)]  site · Trust Center · docs · .well-known

3.2 Components

Component Role Plaintext message content?
Mobile app Encryption, UI, sync Yes (on unlocked device)
Cloud authentication Sessions, OAuth No
Cloud database Metadata, envelopes No (per E2EE phase)
Backend services Orchestration, signed URLs, push No
Object storage Encrypted object storage No
Push notifications Alerts No (generic title)

3.3 Regions

4. Message cryptography

4.1 Selected standards

Aligned with SNT Crypto Engine (no non-standard “marketing” algorithms):

Documented post-quantum roadmap: X25519 + ML-KEM-768 hybrid, ML-DSA / SLH-DSA signatures.

4.2 Beta status (transparency)

E2EE rollout is progressive: some phases may carry envelopes or metadata in cleartext on the server during migration. The Trust Center (/trust/visibility) describes what SNT Chat sees today regarding message content.

4.3 Keys and sessions

4.4 What the server never receives

5. Attachments and storage

Attachments follow encrypt on client, then upload:

  1. Local file read;
  2. AES-256-GCM encryption (derived key / envelope per implementation);
  3. Direct upload to object storage via short-lived signed URL;
  4. Metadata (name, size, hash, key reference) in cloud database via backend.

The server never receives: vault password, master key, cleartext file content.

6. Key management and device lock

6.1 Cryptographic identity

6.2 SNT PIN (6 digits)

6.3 Biometrics

7. Authentication and session

7.1 V1 methods

Method V1 status
Email / password Yes
Google Sign-In Yes
Facebook Yes (Android)
GitHub Yes (Android)
Apple Sign-In Platform / store dependent
Passkeys Yes Android
TOTP 2FA Yes

7.2 Cloud session

7.3 Account verification

8. Passkeys (WebAuthn / FIDO2)

8.1 V1 implementation (Android)

8.3 Limits

9. Two-factor authentication (TOTP)

9.1 Standard

9.2 Recovery codes

9.3 Login flow

  1. Primary auth (email, Google, passkey, etc.);
  2. If 2FA enabled: TOTP or recovery code;
  3. Verification on backend before full session.

10. Messaging, sync, and cloud database

10.1 Data model

10.2 Real time

10.3 Attachments

11. Invitations and links

11.1 Referral / invite

12. Cloud infrastructure

12.1 Certified cloud providers

12.2 Encrypted object storage

12.3 CDN / DNS

13. Cloud database access rules

13.1 Principles

13.2 Examples

Collection Client read Client write
users/{uid} Own UID Limited fields
usernames/{name} Controlled Signup transaction
2FA secrets No No

14. Signed URLs (object storage)

14.1 Upload

14.2 Download

15. CDN and transport

15.1 TLS

15.2 Integrity

16. Notifications (push)

16.1 Messaging use

16.2 Privacy

17. Application attestation

17.1 Goal

17.2 Providers

Platform Production
Android Play Integrity
iOS App Attest / Device Check
Web reCAPTCHA v3 (if applicable)

Progressive rollout: Monitoring then Enforced (see project attestation documentation).

18. GDPR: export and deletion

18.1 Export

18.2 Deletion

18.3 Processors

19. Logging and visible data

19.1 What SNT Chat can see

Data Visible on server?
Email, UID, @username, plan Yes
Timestamps, conversation IDs Yes
Message body (E2EE target) No
Decrypted attachment No
PIN / private keys No

19.2 Logs

20. Trust Center and transparency

20.1 Public pages

20.2 Automated status

20.3 Community

21. Responsible disclosure

21.1 Contact

21.2 Scope

22. Known V1 limits

  1. E2EE not universal on all flows;
  2. No published external pentest;
  3. iOS: parity per store timeline;
  4. No full public contractual SLA;
  5. Local malware: outside standard zero-knowledge guarantee.

23. Security roadmap

Item Target
Generalized Double Ratchet Post-beta
App attestation enforced After monitoring
Post-quantum hybrid Crypto engine roadmap
Independent pentest Post-beta
Paid bug bounty Preparation

24. Glossary

Term Definition
E2EE End-to-end encryption: only participants read content
Double Ratchet Signal protocol for forward secrecy
Prekey Pre-published public key to establish a session
Zero-knowledge Server does not hold decryption secrets
TOTP Time-based one-time password
Passkey WebAuthn credential bound to domain / app
App attestation Attestation that the request comes from the official app

25. References

26. Document control

Field Value
Title SNT Chat Security Whitepaper
Version 1.0.0
Date 6 August 2026
Classification Public
Domain sntchat.com
Language English · French edition: same structure

Appendix A · Security FAQ

Q: Can SNT Chat read my messages?
A: See /trust/visibility. The product goal is zero-knowledge on content; exact E2EE deployment status is documented publicly.

Q: What does a push notification contain?
A: A generic label, not the message body in the payload.

Q: How do I verify a contact?
A: Safety number or QR scan in Security Center.

Q: Where to report a vulnerability?
A: /trust/disclosure and security.txt.

Appendix B · Threat scenarios (summary)

B.1 Another user’s account compromised

Impact: metadata, no decryption without victim keys.
Mitigations: 2FA, passkeys, cloud database isolation.

B.2 Object storage leak

Impact: encrypted blobs only.
Mitigations: short signed URLs, client encryption.

B.3 Support social engineering

Procedure: no backdoor, no private key recovery; account deletion on request (GDPR).

Signature éditoriale

Document approuvé pour publication publique par SNT Chat · Security & Privacy.

Contact : support@sntchat.com · Divulgation responsable : sntchat.com/trust/disclosure

SNT Chat Security & Privacy

© 2026 SNT Chat. Tous droits réservés.