крипто плагин
Здравствуйте.
В интернет мессенджере Miranda есть возможность шифрования данных, сохраняемых в свою БД.
Шифрование вынесено в отдельный плагин. Существующий плагин производит шифрование самопальным поточным алгоритмом Athena.
Мало того, что шифр самопальный, так еще применен неправильно и шифрует одной гаммой все сохраняемые значения.
Я хочу сделать плагин с нормальным шифрованием, но существующий интерфейс плагина предоставляет зашифрованным данным ровно такой же размер, как до шифрования.
Можно ли что нибудь сделать в этом случае?
При шифровании данные необходимо сжимаются, оставшееся место можно забивать нулями/рандомом.
Но лучше не изобретать велосипед, а воспользоваться полнодисковым шифрованием. В случае винды это DiskCryptor.
"При шифровании данные необходимо сжимаются, оставшееся место можно забивать нулями/рандомом."
В общем случае неприменимо. Неизвестно насколько сожмутся данные и хватит ли полученно разницы. Кроме того данные могут быть например размером всего в несколько байт. Как такие сжимать?
"Но лучше не изобретать велосипед, а воспользоваться полнодисковым шифрованием. В случае винды это DiskCryptor."
Полнодисковое шифрование это отдельный класс защиты. Здесь интересует конкретно шифрование данных в БД.
Это крайне нерекомендуемая полумера. Если вы понимаете, что следы на диске потенциально остаются несмотря на шифрование, вам это должно быть очевидно.
Цитаты ставятся[link1] так: <[текст цитаты]>
Полнодисковое шифрование используется. Но у него имееются свои векторы атаки, так скажем. Интересует шифрование записей в БД. В общем случае, можно ли сделать нормальное шифрование, если выходной размер должен быть не больше входного.
[humor]
Напомнило:
Phillip Rogaway, Thomas Shrimpton "The SIV Mode of Operation for Deterministic Authenticated-Encryption (Key Wrap) and Misuse-Resistant Nonce-Based Authenticated-Encryption"[link2]
P. Rogaway, T. Shrimpton "Deterministic Authenticated-Encryption A Provable-Security Treatment of the Key-Wrap Problem"[link3]
[/humor]
А если серьёзно, то по теме можете ещё погуглить видео лекции "Deterministic Encryption:SIV and wide PRP (21 min)". Есть и с субтитрами.
unknown
эээ... а можно как нибудь своими словами?
Я так понимаю, что ничего в такой ситуации не сделать?
Ну если совсем на пальцах на уровне фольклорной схемы...
Посчитайте хэш-функцию всех блоков открытого текста, кроме первого. Используйте это число в качестве вектора инициализации. Поскольку такой вектор инициализации не из рэндома, то он синтетический — SIV. Зашифруйте весь открытый текст в режиме CBC с использованием SIV вместо IV. Поскольку такое шифрование не рэндомизированное, то оно детерминистское. Дописывать этот SIV в начало шифртекста не нужно, поэтому размер шифртекста не растёт. Последний блок открытого текста обычно не кратен блоку шифра, но это стандартная тривиально решаемая проблема: ещё раз пошифровать предыдущий блок и с его итерации получить нужное количество битов гаммы для ксора с открытым текстом; или использовать ciphertext stealing.
Расшифровывается всё в обратном порядке. Зная ключ, текущий и предыдущий блоки шифртекста, получаем текущий блок открытого текста. Так расшифровываем весь открытый текст, кроме первого блока, из него (всего открытого текста кроме первого блока) хэшированием вычисляем SIV и при помощи него расшифровываем первый блок.
Это примитивная иллюстрация принципа SIV/Deterministic encryption. Может быть, это лучше чем ничего. По-настоящему требуется нечто более сложное (не ради сложности, а ради соблюдения множества критериев безопасности и практичности), подо что пытается подвести доказуемое решение Рогувэй, Шримптон и др. и то, это пока ещё слишком сырое решение. Готового и доверяемого режима, который можно было бы взять для этой цели из какой-либо библиотеки, скорее всего нет.
unknown
Более менее понятно.
А что делать, если размер данных меньше размера блока?
В детерминированном шифровании основной недостаток напрямую вытекает из принципа работы — извлечения энтропии из открытого текста. А она при прочих равных тем меньше, чем меньше размер этого текста и будет существенно малой, если размер открытого текста меньше размера блока.
Существуют ещё и т.н. режимы "length preserving encryption", позволяющие в т.ч. получать псевдослучайную перестановку (PRP) произвольно малого размера по отношению к блоку стандартного шифра (напр. из AES). И недостаток здесь такой же: PRP размером в 1 байт м.б. неотличима от идеально случайной, но её стойкость будет ограничиваться тем, что против неё можно осуществить брутфорс — перебрать 256 вариантов.
Если соединить SIV, Deterministic Encryption, Length Preserving Encryption и ещё Tweakable Encryption (чтобы кроме ключа и IV подавать на вход шифра, например, номер записи в базе), то теоретически можно получить то, что нужно.
Это работа для теоретика неслабого уровня, в которой придёться рассмотреть много подводных камней и привести непростые доказательства, иначе такой работе не стоит доверять.
Оно точно вам нужно? Или проще переписать программу под работу с базой другого формата, который бы использовал только простые стандартные режимы шифрования — без экономии размера полей и с полной рэндомизацией?
Обычно для компьютерного софта выбирают такой путь. А сверхэкономный эксклюзив проектируют спецы для каких-нибудь сверхминиатюрных устройств, смарт-карт и т.д. Как-то использовать такие прецизионные режимы шифрования для обычных программ — это как забивать гвозди микроскопом.
по-взрослому копья ломаются вокруг Миранды..
Для Thunderbird не помешало бы. Искал – не нашёл. Казалось бы, чего сложного шифровать мастер-паролем не только пароли, но и всю почтовую базу. Да что там базу – всю папку профиля. При запуске запрашивается пароль, выбираешь профиль (кстати!) и загружаешь. Вроде всё необходимое для этого в программе присутствует.
у Бата есть. ну а почему вообще в контейнер не разместить Thunderbird или Миранду? отпадет необходимость шифрования профиля..
Если можно было бы перешифровывать всю базу (при каждой записи или хотя бы при каждом сеансе), то тогда другое дело. Это было бы просто реализуемым решением.
unknown
Просто хотелось ограничиться только крипто плагином, но видимо все же придется переделывать драйвер БД...
Идея сводится к тому, чтобы все данные на диск программа писала только шифрованными, следила за wipe'ом удаляемых файлов и т.д. Последовательное решение этой проблемы превращается в переизобретение файловой системы с поддержкой шифрования. В частном случае будет что-то типа ad hoc решений а-ля ecryptFS[link4], но у них есть существенные[link5] трудности. Как уже отметил unknown, игра не стоит свеч: проще переписать формат базы данных или воспользоваться полнодисковым шифрованием / отдельным контейнером.