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

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


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


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


Thanks.


 
На страницу: 1, 2, 3, 4, 5, 6 След.
Комментарии
— Гость (17/09/2014 14:06)   <#>
Интересная таблица из filehttp://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. Видимо его и нужно первым в списке приоритетов ставить.
— unknown (17/09/2014 20:18, исправлен 17/09/2014 20:30)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Да, об этом неоднократно упоминалось. Даже в этой теме на предыдущей странице есть мой /comment77253, который содержит ссылку на /comment47738. Другое дело, что оценки Шнайера слишком спекулятивны, его методика подсчёта стойкости, скорее всего, не вполне корректна; цифры известных (тем более ещё только на тот момент) атак не приводятся так легко к одному баллу.



Здесь корректное сравнение ещё более затруднено, если вообще возможно. Если что, мой /comment16324 тоже можете считать субъективным и спекулятивным :)



А если взломают не AES, а DH/RSA? С середины 2000-х и по сегодняшний момент уже после знакомства с документами, которые ему лично выслал Сноуден, Шнайер параноит именно в эту сторону: со всей симметрикой в целом (включая AES) всё в порядке, АНБ ничего поломать не может, а с асимметрикой — подозрительно. Будем теперь подхватывать новый модный тренд от Шнайера?



С такой постановкой вопроса не согласен один из авторов Twofish. Подозреваю, что он и есть главный автор, а Шнайер только так, фамилию поставил руководил процессом.

— Гость (18/09/2014 14:17)   <#>
А если взломают не AES, а DH/RSA?

В этой теме обсуждаются только симметричные алгоритмы, не надо всё в одну кучу валить. Да и там выбора особо нет – только асиметрика на простых числах – обычные RSA и DH, пока не доказано что эллиптика обладает качественно более высокой стойкостью. А сейчас эллиптика наиболее уязвима к основной угрозе – скрытому внедрению потайных ходов.

С такой постановкой вопроса не согласен один из авторов Twofish.

Он рассуждает чисто академически, с позиции хомячка, у которого государство это оплот добра, спецслужбы защищают людей от террористов, а заговоры – больная фантазия маргиналов. В этом плане мнение самого Шнайера более авторитетно, т.к. академическая подготовка у него сочетается с более трезвым взлядом на жизнь. Всё это конечно спекуляции, но ничего другого нет. Понятно, что конкурс AES проходил под контролем АНБ и победить мог только алгоритм, наиболее перспективный в плане взлома, либо уже имевший слабые места известные только АНБ. Twofish и Serpent были признаны наиболее стойкими по мнению экспертов. Но обладая преимуществом, они проиграли на анбшном конкурсе, что можно расценить как признание их надёжности со стороны АНБ. Возможно что у них будут найдены слабые места или уже найдены, но у Rijndael они видимо обнаружены ещё до конкурса, иначе бы он не победил.

Чтобы те люди при отправке сообщений Вам предпочтительно шифровали TWOFISH'ем, нужно прописать эти параметры в Ваш открытый ключ

Согласно man-странице, при шифровании учитываются только предпочтения отправителя, с учётом списка алгоритмов ключа получателя. Предпочтения из ключа получателя используются только если отправитель не имеет собственных.
— Гость (18/09/2014 14:36)   <#>
Группировать в списке предпочтений лучше наверное не по размеру блока, а по алгоритму. Если положиться на данные таблицы конкурса 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.
— SATtva (18/09/2014 16:52)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

Вы исходите из того, что АНБ — это какой-то светоч знания, что ему известно то, к чему никогда и ни при каких обстоятельствах не смогут придти другие. История криптологии показывает, что это не так. И АНБ знает, что это не так. Но, по Вашему мнению, оно продавливает принятие стандарта для защиты информации вплоть до Top Secret, при том, что через несколько лет все потенциальные уязвимости будут известны и открытому академическому сообществу, и потенциальным противникам.


Вообще-то, наоборот: сначала находится логическое пересечение списков отправителя и получателя, затем из полученного списка выбирается алгоритм, имеющий наивысший приоритет у получателя.
— unknown (18/09/2014 21:59, исправлен 18/09/2014 22:29)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Шнайер привёл некие баллы, не указав их размерности. Они указывают лишь на отношение числа взломанных раундов к общему числу раундов шифра. Это число у каждого шифра и у каждой атаки будет разным. И даже у 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", неформально это звучало как-то так.



То, что он менее известен, чем Шнайер, не значит, что он такой, как вы его себе представляете и рассуждает именно в таком ключе.


И да, не прошло и одиннадцати лет (м.б. больше, т.к. это не первое высказывание) как вспомнил подстрочник, чтобы найти вариант оригинала:


From: daw@xxxxxxxxxxxxxxxxxxxxxx (David Wagner)
>How about TWOFISH ?

No, please. Stick to AES and Triple-DES; they are very fine algorithms.


My strong advice is to use AES, not Twofish. There's nothing wrong with Twofish — I'm pleased with the design and how it has held up — but I think AES is clearly the right choice over Twofish. AES was selected for the standard over all other competitors, and I think, rightly so. Most importantly, AES is receiving far more scrutiny than Twofish. This gives a powerful reason to prefer AES over Twofish (or any of the other finalists, including Serpent, for that matter).


I prefer to view Twofish as deprecated these days and to encourage people to use AES instead, unless there is some special requirement that makes AES unsuitable.


Full disclosure: I was a co-designer of Twofish, so I'm probably biased.
— Гость (18/09/2014 22:21)   <#>
Вы исходите из того, что АНБ ... известно то, к чему никогда и ни при каких обстоятельствах не смогут придти другие

