Всем привет, разрабатываю одну программу и необходимо хранить данные в базе данных при этом в зашифрованном виде. Шифрование применяю симметричное. Для того чтобы не расшифровали перебором - к данным прикрепляю соль в открытом виде которая хранится в открытом виде в этой же таблице.
Тут меня терзают сомнения, про соль в основном видел примеры с такой аргументацией: "для многих вычисленных хэшей есть уже готовые таблицы, поэтому просто вычислить хэш недостаточно, надо к хэшу присоединить произвольную строку, чтобы поиск по таблицам не помог".
Тут все понятно, а вот как быть с симметричным шированием? Ведь по сути соль лежит рядом с зашифрованными данными? Это же не хэш. В общем оправдано ли такое применение соли(лежит рядом в открытом виде) или необходимо чтобы соль была тоже неизвестна?

Что такое "соль" в данном контексте? имитовставка?

Да, некий произвольный массив данных, т.е. я беру шифруемые данные присоединяю к ним этот массив и шифрую
Собственно можно даже вопрос так переформулировать:
1. Нужна ли вообще соль при симметричном шифровании или все определяется длиной ключа? 
2. Нужна ли она в случае если у меня размер шифруемых данных очень мал?

Это сообщение отредактировал(а) Fobos - 29.2.2012, 12:18

Обычно шифрование выполняется блоками определённой длины. Если блок меньше (скажем хвостовой) - он всё равно дополняется до полного (нулевыми битами, текстовыми пробелами и пр.). Так что постановка имитовставки - это обычная практика.

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

Хм, насчет хвостовых блоков и дополнения - не думаю что это необходимо выполнять разработчику, это деталь реализации - зачем мне как пользователю криптобибилотеки знать о размерах блоков которыми шифруются данные и подгонять размер своих данных под "необходимый"
На мой взгляд реализация должна сама дополнить шифруемый блок данных до требуемого и зашифровать.
Криптостойкость не должна зависеть от длины шифруемого сообщения, а только от размера ключа - я прав?

А ты и не будешь знать. Если ты пользователь криптобиблиотеки.


Зависит от алгоритма.

Это только поможет взломать шифр. Когда есть шифр и часть зашифрованного текста, взлом упрощается по сравненю с тем, когда есть только шифр.

В качестве соли берут обычно случайную последовательность, которую естественно нигде не хранят.

Я так понял, ответа на вопрос так и не было )

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

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




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

По теории - да. Но если метод имеет математические или статистические уязвимости?

мы щас об алгоритме шифрования Васи Пупкина? Извините, я такие не рассматривал.

гуглите про радужные таблицы

Если использовать соль как в паролях, присоединяя её к тексту -- то да, от наличия части текста стойкость шыфрования уменьшается. Часто -- резко. Но без соли сразу обнаружываются повторяющиесе блоки текста, что само по себе плохо, а часто очень плохо. Потому соль использовать надо, но с умом -- например, XORить её с исходным текстом или там в качестве полинома для его преобразования использовать.

Я думаю ТС немного спутал соль при хешировании паролей в базе данных, и соль при простом симметричном шифровании.
В первом случае, соль действительно нужно хранить, иначе не проверить пароль.
Во втором, хранить не нужно.


Выглядит это примерно так.
Допустим, есть секретный текст: "Секретный текст"
К этому секретному тексту добавляется маркер конца строки (В С/С++ это '\0', например)
После маркера добавляется случайная последовательность, до заполнения блока.
Выглядит это примерно так "Секретный текст\0@#$%$#@#$%"
И вся это шифруется.

Случайную последовательность инициализировать текущим временем, или другими трудно угадывамыми параметрми (положение мыши, и т.д.).
Ее нигде не запоминать, и уж тем более не хранить! Для расшифровки она не нужна.
Одинаковый текст, зашифрованный таким образом, будет выглядеть каждый раз по разному.

Если секретный текст больше 60% размера блока, нужно разбить его на несколько частей, так чтобы было примерно 60%-текста, 40%-случайного "мусора" в каждом блоке. Ну соотношение может быть и другое, это степень паранои дело вкуса .


Это сообщение отредактировал(а) volatile - 11.3.2012, 10:58

Пержде чем изобретать сомнитвельного качестве велосипед, рекомендую ознакомиться с режимами блочного шифрования: http://en.wikipedia.org/wiki/Cipher_block_chaining



Мда, вот такие алгоритмы и придумывают при незнании стандартных, нормальных подходов.(ссылка выше). 
А почему именно 40% процентов мусора. А если мусора будет 60%, то по-вашему стойкость будет выше?
Да и, а вот если надо не строку шифровать, а массив байт, там \0 может встретиться внутри данных, вы как будете опередлять который из \0 ограничитель

А причем здесь вообще режимы блочного шифрования?
Их никто не отменял, и не подменял. Здесь вообще не про это.


Всё это решается элементарно, когда дойдет дело до написания реального кода.
Смысл сказанного в разъяснении принципа, а уж как его применить к не текстовым данным, любой мало-мальски программирующий додумается.


Написать дежурную фразу типа "это-велосипед", и тыкнуть куда-нибудь в английскую википедию, можно на 95% всех топиков форума.
Впрочем, поступлю так-же, (а че действительно напрягаться, объяснять что-то?)
Читайте.


Это сообщение отредактировал(а) volatile - 13.3.2012, 00:21