«Разблокируй телефон.» — Он разблокирует. Открывается мессенджер. Чаты с «Alex», «Mila», «Family». Всё выглядит нормально. Всё — подделка.
Привет, Хабр! Я разрабатываю open-source мессенджер Xipher (C++/Android), и одна из фич, которую пришлось проектировать особенно тщательно — Panic Mode. Это система правдоподобной отрицаемости (plausible deniability): при вводе специального PIN-кода мессенджер показывает полностью фейковую, но убедительную базу данных с поддельными чатами, а параллельно отправляет скрытый SOS-сигнал на сервер.
В статье разберу архитектуру целиком — от криптографического разделения баз до генерации правдоподобных фейков и маскировки panic-алерта под рутинный сетевой запрос. Весь код — из реального проекта.
Исходники открыты — ссылка на GitHub в конце статьи.
Содержание
1. Зачем нужна правдоподобная отрицаемость
E2EE решает проблему перехвата. Исчезающие сообщения решают проблему хранения. Но ни то, ни другое не решает проблему физического принуждения.
Сценарии:
Пограничный контроль: вас просят разблокировать телефон и показать мессенджер. В ряде стран отказ — уголовное правонарушение (UK — Regulation of Investigatory Powers Act, Part III: до 2 лет тюрьмы за отказ предоставить ключ шифрования)
Задержание: устройство изъято, пароль получен под давлением
Корпоративный шпионаж: сотрудника вынуждают показать рабочие чаты
Домашнее насилие: абьюзер требует доступ к переписке
Во всех этих случаях жертва не может солгать — пустой мессенджер или отсутствие приложения вызовут подозрения. А «Удалить чат» оставляет forensic-следы в SQLite (WAL-журнал, UNDELog, свободные страницы).
Правильный ответ — не скрывать, а подменять. Показать убедительную, нормально выглядящую переписку, которая не вызовет вопросов. Именно это делает Panic Mode.
Концепция не нова — VeraCrypt Hidden Volume использует тот же принцип для дисков. Я адаптировал его для мессенджера.
2. Архитектура: две базы, один PIN-экран
Система построена на двух полностью изолированных SQLCipher-базах данных:
+---------------------------------------+ | Android Device | | | | /data/data/com.xipher/.../ | | | | +----------------+ +----------------+| | | real_user.db | | decoy_user.db || | | (SQLCipher) | | (SQLCipher) || | | | | || | | PIN: 1234 | | PIN: 5678 || | | Реальные чаты | | Фейковые чаты || | | 47 диалогов | | 47 диалогов || | | 12K сообщений | | ~180 сообщений || | +----------------+ +----------------+| | | | +------------------------------------+| | | PinUnlockActivity || | | [ _ _ _ _ ] <-- один экран || | | Введите PIN || | +------------------------------------+| +---------------------------------------+
Ключевые принципы:
Один экран ввода — пользователь вводит PIN в одно и то же поле. Нет кнопки «Panic Mode», нет переключателя, нет визуальной разницы
Криптографическое разделение — какая база откроется, определяет PIN через SQLCipher, а не
if/elseв кодеСтруктурная мимикрия — количество чатов в decoy-базе совпадает с реальной, типы чатов (DM/группы/каналы) сохранены
Полная изоляция — в panic mode WebSocket отключён, push-токен не синхронизируется, реальные данные невидимы
3. Криптографическая развилка: SQLCipher решает за вас
Это самая элегантная часть. В коде нигде нет сравнения if (pin == panicPin). Вместо этого:
private void initInternal(Context context, String password, boolean allowDecoyCreate) throws InvalidPasswordException { char[] passphrase = password != null ? password.toCharArray() : new char[0]; try { try { // ▶ Шаг 1: пробуем открыть РЕАЛЬНУЮ базу с введённым PIN DbHolder real = openDatabase(context, REAL_DB_NAME, passphrase, true); setActive(context, real, false); // isPanic = false return; } catch (Exception ignore) { // SQLCipher не смог расшифровать → PIN не от реальной базы } // ▶ Шаг 2: реальная не открылась → пробуем decoy if (!PanicModePrefs.isEnabled(context) && !allowDecoyCreate) { throw new IllegalStateException("Panic mode disabled"); } DbHolder decoy = openDatabase(context, DECOY_DB_NAME, passphrase, allowDecoyCreate); if (allowDecoyCreate && decoy.created) { seedDecoy(decoy.db); } setActive(context, decoy, true); // isPanic = true } catch (Exception e) { throw new InvalidPasswordException("Invalid password", e); } finally { wipeChars(passphrase); // Затираем PIN из памяти } }
Как это работает:
Пользователь вводит PIN
DatabaseManagerпробует расшифроватьreal_user.dbэтим PIN через SQLCipherЕсли расшифровка удалась — это реальный PIN. Открывается настоящая база
Если
real_user.dbне расшифровался — пробуемdecoy_user.dbЕсли decoy расшифровался — это panic PIN. Включается panic mode
Если ни одна база не открылась — «неверный пароль»
Почему это надёжно:
Подход |
Уязвимость |
|---|---|
|
Panic PIN хранится в открытом виде или как хеш. Forensic-анализ извлечёт его из APK/SharedPreferences |
|
Наличие двух хешей — прямое доказательство существования panic mode |
SQLCipher try/catch (наш подход) |
Нет сравнения PIN. Нет хранения PIN. SQLCipher — чёрный ящик: либо расшифровал, либо нет. Forensic-аналитик видит два зашифрованных файла и не может доказать, какой «настоящий» |
В setActive() сразу срабатывает цепная реакция:
private void setActive(Context context, DbHolder holder, boolean isPanic) { synchronized (lock) { clearSensitiveStateLocked(); // Затираем предыдущую базу activeDb = holder.db; activePassphrase = holder.passphrase; activeDbName = holder.dbName; panicMode = isPanic; } SecurityContext.get().setPanicMode(isPanic); // ▶ Если panic — немедленно ставим в очередь скрытый SOS if (isPanic) { PanicModeWorker.enqueue(context.getApplicationContext()); } }
Обратите внимание: clearSensitiveStateLocked() затирает байты предыдущего пароля из памяти через Arrays.fill(activePassphrase, (byte) 0). Это не идеальная защита от cold boot атак, но лучше, чем оставлять пароль в куче.
4. Генератор фейков: как обмануть следователя
Фейковая база должна быть убедительной. Пустая база или два чата «Welcome» и «Support» мгновенно выдадут обман. Поэтому DecoyDataGenerator анализирует структуру реальной базы и генерирует правдоподобную копию.
4.1. Зеркалирование структуры
Генератор итерирует по каждому реальному чату и создаёт его «двойника»:
static void generate(Context context, AppDatabase source, AppDatabase target, String selfId, String selfName) { List sourceChats = source != null ? source.chatDao().getAll() : null; if (sourceChats == null || sourceChats.isEmpty()) { seedFallback(target, System.currentTimeMillis()); // Минимальный fallback return; } SecureRandom random = new SecureRandom(); Set<String> usedNames = new HashSet<>(); int index = 0; for (ChatEntity src : sourceChats) { ChatEntity chat = new ChatEntity(); chat.id = "decoy_" + index + "_" + UUID.randomUUID().toString(); // ▶ Сохраняем СТРУКТУРУ: тип чата идентичен реальному chat.isGroup = src.isGroup; chat.isChannel = src.isChannel; chat.isSaved = src.isSaved; chat.isPrivate = src.isPrivate; // ▶ Меняем СОДЕРЖАНИЕ: имя, сообщения, даты — случайные if (src.isGroup) { chat.title = pickUnique(GROUP_NAMES, usedNames, random); } else if (src.isChannel) { chat.title = pickUnique(CHANNEL_NAMES, usedNames, random); } else { chat.title = pickUnique(DIRECT_NAMES, usedNames, random); } // ... } }
Результат: если у вас 15 личных чатов, 8 групп и 3 канала — в decoy-базе будет ровно 15 личных, 8 групп и 3 канала. Но с другими именами и сообщениями.
4.2. Логарифмическое масштабирование сообщений
Наивный подход — «столько же сообщений, сколько в реальном чате» — слишком дорогой и подозрительный (зачем 10 000 скучных сообщений?). Вместо этого:
private static int estimateMessageCount(AppDatabase source, ChatEntity chat, SecureRandom random) { int realCount = source.messageDao().countByChat(chat.id); int count = 2 + (int) Math.round(Math.log(realCount + 1) * 2.0d); if (count < 2) count = 2; if (count > 12) count = 12; return count; }
Логика: 2 + ln(realCount + 1) * 2, ограничено диапазоном [2, 12].
Реальных сообщений |
Фейковых сообщений |
|---|---|
0 |
2 |
10 |
7 |
100 |
11 |
1 000 |
12 (cap) |
10 000 |
12 (cap) |
Почему логарифм? Активный чат (1000 сообщений) должен выглядеть «живым» в preview-списке, но генерировать 1000 фейковых сообщений — и долго, и подозрительно, и бессмысленно: следователь не будет скроллить 1000 сообщений «Got it, thanks!». Достаточно 10-12 сообщений, чтобы чат выглядел естественно при беглом просмотре.
4.3. Пулы нейтрального контента
Фейковые сообщения выбираются из специально составленных пулов — однозначно безобидных и невызывающих подозрений:
private static final String[] DIRECT_MESSAGES = { "Hey, are we still on for today?", "Got it, thanks!", "On my way.", "Can you send the file?", "Let's do it tomorrow.", "Sounds good.", "I'll check and get back to you.", "See you at 6.", "All set here.", "Thanks, appreciate it." }; private static final String[] GROUP_MESSAGES = { "Reminder: meeting at 4pm.", "Anyone free this weekend?", "I'll bring snacks.", "Updated the doc.", "Please review the notes.", "Let's sync after lunch.", "Sharing the draft now.", "Heads-up: schedule changed." };
Контент намеренно скучный. Никаких тем, которые могли бы заинтересовать проверяющего. Только бытовая координация — встречи, файлы, обеды.
4.4. Реалистичная хронология
Фейковые сообщения получают правдоподобные временные метки:
long jitter = random.nextInt(60 * 1000); // Случайный сдвиг до 60 секунд long createdAt = baseTime - ((count - 1 - i) * 2L * 60L * 1000L) + jitter;
Интервал между сообщениями — ~2 минуты с jitter до минуты. Это имитирует естественный ритм переписки: не слишком быстро (бот), не слишком медленно (заброшенный чат).
4.5. Уникальность имён и SecureRandom
private static String pickUnique(String[] pool, Set used, SecureRandom random) { for (int i = 0; i < pool.length * 2; i++) { String candidate = pool[random.nextInt(pool.length)]; if (used.add(candidate)) { return candidate; } } // Fallback: имя + число, если пул исчерпан String fallback = pool[random.nextInt(pool.length)] + " " + (used.size() + 1); used.add(fallback); return fallback; }
Два момента:
SecureRandom, а неjava.util.Random— криптографически стойкий ГПСЧ. Атакующий не может предсказать, какие имена будут выбраныДедупликация через HashSet — никогда не будет двух чатов с «Alex». Если пул имён исчерпан (20 имён, а чатов больше), добавляется порядковый номер: «Alex 21»
4.6. Атомарная запись
target.runInTransaction(() -> { target.messageDao().clearAll(); target.chatDao().clear(); target.chatDao().upsertAll(chats); target.messageDao().upsertAll(messages); });
Вся decoy-база заполняется в одной транзакции. Если процесс упадёт посреди генерации — никакого «корраптнутого» промежуточного состояния.
5. Скрытый SOS: AES-GCM под видом metadata_sync
При активации panic mode на сервер должен уйти сигнал «убить все мои реальные сессии». Но этот сигнал сам по себе — улика. Если наблюдатель видит POST /api/panic — игра окончена.
Решение: замаскировать panic-алерт под рутинный сетевой запрос.
5.1. Внешний слой: безобидный JSON
private Request buildRequest() throws Exception { String token = SecurityContext.get().getCurrentSessionToken(); String deviceId = Settings.Secure.getString( getApplicationContext().getContentResolver(), Settings.Secure.ANDROID_ID); String encrypted = encryptPayload(token, deviceId); // ▶ Внешний JSON — выглядит как рутинная синхронизация JsonObject body = new JsonObject(); body.addProperty("type", "metadata_sync"); body.addProperty("ts", System.currentTimeMillis()); body.addProperty("device_id", deviceId != null ? deviceId : "unknown"); body.addProperty("payload", encrypted); // Настоящий сигнал — внутри RequestBody rb = RequestBody.create(body.toString(), JSON); return new Request.Builder() .url(BuildConfig.API_BASE + "/api/v1/auth/panic_alert") .post(rb) .header("X-Auth-Token", token) .build(); }
Наблюдатель, перехватывающий HTTPS-трафик (даже через корпоративный MITM-прокси с установленным корневым сертификатом), видит:
{ "type": "metadata_sync", "ts": 1708701234567, "device_id": "a1b2c3d4e5f6", "payload": "dGhpcyBpcyBub3QgdGhlIHJlYWwgcGF5bG9hZA..." }
Поле type: "metadata_sync" — стандартный тип запроса, который приложение отправляет регулярно. Один лишний запрос неотличим от фонового трафика.
5.2. Внутренний слой: AES-128-GCM
private String encryptPayload(String token, String deviceId) throws Exception { // ▶ Деривация ключа: SHA-256(token + "|" + deviceId), обрезка до 16 байт String keyMaterial = (token != null ? token : "") + "|" + (deviceId != null ? deviceId : ""); byte[] keyBytes = MessageDigest.getInstance("SHA-256") .digest(keyMaterial.getBytes(StandardCharsets.UTF_8)); byte[] aesKey = Arrays.copyOf(keyBytes, 16); // ▶ AES-128-GCM с случайным 12-байт IV byte[] iv = new byte[12]; new SecureRandom().nextBytes(iv); Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding"); cipher.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(aesKey, "AES"), new GCMParameterSpec(128, iv)); // ▶ Настоящий payload — скрыт внутри JsonObject payload = new JsonObject(); payload.addProperty("event", "metadata_sync"); // Камуфляж даже внутри payload.addProperty("panic", true); // Единственный маркер payload.addProperty("action", "kill_sessions"); // Что сделать payload.addProperty("ts", System.currentTimeMillis()); byte[] ciphertext = cipher.doFinal( payload.toString().getBytes(StandardCharsets.UTF_8)); // IV || ciphertext → Base64 byte[] combined = new byte[iv.length + ciphertext.length]; System.arraycopy(iv, 0, combined, 0, iv.length); System.arraycopy(ciphertext, 0, combined, iv.length, ciphertext.length); return Base64.encodeToString(combined, Base64.NO_WRAP); }
Почему именно так:
Решение |
Зачем |
|---|---|
AES-128-GCM |
Шифрование + аутентификация. Нельзя подменить payload |
Ключ = SHA-256(token + deviceId) |
Только сервер (знающий оба значения) может расшифровать. Не нужен отдельный shared secret |
Случайный IV |
Каждый запрос уникален. Нельзя определить panic по повторяющемуся blob |
|
Если AES вскрыт, содержимое выглядит рутинным. |
5.3. Гарантия доставки: WorkManager
public static void enqueue(Context context) { Constraints constraints = new Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .build(); OneTimeWorkRequest req = new OneTimeWorkRequest.Builder(PanicModeWorker.class) .setConstraints(constraints) .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 10, TimeUnit.SECONDS) .build(); WorkManager.getInstance(context.getApplicationContext()) .enqueueUniqueWork(UNIQUE_NAME, ExistingWorkPolicy.REPLACE, req); }
Почему WorkManager, а не просто OkHttp?
Переживает убийство процесса — если Android убьёт приложение после ввода panic PIN, WorkManager возобновит задачу при следующем запуске
Ожидание сети — если телефон был в авиарежиме, panic-алерт уйдёт сразу при появлении сети
Exponential backoff — при ошибке сети: 10с → 20с → 40с → ... Не бросает попытки
REPLACE policy — повторный вход в panic mode не создаёт дубликаты
Что делает сервер: получив panic-алерт, сервер расшифровывает payload, проверяет "panic": true, и убивает все активные сессии пользователя. Это значит: никто не сможет подключиться к аккаунту с другого устройства, используя украденный токен.
6. Сетевая изоляция: ни один реальный бит не утечёт
Panic mode бесполезен, если сквозь фейковую базу просвечивают реальные данные. Поэтому в panic mode вся реальная сетевая активность отключена.
6.1. WebSocket заблокирован
// SocketManager.java public void connect() { if (SecurityContext.get().isPanicMode()) { Log.w(TAG, "panic mode active; websocket blocked"); Listener l = listener; if (l != null) l.onClosed(); return; } // ... нормальное подключение }
В panic mode WebSocket не открывается. Приложение не получает реальных входящих сообщений и не отправляет исходящих. Для UI это выглядит как «нет интернета» — вполне правдоподобно.
6.2. Push-токен не синхронизируется
// PinUnlockActivity.java private void openMain() { if (!SecurityContext.get().isPanicMode()) { PushTokenManager.syncIfPossible(this); // Только для реального режима } startActivity(new Intent(this, ChatActivity.class)); finish(); }
Push-токен FCM/RuStore не отправляется на сервер. Это значит: сервер не будет слать push-уведомления на это устройство, и новые сообщения за реальных собеседников не просочатся через notification bar.
6.3. Визуальная идентичность
ChatActivity открывается одинаково независимо от режима. Тот же список чатов, тот же UI, те же иконки. Наблюдатель, смотрящий через плечо, не заметит разницы.
7. Полный flow: что происходит посекундно
t=0.000 Пользователь вводит panic PIN [5678] в PinUnlockActivity t=0.001 DatabaseManager.init("5678") вызван t=0.050 SQLCipher пробует: real_user.db + "5678" → FAIL (неверный ключ) t=0.100 SQLCipher пробует: decoy_user.db + "5678" → SUCCESS t=0.110 setActive(decoy, isPanic=true) ├── clearSensitiveStateLocked() // Затирает bytе[] старого пароля ├── SecurityContext.setPanicMode(true) // Глобальный volatile флаг └── PanicModeWorker.enqueue() // SOS в очередь WorkManager t=0.120 PinUnlockActivity.openMain() ├── PushTokenManager.syncIfPossible → SKIP (panic mode) └── startActivity(ChatActivity) t=0.200 ChatActivity отображает decoy-чаты: Alex, Mila, Family, Weekend Plan, City News ... t=0.300 SocketManager.connect() → BLOCKED (panic mode) → UI показывает "connecting..." (выглядит как слабый интернет) t=0.500 PanicModeWorker.startWork() ├── buildRequest(): JSON { type: "metadata_sync", payload: AES(...) } └── OkHttp POST /api/v1/auth/panic_alert t=1.200 Сервер получает запрос ├── Расшифровывает payload: { panic: true, action: "kill_sessions" } └── Инвалидирует все сессии пользователя Итого: 1.2 секунды от ввода PIN до убийства всех сессий.
8. Модель угроз: от кого защищаем
Adversary |
Возможности |
Panic Mode защищает? |
|---|---|---|
Пограничный контроль |
Визуальный осмотр телефона, 5-10 минут |
Да — увидят нормально выглядящий мессенджер с безобидными чатами |
Разъярённый партнёр |
Требует разблокировать, проверяет чаты |
Да — увидят «Alex», «Mila», «Got it, thanks!» |
Forensic-аналитик |
Полный дамп файловой системы, инструменты типа Cellebrite |
Частично — увидят два зашифрованных файла, но SQLCipher с достаточно длинным PIN устойчив |
Forensic + знание о Xipher |
Знает что Xipher имеет panic mode, ищет |
Слабо — наличие двух файлов БД может вызвать подозрения (см. раздел «Ограничения») |
Cold boot / RAM dump |
Извлечение ключей из оперативной памяти |
Нет — |
9. Сравнение с аналогами
VeraCrypt Hidden Volume
VeraCrypt Hidden Volume — прямой идеологический предшественник. Два пароля → два раздела диска. Внешний выглядит нормально, внутренний — настоящий.
Чем Panic Mode отличается:
Адаптирован для мессенджера, а не файловой системы — генерируются чаты, а не файлы
Автоматическая генерация контента (VeraCrypt требует вручную заполнять outer volume)
Серверный компонент (kill sessions) — VeraCrypt чисто локальный
Signal — нет аналога
Signal не предлагает правдоподобной отрицаемости. «Disappearing messages» удаляют контент, но не скрывают факт использования мессенджера. Пустой Signal с нулём чатов — сам по себе подозрителен.
Briar — нет аналога
Briar (Tor-based мессенджер для активистов) шифрует все данные локально, но тоже не имеет decoy-режима. При принуждении — либо отдаёшь PIN, либо отказываешься.
Итоговая таблица
Критерий |
VeraCrypt |
Signal |
Briar |
Xipher Panic Mode |
|---|---|---|---|---|
Два пароля → два набора данных |
Да |
Нет |
Нет |
Да |
Автогенерация фейков |
Нет (вручную) |
— |
— |
Да (DecoyDataGenerator) |
Структурная мимикрия |
Зависит от пользователя |
— |
— |
Да (зеркалирует реальные чаты) |
Скрытый серверный алерт |
Нет |
Нет |
Нет |
Да (AES-GCM metadata_sync) |
Kill other sessions |
N/A |
Нет |
Нет |
Да (panic → kill_sessions) |
Устойчив к forensic |
Высоко |
Низко |
Средне |
Средне (см. ограничения) |
10. Честные ограничения
10.1. Два файла базы данных — улика
Forensic-аналитик, знающий о Xipher, обнаружит два файла в /data/data/com.xipher/databases/: real_user.db и decoy_user.db. Само наличие двух баз — косвенное доказательство panic mode.
Mitigation (будущее): использовать единый файл с двумя SQLCipher-«страницами» (аналог VeraCrypt, где outer и hidden volume в одном контейнере). Это сложнее реализовать с Room/SQLCipher, но теоретически возможно.
10.2. Имена файлов говорящие
real_user.db и decoy_user.db — очевидные имена. В production стоит использовать нейтральные имена (user_v1.db, user_v2.db), чтобы не было ясно, какой файл «настоящий».
10.3. JVM не гарантирует затирание памяти
wipeChars(passphrase) вызывает Arrays.fill(passphrase, '\0'), но JIT-компилятор может оптимизировать эту запись (dead store elimination). Garbage Collector может создать копии массива при сборке. Для Java/Android это нерешаемая проблема — единственное полное решение — NDK + mlock + explicit_bzero.
10.4. Английский контент фейков
Текущие пулы сообщений — на английском. Для русскоговорящего пользователя англоязычные чаты подозрительны. Необходима локализация пулов под язык устройства.
10.5. Пустая история после входа
В panic mode WebSocket отключён → новые сообщения не приходят. Если следователь наблюдает за телефоном длительное время, отсутствие входящих вызовет вопросы. Частичное решение — генерировать фейковый «incoming message» по таймеру, но это значительно усложняет систему.
10.6. Rubber-hose cryptanalysis
Никакая техническая мера не защищает от достаточно мотивированного физического насилия. Panic Mode снижает порог «знаю, что скрываешь» до «может быть, скрываешь», но не устраняет его полностью. Это инструмент для покупки времени, а не абсолютная защита.
11. Заключение
Panic Mode — это реализация принципа «не скрывай — подменяй» для мессенджера:
Две SQLCipher базы — криптографическая развилка без
if/elseс PINDecoyDataGenerator — зеркалирует структуру реальных чатов, логарифмически масштабирует сообщения, использует SecureRandom
PanicModeWorker — AES-128-GCM panic-алерт, замаскированный под
metadata_sync, с гарантией доставки через WorkManagerСетевая изоляция — WebSocket, push-токены и real-time данные полностью отключены в panic mode
Это не серебряная пуля — у подхода есть конкретные ограничения. Но для сценария «показать телефон за 5 минут» — это разница между «здесь скрытые чаты» и «обычный мессенджер, вот Alex пишет See you at 6».
Что можно забрать в свой проект:
Криптографический fork вместо условного — пусть шифрование решает, какой путь выбрать, а не ваш код
Структурная мимикрия — фейковые данные должны повторять форму реальных
Камуфляж сетевых запросов — критические сигналы должны быть неотличимы от рутинного трафика
Логарифмическое масштабирование — универсальный приём для «достаточно, чтобы выглядело реально, не слишком, чтобы было дорого»
Источники и дальнейшее чтение
Plausible deniability:
VeraCrypt: Plausible Deniability — идеологическая основа hidden volumes
UK RIPA Part III — закон, обязывающий раскрывать ключи шифрования
Czeskis A. et al. — Defeating Encrypted and Deniable File Systems (USENIX Security '08)
SQLCipher:
SQLCipher Design — 256-bit AES, PBKDF2 key derivation, HMAC-SHA512 page authentication
Mobile forensics:
Anglano C. — Forensic analysis of WhatsApp Messenger on Android smartphones (Digital Investigation, 2014)
Cellebrite UFED — промышленный инструмент извлечения данных из мобильных устройств
Исходный код проекта: github.com/w78flezeex/Xipher.pro (copyleft-лицензия)
Это вторая статья из серии о криптографической архитектуре Xipher. Первая была про защиту метаданных (Metadata Guard). Если интересен разбор E2EE-слоя (X25519 + Double Ratchet) — пишите в комментариях.
Комментарии (84)
remindscope
24.02.2026 21:54Зачем подделывать вообще все чаты, мне не очень понятно.
Предположим, мы имеем дело с разъяренным партнёром. Попробуйте ему объяснить, куда пропала переписка с ним самим.
Конечное количество сообщений тоже можно было бы сделать элегантнее - в момент доскролла до конца показывать уведомление, что нет сети.
Если мы говорим про сценарий со следователем, то в момент проверки телефона с большой вероятностью у него уже будет на вас досье. Совпадут ли данные из досье с выдуманными сообщениями?
Имхо, только в аэропорту и прокатит такая история, что печально - видно, как много усилий было вложено.
Flux82
24.02.2026 21:54Сюда вряд ли вложено много усилий, а вложено пара десятков долларов за работу LLM-агента для написания кода. Структуризация статьи и стиль описания тоже соответствует LLM.
По сути же есть очень много провалов, которые комментаторы здесь отметили. Решение в текущем виде не годится вообще и вызовет подозрений гораздо больше, чем снимет. Разумно было бы секретные чаты хранить в БД вперемешку с несекретными, но доступ к ним получать по другому ключу.
Но даже здесь будет провал, потому что завтра за то, что сегодня не запрещено, будут сажать ("продолжающееся деяние", и т.п.). Так что единственное рабочее решение - либо ехать туда где ещё есть свобода, либо не пользоваться никакими каналами связи, кроме личного общения. Впрочем, когда-то и это не поможет, когда поиск врагов наконец-то будут делать по анонимным доносам.
ArtyomOchkin
24.02.2026 21:54Согласен с вами. Кстати, под пунктом 2 статьи псевдографика прямо-таки намекает на LLM, даже больше, чем ошибка в кодировке пары символов, которую я заметил в конце статьи. Редко так тщательно просто для объяснения рисуют псевдографику.
Svortex Автор
24.02.2026 21:54Хорошие замечания, разберу по порядку.
Партнёр ищет переписку с собой, а её нет — да, это провал. Поэтому выше уже обсудили: правильнее не генерировать полностью фейковую базу, а прятать только помеченные чаты, остальное показывать как есть. Тогда переписка с партнёром на месте, просто без тех диалогов, которые ты заранее скрыл.
«Нет сети» при доскролле — элегантно, записал. Лучше чем обрыв на пустом месте.
Про следователя с досье — согласен, против целевого расследования с подготовкой decoy не поможет. Но panic mode и не про это. Он про массовые проверки: погранконтроль, рутинный досмотр, бытовые ситуации. Там не сверяют досье, а листают на месте и решают за минуту.
По сути вы правы: аэропорт, рутинная проверка, ревнивый партнёр — вот реалистичные кейсы. Следователь с ордером — нет. И честно говоря, от такого сценария не спасёт ни один мессенджер.
wtflorio
24.02.2026 21:54Отвечать на комментарии нейронкой это уже наивысший уровень "искусства"=). В целом вся статья и комментарии похожи на некий "эксперимент автора" по использованию нейросетей.
192IP
24.02.2026 21:54Да, согласен, сам сижу читаю и понимаю насколько же автору лень даже на комментарии отвечать, что он их тупо в нейронку закидывает.. у удивительном мире живём.
MamaLuyba
24.02.2026 21:54ну, судя по реальной грамматике автора (которую можно увидеть в его первом комменте на сайте), без нейронки он и диктант за пятый класс не напишет.
сам коммент (почувствуйте разницу, как грится):
зачем подобное пропускает хабр - загадка
ArtyomOchkin
24.02.2026 21:54Идея в целом интересная. Но, главное, кроме концепта, сам-то мессенджер как работает? При централизации, как тот же Telegram и WhatsApp, падает устойчивость к блокировкам. А реализовать надёжный peer-to-peer мессенджер - ещё сложнее, в плане корректного соединения двух абонентов и своевременной синхронизации. Да и главное, пустой аккаунт в известном мессенджере вызовет меньше вопросов, недели открытый незнакомый опенсорсный аналог - это точно добавит вопросов ("а что это, а зачем?"/"покажите лучше tg/wa"). К слову, у меня ни разу на границе не проверяли содержимое телефона, максимум - включается или нет. Допросов, к счастью, не было :). Да и что, собственно, из законного так сильно скрывать? Одно дело не ставить Мах, и везде использовать шифрование данных, включая диски, microSD, чаты... Но вот наличие чего-то нестандартного скорее лишь привлечёт лишнее внимание.
Сам стиль статьи пропитан ChatGPT (имхо, не буду утверждать на 100%). И значки "?" на это недвусмысленно намекают ))
Это вторая статья из серии о криптографической архитектуре Xipher. Первая был�� про защиту метаданных (Metadata Guard). Если интересен разбор E2EE-слоя (X25519 + Double Ratchet) — пишите в комментариях.
Markscheider
24.02.2026 21:54И значки "?" на это недвусмысленно намекают ))
Это вторая статья из серии о криптографической архитектуре Xipher. Первая был�� про защиту метаданных
Это хабровские значки, местные :)
Ergistael
24.02.2026 21:54А зачем они? Очень бесят — на сайте, который приилее должен быть эталоном... (Про поиск по сайту умолчу: ужас.)
vvzvlad
24.02.2026 21:54Это баг на хабре (один из тысячи), который никак не могут поправить.
Markscheider
24.02.2026 21:54баг на хабре (один из тысячи)
Остальные 999 озвучите?
trinxery
24.02.2026 21:54Иногда из комментариев под статьями пропадают целые ветки, потом возвращаются (емнип у меня есть сохранённая страница, где это видно), нередко вместо страницы вылезает Javascript'овые ошибки, отрицательное число голосов (не сумма голосов, а число плюсов и минусов отдельно) на комментарии, счётчик непрочитанных комментариев и трекер работают когда как; иногда случается полный сайта отвал с 502, емнип несколько недель назад Хабр с ним лежал несколько часов...
Раз уж начали, то Хабр жутко тяжеловесный. На неплохом смартфоне читать комментарии под статьёй, где их жалкая тысяча, проблематично. Нету самых основных фич типа сжатия вставляемой картинки, из-за чего авторы регулярно радуют нас PNG'шками мегабайтных размеров. Нет кнопки копирования фрагмента кода. Поиск ужасный, "site:habr.com запрос" в Гугле наше всё. Нет поиска по закладкам (собрал туда уже несколько сотен комментариев), нет сортировки статей по числу комментариев.
Жаловаться можно ещё долго. Это я ещё почти не читаю сами статьи (наверное одна статья на тысячи прочитанных комментариев) и не пишу.
Maxim_Q
24.02.2026 21:541) Какая серверная часть мессенджера Xipher, основа Jabber (XMPP)?
2) Есть возможность изменить в телефоне название программы и иконку чтобы никто не догадался что это за прога?
UnknownUserMax
24.02.2026 21:54Пограничный контроль: вас просят разблокировать телефон и показать мессенджер. В ряде стран отказ — уголовное правонарушение (UK — Regulation of Investigatory Powers Act, Part III: до 2 лет тюрьмы за отказ предоставить ключ шифрования)
Эм, а не проще просто удалить мессенджер?
Wesha
24.02.2026 21:54Я летаю через границы со свежекупленным дешёвым телефоном.
Ищите сколько угодно.
arielf
24.02.2026 21:54Хорошее решение!
ss-pol
24.02.2026 21:54Новенький телефон без соцсетей тоже вызовет подозрения. То есть как минимум надо создать какие-то аккаунты в соцсетях (не вчера) и там что-то запостить, фоточки какие-нибудь. Также желательно отдельную симку для этого иметь, ведь многие привязываются к номеру, могут, например, поставить и активировать Телеграм с этим номером.
Но этот мессенджер явно про другой случай. Это когда у тебя забрали телефон без предварительной подготовки. Просто внезапно остановили и забрали, не дав возможности с ним что-то сделать.
Wesha
24.02.2026 21:54Новенький телефон без соцсетей тоже вызовет подозрения.
Да вы что там, совсем уже долбанулись? Ну нет у меня
телевизорасоцсетей! Я не страдаю манией всем в морду совать, что я вчера вечером кюшал! Не их это собачье дело!Впрочем, телевизора тоже нет.
ss-pol
24.02.2026 21:54Вам шашечки или ехать? Время такое. Сам по себе новенький телефон без соцсетей наверное не будет основанием для принятия решения. Но если есть ещё какие-то подозрительные факторы (например украинское гражданство при въезде в РФ), то в совокупности может сработать. Причём объяснять причину разворота в аэропорту тебе едва-ли будут.
Wesha
24.02.2026 21:54Но если есть ещё какие-то подозрительные факторы (например украинское гражданство при въезде в РФ),
Не нахожу ничего удивительного в том, что у условной Марлен Дитрих в 1943 году могли быть небольшие проблемы со въездом в СССР.
arielf
24.02.2026 21:54Новенький телефон без соцсетей тоже вызовет подозрения.
Это не их собачье дело, почему у вас чистый телефон. Максимум, что смогут -- это не впустить в ту страну. Но это же лучше, чем не выпустить из этой, верно?
Qlavrt
24.02.2026 21:54Эмм.... И при этом перестаёте пользоваться всем тем, что на основном телефоне, оставив его дома? Если же вы везете основной в багаже, то его ведь увидят на рентгене и могут заставить достать и включить и т.д.?!
Wesha
24.02.2026 21:54И при этом перестаёте пользоваться всем тем, что на основном телефоне, оставив его дома?
Я не отношусь к тем
извра, кто обклеивает комнату обоями через замочную скважину — контент я рассматриваю на нормальном большом мониторе, а на телефоне у меня только то, что необходимо вне дома — например, трекер общественного транспорта. Но зачем мне в условной России знать, когда прибывает автобус №123 в Портленде?
oeditus
24.02.2026 21:54Тогда зачем нужен свежекупленный дешёвый силиконовый дубликат?
У меня просто тоже кроме трекера транспорта и приложений вызова такси на телефоне ничего нет, но я его вожу с собой ради камеры в кармане. Кто-то пару лет назад (кажется, бриты) спросили, где, мол, клиенты соцсетей, я им ответил: «В смартфонах тинейджеров». Поржали и разошлись.
Wesha
24.02.2026 21:54Тогда зачем нужен свежекупленный дешёвый силиконовый дубликат?
Чтобы не возникало соблазна взять на минуточку оригинал и что-нибудь туда подсадить.
nixtonixto
24.02.2026 21:54Я не отношусь к тем извра, кто обклеивает комнату обоями через замочную скважину — контент я рассматриваю на нормальном большом мониторе
Для людей без дальнозоркости потреблять контент через смартфон удобней, чем с большого монитора. Статистика продаж смартфонов и ПК/ноутбуков это подтверждает.
Wesha
24.02.2026 21:54Статистика продаж смартфонов и ПК/ноутбуков это подтверждает.
«100 миллионов леммингов не могут быть неправы»?
nixtonixto
24.02.2026 21:54Вот так разорился гигант Kodak, до последнего продвигавший плёночную фотографию. Вместо того, чтобы посмотреть на действия 100 млн леммингов и вовремя перейти на цифрофото.
Tragern
24.02.2026 21:54Тогда уж всю "опасную информацию" проще засунуть на отдельный носитель, заодно вообще всë вытащив из телефона, и спрятать весьма глубоко в одежду и ещë и металлическую упаковку в ней.
А телефон до упора забить кучей разных имеющих необходимость абстрактно в целом для большинства людей, но лично бесполезных (главное - поддерживаемых) приложений...
Wesha
24.02.2026 21:54Зачем «в одежду» — всевозможные дропбоксы пока ещё не забанили, а даже если забанят — вполне поместится на SD‑карточку (в зашифрованном виде, конечно).
Tragern
24.02.2026 21:54А ещë лучше - иметь среди "свежекупленных" такой, по которому чисто технически будет понятно, что им невозможно долго пользоваться именно как телефоном, не считая того, что внутри него ничего нет физически...
ss-pol
24.02.2026 21:54> не проще просто удалить мессенджер?
Этот режим, очевидно, для случая, когда нет времени/возможности удалить. Иначе да - просто удаляешь и всё.
Другое дело, что 99.99% людей сидит в популярных сетях и именно они в общем случае будут интересовать как досматривающего, так и тебя самого.Какие-то частные мессенджеры, с тремя абонентами, будут неинтересны в общем случае, и прежде всего самому тебе.
UnknownUserMax
24.02.2026 21:54нет времени/возможности удалить
смахнул пальцем телеграм наверх - удалилось меньше чем за секунду.
BugM
24.02.2026 21:54На сколько лет вас посадят за предоставлению сотруднику пограничного контроля заведомо ложной информации?
Wesha
24.02.2026 21:54Для этого надо сначала доказать, что там есть не-ложная.
BugM
24.02.2026 21:54Риск обнаружения есть всегда. Ну хотя бы по названию и внешнему виду приложения. Пограничникам любят выдавать справочники со списками подозрительных штук и кто-то из них может и запомнить. А дальше по тому же закону посидите пока не разблокируете настоящий мессенджер. Ну или пока экспертиза не разберется и не разблокирует.
Знать заранее сколько лет за такое дадут очень полезно. А то может оно того и не стоит?
0x62ash
24.02.2026 21:54Как я понял этот акт относится к уже изъятым через ордер вещам, а не к досмотру на границе
arielf
24.02.2026 21:54Никому и никогда не показывайте свой телефон. Лишь экран -- что у вас именно телефон, а не муляж. Почему? Ну потому, что с вашего телеофона могут разместить запрещённую информацию в Сети и сказать, что это вы. Много легче, чем сунуть вам в карман наркотики.
Пересечь границу очень легко -- сохраните образ телефона в облаке, обнулите телефон и восстановите из облака после пересечения. У нормальных телефонов (Samsung и Apple) есть нужные функции.
При угрозе со стороны силовиков -- нужно вввести неправильно пароль N раз, и телефон целиком обнулится. Телефон вы потом новый купите, а вот свободу -- увы.
AVikont
24.02.2026 21:54Ну потому, что с вашего телеофона могут разместить запрещённую информацию в Сети и сказать, что это вы.
А заодно переведут все деньги с банковских карт.
Хорошо ещё, если на нейтральные счета, а не в сторону каких-нибудь терорганизаций.Пересечь границу очень легко -- сохраните образ телефона в облаке, обнулите телефон и восстановите из облака после пересечения.
В крайнем случае или если пересечение разовое, можно продать телефон б/у, а на новом месте купить новый. Если пересечения регулярные, то проще на каждом месте иметь свою трубку, синхронизироваться через облако. При необходимости перевозить только SIMку, хотя обычно покупают местную карту.
AllFiction
24.02.2026 21:54Упрощу - не нужно посещать тоталитарные страны. к сожалению сейчас таки становится больше, но история показывает, что это процесс циклический.
Юмор в том что слабовики как кадровики - им не сильно интересны факты, если захотят повязать то причиной станет как раз отсутствие телефона/переписок. Историям с подписыванием чистосердечного признания на чистом листе больше столетия и не только на территории СНГ
arielf
24.02.2026 21:54Ну, если захотят повязать именно вас, то им реально причины не нужны. Но разговор про случайных жертв. И почти все эти жертвы сами раблочили свои телефоны.
Вот силовики случайным образом выбрали нескольких человек и решили их проверить. Первый разблочил им телефон, и у него нашли пост из 2014, который по новым законам что-то нарушил. Второй же отказался раблочить телефон или обнулил его, или взял новый. Первого можно сразу взять, а со вторым нужно возиться. И второго скорее всего отпустят, мол вали быстрее.
Не облегчайте им жизнь, вот про что речь.
nixtonixto
24.02.2026 21:54По факту в РБ первый отделывался сутками ареста, а второго могли избить до реанимации. Никогда не делайте то, что идёт в разрез с планами силовиков или может их рассердить.
fujikiriku
24.02.2026 21:54Целиком и полностью согласен с вами. Единственная проблема - в симкартах, их приходится возить с собой, и при ее разблокировке - может что-то быть к ней привязано. Лично я у себя постарался все с этой стороны обезопасить, но советовал знакомым только - "облачный пароль на телегу и пин-код на симку", ну помимо сброшенного на ноль телефона - потому что у каждого своя ситуация, сторонний человек все не предусмотрит.
EXOutcomes
24.02.2026 21:54Я может не специалист, но не проще ли создать виртуальное устройство на арендованном облачном сервере и если уж есть что скрывать, то темные делишки обсуждать с применением этого виртуального устройстве. А всю белую переписку вести на своём устройстве. Зачем эти фейковые мессенджеры?
arielf
24.02.2026 21:54Проблемы в том, что новые законы написаны так размыто, что по ним любого можно набутылить. Всем, кто живёт в РФ уже "есть что скрывать".
WantedPotato
24.02.2026 21:54Ерунда.
Единственная защита - не связываться с сомнительными людьми и информацией.
Wesha
24.02.2026 21:54Проблема в том, что никто не знает вчера, какие люди будут объявлены «сомнительными» завтра.
Kahelman
24.02.2026 21:544)A notice under this section imposing a disclosure requirement in respect of any protected information—
(a)must be given in writing or (if not in writing) must be given in a manner that produces a record of its having been given;
(b)must describe the protected information to which the notice relates;
(c)must specify the matters falling within subsection (2)(b)(i) or (ii) by reference to which the notice is given;
(d)must specify the office, rank or position held by the person giving it;
(e)must specify the office, rank or position of the person who for the purposes of Schedule 2 granted permission for the giving of the notice or (if the person giving the notice was entitled to give it without another person’s permission) must set out the circumstances in which that entitlement arose;
(f)must specify the time by which the notice is to be complied with; and
(g)must set out the disclosure that is required by the notice and the form and manner in which it is to be made;
and the time specified for the purposes of paragraph (f) must allow a period for compliance which is reasonable in all the circumstances.
Прежде чем Англией пугать, прочтите закон на который ссылаетесь. Это не просто пограничник попросил это сложная процедура.
Плюс как писали- проще удалить мессенджер с телефона при пересечении границы
santjagocorkez
24.02.2026 21:54Ну, если уж на то пошло, то даже в России это довольно сложная процедура, потому как является самым настоящим досмотром (акт, протокол, понятые).
У меня вызывают стойкое недоумение всякие рассказы вида «подошли в аэропорту перед вылетом, сказали разблокировать телефон». Вот самым натуральным образом.
Во-первых, подошли, и что? «Для начала представься».
Во-вторых, что значит «пройдемте»? Я задержан? Где акт с той самой пресловутой причиной задержания? Ах, не задержан? Мне и здесь достаточно неплохо.
В-третьих, предъявить телефон? Вот он. Что значит «разблокировать»? Где акт досмотра и понятые? Что значит «передать сотруднику»? Где акт об изъятии?
И все эти бумажки оставляют нестираемый след, по которому не только за незаконные действия иск вчинится, но и вчинится иск о компенсации испорченной поездки, сгоревших билетов на самолёт и так далее.
А те, кто добровольно и с песней уже на этом этапе от своих прав отказались, не нуждаются ни в каких средствах сокрытия, потому как их права и дальше будут отрицаться, а им будут вменяться самые разные нарушения независимо от их действий.
А, ну и да, если ты такой аутло, то тем более стоит отказаться от предъявления и разблокировки, потому как отказ выполнить законное (им ещё придётся доказать законность) требования сотрудника — это КоАП, а там у тебя, видимо, материал на УК. Выбор очевиден.
Wesha
24.02.2026 21:54У меня вызывают стойкое недоумение всякие рассказы вида «подошли в аэропорту перед вылетом, сказали разблокировать телефон». Вот самым натуральным образом.
Это к вопросу о том, почему люди переводят деньги на безопасный счёт. В наше время Задорнов говорил, что «Америка — страна непуганых идиотов», но в последнее время Россия к Америке непохо приблизилась, по немалому количеству показателей.
poige
24.02.2026 21:54Вводят спец. комбо — читают, например, «Мастер и Маргарита», обыск у Берлиоза, etc — расписанный как чат:
[Behemoth] Гражданин начальник, прошу отметить — примус не трогаю.
[Officer] Документы предъявите.
[Behemoth] А котам документы разве положены?
kabashin
24.02.2026 21:54Сразу вспоминается дело Эпштейна и его переписки. Зачем отправлять компрометирующие тебя документы/сообщения/файлы в интернет и хранить их на телефоне?
Quilly
24.02.2026 21:54Не проще вместо всех фейковых непонятных чатов/сообщений, фейковость которых вскроется просто прятать конкретные чаты при неверном пароле?
Или как в ватсапе скрытые чаты, которые появлются при вводе в строке поиска конкретного пароля без обратной связи, чаты появляются только при верном пароле, наличие их установить сложно по крайней мере в сценарии «ввел код-полистал-отдал телефон обратно». Разве что можно второй пароль(паник) добавить и туда чат с легендой-любовницей(ом). Этого достаточно и вполне реалистичный кейс.
А в случае с ios автор публикации знает актуальные эксплоиты на последние эдак дцать минор версий, которые позволят реверс сделать? Да и с андроид тоже на нормальных современных телефонах неплохо с безопасностью. По крайней мере явно для уровня «дай пароль». А если есть ресурсы расковырять твой телефон до байта — то в таком случае и пароль не понадобится, иные методы найдут.
Какая-то чрезмерная фича для параноиков, которой пользоваться будут 3 калеки, так еще и фейк чаты вызывают вопросы. Если достоверно знают, что у тебя жена с таким-то именем и начальник имеет такой-то аккаунт будет странно если при разблркировке там окажется набор левых чатов с кем угодно, но не с женой. При нажатии на аккаунт фейк собеседника что открывается? Какой id? При отправке сообщения в этот чат сообщение читается/отвечается на него? Нет? Ну тогда действительно фича уровня разве что погранконтроль переходить, не более. Даже в том же кейсе описанном автором, например, когда муж/парень избил в ревности, забрал телефон, получил пароль я слабо себе представляю что дадут фейк чаты.
Короче по всем фронтам максимально нелепая статья о максимально нелепом функционале. Фича ради фичи.
pendurov
24.02.2026 21:54Большое спасибо за статью. Я у себя в WWChat тоже реализовал "ПИН для ввода под принуждением", но у меня настройка - удалять всё или только E2EE чаты. Интересная мысль использовать WorkManager. Пошел думать (у меня ещё клиент для iOS и десктопы)
K0styan
Не готов оценить техническое решение, но именно поведенческая часть, как по мне, сильно хромает.
Буквально начиная с идеи, что 12 сообщений хватит для каждого чата. Проверяющие не просто смотрят на чаты - они ищут неодобряемое, поэтому будут скроллить сильно глубже, чем на 2-3 свайпа. И, кстати, могут отдельно открыть вкладку со вложениями/изображениями чата. Они могут задавать вопросы по переписке - и ответить на них владелец точно не сможет. Ну и сама по себе правдоподобность и неповторяемость текстов - тоже задачка непростая.
Поэтому идеальным вариантом всё же видится отображение в panic mode самых настоящих чатов, за вычетом отдельно отмеченных заранее.
Svortex Автор
Да, вы правы — поведенческая часть сейчас самое слабое место. 12 сообщений и шаблонные тексты не выдержат реального допроса, тут спорить нечего.
Идея с отображением реальных чатов минус помеченные — сильнее. Ты знаешь контекст, можешь ответить на вопросы, вкладка с медиа живая. Для погранконтроля и бытовых сценариев это убедительнее любой генерации.
Буду делать: пользователь заранее помечает «приватные» чаты, по panic PIN они просто исчезают, остальное — как есть. Спасибо за фидбэк.
DrMefistO
"Да, вы правы - будто Claude отвечает":)
Hadis
Какой хороший пример деструктивного влияния на межличностные коммуникации со стороны нейросетей, когда совершенно естественная и человечная фраза вызывает подозрение. Люди учатся не доверять никому и ничему. Беда в том, что тот, кто реально хочет обмануть, прекрасно об этом знает, и уж точно умеет сделать всё так, чтобы подозрений не вызвать.
Wesha
Будущее коммуникаций
DrMefistO
Человеку может быть просто лень :)
MamaLuyba
во-первых, статья и ответы на комменты написаны нейросеткой - это факт. во-вторых, не знаю, с кем ты общаешься, что для тебя написанный коммент - "естественный и человечный". даже переписки с начальством выглядят человечнее.
vvzvlad
Статья тоже такое ощущение вызывает
Wesha
А как Вам такой вариант: пин состоит из 8 (4+4) цифр, в списке чатов можно пометить «эти чаты — обычные, эти — секретные». Перед записью в базу к сообщению добавляется его контрольная сумма, и все сообщения шифруются ключом К1 из первых четырёх цифр — но сообщения «секретных» частов перед этим шифруются ключом К2 из вторых четырёх цифр, а уже получившаеся мешанина шифруется ключом К1.
Теперь следите за руками: на границе вы вводите правильные первые 4 цифры, а вторые — от балды (например, год рождения Пушкина). Сообщения из обычных чатов расшифровалось правильно и показываются как ни в чём ни бывало (у них КС совпала, и клиент их показывает), но при этом у сообщений из секретных чатов КС не совпала, и клиент их пропускает — соответственно, эти сообщения в интерфейсе не видны.
Когда за вами не следят — вводите правильно все 8 цифр, и теперь КС совпали уже у всех сообщений, и показываются все.
А ещё в базу можно добавлять «якобы сообщения», состоящие целиком из мусора — у них КС никогда не совпадёт, что бы ни было введено, и они никогда не будут показаны пользователю — но спецура будет тратить время, пытаяся расшифровать и их тоже (ха‑ха) — ведь на них не написано, что они ложные.
WASD1
А уж какой счёт за электричество (от нагрева паяльника) придёт - страшно подумать.
Такъ разоримъ.
Wesha
Я уже неоднократно писал: если противнику нельзя доверять, что он не дойдёт до такого уровня беспредела — то нужно быть альтернативно одарённым, чтобы после этого доверять его же обещаниям, что «если выдашь код, то выключим паяльник»: ведь и тут тоже обманут.
WASD1
Ага.
Ещё есть "гениальные" советы делать 2-3 секретных чата (вместо 1го).
А теперь поставьте себя на место хоть товарища майора хоть господина колонела (для которых сохранность вашей тушки в KPI если и входит, то с крайне малым коэф-ом).
Применил первый раз ректальный криптоанализатор - упала квартальная премия
Применил второй раз криптоанализатор - упала годовая премия
Применил третий раз криптоанализатор - упало внеочередное звание.
ВНИМАНИЕ ВОПРО - сколько попыток криптоаанализатора ещё произойдёт прежде чем он поймёт, что нафармить ништяков больше не получится?
Wesha
Я вот сейчас не понял — это Вы со мной сейчас соглашаетесь, или тонко ехидствовать пытаетесь?
WASD1
Как и я чуть выше - поэтому скорее по фактам, что за\против.
Сама идея - играть в игры с "товарищем майором \ господином колонелем" выглядит заведомо проигрышной при таком диспаритете возможностей.
Wesha
Вот только диспаритет этот — в мою пользу.
«Что они могут мне сделать? Максимум — убить.»