How UseCrypt Messenger works: database encryption, application keys and locked-state behaviour

1. Three distinct places where a conversation needs protection

A conversation exists as traffic in transit, as a stored record on a device and as readable information in a running application. Protecting one does not settle the other two. End-to-end encryption concerns the communicating endpoints of a protocol. Data-at-rest protection concerns stored data. Process and memory protection concern the period when the application uses it.

Suppose an attacker obtains the database file from a phone backup but not the key or an authorised application session. Database encryption addresses the transition from copied bytes to readable records. If the attacker instead controls an unlocked application, content may be obtainable through its display, process or export functions. Those scenarios must not be merged into a single claim about encryption.

The practical improvement is an additional requirement for reading the copied archive: the attacker needs more than the storage object. OWASP MASVS-STORAGE-1 supplies an independent criterion for secure mobile storage. It is a testing reference, not a certificate awarded to UseCrypt.

2. SQLite organises records; AES protects their content

The product document identifies SQLite as the application's local database and AES-256 as the cipher used for records. SQLite describes storage and access structures. AES describes cryptographic transformation. Identifying a file as SQLite does not establish which fields or pages are protected.

A useful logical model is C = Encrypt(K, M, parameters), where M is the protected record, K the key and C its encrypted representation. This notation does not specify the AES mode, initialisation values, integrity mechanism or record format. The source does not unambiguously identify SQLCipher or whole-page database encryption, so those properties are not added to the product description.

A storage review must also examine journals, attachments, caches and backups. SQLite can use rollback journals or a write-ahead log. The SQLite rollback-journal documentation and WAL documentation explain why looking at a single database file is not an exhaustive test. These are review surfaces, not an allegation that Messenger leaks data there.

3. The application passcode changes the key-protection model

The document distinguishes configurations with and without an application passcode. Without it, the database key is described as stored without additional passcode encryption inside the operating system's key store. That does not mean the key is a public plaintext file: the platform still enforces its own protection boundary.

With a passcode, the document refers both to deriving a key from that passcode and storing an encrypted key in the system key store. It does not supply the complete derivation function, its parameters or the precise relationship between those steps. A possible design in which a passcode-derived key wraps a random database key must not be presented as a confirmed implementation.

AES-256 does not make a short passcode equivalent to a random 256-bit secret. If a code is selected uniformly from N possibilities, its maximum selection entropy is log2(N). Human choices may be less unpredictable. The effective resistance to guessing also depends on attempt limits, derivation cost and platform enforcement.

Consequently, the review asks which checks can be performed offline, which require the running device and whether a failed attempt has a measurable cost. Those details matter more than a bare algorithm name. They must be measured for the identified build, not assumed from this overview.

4. A system key store has platform-specific properties

The product source uses the general term "system key store". That alone does not establish a hardware security level, a key's availability after screen lock or a requirement to authenticate for every use. iOS and Android implementations need separate examination.

Android Keystore documentation distinguishes controls on extraction and use. A non-exportable key is not identical to a key that a compromised process cannot ask the system to use. Hardware protection and access conditions depend on the device and key configuration.

Apple's Keychain protection documentation explains availability classes and platform enforcement. It supplies context, not evidence of the attributes Messenger selected. A reproducible report should identify the actual attributes, platform version and device rather than simply naming the platform.

5. Opening the database and retaining a key in memory

According to the product description, the application obtains the usable key after startup and successful passcode entry. The key remains in RAM until application shutdown. This does not mean the whole database is copied into RAM, nor that a readable record can never exist while the user views it.

Backgrounding, locking the phone, closing a view and terminating the process are distinct state transitions. A user may describe all of them as closing the app; the operating system does not necessarily treat them alike. The source does not resolve every transition, so testing should record key and data availability in each state.

Storage encryption and live-process protection serve different purposes. A displayed message needs a readable representation. The review therefore examines whether the application's locked state also changes memory access, and whether actual process termination clears the relevant state. An on-screen lock icon cannot answer those questions by itself.

6. Receiving a call without opening the message archive

A phone must be able to ring while its conversation database remains locked. The document describes a minimal set of operating data retained in the system key store to support calls, including an authentication token for the call server.

This separates call signalling from access to the complete conversation archive. The call-handling path need not use the archive as its sole source of operating data. The token nevertheless has its own permissions, lifetime and revocation behaviour. Its security must be reviewed separately from message confidentiality.

Incoming call
  -> minimal signalling data in system key store
  -> communication with call server
  -> call handling
  != automatic unlocking of the full message history

This is the documented functional separation, not a complete network diagram. It does not establish serverless operation, a peer-to-peer topology or the absence of all call metadata. Those require a communication-protocol and deployment specification.

7. Notification previews are a separate disclosure path

For a message received while the database is locked, the source describes a notification without contact information or a content preview. This is an interface-level protection. Encrypting network traffic cannot stop an application from displaying a sender or message on the lock screen if it is configured to do so.

Testing should cover the lock screen, notification centre and transitions before and after database unlock. Notification extensions, watches, connected computers, app-switcher previews and screen captures are additional surfaces to examine. The product document does not establish the behaviour of all those integrations.

Suppressing a preview is not the same as eliminating delivery metadata. Push systems and service infrastructure may still process delivery information. A careful explanation preserves that distinction instead of deriving network anonymity from a notification setting.

8. Reproducible acceptance testing

An engineering report starts with the application build, platform, operating-system version, device and passcode configuration. It then separates storage extraction, key-store access and control of the running process. A result belongs to its specific scenario.

