LINUX.ORG.RU

Посоветуйте симметрический алгоритм шифрования


0

0

Посоветуйте симметрический алгоритм шифрования, наиболее устойчивый, по вашему мнению. Желательно два варианта:

1. Свободный от патентов.

2. Несвободный от патентов, но с открытым алгоритмом.

>Посоветуйте симметрический алгоритм шифрования, наиболее устойчивый, по вашему мнению.

Симметрический алгоритм сделать устойчивым немудрено. Сделай хоть виртуальную энигму с тысячей колесиков и предварительной зиповкой.

Absurd ★★★
()

1. Blowfish

2. А зачем если в 1-м варианте алгоритм и так открыт.

Lucky1 ★★★
()

Шифрование с закрытым алгоритмом (пункт 2) можно выбрасывать на помойку сразу. Все алгоритмы шифрования должны быть открыты, это основа криптографии.

anonymous
()

1) AES (Rijndael) , Blowfish

2) другие кандидаты в AES: MARS , Serpent


Sylvia ★★★★★
()

ГОСТ 28147-89 "Система обработки информации. Защита криптографическая"

anonymous
()

Без конкретизации.. Специально для вас стандарты пишут.

AES/128

vasily_pupkin ★★★★★
()
Ответ на: комментарий от anonymous

закрытый != несвободный от патентов

Reset ★★★★★
()

Шифрования чего? Прежде всего при выборе следует учитывать необходимую надежность, скорость, ... То есть, если данные стоят миллиарды, то надежность превыше всего, если это VPN через который не ходят приватные данные, то скорее важна скорость.

А так AES/ГОСТ 28147 с параметрами от КриптоПРО из RFC.

rymis ★★
()
Ответ на: комментарий от rymis

Так же нужно учитывать, что если конечное ПО будет использоваться в ГОС организациях (или же к ним приближенных), то можно использовать только ГОСТ.
И если ПО будет комерческим (хоть за поддержу деньги будете брать), то необходимо иметь ГОС лицензию на реализацию криптографических алгоритмов даже если всем этим будет заниматься только одно физическое лицо. И не важно какой алгоритм шифрования будет реализован.

expelled ★★
()
Ответ на: комментарий от expelled

Пусть иностранные шифры идут лесом, там из блочных симметричных Triple DES труЪ.
А вообще ГОСТ очень хорош. Вместе с CFB режимом, очень хорошо.

jreznot
()
Ответ на: комментарий от expelled

И если ПО будет комерческим (хоть за поддержу деньги будете брать), то необходимо иметь ГОС лицензию на реализацию криптографических алгоритмов даже если всем этим будет заниматься только одно физическое лицо. И не важно какой алгоритм шифрования будет реализован.

Эммм... А можно подробнее на этом моменте? Ссылки там и пр. Иначе получается, что все те мириады коммерческих проектов, в которых используются скажем AES или Blowfish, в подавляющей массе своей нарушают законодательство РФ т.к. естественно не имеют никаких лицензий? Что-то мне в это слабо верится...

bibi
()
Ответ на: комментарий от bibi

http://www.xrm.ru/uc/law/278/
пункты 2.в, 2.г и 3-й пункт
хотя стоит прочитать вообще все.. потому как множества ньюансов в духе:
http://www.xrm.ru/uc/law/277/
"Настоящее Положение не распространяется на предоставление услуг в области шифрования информации с использованием:
б) шифровальных (криптографических) средств, являющихся компонентами доступных для продажи без ограничений посредством розничной торговли, либо сделок по почтовым запросам, либо электронных сделок, либо сделок по телефонным заказам программных операционных систем, криптографические возможности которых не могут быть изменены пользователями, которые разработаны для установки пользователем самостоятельно без дальнейшей существенной поддержки поставщиком и техническая документация (описание алгоритмов криптографических преобразований, протоколы взаимодействия, описание интерфейсов и т.д.) на которые является доступной, в том числе для проверки;"

expelled ★★
()
Ответ на: комментарий от bibi

>скажем AES или Blowfish
те же буржуины снова ввели лецензирование на ПО, которое будет разрабатываться и использоваться на теретории США

