id: Гость   вход   регистрация
текущее время 11:32 28/03/2024
Автор темы: Serghan, тема открыта 14/05/2006 04:34 Печать
http://www.pgpru.com/Форум/РаботаСGnuPG/КакВыбратьАлгоритмСимметричнгоШифрования
создать
просмотр
ссылки

Как выбрать алгоритм симметричнго шифрования?


Dоброго Времени Суток!


Как в GnuPG выбрать алгоритм симметричнго шифрования?
По умолчания стоит CAST5, можно ли использовать другой?


Thanks.


 
На страницу: 1, 2, 3, 4, 5, 6 След.
Комментарии
— unknown (05/03/2014 22:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Причины по большой части чисто исторические.

В начале девяностых был дефицит стойких блочных шифров. DES имел короткий ключ, 3-DES — неудобен, да и разрабатывался DES ещё в 70-хх взакрытую в IBM под контролем АНБ. Его вообще планировалось выпускать вначале только в виде залоченных микросхем и держать в секрете, но при передаче документов в НИСТ он был по ошибке опубликован и утёк в открытую литературу. Эту ошибку АНБ спустя двадцать лет признала одной из самых больших в своей истории.

На замену DES одно время стали широко использовать алгоритм IDEA от контролируемой АНБ компании Crypto AG, но она наложила патентный запрет. На сцену вышел CAST-5, Шнайер его удачно переделал в Blowfish, который и стал самым популярным в свободном ПО того времени.

На волне популярности Blowfish командой под руководством Шнайера был создан Twofish с самыми современными на тот момент требованиями: 128-битным блоком и ключом в 128-256 бит. Он получил распространение сразу после публикации, ещё до того, как был объявлен AES. Twofish вроде как не создавался под этот конкурс, но полностью подходил под его критерии и вошёл в пятёрку финалистов.

Threefish создавался под конкурс хэшей SHA-3 в составе хэша Skein и также вошёл в пятёрку финалистов. С его размером блока в 1024 бита использовать его для шифрования в большинстве приложений — неэкономно. Маловероятно, что его включат в GnuPG. Кроме того, он принадлежит к группе т.н. ARX-шифров, против которых были открыты неожиданные атаки. Ещё более настораживают атаки, основанные на другом принципе. Считалось, что для ARX невозможно составить таблицу дифференциалов, как для традиционны шифров с S-блоками или их аналогами. Но были найдены способы упрощения этой задачи и было найдено неожиданно много рабочих дифференциалов. Это не значит, что такие шифры нестойкие, но сами доказательства стойкости из-за этого становятся плохообоснованными.

Camellia, GOST — прогиб под национальные стандарты.

Serpent неформально получил высшие оценки стойкости на конкурсе AES, но я отношусь к этому скептически, а к такому сравнению, как спекулятивному и слабообоснованному. В нём мелкие S-блоки, плохо обоснованный по конструкции, хотя и интересный, слой линейной диффузии, а стойкость накручена удвоением числа раундов — также как это сделано в ГОСТ. Ну да, громкие имена его авторов. Но и его обоснование и исследования — особо не впечатляют. Работы Шнайера по Twofish и Skein сразу видны, что идут по своему уровню и затратам усилий на построение доказательств на уровне работ по AES и Keccak. Это — эталон того, как надо. Даже если чего-то не понятно, приятно читать и видно, что авторы старались в каждой мелочи. Субъективно — над серпентом как будто так не старались, не знаю.


Если не ошибаюсь, Twofish уникальный шифр в том, что никаких оптимизаций на этот случай не предусмотрено и там фактически одинаковая имплементация: любой размер ключа, меньший 256 бит просто дополняется до 256 бит нулями побайтово. Могу, правда ошибаться, пишу по памяти.
— SATtva (06/03/2014 08:05)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Вопрос был как раз в том, как рассортировать всякую малопопулярную экзотику, к которой я индифферентен и которой мало интересовался.

Можете никак не сортировать, просто не указывайте то, что Вам не интересно. В крайнем случае будет использован 3DES.

Есть такая странная страница, где введены аббревиатуры для много чего, что в самом GnuPG вроде как (по крайней мере, по умолчанию) отсутствует.

Это документация libgcrypt. Хотя GnuPG использует эту библиотеку в качестве криптографического бекэнда, по факту он импортирует из неё только то, что есть в стандарте OpenPGP.
— Гость (07/03/2014 04:52)   <#>
Спасибо за ответы. Если исходить из презумпции исторического прогресса (каждый более новый шифр не слабее предыдущего), то получается такая картина: Twofish > Blowfish > CAST-5 > IDEA > 3DES.


Всё сказанное справедливо и для Twofish, раз он предок Threefish?

С учётом того, что Threefish и Serpent отсутствуют в OpenPGP, Twofish можно считать 256-битовым:

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

а национальной малоизвестной экзотике мы вообще не доверяем* доверяем только в качестве умолчального SSL-шифра для pgpru.com, присутствующие по дефолту алгоритмы

Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256

можно рассортировать по группам так:

{AES256, TWOFISH} > AES192 > AES > Blowfish > CAST-5 > 3DES > CAMELLIA256 > CAMELLIA192 > CAMELLIA128.

Есть ли у кого-нибудь возражения по поводу такой сортировки?


Есть --personal-cipher-preferences, которая полностью полагается на систему предпочтений, а есть --cipher-algo, которая фиксирует алгоритм, полностью игнорируя предпочтения. Есть ли что-то среднее между этими двумя крайностями? Можно ли инструктировать GnuPG полагаться, например, на предпочтения получателя, но при этом запретить использование какого-нибудь конкретного слабого/нежелательного шифра вообще? Можно ли как-то отключить в конфиге поддержку некоторых встроенных шифров (той же CAMELLIA, к примеру)?

*3DES всё-таки лучше в литературе, думаю, изучен, чем CAMELLIA.
— SATtva (07/03/2014 09:29)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Можно ли инструктировать GnuPG полагаться, например, на предпочтения получателя, но при этом запретить использование какого-нибудь конкретного слабого/нежелательного шифра вообще?

Так --personal-cipher-preferences для того и служит — это перечень Ваших предпочтений, который объединяется с перечнем получателя (булевым пересечением) для формирования итогового списка, из которого берётся алгоритм, стоящий первым. Если Вы исключите из своего списка, допустим, CAMELLIA, то он не будет использоваться ни при каких обстоятельствах, даже если у получателя он первый в списке.
— unknown (07/03/2014 10:44, исправлен 07/03/2014 10:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Twofish — скорее полностью переработанный Blowfish, от которого остались в качестве интересной идеи только ключезависимые S-блоки, но другие по параметрам, по другому создаваемые и работающие, упакованные в другую структуру.


А Threefish создавался совсем с нуля и никаких идей от предыдущих фишей вообще не использовал. Общее с предшественниками только кусок названия и соавторство Шнайера.

— Гость (09/03/2014 01:29)   <#>

Правильно ли я понимаю, что это работает следующим образом?
  1. Алиса хочет послать письмо Бобу.
  2. Алиса находит те шифры в списке предпочтений Боба, которые она, Алиса, тоже поддерживает. Эти шифры формируют итоговый список (упорядочение то же, какое было до этого).
  3. Из полученного итогового списка выбирается первый алгоритм. Если список пустой, выбирается 3DES.
Почему в OpenPGP до сих пор 3DES, а не какой-нибудь AES/Twofish?! Почему никто не работает? Вопрос риторический.
— SATtva (09/03/2014 10:58)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Верно.
— Гость (19/03/2014 06:37)   <#>

У «неё» — это у кого из них? RIPEMD160 или MD5?
— Гость (19/03/2014 07:54)   <#>
Может быть, какие-то алгоритмы целесообразно вообще исключить из setpref? Если оттуда выкинуть, допустим, MD5, RIPEMD160, CAST5 и всю CAMELLIA, будет ли это разумным шагом? Сильно ли это порушит совместимость с не слишком старыми версиями GnuPG?
— SATtva (19/03/2014 09:48)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Может быть, какие-то алгоритмы целесообразно вообще исключить из setpref?

Ровно это я и предлагал в нескольких постах выше.

AES и Twofish добавлены в GnuPG более 10 лет назад, SHA-1 является MUST по стандарту. Никакие актуальные версии такой шаг не затронет. Плюс, как уже было сказано, в крайнем случае будет использован 3DES, так что без связи не останетесь.
— unknown (19/03/2014 09:58)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

У RIPEMD160 больше запас прочности, чем у MD5. Не только по размеру отпечатка, но и по способу обработки хэшируемых данных. Возможно, она даже более стойкая, чем SHA-1. Но поскольку они всё равно принадлежат к схожей по конструкции группе, не исключено, что будет создан метод анализа, ломающий их всех.

Может быть, какие-то алгоритмы целесообразно вообще исключить из setpref? Если оттуда выкинуть, допустим, MD5, RIPEMD160, CAST5 и всю CAMELLIA, будет ли это разумным шагом?

А вам кто-то реально пишет с использованием этих алгоритмов?
— Гость (19/03/2014 18:55)   <#>

Пока нет, но я же заранее не могу предсказать, кто, когда и с каким PGP-софтом захочет что-либо написать.


Теперь понятно.


Выражение «если ..., то ...» ≠ «так следует делать», поэтому и был задан уточняющий вопрос. ☺
— Гость (24/03/2014 01:13)   <#>
Задаю предпочтения в конфиге ~/.gnupg/gpg.conf, ещё до генерации ключа — он их игнорирует. Задаю в командной строке:



Тоже игнор. В ключе:
gpg> showpref
[ultimate] (1). xxx <xxx@xxx>
     Cipher: AES256, AES192, AES, CAST5, 3DES
     Digest: SHA256, SHA1, SHA384, SHA512, SHA224
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
По-моему, стоят дефолты, т.е. вообще ничего не поменялось. Почему я не могу создать ключ с предпопределёнными предпочтениями? Почему я должен каждый раз после генерации ключа менять их руками, да ещё и для каждого uid'а?
— Гость (24/03/2014 01:19)   <#>
Или указанные опции влияют только на создаваемые шифрованные/подписываемые сообщения, но не на дефолты ключа при его генерации? Т.е. способов иначе поменять pref, кроме как после генерации ключа, вообще нет? Задокументирован этот момент невнятно.
— unknown (24/03/2014 11:43)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

У меня по опыту тоже складывалось такое мнение. Сначала генерится ключ. В экспертном режиме можно задать асимметрику при генерации, а затем править предпочтения симметрики.

Здесь ещё указывали, что некоторые заранее заданные предпочтения при генерации работают только в batch-режиме.
На страницу: 1, 2, 3, 4, 5, 6 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3