Deux affirmations de force très différente

Un coffre leurre présente un contenu ordinaire sous un identifiant, de sorte qu'une personne qui vous contraint à ouvrir quelque chose voit quelque chose de plausible. C'est atteignable et utile.

La négation plausible est une affirmation bien plus forte : qu'un observateur ne peut établir du tout que d'autres données protégées existent. La plupart des conceptions d'app ne peuvent pas la fournir, et l'écart entre les deux est là où les gens s'attirent des ennuis.

Les preuves qui sapent la négation

La négation échoue sur des preuves hors du contrôle de l'app, et il y en a plus que la description de la fonction ne le suggère.

  • Les enregistrements d'applications installées et l'historique d'achat de la boutique.
  • Le stockage total consommé par l'app par rapport à ce qu'un leurre expliquerait.
  • Les sauvegardes d'appareil contenant le conteneur de l'application.
  • L'historique des notifications, les statistiques d'usage et l'attribution de la batterie.
  • Les exportations et copies qui ont précédemment quitté le coffre.

La contrainte destructrice est un mécanisme différent

Un identifiant de contrainte destructeur ouvre un espace tout en invalidant l'accès aux autres. Il change ce qui reste disponible ; il ne prouve pas que rien d'autre n'a jamais existé.

Il est aussi irréversible, ce qui signifie qu'un déclenchement accidentel — ou une véritable urgence où vous aurez besoin des données plus tard — produit une perte permanente. Ce compromis devrait être fait délibérément et testé avant qu'il ne compte.

Modélisez l'observateur de façon précise

  • Définissez qui est l'observateur et quelles preuves il peut réellement inspecter.
  • Séparez le comportement de leurre non destructif du comportement de contrainte destructeur.
  • Testez les conséquences d'un déclenchement accidentel avant d'activer quoi que ce soit d'irréversible.
  • Confirmez ce qu'une sauvegarde préserve, car une sauvegarde peut contredire une affirmation de négation.

Affirmations à ne pas faire, ni croire

  • Promettre la négation sur la force d'un second code PIN seul.
  • Activer des actions irréversibles sans une voie de récupération testée.
  • Supposer qu'un leurre vainc un observateur qui peut inspecter le stockage ou les sauvegardes.

Ce qui est réalistement atteignable

Un leurre qui montre un contenu plausible, et une conception qui n'affiche pas de liste de coffres ni de décompte de coffres, changent de façon significative ce qu'un seul identifiant divulgué révèle.

C'est une propriété réelle et défendable. Ce n'est pas la même chose que prouver l'absence, et un fournisseur qui commercialise le second tout en implémentant le premier décrit une garantie que personne ne peut tenir.

Priya commence par un test non sensible : « Définis l'observateur et les preuves qu'il peut inspecter ». Ensuite, Priya suit la deuxième vérification : « Sépare le comportement de leurre non destructif de la contrainte destructrice ». Ce scénario fictif illustre le processus de décision ; ce n'est pas un compte rendu de tests de produit.

  • Promettre la négation à partir d'un second code PIN seul
  • Activer des actions irréversibles sans récupération

NullVault revendique-t-il une négation plausible parfaite ?

Non. Sa conception Android évite une liste maîtresse visible et prend en charge des schémas de coffre séparés, mais des preuves au niveau de l'appareil peuvent rester.

Que dois-je vérifier avant de me fier à « négation plausible contre un coffre leurre » ?

Pour « négation plausible contre un coffre leurre », vérifiez l'élément protégé après un verrouillage complet, identifiez chaque copie restante et confirmez la récupération avant de supprimer un original irremplaçable. Les contrôles exacts dépendent de l'appareil, de la version du système d'exploitation et du modèle de stockage décrits dans ce guide.

« Négation plausible contre un coffre leurre » supprime-t-il toutes les autres copies ?

Non. Quand vous envisagez « négation plausible contre un coffre leurre », traitez les exportations, les photothèques cloud, les messages, les téléchargements, les destinataires, les sauvegardes et les dossiers d'éléments supprimés comme des copies ou limites de stockage distinctes qui exigent leur propre examen.

Sources principales de ce guide