Автор эксперимента на Habr предлагает не просто шифровать запись с персональными данными, а «растворять» её в массиве семантически правдоподобных вариантов. Проверить идею можно в открытой песочнице — но заявленную стойкость ещё предстоит доказать на практике.
Суть события
В опубликованном эксперименте разбирается жёсткий сценарий: злоумышленник уже получил файл, в котором находятся телефон, email, паспортные данные, адрес, ИНН и СНИЛС. Автор намеренно облегчает атаку и раскрывает почти всё сопутствующее: длину сообщения, число слов, PIN и порядок слов.
Скрытыми остаются секретное векторное пространство и алгоритм сборки. По замыслу автора, именно они превращают утечку файла в задачу без однозначного ответа: перебор порождает миллионы осмысленных комбинаций, а отличить настоящую запись от правдоподобных ложных вариантов архитектурно невозможно. Это заявление автора подхода, а не результат независимой проверки.
Детали
Приведённое сообщение содержит 361 символ, 317 символов без пробелов и 45 слов. Эти параметры не объявляются дополнительным секретом. Такой дизайн интересен тем, что защита должна сохраняться даже после раскрытия структуры записи и части служебных данных — типичная ставка не на тайну формата, а на недоступность ключевого механизма восстановления.
Для обычного пользователя практический вопрос прост: сможет ли похититель после утечки понять, где именно его паспорт или адрес. Предложенный ответ — нет, если у атакующего отсутствуют векторное пространство и алгоритм сборки. Однако из исходного материала нельзя сделать вывод, что метод уже прошёл криптографический аудит, выдержал целевые атаки или готов заменить существующие средства защиты.
Контекст
Подход меняет последствия компрометации: ценность украденного массива должна снижаться, поскольку каждая убедительная версия конкурирует с множеством других. Но это не отменяет базовую безопасность хранения. Если вместе с данными утекут секретное пространство или алгоритм сборки, исходная предпосылка эксперимента изменится; источник не сообщает, как система ведёт себя в таком сценарии.
Есть и эксплуатационные вопросы: как выдавать доступ законному пользователю, менять секреты, делать резервные копии и восстанавливать данные без потери. Для команд, которые соединяют разнородные хранилища, полезен также наш материал о том, как объединить 15+ баз данных в TypeScript-приложении. Он не проверяет эту защитную схему, но показывает, почему архитектура доступа важна не меньше формата данных.
Что дальше
Автор приглашает желающих испытать подход в песочнице. Самый полезный следующий шаг — пытаться не угадать одну запись, а найти воспроизводимый способ отличать истинный вариант от ложных, имея все раскрытые параметры. Именно такой тест проверяет центральное обещание идеи.
Компаниям пока разумно рассматривать эксперимент как исследовательскую гипотезу. До внедрения нужны независимый разбор модели угроз, аудит алгоритма, оценка ошибок восстановления и понятный план действий при утечке секретных компонентов. Иначе необычная конструкция может дать ложное чувство безопасности — пожалуй, самый дорогой результат любого защитного эксперимента.