Вы неверно поняли, из моих слов это не следует. АНБ (и любая другая спецслужба) стремится знать то, чего не знают другие, и как можно дольше сохранять это преимущество. Если взломают AES, для АНБ это не станет катастрофой, они продавят другой алгоритм, слабые места которого на момент принятия будут известны только им. И тут на сайте была информация, что в США для передачи секретных данных используются закрытые алгоритмы NSA Suite A и B, так что для шифрования гостайны AES не применяют.

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

Вы это проверяли, и если да, то как? Опция list-packets и pgpdump не выдают информации об используемом симметричном алгоритме. Он по-видимому указан в метаданных сеансового ключа, который зашифрован RSA. Как его извлечь оттуда стандартными инструментами не совсем ясно.

Если обстоит дело так как утверждаете вы, то указывать приоритеты в gpg.conf бессмысленно, т.к. ключ получателя всегда имеет приоритет.

В man gpg2 для personal-cipher-preferences имеется объяснение, которое противоречит вашему утверждению

This allows the user to safely override the algorithm chosen by the recipient key preferences

— unknown (18/09/2014 22:44, исправлен 18/09/2014 22:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

В военке, связанной с взаимодействием между странами (NATO) — практически везде Suite B. В известных спецификациях разведсетей — аналогично. Конечно, если считать, что все конкурсы — это фарс, то можно сказать, что вся известная по этим вопросам документация — тоже деза и фальшивки, специально отобранные для слива на Cryptome и аналоги. И опять же, что считать гостайной. Какие-нибудь отчёты и видеоконференции Госдепа — тоже могут проходить как гостайна, только фиг им кто Suite A доверит.



This allows the user to safely override the algorithm chosen by the recipient key preferences

Можно легко придумать объяснение без противоречия: не стоит беспокоиться за безопасность вашего выбора предпочтений — они просто не сработают при возможном конфликте с предпочтениями получателя.

— Гость (19/09/2014 07:53)   <#>
Как не сработают, если прямым текстом написано override, а safely означает что учитываются доступные получателю алгоритмы, вместо жёсткого задания как в cipher-algo (у получателя может не быть выбранного отправителем алгоритма).

Если всё так как вы пишете, то слово preferences в опции personal-cipher-preferences не имеет смысла. В этом случае это просто список выбранных отправителем алгоритмов, а их приоритет всегда определяется ключом получателя.

В любом случае хотелось бы проверить на примере, но неясно как это сделать.
— SATtva (19/09/2014 09:57)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118

К сказанному unknown'ом стоит добавить, что AES — это ещё и практически весь финансовый и коммерческий трафик. Если AES будет взломан, это может стать катастрофой не только для АНБ.


Если на связке присутствует ключ, которым зашифрованы данные, то --list-packets попытается их расшифровать.


При обычном симметричном шифровании используется самый высокоранговый алгоритм из этого списка. Плюс этот же список будет по умолчанию зашит в новый генерируемый ключ (т.е. именно его будут использовать Ваши корреспонденты). Так что всё с этим словом в порядке.
— Гость (19/09/2014 12:06)   <#>
Из-за специфических настроек этого форума, предыдущее сообщение неверно отобразилось и его лучше удалить.

К сказанному unknown'ом стоит добавить, что AES — это ещё и практически весь финансовый и коммерческий трафик. Если AES будет взломан, это может стать катастрофой не только для АНБ.

Вряд ли в спецслужбах волнуют проблемы финансов и коммерции. Они на госпайке, их эти проблемы не затронут. Их функция – удерживать власть любой ценой, и контроль информации это основа их деятельности.

Если на связке присутствует ключ, которым зашифрованы данные, то list-packets попытается их расшифровать.

Пытается, но для вывода расшифрованных данных нужна была опция verbose. В общем проверил и мои слова подтвердились – приоритет выбора симметричного алгоритма определяется из gpg.conf, а не настройками ключа.

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

Приоритеты из gpg.conf не влияют на генерацию ключа. Из нужно вручную устанавливать командой setpref.
— SATtva (19/09/2014 12:36)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Да, действительно. Теперь интересно, откуда возникла путаница — такое впечатление, что в каких-то предыдущих версиях логика была иной (и более логичной: определять режим защиты — прерогатива получателя). Стандарт OpenPGP не диктует строгий механизм поведения: реализации вольны выбрать любой алгоритм из пересечения списков отправителя и получателя.


Всё даже проще: с -v используемый алгоритм отображается ещё на этапе зашифрования.


Влияют, просто я спутал название опции с default-preference-list. :)
— Гость (19/09/2014 13:50)   <#>
определять режим защиты — прерогатива получателя

Мне представляется наоборот – отправитель составляет сообщение, осознаёт его ценность и несёт за него ответственность.
— SATtva (19/09/2014 13:58)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Отправитель уже и так вынужден использовать ключ получателя, имеющий некоторые изначально заданные параметры, определяющие степень безопасности коммуникации, такие как длина, асимметричная схема, срок действия и т.д. Так что вполне логично, чтобы и симметричный алгоритм задавался именно получателем.
— Lumenman (01/02/2015 01:33)   профиль/связь   <#>
комментариев: 6   документов: 0   редакций: 0
Подскажите, ключу задал setpref:
TWOFISH AES256 AES192 BLOWFISH CAST5 3DES IDEA
SHA512 SHA256 SHA384 SHA224 RIPEMD160 SHA1
при подписывании файла выбирается SHA1. Почему?
Когда прописываю personal-cipher-preferences и personal-digest-preferences в gpg.conf, то файл подписывается с SHA512. Как так?
Такой эффект, что при использовании консоли, что при графической оболочки.
На страницу: 1, 2, 3, 4, 5, 6 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3