| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Алгоритмы > Нужна ли соль при шифровании данных |
| Автор: Fobos 29.2.2012, 11:13 |
| Всем привет, разрабатываю одну программу и необходимо хранить данные в базе данных при этом в зашифрованном виде. Шифрование применяю симметричное. Для того чтобы не расшифровали перебором - к данным прикрепляю соль в открытом виде которая хранится в открытом виде в этой же таблице. Тут меня терзают сомнения, про соль в основном видел примеры с такой аргументацией: "для многих вычисленных хэшей есть уже готовые таблицы, поэтому просто вычислить хэш недостаточно, надо к хэшу присоединить произвольную строку, чтобы поиск по таблицам не помог". Тут все понятно, а вот как быть с симметричным шированием? Ведь по сути соль лежит рядом с зашифрованными данными? Это же не хэш. В общем оправдано ли такое применение соли(лежит рядом в открытом виде) или необходимо чтобы соль была тоже неизвестна? |
| Автор: Akina 29.2.2012, 11:41 |
| Что такое "соль" в данном контексте? имитовставка? |
| Автор: Fobos 29.2.2012, 12:10 |
| Да, некий произвольный массив данных, т.е. я беру шифруемые данные присоединяю к ним этот массив и шифрую Собственно можно даже вопрос так переформулировать: 1. Нужна ли вообще соль при симметричном шифровании или все определяется длиной ключа? 2. Нужна ли она в случае если у меня размер шифруемых данных очень мал? |
| Автор: Akina 29.2.2012, 13:05 |
| Обычно шифрование выполняется блоками определённой длины. Если блок меньше (скажем хвостовой) - он всё равно дополняется до полного (нулевыми битами, текстовыми пробелами и пр.). Так что постановка имитовставки - это обычная практика. Если же перед шифрованием шифруемый поток порезать на блоки случайной длины и дополнить случайными битами в случайных позициях (понятное дело, восстановимых) - мат. стойкость шифрования значительно увеличится, потому что усложнится процесс идентификации удачи при брутфорсе. |
| Автор: Fobos 29.2.2012, 13:32 | ||
Хм, насчет хвостовых блоков и дополнения - не думаю что это необходимо выполнять разработчику, это деталь реализации - зачем мне как пользователю криптобибилотеки знать о размерах блоков которыми шифруются данные и подгонять размер своих данных под "необходимый" На мой взгляд реализация должна сама дополнить шифруемый блок данных до требуемого и зашифровать. Криптостойкость не должна зависеть от длины шифруемого сообщения, а только от размера ключа - я прав? |
| Автор: Akina 29.2.2012, 22:50 | ||||
А ты и не будешь знать. Если ты пользователь криптобиблиотеки.
Зависит от алгоритма. |
| Автор: volatile 29.2.2012, 23:58 | ||
Это только поможет взломать шифр. Когда есть шифр и часть зашифрованного текста, взлом упрощается по сравненю с тем, когда есть только шифр. В качестве соли берут обычно случайную последовательность, которую естественно нигде не хранят. |
| Автор: Alexandr87 1.3.2012, 14:01 | ||
| Я так понял, ответа на вопрос так и не было ) В хэш-функции секретных входных параметров нет, поэтому ко всяким там паролям перед хэшированием "примешивают соль" (добавляют к хэшируемым данным дополнительные данные, известные приложению). После этого, даже если стырят базу с хэшами они не смогут сделать поиск хэшируемого текста в заранее просчитанных базах. В шифровании есть секретный элемент - ключ, и поэтому прикрепление дополнительных данных к зашифровываемому тексту не улучшит стойкость шифрования против перебора. )))
мат. стойкость шифрования не увелится. Да и вообще от лукавого всё это - по теории стойкость шифрования должна строится только на знании секретного ключа, а никак не знании алгоритма. |
| Автор: Akina 1.3.2012, 14:06 | ||
По теории - да. Но если метод имеет математические или статистические уязвимости? |
| Автор: Alexandr87 1.3.2012, 14:08 | ||
мы щас об алгоритме шифрования Васи Пупкина? Извините, я такие не рассматривал. |
| Автор: marijuana1 5.3.2012, 05:31 |
| гуглите про радужные таблицы |
| Автор: tzirechnoy 10.3.2012, 18:43 |
| Если использовать соль как в паролях, присоединяя её к тексту -- то да, от наличия части текста стойкость шыфрования уменьшается. Часто -- резко. Но без соли сразу обнаружываются повторяющиесе блоки текста, что само по себе плохо, а часто очень плохо. Потому соль использовать надо, но с умом -- например, XORить её с исходным текстом или там в качестве полинома для его преобразования использовать. |
| Автор: volatile 11.3.2012, 10:46 | ||
| Я думаю ТС немного спутал соль при хешировании паролей в базе данных, и соль при простом симметричном шифровании. В первом случае, соль действительно нужно хранить, иначе не проверить пароль. Во втором, хранить не нужно.
Выглядит это примерно так. Допустим, есть секретный текст: "Секретный текст" К этому секретному тексту добавляется маркер конца строки (В С/С++ это '\0', например) После маркера добавляется случайная последовательность, до заполнения блока. Выглядит это примерно так "Секретный текст\0@#$%$#@#$%" И вся это шифруется. Случайную последовательность инициализировать текущим временем, или другими трудно угадывамыми параметрми (положение мыши, и т.д.). Ее нигде не запоминать, и уж тем более не хранить! Для расшифровки она не нужна. Одинаковый текст, зашифрованный таким образом, будет выглядеть каждый раз по разному. Если секретный текст больше 60% размера блока, нужно разбить его на несколько частей, так чтобы было примерно 60%-текста, 40%-случайного "мусора" в каждом блоке. Ну соотношение может быть и другое, это степень паранои дело вкуса . |
| Автор: Alexandr87 12.3.2012, 13:54 | ||||
Пержде чем изобретать сомнитвельного качестве велосипед, рекомендую ознакомиться с режимами блочного шифрования: http://en.wikipedia.org/wiki/Cipher_block_chaining
Мда, вот такие алгоритмы и придумывают при незнании стандартных, нормальных подходов.(ссылка выше). А почему именно 40% процентов мусора. А если мусора будет 60%, то по-вашему стойкость будет выше? Да и, а вот если надо не строку шифровать, а массив байт, там \0 может встретиться внутри данных, вы как будете опередлять который из \0 ограничитель |
| Автор: volatile 13.3.2012, 00:05 | ||||||
А причем здесь вообще режимы блочного шифрования? Их никто не отменял, и не подменял. Здесь вообще не про это.
Всё это решается элементарно, когда дойдет дело до написания реального кода. Смысл сказанного в разъяснении принципа, а уж как его применить к не текстовым данным, любой мало-мальски программирующий додумается.
Написать дежурную фразу типа "это-велосипед", и тыкнуть куда-нибудь в английскую википедию, можно на 95% всех топиков форума. Впрочем, поступлю так-же, (а че действительно напрягаться, объяснять что-то?) http://www.di-mgt.com.au/cryptopad.html. |
| Автор: Alexandr87 13.3.2012, 07:21 | ||||||
да не обижайтесь вы, просто реально отвечаете не разбираясь в вопросе. Если бы вы прочитали сами ссылку, которую выложили, то там ясно написано, что падинг применяется лишь для добивания последнего блока (когда используется режиме шифрования блоками), а никак не для подстановки в каждый блок с целью внести случайность. (Если посмотреть то большинство стандартных методов падинга вообще не вносят случайность)
При том, что режимы блочного шифрования как раз и решают проблему одинаковых выходных блоков при одинаковых входных в режиме блочного шифрования ECB. Ну и коль уж вы решили спорить, то ответьте пожалуйста на вопрос из моего предыдущего поста:
|
| Автор: volatile 14.3.2012, 02:20 | ||||||
Мне кажется вы не знаете что такое ECB Вот http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B6%D0%B8%D0%BC_%D1%8D%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%BE%D0%BD%D0%BD%D0%BE%D0%B9_%D0%BA%D0%BE%D0%B4%D0%BE%D0%B2%D0%BE%D0%B9_%D0%BA%D0%BD%D0%B8%D0%B3%D0%B8 на русском
то есть диаметрально противоположное вашим предположениям.
я вообще не собирась ни с кем спорить. я просто дал одну из версий что можно сделать, и она гарантировано не понижает стойкость, по сравнению с тем что ТС хотел вначале. А уж использовать это, или нет, это его дело. Спорить, или доказывать кому-то чего-то в мои планы не входит, так что соори. |
| Автор: Alexandr87 14.3.2012, 08:10 | ||||||||||
1. это были не предположения, а утверждения
не удивлен.
Вы точно уверены, что диаметрально противоположны?
жаль. Ведь видно, что после прочтения вы осознали, что фигню писали. Но признаться в этом не позволяет гордость. Ок  |
| Автор: volatile 14.3.2012, 23:56 | ||
Я честно говоря надеялся что вы описАлись вчера просто, или не до конца поняли английское отрицание. Поэтому собственно и привел цитату с русскогй википедии. Но дело оказывается не в языке  Короче.Alexandr87, извинте меня, но не хочу вести дискуссию, в стиле reductio ad absurdum Да. Если есть еще какие претензии, то направляйте их http://ru.wikipedia.org/. Желаю удачи. |
