Your message can be encrypted correctly and still be addressed to the wrong cryptographic key. The name on the contact card does not solve that problem. The sender needs evidence that the key belongs to the intended recipient.
This is a separate question from whether a provider keeps the private key. A service can leave private keys on devices while operating the directory that tells those devices which public keys to use. That directory becomes part of the trust model. It deserves its own explanation, tests and visible failure behaviour.
Encryption needs a trustworthy destination
Imagine an employee sending a confidential document to a colleague for the first time. The application asks a directory for the colleague’s public key. If an attacker can substitute another key and the application has no independent verification, strong encryption can protect the document on its journey to that attacker.
This is a hypothetical design failure, not evidence that a particular provider reads messages. It explains why key distribution and content encryption cannot be evaluated as unrelated boxes on a checklist. The cryptography can behave exactly as specified while the application makes the wrong identity decision.
A familiar defence is to compare a fingerprint or safety number using a separate trusted route. Signal’s safety-number documentation describes verification for individual conversations. The separate route matters: asking whether a key is correct inside the very connection under suspicion may simply repeat the original assumption.
A directory can be checked, not merely trusted
Signal’s explanation of automatic key verification describes a key-transparency system intended to detect inconsistent associations between account identifiers and public keys. Its design combines verifiable records with checks involving clients and third-party auditors. The article also explains circumstances in which automatic verification is unavailable.
The broader architectural idea is accountability for the directory’s answers. Recording a key change makes it possible to examine whether a lookup is consistent with the recorded history. Independent checks address the harder case in which an operator presents different views to different users. A signature from the directory alone would not establish that everyone received the same view.
This is not blockchain by another name, and a blockchain is not a prerequisite. The questions are which statements are committed, who verifies them, how conflicting views are detected and what clients do with a failed proof. The choice of data structure serves those requirements, rather than replacing them.
Consistency is not a passport
A key directory can consistently associate a key with an account that an impostor registered. That is why consistency and real-world identity must remain distinct. The same distinction applies to a genuine employee whose account or device has been compromised. A valid cryptographic association does not certify that every action is authorised by the person whose name appears on screen.
Account recovery complicates the situation. A legitimate reinstall may create new keys. Users need a usable way to recognise that transition without being trained to ignore every warning. Automatically blocking all changes can make a service unusable; silently accepting every change can conceal the event that verification was meant to expose.
For a company, this becomes an offboarding and incident-response question. Who approves replacement devices? Can an administrator silently add a recipient endpoint? Which contacts see a change? A credible answer describes the mechanism and its limitations rather than relying on a reassuring icon.
Evidence for a comparison
A useful evaluation starts with a controlled key change between two test accounts. Record the client versions, directory response, verification state and user warning. Then exercise an unavailable verification service. The important observation is whether the application reports uncertainty accurately or presents success without the required evidence.
Such testing should remain within systems the evaluator is authorised to examine. It does not require attacking a public directory. Reviewers can use a supplier’s isolated test environment or inspect documented test fixtures and proof-verification code. Repeatability makes the result more valuable than a screenshot of a successful conversation.
The UseCrypt security-review evidence page is the appropriate starting point for the scope of the project’s published review materials. A historical assessment is not automatic proof of a present-day key-transparency deployment. Comparisons with Signal or another messenger should identify the actual mechanism each product documents, and mark an unverified capability as unverified.
Privacy depends on sending encrypted content to the right destination. A technically serious product should make that destination check explainable, observable and testable. Without it, the strongest cipher in the proposal is answering only half the question.
