The problem
Encryption becomes a product problem as soon as somebody has to use it. An application needs a way to create a secret, grant access, protect a file and make that file usable again. Those steps involve identity, permissions, storage and recovery as well as cryptography. A strong algorithm is one part of that system.
CIFER brings these responsibilities into a defined workflow. Its developer infrastructure exposes encryption through a software development kit (SDK) and a Blackbox service, while its consumer-facing product applies protection to private files. The engineering objective is to make the security model understandable at both levels: for the developer integrating a capability and for the person depending on it.
Mickael’s contribution
Mickael’s work on CIFER connects security architecture and product building. That means thinking through how distributed secret custody becomes an application capability, how a developer invokes it and how the resulting workflow can be used in a real product.
The common thread is translating cryptographic infrastructure into usable operations. An integration should make it clear whose secret is involved, who is authorized to use it and where processing occurs. This case study focuses on those public design principles, alongside the interfaces developers can inspect today.
Inside the architecture
The public SDK describes a secret as an ML-KEM-768 key pair. Its public key is available through the InterPlanetary File System (IPFS); private-key material is split across an enclave cluster using threshold cryptography. This separates public encryption material from distributed private-key custody.
In the documented Web3 flow, ownership and delegation determine who may decrypt. The Blackbox receives requests, checks authorization and performs the encryption or decryption operation. The documented API path sends plaintext to the Blackbox for encryption and returns plaintext after authorized decryption. This processing service is therefore part of the trust boundary.
The encryption scheme combines the Module-Lattice-Based Key-Encapsulation Mechanism, ML-KEM-768, with AES-256-GCM, an authenticated symmetric encryption mode. Key encapsulation and data encryption have different jobs. Keeping that distinction visible helps a technical team understand which properties belong to which part of the system.
Engineering decisions that matter
Separate permission from possession. Storing encrypted bytes and being allowed to decrypt them are different capabilities. Explicit authorization creates a place to reason about owner access, delegated access and application behavior when that access changes.
Describe the processing boundary. A gateway can make integrations simpler, but its responsibilities must remain visible. Teams assessing a deployment need to account for the client, transport, processing service and data returned to the authorized caller.
Keep cryptographic claims specific. Post-quantum key encapsulation protects a particular part of the encryption design. It does not automatically make wallet signatures, authentication or the entire application post-quantum. A useful architecture explains the relationship between these layers.
From primitives to products
Private files are a direct application: the user wants to protect information and make it accessible to an intended recipient. A developer needs a stable set of operations that can be connected to a larger document, account or collaboration workflow.
AI agents introduce another integration surface. Mickael has publicly described a CIFER Model Context Protocol (MCP) server that gives agents tools for encrypted files, credentials and persistent context. This connects encryption to the way an agent already invokes capabilities. The application still needs to decide when access is appropriate and how decrypted information is handled after a tool returns it.
Current maturity & further reading
CIFER has public product and developer surfaces. The SDK documentation identifies the SDK as beta, so an integration should pin its version and validate the exact interface it uses. Product capabilities and SDK release status should be assessed separately.
The references below expose the concepts, processing flow and product experience behind this case study. They offer a practical starting point for an architecture conversation about your data, users and operational environment.