Purpose
Define how cryptography is used and how encryption keys are managed across the Perfect Wiki service to protect data confidentiality and integrity.
Scope
Applies to all cryptographic operations on Perfect Wiki systems, including data-in-transit, data-at-rest, application-layer secret encryption, and authentication tokens.
Policy — algorithms and protocols
- Data in transit: TLS 1.2 minimum, TLS 1.3 preferred, with cipher suites supporting perfect forward secrecy. Insecure protocols (SSLv2/3, TLS 1.0/1.1) are disabled at the edge.
- Data at rest: AES-256 full-disk encryption is applied by Google Cloud to all storage holding customer data (Firestore, Cloud Storage, Compute Engine disks).
- Application-layer secrets: Integration tokens and other sensitive values are encrypted with AES-256-GCM using a 32-byte key derived from the service's master encryption secret, with a unique 16-byte IV per ciphertext and authenticated tags verified on decrypt.
- Random material: Generated using cryptographically secure random number generators (Node.js crypto.randomBytes / OpenSSL).
- Hashing: SHA-256 minimum. Legacy algorithms (MD5, SHA-1) are not used for any security purpose.
Policy — key management
- The master application encryption key is provisioned via environment variable, never committed to source control, and accessible only to production runtime and Authorized Personnel.
- Google Cloud manages TLS certificates and at-rest disk encryption keys; rotation is performed by Google per their schedule.
- API tokens generated for customers are 32-byte cryptographically random values. Tokens are stored hashed and can be regenerated by the customer at any time, which immediately invalidates the previous token.
- If a key compromise is suspected, the affected key is rotated immediately and the incident is handled per the Incident Response Plan.
- Encryption keys are destroyed by removing all copies from production and confirming Google Cloud's media-sanitization controls when underlying media is decommissioned.
Customer-managed keys
Customer-managed encryption keys (BYOK) are not currently offered. Enterprise customers requiring CMK should contact us to discuss.
Roles & responsibilities
- CEO/CTO: Owns this policy, approves cryptographic changes, manages the master encryption key.
Review cadence
Reviewed annually and after any cryptography-related security event.