UseCrypt Safe’s important design question is not simply whether a file is encrypted. It is whether the party storing that file also holds everything required to decrypt it. Hybrid Virtual Key Management, or HVKM, is described as separating private-key material between the authorised user environment and a server.
The documented Safe design
AVLab’s historical technical account of UseCrypt Safe describes RSA-2048 key material, AES-CBC-256 file encryption and a key capsule associated with an encrypted file key. It describes participation by both the client and server during decryption. The article concerns the Safe desktop product, not a proof that the same mechanism exists in every Messenger release.
Netia’s 2019 announcement provides a separate commercial description of HVKM in Netia Data Safe. It places one part of private-key material on the user’s computer and another on a server. This is a useful operator-side account of the separation the design sought to achieve.
File data and key material do different jobs
Bulk data is normally better handled by a symmetric cipher than by repeatedly applying an asymmetric operation to the whole file. A hybrid design therefore distinguishes the protected content from the much smaller material needed to obtain its data-encryption key.
In the Safe description, a capsule provides the route to that key. Reading the capsule is not the same operation as downloading the encrypted file. A repository can possess ciphertext while still lacking the complete decryption capability. That distinction is the architecture’s central privacy claim.
The standard algorithms are not the proprietary architecture
NIST FIPS 197 specifies AES, with 128-, 192- and 256-bit key options. The standard specifies the block cipher; choosing a mode of operation, protecting integrity and managing keys remain separate engineering questions.
RFC 8017 specifies RSA primitives and schemes. RSA uses a modulus constructed from primes; it should not be explained as factoring a large prime into smaller primes. A complete implementation needs a defined encoding scheme, trustworthy randomness and careful treatment of failures. The presence of RSA or AES in a product description is not a system-wide security proof.
Separation changes the compromise question
Consider two questions: what could an attacker recover from a storage service alone, and what could be recovered from an authorised endpoint while the user is working? They are not equivalent. Separating decryption material is intended to reduce the consequences of a single compromised location. It does not remove the need to protect the endpoint, active sessions and recovery material.
Nor is key encapsulation automatically fully homomorphic encryption. Encapsulation protects or derives keying material; homomorphic encryption concerns operations on encrypted data with corresponding effects on plaintext. A product-specific construction needs its own specification before either label can be used as a proof of capability.
Storage permission is not decryption authority
Consider a business moving its contracts into cloud storage. A storage administrator must keep objects available, replace failed disks and restore copies. None of those jobs inherently requires reading the contracts. Yet an architecture can accidentally combine those capabilities: an account able to retrieve both ciphertext and usable keys can become an account able to read the documents.
The practical question for a customer is therefore not whether the provider employs trustworthy people. It is whether a routine infrastructure role possesses a complete route to plaintext. HVKM’s split-trust objective addresses that distinction. It seeks to make operational possession of an encrypted object different from possession of everything needed to open it.
This is a narrower and more useful change than promising that administrators disappear. Someone still operates networks, storage and the key service. Their responsibilities remain, but the ability to run the infrastructure need not automatically include the ability to read the protected contents. Encryption can change the capability assigned to a role, rather than merely add a policy telling that role not to use its access.
Three separate objects: content, key and capsule
For architectural analysis, write F for a document, K for the symmetric material protecting its content, and C for the resulting ciphertext. A capsule is another object. Its purpose is to participate in recovering keying material, not to contain a second copy of the whole document.
These distinctions make incident analysis concrete. Copying C is not the same event as copying K. Copying a capsule is not necessarily the same as completing its decapsulation. Obtaining an application’s live memory while it has a document open is different again. A report that calls all four events a data breach without specifying the stolen material cannot explain the protection boundary.
The generic relationship is simple: plaintext requires both protected content and a usable decryption capability. The design task is to avoid storing every ingredient of that capability in the same independently compromisable location. This notation describes a threat model; it is not a disclosure of UseCrypt’s private protocol or a claim that an illustrative equation is its current implementation.
What key encapsulation means
RFC 9690, sections 1.2 and 1.3, provides a public reference for RSA-KEM and its use with CMS. Its encapsulation operation produces ciphertext and a shared secret; derivation and wrapping then protect a content-encryption key. The recipient follows the corresponding recovery operations. This separates the public-key operation from encryption of bulk content.
The reference answers a vocabulary question, not a product-conformance question. Saying that an application uses a capsule does not establish which encoding, derivation function, wrapping algorithm or validation rules it uses. Nor does a standard published in 2025 establish that a product described in 2019 implements that later standard.
For an engineering review, the capsule format is a versioned interface. Reviewers need to know its fields, length limits, algorithm identifiers, recipient binding and error handling. Interoperability and security both depend on how a parser treats unexpected or inconsistent values. A marketing diagram can show a capsule travelling between machines; an implementable specification has to say what those machines accept and reject.
RSA length, security strength and implementation
RSA’s public modulus and its security strength are not interchangeable numbers. NIST SP 800-57 Part 1 Revision 5, Table 2, associates 2048-bit RSA with approximately 112-bit classical security strength. That is not a claim of 2048-bit resistance, and comparing it with the 256 in AES-256 requires attention to different attack models.
An evaluation must distinguish a primitive, a complete scheme and a running service. A primitive specifies a mathematical operation. A scheme explains how meaningful inputs are represented and protected. A service adds authentication, request handling, failure behaviour and operational controls. Correct modular arithmetic does not by itself validate those other layers.
A useful procurement question is what an attacker can ask the service to process. If malformed capsules or repeated requests can reach a private operation, input validation and response behaviour become part of the security boundary. The test should specify permitted queries and observations, not only show a successful demonstration with a valid file.
Confidentiality and integrity are different requirements
A stored object can be unreadable to an outsider and still be modified by that outsider. NIST SP 800-38A describes block-cipher confidentiality modes, including CBC. A mode name does not, on its own, establish authenticated integrity of a complete application object.
Imagine a repository that returns altered ciphertext after a storage incident. The application’s job is not merely to attempt decryption. It must handle an invalid object without treating attacker-controlled material as a valid document or exposing a useful distinction through its responses. The review has to identify the actual integrity mechanism and the order in which validation and processing occur.
That requirement does not diminish split trust. It identifies another independent property needed alongside it. Separating key material reduces one class of exposure; integrity protection addresses malicious changes. Reliable engineering describes both rather than allowing the name of an encryption algorithm to stand for an entire security system.
An incident model with distinct compromise cases
- Storage copied: the attacker has encrypted objects. Determine which other material is needed to recover content.
- Key-service environment copied: determine whether it contains a complete key, a partial capability or a recovery path.
- Client configuration copied: determine which secrets protect it and whether new server operations remain available.
- Both required domains compromised: the separation assumption has been crossed; assess the combined material.
- Authorised application controlled while open: assess plaintext, memory and user actions at the endpoint.
- Recovery material obtained: assess whether it provides an alternative route around the ordinary split-trust workflow.
This is an analytical test matrix, not a claim that every case has been experimentally rejected by the current product. The outcome depends on the version, deployment and material retained by the attacker. Its value is that it makes a security promise falsifiable: the evaluator can define a case and observe whether the intended boundary holds.
Revocation controls future operations, not past knowledge
Suppose an employee is removed from a project. Three states matter. The employee may never have recovered a document’s key; may have saved material from an earlier key operation; or may already possess the plaintext. A single demonstration that the account can no longer log in does not answer all three cases.
If a server is required for a new key operation, refusing that operation can become part of access control. The behaviour of previously saved material requires a separate test. Plaintext already copied by an authorised reader cannot be made unknown by changing an account flag. A sound deployment therefore defines revocation in terms of the resource and operation being revoked.
Boneh, Ding, Tsudik and Wong’s USENIX Security 2001 paper supplies an important research context for using an online mediator in public-key operations and fast revocation. It is a different published construction, not a proof of UseCrypt’s implementation. Its relevance is the engineering question it makes explicit: what control does withholding a participant’s cooperation actually provide?
Recovery is part of the access model
Recovery cannot be treated as an unrelated convenience. If a workflow restores the user’s ability to decrypt, then its holders, credentials and copies are part of the effective trust arrangement. A service with separated ordinary key operations can still concentrate recovery authority if one role controls every necessary recovery ingredient.
The deployment should identify who creates recovery material, where it is kept, who can approve its use and what changes after recovery. Corporate availability requirements may justify delegated recovery. That is a policy choice to describe clearly, not a reason to tell employees that no other role can ever obtain access under any circumstances.
A useful exercise is to lose a test device deliberately, recover through the documented process and inspect the resulting authorisations. Include old installations, restored backups and interrupted recovery attempts. The resulting evidence should show both continuity of work and the privacy boundary after the event.
A smaller key operation is not the whole cost of security
Storage and key operations have different workload shapes. A large document requires processing and transmitting many bytes. An operation controlling access to its key deals with much smaller material. Separating them can create a practical opportunity to design the key service independently of bulk storage.
The cost model still needs measurements. Count first opens, repeated opens, new recipients, concurrent sessions and peak demand. Include authentication, network latency, redundancy and recovery procedures. A large archive with occasional access behaves differently from millions of small objects opened continuously.
It would be wrong to infer a price of a few coins, a fixed percentage reduction of a global market or a company valuation from the size of a key operation alone. A credible business case compares a defined workflow before and after deployment, using the same availability and security requirements. Savings in one component are meaningful when the whole measured service still meets those requirements.
What a reproducible evaluation should deliver
Begin with a version manifest: product build, platform, configuration and cryptographic dependencies. Add the capsule and protocol specifications, a role map and a list of authorised recovery paths. The resulting test plan should identify both the material available to each adversary and the expected behaviour.
For each scenario, retain the preconditions, actions, observations and relevant logs. Test successful operations and deliberate failures. Check an expired session, an untrusted installation, a modified object, a refused key request and an unavailable service. A negative test is useful only when it exercises the boundary the product is supposed to enforce.
Performance testing belongs beside, not inside, the confidentiality claim. Report local processing time separately from authentication, network and service time. Median latency describes a typical operation; upper percentiles reveal whether ordinary users encounter a slow first read during load. Recovery testing should measure how work resumes without silently replacing the intended trust arrangement.
Public repositories help evaluate components, not substitute for the product
The OpenSSL repository provides inspectable source for a widely used cryptographic library. It does not become a repository of HVKM merely because both concern cryptography. A component, its version and the application’s use of that component remain distinct objects of analysis.
Open code makes inspection possible. It does not establish that inspection occurred, that a deployed binary matches the inspected revision or that the application’s configuration is correct. Closed code does not make those questions disappear either. A serious evaluation asks for the evidence available for the actual build and records which parts remain unexamined.
The system-level value of split trust
The strongest architectural proposition is concrete: an organisation can seek to operate encrypted storage without assigning its ordinary storage operator the complete capability to read the stored documents. That separates two powers which are often bundled together in service administration.
For the user, the benefit is not an abstract promise of stronger encryption. It is a different answer to a practical question: does handing somebody responsibility for my storage also hand them my readable files? HVKM’s documented objective is to narrow that automatic equivalence. The resulting product should be judged by its demonstrated separation, recovery behaviour and usability, not by a slogan that it replaces every other security control.
For the wider history of the venture, the Bringing Privacy Back mission explains why access to content matters to Paweł Makowski’s work. The Netia and Plus chapter documents historical commercial distribution. Technical mechanism, public mission and commercial evidence strengthen one another when each remains identifiable.
Further product documentation
The existing Polish HVKM article remains a separate language resource. This English guide adds a standards-oriented reading rather than replacing its historical URL. Follow the UseCrypt technical documentation, the patent and testing chapter and the founder’s biography for different parts of the evidence.