Is cruush end-to-end encrypted?
Not in the open beta. cruush uses server-side encryption at rest for sensitive data, with separate server-side keys for different data types and purposes, authenticated encryption to detect tampering, and versioned key derivation. Login sessions use 256-bit random tokens, with only hashed session tokens stored server-side. This lets cruush support matching, visibility controls, account recovery, moderation, and abuse prevention during beta. We plan to evaluate end-to-end encryption after launch.
What data is encrypted?
Sensitive profile and relationship data is encrypted at rest on the server. Messages and photos will also be encrypted at least server-side for the open beta launch. Some operational data needs to remain queryable so cruush can support matching, visibility filters, account state, abuse prevention, and core app functionality.
Can cruush read user data?
During the open beta, the backend can decrypt data when required to operate the app. cruush is not zero-knowledge and does not claim that the server is unable to access user data.
How are passwords stored?
Passwords are never stored directly. They are hashed with scrypt using per-password salts before being stored.
How are login sessions protected?
Login sessions use 256-bit random tokens. The raw session token is sent only as an HttpOnly cookie, and the server stores only a SHA-256 hash of the token.
What happens if the database is exposed?
A database-only exposure should not reveal encrypted sensitive fields without the server-side encryption keys. Some account, operational, or queryable data may still be readable, so encryption is one layer of protection rather than the entire security model.
Do you rotate encryption keys?
Sensitive encrypted records use versioned key derivation so newer records can move to newer key versions while older records remain readable. Searchable blind indexes require a more careful migration plan before rotation because they are used for lookup.
Do you protect against brute force and abuse?
Yes. cruush uses rate limits on login, signup, password reset, messaging, posting, and other sensitive actions to reduce brute-force attempts, spam, and abuse.
Do you protect against unsafe links and XSS?
Yes. cruush validates public HTTPS URLs for user-supplied image fields and rejects unsafe URL patterns such as javascript:, localhost, private-network, and metadata-service URLs. Authentication email links are escaped before being inserted into HTML.
Why not enable E2EE during beta?
E2EE changes product architecture, account recovery, moderation, abuse handling, search, matching, and multi-device behavior. For the open beta, cruush is prioritizing secure server-side encryption, abuse prevention, and reliable product behavior first.