Как выбрать алгоритм симметричнго шифрования?
Dоброго Времени Суток!
Как в GnuPG выбрать алгоритм симметричнго шифрования?
По умолчания стоит CAST5, можно ли использовать другой?
Thanks.
Ссылки
[link1] http://www.pgpru.com/servisy/packetdump
[link2] http://www.pgpru.com/biblioteka/osnovy
[link3] http://www.pgpru.com/biblioteka/osnovy/vvedenievkripto
[link4] http://www.pgpru.com/biblioteka/osnovy/setjdoverija
[link5] http://www.pgpru.com/biblioteka/osnovy/sessiizaveritelejj
[link6] http://www.pgpru.com/comment33483
[link7] http://www.gnupg.org/documentation/manuals/gcrypt/Available-ciphers.html
[link8] http://lists.gnupg.org/pipermail/gnupg-users/2013-August/047331.html
[link9] http://www.pgpru.com/novosti/2008/heshfunkcijaskeiniblochnyjjshifrthreefish
[link10] http://www.pgpru.com/novosti/2010/kriptoanaliznaosnovevraschenijjnovajaatakaprotivthreefish
[link11] http://www.pgpru.com/comment47738
[link12] http://www.pgpru.com/comment53570
[link13] http://www.pgpru.com/comment77311
[link14] http://www.pgpru.com/comment77249
[link15] http://www.pgpru.com/comment77253
[link16] http://www.pgpru.com/comment16324
[link17] http://www.pgpru.com/comment16303
[link18] http://www.pgpru.com/comment83591
[link19] http://www.pgpru.com/comment83590
[link20] http://www.vpnc.org/ietf-ipsec/03.ipsec/msg01183.html
[link21] http://www.pgpru.com/comment47555
[link22] http://www.pgpru.com/forum/rabotasgnupg/vyborheshaprisozdaniiecp
[link23] http://www.pgpru.com/comment47548
[link24] http://www.pgpru.com/comment47568
[link25] http://www.debian-administration.org/users/dkg/weblog/48
[link26] http://lists.gnupg.org/pipermail/gnupg-devel/2009-May/024999.html
[link27] http://www.pgpru.com/comment83610
[link28] http://www.pgpru.com/comment16888
[link29] http://www.pgpru.com/comment83594
[link30] http://www.opennet.ru/opennews/art.shtml?num=40877
Для единичной операции в командной строке используйте дополнительный параметр --cipher-algo с идентификатором алгоритма. Например, для симметричного шифрования файла по алгоритму Twofish:
Прописывать этот параметр в настройках GnuPG (gpg.conf) не следует, поскольку это приведёт к обходу совместимости алгоритмов получателя сообщения, указанных в сертификате его ключа. В gpg.conf лучше определять собственные предпочтительные алгоритмы в приоритетном порядке с такой конструкции:
В этом случае, если получатель сообщения поддерживает Twofish, сообщение будет зашифровано им. Если нет, смотрим совместимость по AES-256: если поддерживается, шифруем им, если нет — смотрим дальше.
То же самое касается функций хэширования и алгоритмов сжатия:
Для защиты закрытых ключей есть дополнительные параметры:
Первый определяет алгоритм шифрования закрытых ключей на диске, а второй — функцию хэширования парольной фразы. (Ещё есть параметр s2k-mode, задающий режим вычисления ключа шифрования из парольной фразы, но там по умолчанию уже задан самый надёжный режим итеративного хэширования с привязкой.)
SATtva, полагаю что это опечатка:
Sattva, в gpg.conf прописал: – "gpg personal-cipher-preferences TWOFISH AES256"
Всё равно по Default GnuPG при симмтричном шифровании использует CAST5.
Как выствить по умолчанию свой алгоритм симметричного шифрования?
А у Вас случайно не включен режим --openpgp или --pgp6, который блокирует выбор шифра? Его можно заменить параметром --gnupg или в более поздних версиях, --pgp7 или --pgp8
unknown, нет, не велючен. Если применяешь для единиченой операции: – "gpg --cipher-algo TwoFish -c d:\sometext.txt" всё нормально, а когда прописываешь в gpg.conf: – "gpg -c somefile.txt --cipher-algo TWOFISH" всё равно шифрует CAST5 :-(
Serghan, у Вас команда для конфига указана неправильно, оттого, видимо, и игнорируется. Должно быть:
Без gpg в начале.
Строка в gpg.conf: "personal-cipher-preferences TWOFISH AES256"
Ничего не изменила. По умолчанию остался CAST5.
Так, а шифруете Вы открытым ключом или симметричным (иными словами, используете свитч -e или -c)? При шифровании открытым ключом приоритет имеют предпочтения, заданные в сертификате ключа. Если же простой парольной фразой, то должен использоваться шифр, указанный первым в списке personal-cipher-preferences.
Кстати, Вы уверены, что GnuPG корректно считывает файл настроек? Прочие указанные в нём параметры применяются верно?
Если даже после исполнения всех этих рекомендаций проблема всё же сохранится, прошу Вас разместить здесь содержимое gpg.conf. Возможно, имеет место конфликт с какой-то иной опцией.
Шифрую симметричным шифрованием, использую следующую команду: "gpg -c exaple.txt"
Содержимое файла gpg.conf
Очень странно. Версия: gpg (GnuPG) 1.4.5
Вот пример ходил, от unknown кажется:
tar -c -f- secDATA | gpg -c --cipher-algo RIJNDAEL256 > secDATA.tar.gpg
и
gpg --decrypt --cipher-algo RIJNDAEL256 secDATA.tar.gpg
Это принудительный выбор шифра. Мне странно, что обычный метод с помощью personal-cipher-preferences не срабатывает.
Так кто нибудь пробовал у себя на машине сделать такое:
У меня не работает. У кого нибудь получилось, или это только у меня глюки?
Вот соответствующий кусок из моего конфига (разумеется, всё работает):
Создал конфиг из вышеперечисленного, и ничего больше, не работает! :-(
Поставьте в конфиг строку cipher-algo TWOFISH, зашифруйте какой-нибудь файл с помощью -c, а затем проверьте шифртекст с помощью --list-packets. Файл будет зашифрован именно Twofish'ем? Мне просто интересно, считывается ли вообще конфиг.
Проверил, и провел ешё ряд тестов которые привели меня к выводу что конфиг вообще не обрабатывается!
...не могу ни с чем связать, в чём может быть проблема?
Ну, теперь хоть видим логику в поведении. Проверьте, в переменных среды у Вас есть переменная GNUPGHOME, указывающая путь к директории с файлом gpg.conf?
Создал переменную "GNUPGHOME" прописал путь к директории с "gpg.conf", настройки из конфика стали читаться. GnuPG была прописанна в переменной "PATH", я думал этого достаточно.
Нет, PATH определяет путь к исполняемому файлу gpg, а GNUPGHOME служит указателем именно на каталог с файлом конфигурации. Это позволяет создавать достаточно гибкие схемы.
Скажем, у меня gpg установлен ниже стандартного каталога приложений Program Files (к которому умолчальный пользователь не должен и не имеет никаких особых прав, кроме чтения), файл настроек находится за пределами этого каталога, причём под учётной записью с очень урезанными правами я могу этот файл править. А ключи вообще размещены чёрти где — на них стоят указатели уже в самом файле настроек.
Если не затруднит ответить, а как создать эту переменную GNUPGHOME?
Та же проблема.
Откройте панель управления Windows > Система > вкладка Дополнительно > Переменные среды (кнопка внизу). В блоке переменных пользователя (сверху) нажмите Создать. В качестве имени переменной введите GNUPGHOME, а значением укажите путь к директории с файлом настроек.
Да, спасибо за ответ я так и делал, но почему-то безрезультатно.
В общем, я делал так:
WindowsXP SP2
1) Установка GnuPG 1.4.7(gnupg-w32cli-1.4.7.exe) в каталог C:\Program Files\GNU\GnuPG
2) Добавление в системную переменную Path пути C:\Program Files\GNU\GnuPG
3) Создание пользовательской переменной GNUPGHOME со значением пути C:\Program Files\GNU\GnuPG
4) Создание и добавление файла реестра вида:
REGEDIT4
5) Создание файла gpg.conf в директории C:\Program Files\GNU\GnuPG:
personal-cipher-preferences TWOFISH AES256 AES192 AES BLOWFISH CAST5 3DES
personal-digest-preferences SHA512 SHA256 RIPEMD160 SHA384 SHA1 MD5
В общем проблема в чем: при создании ключей почему то игнорируются установки gpg.conf, ключи всегда шифруются AES, а хэш всегда SHA-1. Но при шифровании из командной строки типа gpg -c somefile.txt – файл как и определено в gpg.conf шифруется TWOFISH, значит gpg.conf все таки читается. Почему же при создании ключей он игнорируется? Не очень хочется пытаться делать это все через командную строку и --edit-key, должен же gpg.conf и в этом случае читаться. Переустанавливал не помогло. Скоро убью сибя ап стену ;) хелп ми сомбади!
Пункт 3 не имеет смысла, если конфиг Вы размещаете в программной директории GPG.
Ключи или сообщения? Для защиты ключей (процедур String-To-Key и шифрования секретного ключевого материала) используются параметры s2k-cipher-algo и s2k-digest-algo.
Лучше gpg.man почитайте.
SATtva речь именно о ключах. Они упорно генерировались с хэшем SHA-1 и были зашифрованы AES, несмотря на то, что в gpg.conf было прописано:
s2k-cipher-algo TWOFISH
s2k-digest-algo SHA256
Я решил эту проблему прописав в gpg.conf строчку предпочтений:
default-preference-list TWOFISH AES256 AES192 AES CAST5 BLOWFISH 3DES SHA512 SHA256 RIPEMD160 SHA384 SHA1 MD5 ZIP ZLIB BZIP2 Uncompressed
И все стало тип-топ. Ключи генерируются как и указано с TWOFISH и SHA512.
Поэтому спасибо за внимание, проблема вроде решена.
default-preference-list определяет не то, чем ключи будут шифроваться (это задача s2k-cipher-algo), а чем они будут шифровать. Будьте точны в формулировках.
Запускаем gpg --edit-key [user-ID]
попадаем после ввода пароля в меню редактирования своего ключа.
Можем набрать help:
Command> help
Даём комманду:
Command> showpref
Видим что-то типа:
Даём другую комманду:
Command> pref
Это список предпочтений ключа в кодовом виде. (S-номер шифра, H--номер хэша, Z-номер алгоритма компрессии).
Даём комманду setpref с другими предпочтениями:
Набираем showpref, чтобы убедиться, что всё получилось как надо:
Если всё в порядке, то сохраняемся (save), если нет, то прерываем работу (quit или [Ctrl+c])
Command> save
В процессе выполнения комманд будут возникать запросы пароля и возможно требование выбрать текущий идентификатор пользователя (если например на ключ повешено несколько E-mail) – это делается коммандой uid с номером.
Теперь можете экспортивать изменённый ключ на сервер ключеё и посоветовать его обновить всем своим корреспондентам,
Их программа будет выбирать при шифромании сообщения к вам предпочитаемый алгоритм из числа доступных с начала списка,
А Ваша программа также будет использовать предпочитаемый тип хэша для
подписи,
А как посмотреть информацию о каком-нибудь .gpg файле? Есть ли подписи, алгоритм шифрования и т. д.?
gpg --list-packets file.gpg
Или загрузить сюда[link1].
Как понять вывод этой команды? Есть где-нибудь документация gpg не для турбо-гиков, которые знают по номерам все странные опции?
По ссылке выше Вы найдёте ссылку на спецификации стандарта OpenPGP, где приведены эти "номера всех странных опций". Ещё есть сервис http://www.pgpdump.net, вывод которого несколько более информативный.
Спасибо за ссылку на RFC, не знал что такой есть. Вообще, с таким высоким порогом вхождения PGP обречён на вечную нишевость.
До сих пор не понимаю, как доверять чужому паблик ключу, который я импортировал вручную. Пишет, типа ключ не валидный. Почему? В GPA не вижу опции для пометки импортированного ключа как правильного. Это как-то связано с web of trust? Но если у меня только свой и чужой ключи, что делать-то.
У Вас два варианта:
/Библиотека/Основы/ВведениеВКрипто[link3]
/Библиотека/Основы/СетьДоверия[link4]
/Библиотека/Основы/СессииЗаверителей[link5]
А лезть в своей повседневной работе в --list-packets не нужно совершенно. Это функция только для выявления сложных проблем, отладки и разработки, обычному пользователю она вообще не нужна.
Благодарю за развёрнутый ответ, постараюсь внять премудростям.
Вопрос в следующем: просто "врезал" в конец файла gpg.conf настройки
personal-cipher-preferences TWOFISH AES256 AES192 AES CAST5 BLOWFISH 3DES
personal-digest-preferences SHA512 SHA384 SHA256 RIPEMD160 SHA1 MD5
personal-compress-preferences BZIP2 ZLIB ZIP Uncompressed
# cipher-algo TWOFISH
# digest-algo SHA512
compress-algo ZIP
s2k-cipher-algo TWOFISH
s2k-digest-algo SHA384
s2k-mode 3
и всё работает. Но где в файле gpg.conf эти настройки следует размещать? (или это не имеет значения?)
Не имеет значения, особенно если вписать их в конец. :-) Опции, указанные в gpg.conf ниже, переназначают те, которые были указаны выше (если такие там где-то были).
Кстати, предпочтения алгоритмов, указанные в gpg.conf, используются как Ваши предпочтения при отправке сообщений другим людям (в красках накануне обсуждали здесь[link6]). Чтобы те люди при отправке сообщений Вам предпочтительно шифровали TWOFISH'ем, нужно прописать эти параметры в Ваш открытый ключ (или сгенерировать новый):
BZIP2 не советую делать приоритетным. Работает медленно при сжатии и расжатии, а толку чуть.
С каких это пор BZIP2 стал медленно расжимать? Сжимает медленно, но эффективнее ZLIB/ZIP
Хотя первый BZIP интереснее, почему бы и его не реализовать.
Придётся пробивать новый идентификатор в OpenPGP. Похоже, что это мало кому интересно.
А как поведёт себя программа, если в списке предпочитаемых алгоритмов ключа не указать 3DES, а при отправлении мне сообщения – не будет найдено ни одного соответствия предпочтений алгоритмов?
В стандартах обычно прописывают must или should.
Если 3DES обязателен к исполнению (must), а не просто "желателен" или "предпочитаем" (should), то он будет выбран по-любому.
Технически это реализовано так: когда пользователь меняет список предпочтений, то даже если явным образом не включил в него 3DES, он в любом случае добавляется программой в конец списка. Так что даже если задать пустой список, в нём в любом случае окажется 3DES.
Вопросы на тему рекомендуемых на сей день showperf:
Производительность и слишком особые случаи не интересуют, интересна именно криптостойкость этих примитивов.
Ни один уважаеющий себя криптограф не напишет такой статьи, по причине слишком большой амбициозности задачи. А если всё таки напишет, то это будет многостраничный обзор с кучей всяких формул, дифференциалов и прочих совершенно абстрактных сферических коней в вакууме, интересный только для разработчиков шифров последующих поколений и совершенно бесполезный в выборе существующих.
Если по-простому — выбирайте AES-256. Если не знаете, чем он лучше или хуже других, то успокойтесь на этом. Если считаете, что вас обманывают и хотите показать свою параноидальную нестандартность — можете выбрать Twofish. Если вам просто нравится азиатская экзотика — можете выбрать Camellia-256. Остальные шифры можете считать, что остались для исторической совместимости. Они не поломаны, но устарели по дизайну.
Да, выбирайте её. Пока SHA-3 ещё не ввели.
Изначально у неё запас прочности больше, но не факт, что это сейчас имеет значение.
Алгоритмы сжатия не имеют отношения к криптостойкости.
Это понятно, но не делать же оговорки на каждый чих. :-) Тут имелось ввиду «рассортировать по степени сжатия».
С шифром №1 я для себя уже определился. Вопрос был как раз в том, как рассортировать всякую малопопулярную экзотику, к которой я индифферентен и которой мало интересовался.
Есть такая странная[link7] страница, где введены аббревиатуры для много чего, что в самом GnuPG вроде как (по крайней мере, по умолчанию) отсутствует. Там прочитал:
Японское гумноCamellia уже там, ГОСТ форсится, а вот добавить туда нормальный serpent почему-то не сумели до сих пор[link8]. Или у меня устаревшая информация? Потом, судя по мануалу, в GnuPG по умолчанию есть только Twofish-256, а для Twofish-128 хоть аббревиатура и введена, его имплементации нету(?).Сделал чистый профиль для экспериментов, и проблема подтверждается: почему-то GnuPG в целом игнорирует многие предпочтения при генерации ключей, даже если они указаны в ~/.gnupg/gpg.conf. Из-за этого приходится уже после генерации ключей руками их менять через gpg --edit-key → setpref.
Кстати, а почему Threefish менее популярен, чем Twofish? Он же вроде был позже разработан и поэтому, стало быть, не должен быть хуже своего предка. Или всё равно считается, что он не настолько хорошо проверен временем, как Twofish? Про его поддержку в GnuPG что-то тоже ничего не слышно. Казалось бы, финалисты AES — достаточно популярные шифры, чтобы уже давно быть имплеменченными в GnuPG, ан нет...
Причины по большой части чисто исторические.
В начале девяностых был дефицит стойких блочных шифров. DES имел короткий ключ, 3-DES — неудобен, да и разрабатывался DES ещё в 70-хх взакрытую в IBM под контролем АНБ. Его вообще планировалось выпускать вначале только в виде залоченных микросхем и держать в секрете, но при передаче документов в НИСТ он был по ошибке опубликован и утёк в открытую литературу. Эту ошибку АНБ спустя двадцать лет признала одной из самых больших в своей истории.
На замену DES одно время стали широко использовать алгоритм IDEA от контролируемой АНБ компании Crypto AG, но она наложила патентный запрет. На сцену вышел CAST-5, Шнайер его удачно переделал в Blowfish, который и стал самым популярным в свободном ПО того времени.
На волне популярности Blowfish командой под руководством Шнайера был создан Twofish с самыми современными на тот момент требованиями: 128-битным блоком и ключом в 128-256 бит. Он получил распространение сразу после публикации, ещё до того, как был объявлен AES. Twofish вроде как не создавался под этот конкурс, но полностью подходил под его критерии и вошёл в пятёрку финалистов.
Threefish создавался под конкурс хэшей SHA-3 в составе хэша Skein[link9] и также вошёл в пятёрку финалистов. С его размером блока в 1024 бита использовать его для шифрования в большинстве приложений — неэкономно. Маловероятно, что его включат в GnuPG. Кроме того, он принадлежит к группе т.н. ARX-шифров, против которых были открыты неожиданные атаки[link10]. Ещё более настораживают атаки, основанные на другом принципе. Считалось, что для ARX невозможно составить таблицу дифференциалов, как для традиционны шифров с S-блоками или их аналогами. Но были найдены способы упрощения этой задачи и было найдено неожиданно много рабочих дифференциалов. Это не значит, что такие шифры нестойкие, но сами доказательства стойкости из-за этого становятся плохообоснованными.
Camellia, GOST — прогиб под национальные стандарты.
Serpent неформально получил высшие оценки стойкости[link11] на конкурсе AES, но я отношусь к этому скептически, а к такому сравнению, как спекулятивному и слабообоснованному. В нём мелкие S-блоки, плохо обоснованный по конструкции, хотя и интересный, слой линейной диффузии, а стойкость накручена удвоением числа раундов — также как это сделано в ГОСТ. Ну да, громкие имена его авторов. Но и его обоснование и исследования — особо не впечатляют. Работы Шнайера по Twofish и Skein сразу видны, что идут по своему уровню и затратам усилий на построение доказательств на уровне работ по AES и Keccak. Это — эталон того, как надо. Даже если чего-то не понятно, приятно читать и видно, что авторы старались в каждой мелочи. Субъективно — над серпентом как будто так не старались, не знаю.
Если не ошибаюсь, Twofish уникальный шифр в том, что никаких оптимизаций на этот случай не предусмотрено и там фактически одинаковая имплементация: любой размер ключа, меньший 256 бит просто дополняется до 256 бит нулями побайтово. Могу, правда ошибаться, пишу по памяти.
Можете никак не сортировать, просто не указывайте то, что Вам не интересно. В крайнем случае будет использован 3DES.
Это документация libgcrypt. Хотя GnuPG использует эту библиотеку в качестве криптографического бекэнда, по факту он импортирует из неё только то, что есть в стандарте OpenPGP.
Спасибо за ответы. Если исходить из презумпции исторического прогресса (каждый более новый шифр не слабее предыдущего), то получается такая картина: Twofish > Blowfish > CAST-5 > IDEA > 3DES.
Всё сказанное справедливо и для Twofish, раз он предок Threefish?
С учётом того, что Threefish и Serpent отсутствуют в OpenPGP, Twofish можно считать 256-битовым:
а национальной малоизвестной экзотике мы
вообще не доверяем* доверяем[link12] только в качестве умолчального SSL-шифра для pgpru.com, присутствующие по дефолту алгоритмыможно рассортировать по группам так:
Есть ли у кого-нибудь возражения по поводу такой сортировки?
Есть --personal-cipher-preferences, которая полностью полагается на систему предпочтений, а есть --cipher-algo, которая фиксирует алгоритм, полностью игнорируя предпочтения. Есть ли что-то среднее между этими двумя крайностями? Можно ли инструктировать GnuPG полагаться, например, на предпочтения получателя, но при этом запретить использование какого-нибудь конкретного слабого/нежелательного шифра вообще? Можно ли как-то отключить в конфиге поддержку некоторых встроенных шифров (той же CAMELLIA, к примеру)?
*3DES всё-таки лучше в литературе, думаю, изучен, чем CAMELLIA.
Так --personal-cipher-preferences для того и служит — это перечень Ваших предпочтений, который объединяется с перечнем получателя (булевым пересечением) для формирования итогового списка, из которого берётся алгоритм, стоящий первым. Если Вы исключите из своего списка, допустим, CAMELLIA, то он не будет использоваться ни при каких обстоятельствах, даже если у получателя он первый в списке.
Twofish — скорее полностью переработанный Blowfish, от которого остались в качестве интересной идеи только ключезависимые S-блоки, но другие по параметрам, по другому создаваемые и работающие, упакованные в другую структуру.
А Threefish создавался совсем с нуля и никаких идей от предыдущих фишей вообще не использовал. Общее с предшественниками только кусок названия и соавторство Шнайера.
Правильно ли я понимаю, что это работает следующим образом?
Почему в OpenPGP до сих пор 3DES, а не какой-нибудь AES/Twofish?! Почему никто не работает[link13]? Вопрос риторический.Верно.
У «неё» — это у кого из них? RIPEMD160 или MD5?
Может быть, какие-то алгоритмы целесообразно вообще исключить из setpref? Если оттуда выкинуть, допустим, MD5, RIPEMD160, CAST5 и всю CAMELLIA, будет ли это разумным шагом? Сильно ли это порушит совместимость с не слишком старыми версиями GnuPG?
Ровно это я и предлагал в нескольких постах выше.
AES и Twofish добавлены в GnuPG более 10 лет назад, SHA-1 является MUST по стандарту. Никакие актуальные версии такой шаг не затронет. Плюс, как уже было сказано, в крайнем случае будет использован 3DES, так что без связи не останетесь.
У RIPEMD160 больше запас прочности, чем у MD5. Не только по размеру отпечатка, но и по способу обработки хэшируемых данных. Возможно, она даже более стойкая, чем SHA-1. Но поскольку они всё равно принадлежат к схожей по конструкции группе, не исключено, что будет создан метод анализа, ломающий их всех.
А вам кто-то реально пишет с использованием этих алгоритмов?
Пока нет, но я же заранее не могу предсказать, кто, когда и с каким PGP-софтом захочет что-либо написать.
Теперь понятно.
Выражение «если ..., то ...» ≠ «так следует делать», поэтому и был задан уточняющий вопрос. ☺
Задаю предпочтения в конфиге ~/.gnupg/gpg.conf, ещё до генерации ключа — он их игнорирует. Задаю в командной строке:
Тоже игнор. В ключе:
Или указанные опции влияют только на создаваемые шифрованные/подписываемые сообщения, но не на дефолты ключа при его генерации? Т.е. способов иначе поменять pref, кроме как после генерации ключа, вообще нет? Задокументирован этот момент невнятно.
У меня по опыту тоже складывалось такое мнение. Сначала генерится ключ. В экспертном режиме можно задать асимметрику при генерации, а затем править предпочтения симметрики.
Здесь ещё указывали, что некоторые заранее заданные предпочтения при генерации работают только в batch-режиме.
Интересная таблица из http://www.schneier.com/paper-twofish-final.pdf
Базопасность к взлому пяти финалистов AES
Algorithm: * MARS * RC6 Rijndael * Serpent * Twofish
Safety factor: * 1.90 * 1.18 * 1.11/1.33/1.56 * 3.56 *** 2.67
(1.11/1.33/1.56 для 128/192/256-битного ключа)
Единица соответствует взломанному алгоритму.
Получается что финал выиграл самый слабый ко взлому шифр Rijndael.
Интересно узнать числа для Blowfish и CAST5, напишите ссылку если кто знает.
Для личного использования на современных комьютерах производительность шифрования не имеет практического значения. Главное это стойкость ко взлому. Но все "эксперты" в один голос нахваливают AES, потому что он быстрый. Ситуация примерно как с systemd – везде его проталкивают, и основной аргумент – быстрая загрузка. Я загружаю компьютер один раз в день и мне всё-равно займёт это 15 секунд или 45. Но то, что в системе поселится мутный монстр с правами рута, это катастрофа. Аналогично с шифрованием. Займёт оно 100 миллисекунд или 200 – совершенно не важно, но если вся шифрованная переписка окажется вскрытой, это не шутка. Не верю что можно быть таким глупым и разменивать реальную безопасность на модные и ненужные фишки. Злой умысел скорее присутствует, да не может в стране с 50-тысячным анб победить самый стойкий алгоритм на конкурсе гражданских шифров.
К сожалению, в gpg кроме AES доступен только один другой финалист – Twofish. Видимо его и нужно первым в списке приоритетов ставить.
Да, об этом неоднократно упоминалось. Даже в этой теме на предыдущей странице есть мой /comment77253[link15], который содержит ссылку на /comment47738[link11]. Другое дело, что оценки Шнайера слишком спекулятивны, его методика подсчёта стойкости, скорее всего, не вполне корректна; цифры известных (тем более ещё только на тот момент) атак не приводятся так легко к одному баллу.
Здесь корректное сравнение ещё более затруднено, если вообще возможно. Если что, мой /comment16324[link16] тоже можете считать субъективным и спекулятивным :)
А если взломают не AES, а DH/RSA? С середины 2000-х и по сегодняшний момент уже после знакомства с документами, которые ему лично выслал Сноуден, Шнайер параноит именно в эту сторону: со всей симметрикой в целом (включая AES) всё в порядке, АНБ ничего поломать не может, а с асимметрикой — подозрительно. Будем теперь подхватывать новый модный тренд от Шнайера?
С такой постановкой вопроса не согласен[link17] один из авторов Twofish. Подозреваю, что он и есть главный автор, а Шнайер только
так, фамилию поставилруководил процессом.В этой теме обсуждаются только симметричные алгоритмы, не надо всё в одну кучу валить. Да и там выбора особо нет – только асиметрика на простых числах – обычные RSA и DH, пока не доказано что эллиптика обладает качественно более высокой стойкостью. А сейчас эллиптика наиболее уязвима к основной угрозе – скрытому внедрению потайных ходов.
Он рассуждает чисто академически, с позиции хомячка, у которого государство это оплот добра, спецслужбы защищают людей от террористов, а заговоры – больная фантазия маргиналов. В этом плане мнение самого Шнайера более авторитетно, т.к. академическая подготовка у него сочетается с более трезвым взлядом на жизнь. Всё это конечно спекуляции, но ничего другого нет. Понятно, что конкурс AES проходил под контролем АНБ и победить мог только алгоритм, наиболее перспективный в плане взлома, либо уже имевший слабые места известные только АНБ. Twofish и Serpent были признаны наиболее стойкими по мнению экспертов. Но обладая преимуществом, они проиграли на анбшном конкурсе, что можно расценить как признание их надёжности со стороны АНБ. Возможно что у них будут найдены слабые места или уже найдены, но у Rijndael они видимо обнаружены ещё до конкурса, иначе бы он не победил.
Согласно man-странице, при шифровании учитываются только предпочтения отправителя, с учётом списка алгоритмов ключа получателя. Предпочтения из ключа получателя используются только если отправитель не имеет собственных.
Группировать в списке предпочтений лучше наверное не по размеру блока, а по алгоритму. Если положиться на данные таблицы конкурса AES и сравнить safety factor, то Rijndael-256 более стоек чем Rijndael-128 всего в 1.56/1.11 = 1.405 раза. Предполагая, что пропорции для Twofish и Serpent такие же, получим для гипотетических алгоритмов Twofish-126 и Serpent-128 значения будут SF=1.9 и SF=2.53. Это на фоне Rijndael-256 с SF=1.56. То есть 128-битные аналоги Twofish и Serpent оказываются значительно надёжней чем 256-битный Rijndael. Получается что доверие к алгоритму более существенно чем размер блока. Если Twofish и Blowfish более доверяемые алгоритмы, то в списке приоритетов они должны идти перед AES256, несмотря на 128-битный блок Blowfish.
Вы исходите из того, что АНБ — это какой-то светоч знания, что ему известно то, к чему никогда и ни при каких обстоятельствах не смогут придти другие. История криптологии показывает, что это не так. И АНБ знает, что это не так. Но, по Вашему мнению, оно продавливает принятие стандарта для защиты информации вплоть до Top Secret, при том, что через несколько лет все потенциальные уязвимости будут известны и открытому академическому сообществу, и потенциальным противникам.
Вообще-то, наоборот: сначала находится логическое пересечение списков отправителя и получателя, затем из полученного списка выбирается алгоритм, имеющий наивысший приоритет у получателя.
Шнайер привёл некие баллы, не указав их размерности. Они указывают лишь на отношение числа взломанных раундов к общему числу раундов шифра. Это число у каждого шифра и у каждой атаки будет разным. И даже у 128 и 256 битного шифра тоже может быть неодинаковым. Шнайер не указал, какой показатель степени стойкости эти баллы реально подразумевают. Если бы он разработал строгую методику оценки стойкости того, что ещё не поломано, то это был бы сам по себе фундаментальный теоретический скачок.
Ваше сравнение на основе этих баллов скорее всего более некорректно, чем сами эти баллы: атака против 128-бит версии потребует немного меньше 128-бит, а атака против 256-бит версии потребует немного меньше 256-бит, но раундов в 128-бит версии (по ключу, есть ещё и внеконкурсная версия с 256-битным блоком) Rijndael — 10, а в 256-битной — 14. А атаки — на неполное число раундов.
К примеру, ломается 8/10 раундов 128-битного Rijndael и 12/14 раундов 256-битного Rijndael. И будут по Шнайеру баллы 10/8 = 1.25 и 14/12 = 1.17. И 256-битный AES на основании этого не может в прямом сравнении быть слабее 128-битного из-за того, что 1.17 < 1.25.
Наконец, Twofish работает по сбалансированной Файстелевской схеме, в отличие от SP-схемы Rijndael. Иначе говоря, Rijndael обрабатывает полный блок за каждый раунд, а Twofish — только половину. А балльная система таких тонкостей не учитывает.
Т.е., вы в своей оценке путаете неполнораундовые атаки с неполноключевыми атаками. Т.е., большими, чем брутфорс. Хотя на конкурсе AES такие ещё особо не публиковали, но на SHA-3 — вполне (не по размеру ключа, т.к. хэши изначально бесключевые, а на число операций по размеру блока). А что, идея — на полнораундовых, но неполноключевых атаках (больших по числу операций, чем брутфорс) тоже можно поспекулировать и вывести из них какие-нибудь баллы.
Эти баллы не совсем пусты, они несут определённую информативность, но скорее подводят очень грубую оценку качества известных атак на момент конкурса только по числу раундов и уж точно никакой коспирологии не подразумевают. И эта оценка в целом не поменялась, хотя трудно теперь об этом говорить, т.к. интерес к другим финалистам конкурса утрачен. Эта оценка несколько скорректировалась в отношении Serpent, за которым из-за первоначального заявления Шнайера, закрепилась популярность у шифрпанков. Неудивительно, что самым стойким шифром долгое время считался ГОСТ, который делался по похожей схеме — с достижением стойкости на увеличенном числе раундов. Что опять ничего толком не говорит — сейчас все симметричные алгоритмы так стали делать: слабая раундовая функция и задранное по максимуму число раундов. И новые алгоритмы с фантастическим числом раундов, пока на них известны только малораундовые атаки, будут иметь фантастические баллы стойкости.
Есть разный подход к проектированию шифров: сделать мало стойких раундов с учётом того, что каждый раунд будет вносить столь экспоненциально большие затраты стойкости, что можно позволить поломать большую часть раундов и балансировать на малом числе оставшихся или сделать не слишком стойкие раунды, но с запасом на их количество. Rijndael, по крайней мере по исходным заложенным идеям, скорее пытались проектировать по первому типу. Serpent скорее пошёл по второму пути. RC6 — возможно слабый сам по себе, не укладываясь в эту формальную расстановку раундов. На счёт остальных сказать сложно.
Число раундов — самый примитивный в силу своей очевидности (после размера ключа и блока) параметр стойкости, если смотреть с позиций — тупо увеличивай, хуже не будет. С этой т.з. Rijndael характеризовался как "slightly underengineered", RC6 — "significantly underengineered", Serpent — "heavy overengineered", неформально это звучало как-то так.
То, что он менее известен, чем Шнайер, не значит, что он такой, как вы его себе представляете и рассуждает именно в таком ключе.
И да, не прошло и одиннадцати лет (м.б. больше, т.к. это не первое высказывание) как вспомнил подстрочник, чтобы найти вариант оригинала[link20]:
Вы неверно поняли, из моих слов это не следует. АНБ (и любая другая спецслужба) стремится знать то, чего не знают другие, и как можно дольше сохранять это преимущество. Если взломают AES, для АНБ это не станет катастрофой, они продавят другой алгоритм, слабые места которого на момент принятия будут известны только им. И тут на сайте была информация, что в США для передачи секретных данных используются закрытые алгоритмы NSA Suite A и B, так что для шифрования гостайны AES не применяют.
Вы это проверяли, и если да, то как? Опция list-packets и pgpdump не выдают информации об используемом симметричном алгоритме. Он по-видимому указан в метаданных сеансового ключа, который зашифрован RSA. Как его извлечь оттуда стандартными инструментами не совсем ясно.
Если обстоит дело так как утверждаете вы, то указывать приоритеты в gpg.conf бессмысленно, т.к. ключ получателя всегда имеет приоритет.
В man gpg2 для personal-cipher-preferences имеется объяснение, которое противоречит вашему утверждению
В военке, связанной с взаимодействием между странами (NATO) — практически везде Suite B. В известных спецификациях разведсетей — аналогично. Конечно, если считать, что все конкурсы — это фарс, то можно сказать, что вся известная по этим вопросам документация — тоже деза и фальшивки, специально отобранные для слива на Cryptome и аналоги. И опять же, что считать гостайной. Какие-нибудь отчёты и видеоконференции Госдепа — тоже могут проходить как гостайна, только фиг им кто Suite A доверит.
Можно легко придумать объяснение без противоречия: не стоит беспокоиться за безопасность вашего выбора предпочтений — они просто не сработают при возможном конфликте с предпочтениями получателя.
Как не сработают, если прямым текстом написано override, а safely означает что учитываются доступные получателю алгоритмы, вместо жёсткого задания как в cipher-algo (у получателя может не быть выбранного отправителем алгоритма).
Если всё так как вы пишете, то слово preferences в опции personal-cipher-preferences не имеет смысла. В этом случае это просто список выбранных отправителем алгоритмов, а их приоритет всегда определяется ключом получателя.
В любом случае хотелось бы проверить на примере, но неясно как это сделать.
К сказанному unknown'ом стоит добавить, что AES — это ещё и практически весь финансовый и коммерческий трафик. Если AES будет взломан, это может стать катастрофой не только для АНБ.
Если на связке присутствует ключ, которым зашифрованы данные, то --list-packets попытается их расшифровать.
При обычном симметричном шифровании используется самый высокоранговый алгоритм из этого списка. Плюс этот же список будет по умолчанию зашит в новый генерируемый ключ (т.е. именно его будут использовать Ваши корреспонденты). Так что всё с этим словом в порядке.
Из-за специфических настроек этого форума, предыдущее сообщение неверно отобразилось и его лучше удалить.
Вряд ли в спецслужбах волнуют проблемы финансов и коммерции. Они на госпайке, их эти проблемы не затронут. Их функция – удерживать власть любой ценой, и контроль информации это основа их деятельности.
Пытается, но для вывода расшифрованных данных нужна была опция verbose. В общем проверил и мои слова подтвердились – приоритет выбора симметричного алгоритма определяется из gpg.conf, а не настройками ключа.
Приоритеты из gpg.conf не влияют на генерацию ключа. Из нужно вручную устанавливать командой setpref.
Да, действительно. Теперь интересно, откуда возникла путаница — такое впечатление, что в каких-то предыдущих версиях логика была иной (и более логичной: определять режим защиты — прерогатива получателя). Стандарт OpenPGP не диктует строгий механизм поведения: реализации вольны выбрать любой алгоритм из пересечения списков отправителя и получателя.
Всё даже проще: с -v используемый алгоритм отображается ещё на этапе зашифрования.
Влияют, просто я спутал название опции с default-preference-list. :)
Мне представляется наоборот – отправитель составляет сообщение, осознаёт его ценность и несёт за него ответственность.
Отправитель уже и так вынужден использовать ключ получателя, имеющий некоторые изначально заданные параметры, определяющие степень безопасности коммуникации, такие как длина, асимметричная схема, срок действия и т.д. Так что вполне логично, чтобы и симметричный алгоритм задавался именно получателем.
Подскажите, ключу задал setpref:
TWOFISH AES256 AES192 BLOWFISH CAST5 3DES IDEA
SHA512 SHA256 SHA384 SHA224 RIPEMD160 SHA1
при подписывании файла выбирается SHA1. Почему?
Когда прописываю personal-cipher-preferences и personal-digest-preferences в gpg.conf, то файл подписывается с SHA512. Как так?
Такой эффект, что при использовании консоли, что при графической оболочки.
Напомнило:
Вы просто подписываете или подписываете и шифруете?
Для начала, есть предпочтения алгоритмов ваши, а есть предпочтения получателей. Потом, setpref и опция --default-preference-list задают ваши предпочтения, которые будут видеть ваши абоненты. А personal-{cipher,digest}-preferences — ваши предпочтения выбора алгоритмов для вас самих. Похоже, так.
Грубо говоря, в параметрах ключа через setpref для посторонних вы можете указать, что предпочитаете SHA512 вместо SHA1. Однако, сами при этом, когда вам что-то нужно подписать, допустим, хотите использовать SHA1 вместо SHA512 — это достигается как раз опцией personal-digest-preferences. Понятно, что первые предпочтения могут технически не совпадать со вторыми.
Если что, личные настройки срабатывают только тогда, когда нет конфликта. Например, если вы просто подписываете — это одно, а если шифруете и подписываете нечто для абонента, то gpg должно учесть, что абонент поддерживает соответствующий хэш и шифр для расшифровки и проверки подписи. Есть опции принудительного игнорирования настроек абонента (типа digest-algo), но их не рекомендуют включать, чтобы не порушить совместимость. Вроде всё так, но могу ошибиться.
P.S. Топик в тему[link22] вашего вопроса.
Ага, прочитал, спасибо) Значит, так и надо, а хэш подписи задам в gpg.conf
А подскажите еще, если я генерировал ключь, как оказалось, при использовании SHA1 (сделал анализ публичного ключа через сервис сайта), ничего страшного? Уже никак не изменить на более стойкий хэш?
Указанный в preferences хэш-алгоритм не участвует в выработке ключа (алгоритм, которым хэшируется парольная фраза, определяется опцией s2k-digest-algo, см. также остальные опции s2k-* в man gpg). А для генерации отпечатка ключа SHA-1 используется безотносительно настроек, это требование стандарта.
Кстати, да, чтоб не делать лишних действий, после генерации ключа выставляя preferences через setpref, лучше сразу до генерации ключа задать их в gpg.conf через default-preference-list. Поскольку любая смена предпочтений — навешивание дополнительного pgp-пакета на ключ, это ещё полезно для нераздувания размера ключа выше необходимого.