UseCrypt Safe separates control of infrastructure from the cryptographic operation needed to read a protected file. UseCrypt Messenger addresses another boundary: access to conversation data stored on a phone. These are distinct solutions to distinct security problems.
A storage administrator can operate disks, copy backups and maintain a service without necessarily holding every secret needed to decrypt its contents. That distinction is the practical motivation for Safe’s Hybrid Virtual Key Management, or HVKM. Messenger’s documented local-data design instead combines an encrypted database with application access controls and the operating system’s key store. This knowledge base explains each mechanism without treating one product’s documentation as evidence about another.
1. The problem: encryption is not enough if one compromise exposes the key
Consider an organisation that puts encrypted documents in cloud storage. If the same compromised environment exposes both the files and the usable decryption keys, encryption has not created an independent boundary. The relevant question is not simply whether a disk is encrypted. It is which combinations of credentials, devices and services can turn ciphertext into readable content.
Safe’s documented design places part of the private-key operation on the user’s installation and another part on a key service. A copy of the storage is therefore different from possession of the complete capability to read it. The service can participate in an authorised operation without supplying its secret share to the client. The client completes the operation locally.
This changes the trust model, not the laws of cryptography. The organisation still needs reliable endpoints, authentication, software updates and service availability. The specific improvement is separation of decryption authority, rather than a claim that every cybersecurity function disappears.
2. Evidence and product boundaries
The detailed Safe workflow below is based on the company’s cryptographic description, version 1.3, dated 8 October 2018. It is a historical design description, not a declaration of the parameters in a current downloadable build. The internal original is not reproduced here. Public technical context is available in AVLab’s description of UseCrypt Safe. The mathematical primitives are documented independently in RFC 8017.
For Messenger, the internal document titled Data at rest protection describes the local SQLite database, AES-256, the application passcode, operating-system key storage and behaviour when the database is locked. Public historical assessments are collected in Security Reviews. A patent, a design description and a tested application each provide a different kind of evidence.
3. Three different secrets in Safe
The file key KF, the client RSA share du and the server RSA share ds are not interchangeable. KF encrypts the file’s content. The RSA shares participate in the operation that recovers the material protecting that file key. A separate configuration-protection mechanism guards the local client share.
Large files are processed with symmetric cryptography, not by applying RSA to every byte. This matters for performance and for the structure of sharing. A recipient can receive a newly protected form of the same file key without requiring a new encryption of the entire large file. The ciphertext and the recipient’s capability to recover its key are separate objects.
It also makes incident analysis more precise. Disclosure of one file key concerns the objects encrypted with it. Disclosure of a reusable private-operation capability can concern many file-key capsules. Both are serious, but they are different failure modes with different scopes.
4. RSA and the multiplicative split
For a two-prime RSA modulus n = pq, the private exponent d is related to the public exponent e. The Safe description gives the split as duds ≡ d modulo φ(n). The server and client then compose two exponentiations. In a simplified arithmetic model:
n = p * q phi(n) = (p - 1) * (q - 1) e * d = 1 mod phi(n) d_u * d_s = d mod phi(n) t = c^d_s mod n z = t^d_u mod n = c^d mod n
The intermediate value t is a partial result. It is not the server share itself. The client still needs its own share to complete this model of the private operation. This is not splitting a string into equal halves, nor reducing a 2048-bit RSA modulus to two independent 1024-bit keys.
The equation establishes composition, not the security of arbitrary share generation. A degenerate choice such as du = 1 would leave the full operation on the server. A real construction must specify how shares are sampled and protected, how operations are authenticated, and how invalid inputs are handled. The full derivation and worked example are in HVKM, RSA and key capsules.
5. Why a key capsule is not homomorphic file processing
The capsule protects access to the file key. Its purpose is to let an authorised installation recover the key needed for ordinary local decryption. It does not imply that the application computes arbitrary functions over encrypted documents without decrypting them. The algebraic properties of RSA and fully homomorphic encryption are different subjects.
Likewise, a reference to a key encapsulation mechanism, or KEM, is not a complete wire format. A deployable KEM specifies the encapsulation input, decapsulation, key derivation and failure behaviour. RFC 9690 describes a standard RSA-KEM construction; it is useful context, but not proof that historical Safe implemented that specification. The source does not provide enough detail to infer every encoding and derivation parameter.
6. Registration: where the full key exists
The historical workflow generates the RSA key pair at the client during registration. It then creates the client and server shares, transfers the server share, and describes removal of the original complete private key from the client. The important distinction is between initial key generation and subsequent ordinary use.
It would therefore be inaccurate to say that a complete key never exists at any stage. The meaningful claim is that ordinary private operations use the separated shares. Registration is itself a sensitive stage: random-number generation, temporary memory, installation integrity and the authenticated delivery of the server share all belong in its test scope.
7. Local configuration is an additional protection layer
The client share is stored in encrypted configuration. The description reconstructs the configuration key using material associated with the password, a local value R and a server value S released after authentication. Possession of an ordinary configuration file is consequently different from possession of the usable client share.
The design needs both cryptographic and operational analysis. Password guessing depends on the derivation function and its parameters, not on the word “hash” alone. A review should establish which checks can occur offline, which need server cooperation, how repeated attempts are limited, and what a device backup includes. The historical description does not supply every parameter needed for a current reproducible implementation review.
8. File encryption and the ordinary read path
Chapter 10 of the Safe description covers file-key management. A fresh symmetric key protects the file content and name. The encrypted file can be stored while its key is separately protected for an authorised user. To read the file, the client obtains the required partial operation from the key service, completes its own operation and recovers the file key locally.
The large object need not pass through the key service for every cryptographic calculation. The key service operates on the key-protection path. Separating storage traffic from private-key operations is the architectural reason that capacity planning cannot be reduced to “a server contains all our documents”.
The source describes overwriting recovered key material in RAM after use. Actual erasure must be measured in the implementation: memory copies, crash dumps, platform behaviour and compiler optimisation can affect the result. This is a concrete test requirement, not an assertion that a design sentence proves every trace has vanished.
9. Sharing without re-encrypting the whole file
In the documented sharing workflow, the authorised client recovers the file key and protects it for the recipient using the recipient’s public key. The same bulk ciphertext can remain stored. The change is to the recipient’s key-access material and permissions, rather than to the entire document.
This separates two operations: authorising a recipient to recover a key and replacing the encryption of a potentially large object. The source also describes read, write and delete permissions. Such service permissions must not be confused with withdrawing plaintext already copied by a legitimate recipient. Once readable data has been exported, later refusal by a server cannot erase that external copy.
10. Encrypted cloud storage and local storage
In the local-storage mode, protected ciphertext can remain outside Safe’s storage service, including on a physical drive. The key service still participates in the documented access path. “Local file” therefore does not mean “no network dependency”. The design separates where a file is kept from how the authorised client recovers its key.
For an enterprise, that distinction allows a deployment discussion in terms of storage ownership, key-service ownership and endpoint ownership. It does not automatically establish offline access, arbitrary cloud compatibility or uninterrupted operation during a key-service outage. Those properties need the deployment specification and an actual recovery exercise.
11. Trusted installations and device transfer
The source combines user authentication with an installation-specific identity and a configuration file. It describes authorisation of installations using an email token and logging of new installations or network addresses. An account name and password are therefore not the entire described access state.
For a remote transfer between installations, the description uses a Diffie-Hellman exchange and comparison of fingerprints on the old and new installations. A server relays the encrypted transfer. Fingerprint verification matters because establishing an encrypted channel and establishing the identity of the other endpoint are not the same task.
Multi-device access is not inherently excluded by HVKM. It is provided through a controlled transfer or recovery workflow. Claims that protected files can only ever be opened on one physically unique computer would conflict with the described installation-transfer features.
12. Recovery is part of the trust model
Recovery configuration is a separate sensitive object protected with a different password. The source describes registration-time export and a choice not to create it. In a managed environment, an organisation may retain recovery material. Whoever can use that path may acquire a capability absent from routine storage administration.
Recovery cancels the old trusted installations in the documented flow. Password changes re-protect client configuration; other installations must update their own local configuration. Ordinary administrative password reset is not equivalent to recovering the encrypted configuration. These distinctions explain why identity support and decryption recovery need separate procedures.
The practical deployment question is specific: who possesses the recovery object, who possesses its password, and which actions can those people perform? Merely labelling a system “decentralised” cannot answer it. Administrator access and decryption authority develops this boundary in detail.
13. Messenger: encrypted local records rather than Safe file capsules
The Messenger local-data document describes AES-256 protection of SQLite records. It distinguishes operation with and without an application passcode. Without that passcode, the key is described as unencrypted within the operating system’s protected key store. That is not the same as a publicly readable file. With a passcode, the document describes additional passcode-related key protection.
When the application has opened its database, the usable key is described as remaining in RAM until application shutdown. App locking and process termination are consequently separate states. A technically useful explanation must discuss both, rather than treating an on-screen padlock as a complete description of memory protection.
Some limited operating data supports incoming calls before the database has been unlocked. The document distinguishes that from access to the business data inside the encrypted database. Notification handling also limits the display of contact information and message previews when locked. Read the dedicated explanation of Messenger database encryption, key storage and notifications.
14. Patents protect different mechanisms
Four US patents document endpoint and application mechanisms, not a generic claim that all of them patent HVKM. US 11,122,014 B2 addresses local data, tokens and notifications. US 11,210,407 B2 concerns coordinated distress response. US 11,341,218 B2 describes concealed application behaviour under coercion. US 11,228,910 B2 concerns defined conditions associated with possible device compromise.
Each should be read by its claims and description. Product deployment, independent testing and the scope of patent protection remain separate questions. The patent index links to the full records.
15. How an engineering team can verify the architecture
- Identify the exact application build and server configuration before testing.
- Trace the lifecycle of complete keys, split shares, file keys and recovery material independently.
- Test a copied storage database, a copied client configuration and a compromised service separately.
- Verify failure behaviour for unauthorised installations, malformed capsules and unavailable key services.
- Check whether sharing, recovery and device transfer match the documented trust boundaries.
- Measure local memory, database and notification behaviour before and after unlocking.
- Record repeatable procedures, inputs, outputs and exceptions, rather than accepting a demonstration as a proof.
These are acceptance criteria for a pilot. They are not claims that this page has performed a current application audit. Reference projects such as OpenSSL can support study of cryptographic implementation, but are not repositories of UseCrypt’s product code.
16. Product history and further reading
Netia’s announcement of Netia Data Safe documents historical distribution of encryption software developed by UseCrypt. The product’s technical rationale and commercial history should be read together, without converting past distribution into a present availability promise.
Continue with the RSA and HVKM analysis, the administrator-access analysis, Messenger’s Polish technical explanation and the historical security reviews. Each page identifies the mechanism and its evidence, so readers can move from a product-level question to the underlying technical material.
UseCrypt Editorial Team. Substantive review: 8 October 2026. Product-specific details above refer to the identified documentation; the RSA standards and external implementation links supply context, not certification of a current build.