Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Feature]: make self-destruction PIN less noticeable to an adversary

Abierto
  • ¿Algo no está bien?
#7,233 0 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
android
Área
mobile, security

Línea de trabajo

The issue names no files, tests, or entry points. Start by comparing the regular and self-destruction PIN flows using the linked video, then review issue #4765 for the proposed decoy-account direction; done should make the two PIN outcomes indistinguishable to an adversary without breaking data destruction.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement triage
Is there an existing issue for this?
  • I have searched the existing issues
Platform

Android

App version

6.5.6

Feature

The data destruction password works correctly, but an adversary can see with the naked eye whether the user entered the regular password or the self-destruction password. In some cases, the user may be put in danger if the adversary notices that they are hiding something. The video below compares the app’s behavior when the user enters the correct password and when they enter the self-destruction password:

https://youtube.com/shorts/AH-mBpOPC6U?si=FM9eO1UX1f8arBeh

First, the application loads instantly when the regular PIN is entered, but it takes several seconds to load when the user enters the duress PIN. A possible solution would be to add a delay to regular PIN verification, for example by using a key derivation function, so that entering the PIN takes roughly the same amount of time in both scenarios.

Second, when the regular PIN is entered, the size of the user data remains the same before and after unlocking the app. However, when the decoy PIN is entered, the size of the user data decreases after the app is unlocked. Moreover, if the user previously had several megabytes of user data and then shows the adversary an empty account, this may be enough for the adversary to conclude that the user has destroyed their data.

This issue is harder to solve. One possible mitigation would be to preallocate some space even for empty accounts, or to show a decoy user account instead of an empty one after the self-destruction password is entered, as proposed here.

Lenguaje dominante
Haskell
Estrellas
19.5k
Forks
1.4k
Merge medio
1 d 21 h
PR fusionados (30 d)
93

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de simplex-chat/simplex-chat

Todos los issues de simplex-chat/simplex-chat

Issues similares

Más issues de Haskell

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.