expelled ★★
()
Ответ на: комментарий от expelled

Спасибо за ссылки. Правда, это нужно читать явно не в пятницу вечером :) Но почитаю, обязательно.

bibi
()

AES - принятый стандарт. Наиболее уязвим.
Twofish - менее уязвим.
Serpent - в два раза больше раундов, чем у двух предыдущих; отсутствуют серьёзные уязвимости.

Использовать лучше в режиме counter (CTR), т.к. CBC и прочие chain-режимы потенциально могут внести дополнительные уязвимости, медленнее работают со случайным доступом и усугубляют повреждение данных:
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

CTR лекго распараллелить и рассчитывать до поступления собственно данных, получается просто генератор криптостойкой псевдослучайной последовательности для XOR кодовой книги. Параноики могут попробовать все три шифра одновременно, если много процессорных ядер (3*N).

anonymous
()

Спасибо всем за ответы! Пока колебаюсь между twofish, Serpent и ГОСТ 28147-89. Не хотелось бы писать велосипед, а заюзать готовые библиотеки(например, libgcrypt или libmcrypt). Какой, по вашему мнению, из готовых библиотек стоит воспользоваться?

Chaser_Andrey ★★★★★
() автор топика
Ответ на: комментарий от anonymous

> AES - принятый стандарт. Наиболее уязвим.

В каких местах касающихся ТС он наиболее уязвим?

> Serpent - в два раза больше раундов, чем у двух предыдущих; отсутствуют серьёзные уязвимости.

Т.е. в других присутствуют серьезные уязвимости? Пруф?

vasily_pupkin ★★★★★
()
Ответ на: комментарий от expelled

AES сводится к практически табличной подстановке :] Для тех кто с этим делом работает - общеизвестный факт.

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Шифровать строки и записывать в БД (sqlite). Потом, по запросу, извлекать их и разшифровывать. Скорость (пока-что) значение не имеет, т.к. объем данных сравнительно невелик, важнее именно устойчивость.

Chaser_Andrey ★★★★★
() автор топика
Ответ на: комментарий от Chaser_Andrey

Я спрашиваю где ты это использовать будешь :) Что за данные, итд. А так бери любую либу с доступной лицензией. Можешь вообще из едра или openssl основной шаг повыдергивать.

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Пишу прогу на C++/Qt, с помощью которой через гуй (возможно, позже сделаю еще и консольный интерфейс) можно удобно заносить и просматривать чужие пароли и логины к разным сайтам, и не только. Шифровать планирую поля: имена людей, название сайтов, логин и пароль. Пока для собственного использования, но если приведу в нормальный вид - то выложу под GPL3. Только уже столкнулся с подводным камнем - поиск по БД напрямую нельзя осуществить, либо загружать БД целиком, дешифровать и потом искать, либо по очереди каждую запись дешифровать и анализировать. Еще думал на вариантом шифровать всю БД как файл, а при работе разшифровывать в временный файл, но ИМХО, это слишком небезопасно.

Chaser_Andrey ★★★★★
() автор топика
Ответ на: комментарий от Chaser_Andrey

> поиск по БД напрямую нельзя осуществить, либо загружать БД целиком, дешифровать и потом искать, либо по очереди каждую запись дешифровать и анализировать

А что мешает искать сразу по зашифрованным данным?

mannaz
()
Ответ на: комментарий от mannaz

Если искать точное совпадение строк - тогда без проблем, но если, к примеру, в таблице есть куча сайтов и среди них linux.org.ru, linuxforum.rg, linux.org и другие, и я задаю поиск по маске *linux*, как мне это сделать по _зашифрованым_ данным? Без разшифровки тут не обойтись, имхо.

Chaser_Andrey ★★★★★
() автор топика
Ответ на: комментарий от Chaser_Andrey

В таком случае, конечно, не обойтись. Тут лучше определиться так ли нужен поиск по маске для адресов сайтов или именам пользователей, так ли нужно вообще шифровать данные, по которым будет осуществляться поиск.

mannaz
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.