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