(This is a technical deep dive into the cryptography behind Ennote's enterprise architecture. You can read the original full-length post on our engineering blog.)
When evaluating an enterprise secrets manager, the fundamental security question is not just how data is encrypted, but where and for how long the plaintext keys exist. As "The Identity-Driven Secret Manager", Ennote answers this by bridging the gap between infrastructure and identity.
Whether you are a developer logging into our clean, lightning-fast Web UI, a script utilizing our CLI, or a native Kubernetes agent, the cryptographic process is exactly the same. We deliver secure team sharing, enforced SSO, and a sub-1-second sync to infrastructure with zero code changes required and absolute Zero Persistence. To achieve this without compromising security, Ennote employs a verifiable Transient Envelope Encryption model. We do not claim "magic"; we rely on transparent, peer-reviewed cryptographic primitives. Here is exactly how Ennote works, what we use, and why.
1. Zero Persistence vs. Zero Trust (Why We Reject Buzzwords)
Many platforms market themselves as "Zero Trust" (implying strict End-to-End Encryption where the server infrastructure knows absolutely nothing and cannot mediate access). We do not make this claim, because true Zero Trust fundamentally breaks enterprise secret management workflows.
- The Flaw of Zero Trust in Secret Sharing: In a mathematically strict Zero Trust (E2EE) model, there is no centralized authority. If Developer A creates a database password and the company later hires Developer B, the server cannot grant Developer B access. Developer A must manually come online, decrypt the payload locally, and re-encrypt it specifically with Developer B's public key. This approach destroys automated onboarding, makes central Role-Based Access Control (RBAC) impossible, and turns machine-to-machine syncing into a highly fragile, operational nightmare.
- The Ennote Reality - Zero Persistence: Enterprise organizations require centralized governance. We built Ennote to provide seamless onboarding via built-in SSO (Google/Microsoft), full Role-Based Access Control (RBAC), and immutable Audit Logs to track every user action, creating a complete chain of custody for your data. To enable this secure team sharing, the Ennote internal KMS does mediate the cryptographic handshake to securely route access. However, plaintext keys exist only in volatile memory (RAM) for the duration of a cryptographic operation (milliseconds). At no point are plaintext DEKs written to disk, logs, databases, or persistent storage.
We reject the "Zero Trust" buzzword because we prioritize workable, highly-governed enterprise security. We guarantee Zero Persistence.
2. The Foundation: Hybrid Cryptography & Envelope Encryption
To achieve this Zero Persistence safely, we utilize Hybrid Cryptography via Envelope Encryption - the practice of locking a fast symmetric key inside of a highly secure asymmetric key.
In cryptography, there are two primary methods for securing data:
- Symmetric Cryptography: Uses a single, shared key to both encrypt and decrypt data. It is highly efficient and capable of encrypting large payloads at lightning speed. However, it suffers from a distribution flaw: securely transmitting that single key over a network to the recipient creates a massive vulnerability.
- Asymmetric Cryptography (Public-Key): Uses a mathematically linked pair of keys - a Public Key (to encrypt) and a Private Key (kept secretly by the owner to decrypt). This solves the distribution problem entirely, but asymmetric math is computationally heavy and far too slow to encrypt large payloads efficiently.
The Hybrid Approach: Ennote combines both methods. We use the blazing speed of symmetric cryptography to encrypt your actual secrets, and the highly secure, identity-verified nature of asymmetric cryptography to protect and distribute the symmetric key itself.
3. The Root of Trust & Organization-Level Governance
Ennote’s architecture begins with absolute hardware security. The master seeds for our Internal KMS are protected by Cloud HSMs (AWS KMS / Google Cloud KMS) featuring FIPS 140-2 Level 3 validation. This establishes an unhackable root of trust.
From this root, Ennote generates Post-Quantum asymmetric keys using CRYSTALS-Kyber (Kyber-1024), a NIST Post-Quantum standard that protects Data Encryption Keys (DEKs) against "harvest-now-decrypt-later" attacks.
- Crucially, these Kyber keys are established at the Organization level.
- Access to individual resources within your organization is not managed by blindly decrypting the entire vault. Instead, Ennote utilizes Full Role-Based Access Control (RBAC) and immutable Audit Logs to provide granular access control to each individual resource.
4. The Lifecycle of a Secret: High-Speed Payload Protection
When an engineer (via Web UI/CLI) or automated agent creates a secret, the platform executes the following flow:
- Local Generation: The client generates a random 256-bit Data Encryption Key (DEK) locally in volatile memory (RAM).
- Symmetric Payload Encryption: The data payload is encrypted with this DEK using Client-Side AES-256-GCM, ensuring authenticated encryption.
- Asymmetric Encapsulation: The DEK is then encapsulated (enveloped) using the Organization-level KMS Public Key (Kyber) into a secure Key Capsule.
- Blind Storage: We store the encrypted payload alongside the encapsulated DEK. The DEK is completely unreadable to the storage layer, and payloads remain entirely opaque to Ennote.
5. Identity Verification: Why We Use X25519 Over RSA
To securely transmit secrets to your developers or the lightweight Ennote Kubernetes Smart Agent, we must mathematically verify identity. Every client generates an ephemeral Curve25519 (ECC X25519) key pair for Elliptic-Curve Diffie-Hellman (ECDH) key agreement. Private keys never leave the device.
Why not use legacy RSA? Legacy RSA requires massive 2048-bit or 4096-bit keys that are computationally expensive and slow to generate on the fly. X25519 (Elliptic Curve Cryptography) delivers equivalent or greater security with a fraction of the key size (256 bits). Because X25519 keys are incredibly fast to generate and require minimal bandwidth, they perfectly enable the Ennote Agent to maintain its outbound-only gRPC stream for real-time, sub-1-second updates without exhausting cluster resources.
6. Ultimate Enterprise Control: BYOK & Transient Re-Wrapping
For enterprise customers who require absolute cryptographic sovereignty, Ennote offers Bring Your Own Key (BYOK) Support. It is strictly within this BYOK workflow that our transient "re-wrapping" operation occurs.
When an organization enables BYOK, they connect their own Google or AWS KMS (which natively supports asymmetric encryption) to envelope the Ennote Internal KMS keys.
- During an access request under BYOK, the DEK is briefly decapsulated inside the secure KMS enclave in volatile memory (RAM).
- The server immediately performs ECDH with the Client's Public Key, wraps the DEK using the customer's BYOK control logic and derived session key, and instantly flushes memory.
Because the customer owns the ultimate Key Encryption Key via their AWS/GCP KMS, they have complete control over the encryption of the DEK. If a breach is suspected, the customer can instantly revoke access at their own cloud provider level, instantly severing Ennote's ability to re-wrap the DEKs and rendering the vault cryptographically sealed.
7. The Zero-Persistence Guarantee & Confidential Computing
Through this precise combination of Client-Side AES-256-GCM, Organization-level Kyber-1024 encapsulation, ephemeral X25519 identity verification, and optional BYOK transient re-wrapping, Ennote achieves true Zero-Persistence.
Plaintext keys exist only in volatile memory (RAM) for the duration of a cryptographic operation - measured in milliseconds. At no point are plaintext DEKs written to disk, logs, databases, or persistent storage.
Confidential Computing Protection: To entirely eliminate the risk of volatile memory extraction during the transient re-wrapping phase, our KMS enclaves utilize Confidential Computing. This hardware-based isolation encrypts the data while it is in-use within RAM, completely preventing memory dumps or hypervisor-level inspection by any party - including malicious actors, host OS administrators, or our own cloud infrastructure providers. Physical theft of our disks yields absolutely no data.
8. Native Kubernetes Integration & Auto-Rollout
Ennote is designed to replace unencrypted YAMLs and eliminate the need for developers to learn new SDKs. This is powered by our proprietary Kubernetes Smart Agent, deployed directly via Helm.
The lightweight agent establishes an outbound-only gRPC stream - requiring no inbound ports or open firewall rules - to sync secrets directly to Native Kubernetes Secrets in under 1 second. Applications consume these secrets securely via standard envFrom variables with zero code changes required. Furthermore, by adding the restart annotation, Ennote enables Auto-Rollout: when secrets are updated in the Ennote dashboard, the agent automatically rotates the pods depending on those secrets, ensuring immediate and seamless consistency across your entire cluster.
9. Executive Q&A
Q: If you are faster than HashiCorp Vault, and you aren't strict Zero Trust, what security checks are you skipping?
A: None. We are faster because we engineered the bottleneck out of the architecture. Instead of relying on heavy, centralized decryption pipelines, we distribute the workload using highly efficient X25519 Elliptic Curve cryptography and Client-Side AES-256. Ennote doesn't skip security; we modernized the cryptography to match the sub-second speed of modern Kubernetes.
Q: Can a malicious insider at Ennote dump the RAM and steal our keys during the transient re-wrapping?
A: No. Ennote engineers have zero access to customer data keys, and all administrative actions require MFA and are heavily logged. Furthermore, the re-wrapping occurs inside a secure KMS enclave protected by Confidential Computing. Because the memory itself is hardware-encrypted while in use, RAM dumping is mathematically impossible.
Q: If you don't use strict "Zero Trust," how do I guarantee sovereignty over my data?
A: By deploying our BYOK integration. This connects your own AWS or GCP KMS directly to our enclave, giving you the ultimate hardware kill-switch. You maintain total cryptographic sovereignty; Ennote merely facilitates the sub-second routing and seamless RBAC.
Ready to Upgrade Your Secret Management?
Stop compromising between security and developer velocity. Get started with Ennote today to see our Zero-Persistence architecture in action, or book a demo with our engineering team to learn how we can secure your infrastructure.