1. Database copy without a key: examine protected records, indexes and metadata, not only recognisable file headers.
2. Journals and exports: inspect WAL, rollback journals, attachments, caches and backup scope.
3. Passcode and key lifecycle: compare configurations with and without a passcode, identify derivation parameters and record failed-attempt behaviour.
4. Process state: test startup, backgrounding, screen lock, resumption and actual process termination separately.
5. Calls with a locked database: identify available tokens, their privileges and revocation behaviour.
6. Notifications: record contact and message information before and after unlocking.

Use controlled accounts, synthetic conversations and the owner's authorisation. Preserve inputs, procedures and outputs, including negative findings. This is a proposed acceptance plan, not a claim that the editorial team performed these tests on today's application.

9. Historical assessments and their scope

AVLab's 2020 Messenger assessment article reports an examination of an iOS application in a defined scope. It is a public reference to work carried out, not a substitute for retesting a later build, another platform or changed infrastructure.

The security-review index separates independent observation from a design description. A patent documents an invention and its claims. An operator announcement documents distribution. Neither should be silently substituted for an application audit.

10. Technical questions and direct answers

Is the name AES-256 enough to evaluate security?

No. The mode, data format, integrity checks, key generation, key protection and adversary model are also needed. A key length is not a complete protocol.

Is protection identical without an application passcode?

The source distinguishes the configurations. Without the passcode, its additional key-protection layer is absent; the system key store still provides a platform boundary.

Does accepting a call unlock the message history?

That does not follow from the document. It describes a separate minimal signalling dataset. Its contents and permissions need independent examination.

Does this document prove Messenger uses HVKM?

No. HVKM and Safe's key capsules are described in a separate technical analysis. Their properties must not be transferred to Messenger without product evidence.

What does this layer change?

It separates possession of a stored conversation copy from the ability to read its protected records, and limits notification disclosure in the documented locked state. Its effectiveness depends on implementation and configuration.

11. A server can deliver a conversation without being able to read it

Delivering encrypted data and recovering its contents are different capabilities. A communication service may need infrastructure to connect two devices without giving that infrastructure the keys needed to decrypt the conversation. Evaluating this boundary requires a description of key material, its holders and the point where plaintext becomes available.

Consider an acquisition negotiation. The operator may carry the call, but carrying it should not by itself grant access to the negotiation. The technical question is whether the operator's resources are sufficient to recover the session key and read the content. If the infrastructure receives ciphertext and lacks that capability, taking over its storage is not equivalent to recovering the conversation.

This is not a claim that infrastructure disappears. Signalling, delivery and content protection perform separate jobs. The topology and access boundaries must be established for the release being assessed.

12. ZRTP and SRTP: call key agreement is not message storage

RFC 6189: ZRTP describes media-path key agreement for SRTP sessions. In its Diffie-Hellman mode, the devices agree a secret during call setup. The protocol does not assume a PKI or end-device certificates. The RFC is published as Informational.

The AVLab account of the UseCrypt Messenger assessment, published on 17 November 2020, identifies ZRTP for voice calls. It concerns iOS version 2.34 and work by Oded Vanunu and Roman Zaikin. It is evidence of a historical assessment, not a specification for every later build.

A voice-call protocol does not establish how text messages or attachments are encrypted. Each path needs its own specification. Transport protection and the local database encryption explained above address different scenarios: interception during communication and extraction of stored files.

13. The agreed secret must belong to the intended peer

Key agreement is not enough without peer authentication. An assessment must establish how the protected session is bound to the intended person and how an attempted intermediary substitution is detected.

Section 7 of RFC 6189 describes the Short Authentication String that participants compare. This is a protocol mechanism. It does not establish a specific SAS interface in the current Messenger without inspection and testing. The implementation review should identify responses to a mismatch, a key change and continuation after a warning.

Listing algorithms is not a substitute for observing behaviour. Does a failure stop the call? What does the user confirm? Which signal actually provides cryptographic assurance? A padlock icon cannot answer those questions.

14. Content, metadata and device state require separate assessments

Not recovering content does not automatically hide call timing, data size or delivery information. Protection of a powered-off device also does not describe an authorised user reading a message in a running application.

Deployment documentation should identify log categories, retention and each service's permissions. Assess the database, signalling token, attachment, notification preview and process memory separately. This identifies a real access boundary instead of assigning one vague security label to the entire system.

The practical consequence of encryption is specific: an intermediary's resources or a storage copy may be insufficient to recover content. This does not establish resistance to every endpoint compromise or anonymity for all network operations.

15. From reviews to evidence: Messenger, Safe and source material

UseCrypt Messenger and UseCrypt Safe must be assessed through their own mechanisms. The HVKM, RSA and Safe key-capsule analysis in Polish addresses file cryptography. The Safe administrator-access analysis in Polish discusses organisational roles. Neither establishes that Messenger calls use the same protocol.

The UseCrypt security-review register distinguishes assessments and their scopes. The Bringing Privacy Back article in Polish provides accessible context for the video. The UseCrypt publication bank records media coverage. A test result, a specification and a press article are different types of evidence.

Sources and further technical reading

Product source: Data at rest protection, UseCrypt technical document supplied in March 2025. UseCrypt Editorial Team, substantive review 8 October 2026. The original private correspondence and document are not published here.

The linked OWASP, SQLite, Android and Apple materials explain external testing and platform concepts. They are not documentation of UseCrypt's source code. For the broader product family, read UseCrypt's technical knowledge base and Safe's administrator-access analysis. The Polish edition of this explanation covers the same mechanism.

Bringing Privacy Back's Messenger article supplies editorial context. The technical conclusions on this page remain tied to the identified product source and assessment scope, rather than to publicity or a promise of absolute security.