Пишем свой crypto engine для флешек: безопасная память, потоковое шифрование и отказоустойчивость на Python

[SkifDS]

У меня доверия к флешкам с шифрованием не было, нет и не будет. Поясню. В одной компании, где я работал лет 10 назад, пришел перец в качестве комдира и сказал, а давайте мы купим флеху с аппаратным шифрованием и будем хранить на ней базу бухгалтерии. Гендир сказал: О, а давайте, круто же. Все возражения ИТ-отдела (в том числе, официальную служебку. Я ж знал, чем все кончится) послали в центр скульптурной композиции статуи Давида. В итоге флеха сдохла (производитель послал туда же, куда ранее послали ИТ отдел) через пару месяцев, а бакапов базы не было (ну а зачем тогда флеха-то?). И бухи с матом, воем и стоном восстанавливали базу из первички полгода.

Я это к тому, что флешка, имхо, изначально не надежный носитель данных. И если в обычных условиях с нее есть шансы хоть что-то выдернуть, то в случае с шифрованием будет полный тухляк.

[tuxi]

Если я правильно понял, тут решалась задача относительно безопасного способа передачи данных, а не хранения как единственный экземпляр. Так что, "почему бы и нет".

[Valsha]

Так "флешка" это вроде как в качестве примера, можно же использовать SSD винт внешний, у него же надежность будет явно выше, но это тоже вроде как считается "флешкой". Разве нет?

[K0Jlya9]

Почему не VeraCrypt?

Почему питон? Если это вайбкодинг то можно использовать нормальный язык, го например, там и бинарник нормальный будет собран, и GILа не будет, и с байтоблудием нормально всё.

Что вообще происходит, какая задача решается. Почему не Bitlocker/7zip.

Вставил флешку с какими то файлами, скопировал на нее свой бинарник(или 3 бинарника для разных ос?), запустил, ввел пароль и ждешь пока он зашифрует каждый файл по отдельности? Потом передал получателю который в своем компе так же расшифровал? Звучит как будто сову натянули на глобус.

[ki11j0y]

Флеш с скзи, рутокен 2.0 флеш например. Вполне надёжно.

[dimone73]

Рутокен пардон насколько понимаю это типа sim карты с usb интерфейсом, но ни как не средство хранения.

А хотя посмотрел - для 2.0 действительно предусмотрен раздел

[roma1052]

Интересный подход к реализации SecureBytes. Работа с памятью в Python и GC — вечная головная боль для криптографических утилит, и использование bytearray с многопроходной затиркой по NIST SP 800-88 — это зрелое решение для проекта на управляемом языке.

Особенно зацепил момент с деривацией nonce для каждого блока. Часто в самописных движках об этом забывают, что превращает AES-GCM в решето.

Кстати, как исследователь в области квантовой криптографии (сейчас как раз пишу статью про симуляцию BB84), не могу не спросить: не планировали ли вы добавить поддержку алгоритмов, устойчивых к квантовым угрозам (Post-Quantum Cryptography)? Для флешек с долгим сроком хранения данных стратегия «Harvest now, decrypt later» становится вполне реальной угрозой.

В остальном — отличный инженерный разбор, особенно за систему rollback при сбоях. Удачи проекту!

[slimeopus]

Спасибо за такой подробный и профессиональный разбор! Очень приятно, что оценили именно технические детали — работу с памятью и деривацию nonce.

Насчёт Post-Quantum Cryptography — отличный вопрос! Честно признаюсь, пока не углублялся в эту тему достаточно глубоко, чтобы грамотно реализовать. Но для флешек с долгосрочным хранением это действительно актуально, стратегия «Harvest now, decrypt later» — серьёзный аргумент.

Если получится найти время и разобраться с PQC-алгоритмами (скорее всего начну с Kyber/Dilithium из финалистов NIST), то обязательно добавлю поддержку. Возможно даже как опциональный режим для особо важных данных.

Кстати, если у вас есть рекомендации по библиотекам или материалам для старта — буду очень благодарен! Всегда интересно учиться у экспертов в области квантовой криптографии.

Ещё раз спасибо за комментарий и удачи со статьёй про BB84!

[roma1052]

Рад, что тема PQC отозвалась! Для старта с Kyber (ML-KEM) и Dilithium (ML-DSA) в экосистеме Python очень рекомендую заглянуть в сторону библиотеки liboqs (через их официальные python-врапперы). Это сейчас стандарт де-факто для экспериментов с алгоритмами, прошедшими отбор NIST.

Для вашего кейса с флешками стоит учесть пару нюансов:

• Размер ключей: PQC-алгоритмы генерируют ключи и подписи значительно большего размера, чем классика. При потоковом шифровании это может потребовать пересмотра структуры метаданных.

• Гибридный режим: Сейчас хорошим тоном считается использовать "комбинированное" шифрование (например, классический AES + постквантовый инкапсулятор). Это гарантирует, что даже если в новых алгоритмах NIST найдут уязвимость, данные останутся защищены классикой.

Для глубокого погружения также советую ресурс PQC-Zoo и документацию проекта Open Quantum Safe. Удачи с внедрением, будет интересно увидеть реализацию Kyber в вашем движке!

[Mirron11]

Добрый день! Прекрасно, что вы стараетесь разбраться, как использовать криптографию.

Увидел проблемы:

• из-за разницы в использовании nonce в зависимости от размера файла и из-за использования AEAD (шифртекст больше открытого текста на размер тэга -- 16 Б), файл, зашифрованный в режиме non-streaming (размером (100 МБ - 8 Б)) будет расшифровываться в режиме streaming. Nonce при зашифровании и расшифровании не совпадет.

• заявленная отказоустойчивость недействительна, потому что расшифрование файла зависит еще и от франимых в метаданных nonce, а файл с метаданными сохраняется после зашифрования всех файлов.

Предложил бы использовать AI в том числе в качестве ревьюера. Он нашел больше проблем, чем я увидел своими глазами, например:

• зашифрование в поточном режиме не работает, потому что последовательно делаются два цикла for chunk in reader.iter_chunks() (второй цикл сразу выйдет);

• verify несовместим со streaming: делает cipher.decrypt всего файла, независимо от размера.

[slimeopus]

Большое спасибо за внимательный код-ревью! Вы абсолютно правы - все найденные проблемы реальны и критичны:

1. Проблема с nonce - действительно, из-за AEAD-тега (16 байт) зашифрованный файл превышает порог и пытается расшифроваться в потоковом режиме с другими nonce. Это фатальная ошибка.

2. Двойной цикл - классическая ошибка: итератор уже исчерпан после первого прохода для вычисления хеша.

3. verify_encryption_integrity - полностью загружает файл в память, что противоречит идее потоковой обработки.

4. Отказоустойчивость - метаданные сохраняются после шифрования, поэтому при сбое между этими операциями данные теряются.

Это отличный пример того, почему криптографический код требует особенно тщательного ревью. Исправлю все замечания в следующей версии.

Еще раз спасибо за детальный анализ!