Доброго здравия всем присутсвующим!
А программа позволяет работать с каким-нибудь симметричным алгоритмом шифрования файлов или сообщений?
Спасибо.
Комментарии
— Гость (07/12/2004 19:27) 2. Прошу прощения, я пока новичек в этой теме – еще один неясный момент. А чем PGP отличается от тех систем шифрования, что представляются Outlook Express стандартно? Там ведь специально программу ставить не нужно, только сертификат получить. И Outlook получателя почты сам проверяет скажем подлинность, обращаясь в центр сертификации?
Спасибо.
— unknown (08/12/2004 09:08)
А программа позволяет работать с каким-нибудь симметричным алгоритмом шифрования файлов или сообщений?
GnuPG точно может, значит и PGP скорее всего тоже.
А чем PGP отличается от тех систем шифрования, что представляются Outlook Express стандартно? Там ведь специально программу ставить не нужно, только сертификат получить.
Так и Ворде есть шифрование. И в архиваторах. Везде где не лень его пихают в виде дополнительной возможности. Глядишь скоро и в блокнот с калькулятором добавят. Но как бы авторы-программеры не старались, никакой хорошей репутации у него по определению быть не может.
Я конечно Вас ни за что не агитирую, но смотрите сами, чего Вам ближе и какой уровень защиты для Вас достаточный.
— SATtva (08/12/2004 16:11) Georgiy, лучший способ выяснить, что программа может, а чего — нет, это пробежаться по [url=www.pgpru.com/manuals/guide/]Руководству[/url]. Отвечая на поставленный вопрос, да, программа это умеет.
По поводу второго вопроса, почитайте список основных фич PGP[link1]. Если что-то останется непонятным, спрашивайте.
Кстати, Microsloth'овская реализация S/MIME (стандарт шифрования в Аутлуке) весьма дырявая; например, возможен вариант принятия определённым образом сформированного поддельного сертификата X.509 за подлинный. Если понадобится, могу и материалы по этой теме откопать.
— Гость (09/12/2004 04:50) Я хотел сказать вот о чем. Если я поставил подпись не с помощью PGP а с помощью средств Outlook, может ли получатель проверить ее без установки дополнительных программных средств, т.е. автоматизирует ли Outlook эту работу – запрос в центре сертификации?
— SATtva (09/12/2004 13:22) Он сможет сверить подпись в любой программе, поддерживающей S/MIME. Удостоверяющий центр тут не при чём, он только заверяет сертификаты Х.509 и их открытые ключи (так что в конечном счёте пользователь вынужден доверять УЦ, что тот не сделал липовую подпись). Подпись с письма сверяется Вашим открытым ключом, который Вы передаёте получателю. Большинство мэйл-клиентов с поддержкой S/MIME позволяют прикрепить ключ (сертификат) к отправляемому сообщению.
— Гость (10/12/2004 20:01) Уважаемый администратор.
простите за может быть наивный еще один вопросец. В описании проги ничего найти не удалось. Я сделал ключи и пытаюсь отправить письмо с цифровой подписью. Какую лицензию от pgp.com с меня требует программа? У меня свободня версия.
— SATtva (10/12/2004 20:26) Georgiy, не испоользуйте (или удалите) плагин PGP для Аутлука. Это коммерческий компонент, для работы которого нужна платная лицензия. http://www.pgpru.com/faq/license/#3
— Гость (30/12/2004 08:05) Я попытался зашифровать несколько файлов с помощью PGP, поочередно. Методом самораспаковывающегося архива. При этом один файл я не смог расшифровать. Реакция на ввод пароля не такая как при вводе неверного пароля когда окнго подергивается. Окно просто исчезло с экрана, дальше никакой реакции. Это может быть связано с тем, что имя этого файла слишком длинное. (сохраненная интернет страница). С файлами с короткими именами сбоев нет. Та же картина с шифрованием папок. Несколько отдельных файлов то же нормально.
— Гость (30/12/2004 09:09) При таком методе шифровки ключи не используются? Только пароль?
— Гость (04/01/2005 12:45) Скажите пожалуйста, чисто теоретически интересно, какой вид шифрования все же является более стойким – симметричный или ассиметричный.
— unknown (04/01/2005 17:29)
Скажите пожалуйста, чисто теоретически интересно, какой вид шифрования все же является более стойким – симметричный или ассиметричный.
Чисто теоретически на эту тему можно написать большую книжку, а в конце добавить вывод, что сравнивать эти методы шифрования вообще некорректно. У каждого свои достоинства-недостатки.
Если очень-очень обобщать, то симметричные алгоритмы вроде бы надежнее. Увеличив длину ключа до 256 бит можно не беспокоится о переборе грубой силой. Даже если у противника будет бесконечно быстрый компьютер, ему не хватит ни энергии ни вещества для его работы.
Но для симметричных шифров есть огромное число методов криптоанализа и это число постоянно растет, появляются все новые и новые методики, о которых не было известно на момент создания шифра.
С ассиметричными алгоритмами тоже противоречивая ситуация. С одной стороны в их основе лежит хорошо изученная математическая задача и если ее в течении сотен лет никто не решил, то наверное ее не смогут решить и далее.
Однако, если такую задачу решить удасться, то множество ассиметричных алгоритмов сразу же будет взломано.
Увеличивается и скорость численных методов решения сложных задач (целочисленная факторизация и т.д.). В итоге, какой большой ключ не выбери, всегда есть опасения, что он окажется недостаточным не только из-за роста быстродействия компьютеров, но и из-за нахождения все более быстрых алгоритмов вычислений.
А выбрать ассиметричный ключ сколь-угодно большим нельзя (как для симметричных алгоритмов). С ростом ключа слишком сильно падает и скорость ассиметричного шифрования.
В целом считают, что чисто симметричное шифрование вроде бы надежнее. Но это очень большое упрощение, (допущение, обобщение)...
— Гость (04/01/2005 20:38)
Увеличив длину ключа до 256 бит можно не беспокоится о переборе грубой силой.
unknown, :D скажите пожалуйста, не очень я разбираюсь в этих вопросах, если я использую парольную фразу длиной к примеру 30 знаков, при симметричном шифровании, какому количеству бит это соответствует, или я не верно ставлю свой вопрос? :?:
— SATtva (05/01/2005 01:20) Гость, соответствует длине ключа текущего алгоритма. Пароль (какой бы длины он ни был) конкатенируется с salt, итеративно хэшируется, а результирующее хэш-значение используется как ключ. http://www.pgpru.com/faq/tech/#6
— unknown (05/01/2005 17:39)
Единственное, что остаётся злоумышленнику, это попытаться подобрать ключевую фразу или взломать ключ "в люб", т.е. полным перебором всего пространства ключей, что технически невыполнимо. Надёжность защиты закрытого ключа всецело опирается на качество выбранной ключевой фразы, вот почему критически важно, чтобы она была достаточно сложна.
Это опечатка была, да?
— unknown (05/01/2005 17:53)
скажите пожалуйста, не очень я разбираюсь в этих вопросах, если я использую парольную фразу длиной к примеру 30 знаков, при симметричном шифровании, какому количеству бит это соответствует, или я не верно ставлю свой вопрос?
Длина ключа, как уже было сказано, все равно будет приведена к стандартному значению (какую бы Вы фразу не выбрали).
Можно посчитать условную энтропию фразы. Один символ – восемь бит. Один бит при наборе знаков практически никогда не используется.
7*30=210 бит.
Это если фраза состоит из абсолютно статистически случайного и несвязанного набора из множества всех печатаемых символов.
Поскольку запомнить такую ключевую последовательность нереально, можно пойти другим путем для запоминания ключа гарантированной энтропии.
Составляется словарь из нескольких тысяч коротких слов. Случайным образом выбирается сочетание из нужного количества слов. Словарь составлен так, что фраза из 10 слов даст 128-битную энтропию ключевого пространства (после хэширования), из 20 слов – 256 битную.
Словари и методику выбора слов можно брать отсюда:
Взломщик имеет в своём распоряжении сообщение, симметрично зашифрованное парольной фразой (это важно: сообщение, зашифрованное открытым ключом, не поддаётся такой атаке).
Не совсем ясно. В реализации PGP симметричное шифрование (не SDA) происходит секретным ключем (который защищен паролем)? Или все же самим паролем? К примеру пользователь шифрует файл и вводит пароль длиной 8 символв. В стандарте указано, что метод шифрования AES-256. Тогда 256 бит откуда?
Насколько мне представляется шифрование ключем, который защищен паролем, много надежнее, т.к. нужно располагать как паролем так и ключом. В случае шифрования только паролем достаточно украсть (подобрать/вычислить и пр.) только сам пароль.
— SATtva (03/03/2005 13:19) См. в FAQ вопрос о защите закрытого ключа. PGP всегда шифрует сеансовым ключом. При симметричном шифровании этот сеансовый ключ шифруется не открытым ключом получателя, а другим симметричным ключом, вырабатываемым из пароля по алгоритму IT-S2K. Кстати, SDA это касается в равной мере.
Касаемо атаки Мистера-Цуккерато, описание которой цитируете, невозможность её проведения при шифровании открытым ключом исходит из особенностей формирования OpenPGP-пакета в этом режиме. Дело не в пароле, как таковом. Атака не использует методики взлома "по словарю" и подобные; она основана только на подборе шифртекста.
— unknown (03/03/2005 14:47)
Anonymous:
Взломщик имеет в своём распоряжении сообщение, симметрично зашифрованное парольной фразой (это важно: сообщение, зашифрованное открытым ключом, не поддаётся такой атаке).
Не совсем ясно. В реализации PGP симметричное шифрование (не SDA) происходит секретным ключем (который защищен паролем)? Или все же самим паролем? К примеру пользователь шифрует файл и вводит пароль длиной 8 символв. В стандарте указано, что метод шифрования AES-256. Тогда 256 бит откуда?
Насколько мне представляется шифрование ключем, который защищен паролем, много надежнее, т.к. нужно располагать как паролем так и ключом. В случае шифрования только паролем достаточно украсть (подобрать/вычислить и пр.) только сам пароль.
А схэшировать пароль несколько раз нельзя?
Сколько ни подавай битов на вход хэш-функции (или каскада) на выходе-то
всегда будет одинаковое число бит.
Например 256
IT-S2K – собственно это оно и есть.
Хотя фактическая энтропия ключа будет ~ равна энтропии пароля, эсли у злоумышленника есть файл какого-либо ключа этим паролем зашифрованный.
— Гость (06/03/2005 11:51)
При симметричном шифровании этот сеансовый ключ шифруется не открытым ключом получателя, а другим симметричным ключом, вырабатываемым из пароля по алгоритму IT-S2K.
Тогда какой смысл в первом сеансовом ключе? Если получив пароль злоумышленник однозначно получит в свое распоряжение и сеансовый ключ, которым зашифровано сообщение. В ассимметричной схеме злоумышленнику необходимо иметь сам ключ. Как написал unknown, фактическая энтропия ключа будет ~ равна энтропии пароля. Выходит для надежной защиты нужно применять очень длинные пароли, которые очень трудно запомнить, в противном случае появляется возможность подбора хотя бы части его по словарю.
Я бы предоставил пользователю выбор. Для SDA использовал бы метод получения ключа по алгоритму IT-S2K, а для обычного симметричного шифрования использовал бы схему реализованную ныне или, на выбор пользователя, не сеансовый секретный ключ, а постоянный ключ, хранящийся в секрете, – на связке вместе с секретным ключом ассиметричной схемы, с последующим повторным (опять же можно на выбор) шифрованием информации ключом, полученным из пароля по алгоритму IT-S2K.
Тогда надежность системы шифрования увеличиться и зашифрованную информацию можно будет открыть располагая как секретным ключом, так и паролем.
— SATtva (06/03/2005 15:22)
Тогда какой смысл в первом сеансовом ключе?
Смысл в формировании пакета OpenPGP, в стандартизации и совместимости формата. Думайте сами — создавать полностью различные схемы упаковки под symmetric и public key или идентичные стандартизированные схемы с различающимися тэгами. Степень безопасности подобный подход всё равно не понижает.
Как написал unknown, фактическая энтропия ключа будет ~ равна энтропии пароля.
Это значит лишь то, что безусловная энтропия будет равна энтропии пароля. О "трудности" запоминания парольных фраз я уже писал. Подсчитайте пространство комбинаций и энтропию фразы из ста знаков даже при использовании только латинских букв обоих регистров и цифр (запоминать такое и не надо, надо использовать то, что уже в голове лежит). И о каком подборе части пароля Вы говорите? Расчёт хэша производится по полному вводу, а не по его частям, поэтому если злоумышленник не имеет точных данных, что в составе парольной фразы есть те или иные слова и словоформы, условная энтропия снижена не будет, и при переборе по словарю ему всё равно придётся тестировать все возможные сочетания слов, словоформ и символов.
не сеансовый секретный ключ, а постоянный ключ, хранящийся в секрете, – на связке
(Я опечатался, не IT-S2K, а IS-S2K от iterated-salted string-to-key.)
То есть Вам только S2K не нравится? Ну так введите в качестве пароля 16, 32 (в зависимости от длины сим. ключа) или чуть больше абсолютно случайных символов — и будет Вам безусловная энтропия ключа ~ энтропии пароля (немного снижена из-за итеративного хэширования). И не придётся никому из-за таких мелочей стандарт переписывать. А запомнить даже 30 случайных символов не так уж и трудно.
Кстати, формально, согласно стандарту, ничто не мешает шифровать "голым" симметричным ключом. Другое дело, поступают ли так какие-нибудь реализации? Мне о таких не известно. Может GnuPG умеет, если хорошо его об этом попросить. Подобный подход всегда считался небезопасным, т.е. хранение незащищённых симметричных (да и вообще любых) ключей, поэтому, вероятно, и не озаботился никто.
Да, а Вы считаете, что в контексте системы безопасности надёжнее хранить незащищённый случайный ключ на незащищённой связке, чем шифровать непредсказуемым, но детерменированным ключом, секрет которого нигде кроме головы не хранится? Какой вектор выберет злоумышленник, чтобы дешифровать шифртекст: раздобудет связку или займётся взломом по словарю? Вопрос риторический, отвечать не надо.
Тогда надежность системы шифрования увеличиться и зашифрованную информацию можно будет открыть располагая как секретным ключом, так и паролем.
Если следователь Вашей логике, что любая детерменированность неприемлемо снижает безопасность, то информация, зашифрованная и полностью случайным ключом, и ключом, полученным из пароля, будет просто вскрыта по подобранному паролю. Тогда чем предложенная схема способна повысить безопасность? Не пойму...
В действительности, функционально похожая схема в OpenPGP закреплена — public-symmetric session key encryption, но это просто гибридная модель, где сеансовый ключ шифруется и открытыми ключами получателей, и симметричным ключом, выработанным из заданного пароля.
— unknown (07/03/2005 11:09) Кажется я понял, что предлагал наш Гость. В loop-aes (одной из систем шифрования дисков под Linux) можно стандартно зашифровать диск ключем, полученным итерационным хэшированием пароля с "сОлью".
А можно так: сгенерировать полностью случайный ключ, зашифровать его паролем и хранить этот файл отдельно от шифроконтейнера (обычно на флэшке или на смард-карте).
При пересылке, удаленном хранении противнику нету смысла заниматься подбором пароля, пока он не получил доступ к носителю ключа.
Получаем комбинацию: секрет состоит из того, что знаем (пароль) и того, что имеем (ключ на флэшке).
Безопасность увеличивается, надежность падает. (Хотя ключ можно еще как-то разделить и спрятать по разным местам, чтобы не потерять – но тогда безопасность потенциально снизится).
Кстати для реализации всей этой схемы в loop-aes используется как раз GnuPG.
— Гость (07/03/2005 17:05)
При пересылке, удаленном хранении противнику нету смысла заниматься подбором пароля, пока он не получил доступ к носителю ключа.
unknown, я это и имел в виду. Кстати в системе WebMoney используется примерно такая же схема, ключ на носителе, плюс пароль на вход в систему, но там реализация видимо сделана иначе. Ключ там кажется незашифрован, а можно было бы, если уровень секретности слишком высок. В общем я предлагал варианты на выбор пользователя.
Какой вектор выберет злоумышленник, чтобы дешифровать шифртекст: раздобудет связку или займётся взломом по словарю?
Если так просто раздобыть связку, то это то же вопрос риторический, к тому же я предлагал дополнительное шифрование паролем. В целом Ваши ответы то же ясны, спасибо.
Еще один вопрос. По каким соображениям не поддерживается ввод пароля (фразы) из буфера обмена?
— SATtva (07/03/2005 17:27) Я Вам за разработчиков не скажу, но, возможно, по той причине, что содержимое буфера обмена легко перехватить как любому системному процессу, так и джава-скрипту с посещённой веб-страницы. Раз уж они реализовали некоторую защиту от кейлоггеров, вероятно, сочли, что пропускание пароля через буфер создаст лишние риски. Впрочем, это только мои предположения. У меня самого такое положение вещей иногда вызывало неудобства. Хорошо, что помимо PGP всегда можно воспользоваться какой-нибудь иной реализацией стандарта.
Касаемо схемы симметричного шифрования, то, как я сказал, стандарт никаких ограничений здесь не накладывает, Ваши предложения вполне реализуемы, а возможно и реализованы в GnuPG. PGP изначально на такую гибкость не рассчитывался, он выдержан в рамках тесных рекомендаций стандарта, поэтому вряд ли разработчики пойдут на воплощение столь неоднозначной схемы.
— unknown (07/03/2005 20:26)
Ваши предложения вполне реализуемы, а возможно и реализованы в GnuPG.
Конкретно про это мне неизвестно. Скорее всего стандартно такой возможности нет.
Я привел обратный пример. Loop-aes основан на альтернативной реализации crypto-API в ядре.
Но по какой-то причине разработчики не стали включать схему шифрования случайного ключа
паролем ни в свой патч к ядру, ни в свои утилиты, а использовали для этой цели уже существующие
возможности GnuPG.
В принципе, предложенную схему можно реализовать как комбинацию команд в Unix, по аналогии
с тем, как это сделано в работе loop-aes. Если все сделать очень аккуратно и продуманно,
то схема будет (относительно) безопасной.
Генерация случайного ключа (из криптостойкого источника системной энтропии) и его шифрование с парольной фразой:
Шифрование файла file.txt с использованием пароля и ключевого файла file.key:
Расшифрование файла file.txt.gpg с использованием пароля и ключевого файла file.key:
Чтобы не набирать длинные команды каждый раз в консоли, можно завести в системе одну alias-комманду на каждое действие.
Для (рас) шифрования нужен и файл ключа и пароль.
Поскольку данные ключа передаются в pipe не через переменные или echo, то в принципе использование стандартного файлового дескриптора ввода представляется безопасным ?.
(По крайней мере не более опасным, чем обычная работа с данными через коммандную строку
таким способом).
Я не ручаюсь, что в придуманном мной сходу примере нет фатальных ошибок (!!!) – например передача
пустого ключа при неправильном пароле или еще чего. Но это надо уже тщательно проверять и создавать скрипт или свою программу для таких действий (как сделали авторы loop-aes).
По крайней мере похожии комбинации комманд действительно используются при работе loop-aes.
Также мне встречались похожие примеры при работе с OpenSSL и mcrypt – там можно делать еще
более сложные и удивительные вещи, например работать со списками ключей, сгенерированных на
определенный период времени и все через одну комманду!
Простая, но тщательно продуманная команда может делать очень мощные вещи
(речь конечно о 'nix-системах).
Еще один вопрос. По каким соображениям не поддерживается ввод пароля (фразы) из буфера обмена?
В примере выше я попытался использовать возможность работы gpg через файловые дескрипторы. Это безопаснее (не во всех конечно случаях), чем буфер обмена.
Хотя в Win-подобных системах и работа буфера обмена и работа коммандной строки представляют собой печальное зрелище ;-)
Как с точки зрения безопасности, так и функциональности.
Приведенные выше примеры были показаны для ознакомления и иллюстрации возможности работы с симметричными ключами.
Так что, уважаемые зрители нашего маленького шоу, не пытайтесь воспроизводить опасные опыты в домашних условиях без специальной подготовки.
— Гость (09/03/2005 07:03) Unknown, спасибо за столь подробную информацию, во всем этом еще предстоит разбираться, хочется освоить. Разрешите пока вернуться к более ранним Вашим сообщениям. Исходя из данных, приведенных Вами, при вводе пароля, состоящего из случайной комбинации 8 символов, энтропия ключа получается 7*8=56 бит, что при современном уровне развития ЭВМ не обеспечивает надежной защиты информации само по себе. Мне не приходится шифровать какую-либо сверх ценную информацию, поэтому мой вопрос продиктован в большей части теоретическим интересом.
Эквивалентны ли полученные 56 бит абсолютно-случайному ключу, или энтропия такого ключа получается дополнительно заниженной, что, по моему мнению, может быть обусловлено эффектом некоторого «сита», которым можно сразу отбросить часть ключей за счет факта определенных и известных комбинаций битов для каждого символа вводимого с клавиатуры?
Я исхожу их такого (возможно ошибаюсь) расчета:
Беру 30…40 наиболее распространенных в использовании символов – букв, умножаю на 2 (2 регистра) + 10 цифр, т.е. 40*2+10=90 комбинаций на один символ. Полное число комбинаций 2^7=128. 90<128, значит 128-90=38 комбинаций можно выбросить.
— Гость (09/03/2005 08:16)
В примере выше я попытался использовать возможность работы gpg через файловые дескрипторы. Это безопаснее (не во всех конечно случаях), чем буфер обмена. Хотя в Win-подобных системах и работа буфера обмена и работа коммандной строки представляют собой печальное зрелище
Насколько безопасен caches PGP в данном случае? Может в опциях лучше отключить хранение в нем парольной фразы, пусть временное?
— unknown (09/03/2005 09:03)
Мне не приходится шифровать какую-либо сверх ценную информацию, поэтому мой вопрос продиктован в большей части теоретическим интересом.
Ну почему как у пользователя серьезный вопрос или значительный интерес к теме, так сразу оправдываться? Желание серьезно разобраться в каком-либо вопросе ценно уже само по себе и вызывает уважение. Никто на этом форуме над "манией секретности" смеяться не будет. Ну разве что чуть-чуть и по-доброму.
Эквивалентны ли полученные 56 бит абсолютно-случайному ключу, или энтропия такого ключа получается дополнительно заниженной, что, по моему мнению, может быть обусловлено эффектом некоторого «сита», которым можно сразу отбросить часть ключей за счет факта определенных и известных комбинаций битов для каждого символа вводимого с клавиатуры?
Я исхожу их такого (возможно ошибаюсь) расчета:
Беру 30…40 наиболее распространенных в использовании символов – букв, умножаю на 2 (2 регистра) + 10 цифр, т.е. 40*2+10=90 комбинаций на один символ. Полное число комбинаций 2^7=128. 90<128, значит 128-90=38 комбинаций можно выбросить.
Формально, это перебор по словарю или по наиболее вероятным парольным комбинациям. Для борьбы с этой атакой используется "iterated and salted key setup", о котором говорилось выше. Для вычисления ключа из пароля используется так много итераций, что перебор паролей становится намного более медленным чем даже перебор ключа. На выходе медленного итеративного алгоритма получается псевдослучайный ключ, не несущий отпечатков закономерностей пароля.
Но в послденее время, среди проффесиональных криптографов (насколько я могу об этом судить), все больше распространяются взгляды, сходные с изложенными Вами. Шифровать данные нужно только истинно случайным ключем. Ключ должен быть на защищенном отчуждаемом носителе. А пароль – это последний барьер защиты ключа, а не его замена.
Сейчас так проектируются *UKS-системы (unified key setup) – дла управления симметричными ключами. Ключи могут как добавляться в сам файл с данными, зашифрованными паролем, так и хранится отдельно от него.
Еще один плюс отдельного хранения – возможность более легкого уничтожения ключа. А то раньше было так неудобно – приходилось каждый раз уничтожать пользователя, знавшего пароль. ;-) Главное, чтобы он не успел наделать копии.
— SATtva (09/03/2005 12:06)
Насколько безопасен caches PGP в данном случае? Может в опциях лучше отключить хранение в нем парольной фразы, пусть временное?
Кэш PGP — это не буфер обмена, а выделенная область ОЗУ, заблокированная приложением на доступ иных процессов и выгрузку в своп. Правда, возможность считать содержимое этой памяти всё-таки есть (kernel rootkits, например), поэтому, в идеале, кэширование включать не стоит.
А то раньше было так неудобно – приходилось каждый раз уничтожать пользователя, знавшего пароль. Wink
Вы какую методику предпочитаете? Трёхразовое уничтожение по DoD или более надёжное 32-разовое по Гутману? В зависимости от объёмов пользователя, последний вариант иногда может отнимать целую уйму времени, что в критичной ситуации непозволительно.
— unknown (09/03/2005 17:38)
Вы какую методику предпочитаете? Трёхразовое уничтожение по DoD или более надёжное 32-разовое по Гутману? В зависимости от объёмов пользователя, последний вариант иногда может отнимать целую уйму времени, что в критичной ситуации непозволительно.
Вот именно! Из-за этого приходилось действовать по-старинке: прятать их в потайных местах, закапывать в лесу вместе с носителями. Сплошное "security-trough-obscurity". А теперь не страшно – если ключ легко может быть уничтожен, то не так жалко, если они попадут в плен к врагам. Приятного для них все равно мало, но зато секреты с их помощью уже не расшифруешь.
Так что 32-разовое уничтожение не нужно. Но если представить, что информация сохраняется в останках, то это уже шиза полная. Но по весне еще и не так крышу бывает срывает.
— Вий (28/04/2005 19:19) Добрый день!
В одной из публикаций в интернете читал, что при нахождении коллизий в нестойких хеш-функциях противнику легче определить симметричный ключ шифрования, вырабатываемый из пароля. Интересно вот что. При поиске коллизий по открытому тексту для подмены цифровой подписи все кажется более менее понятным – криптоаналитик использует открытый текст, а так же найденные «дыры» алгортима хеша для получения коллизии. Можно ли упростить получение симметричного ключа, зная способ определения коллизии? Ведь ключ злоумышленнику изначально неизвестен, как открытый текст. На основе чего тогда возможен поиск ключа, если нет исходных данных для поиска? Я могу лишь предположить, что для поиска будет использоваться тот же полный перебор, но исходя из информации из топика «хеш-функции», можно будет перебрать лишь некоторую часть парольных фраз/паролей общим пространством гораздо меньшим, чем до достижения «естественной» коллизии (получается, что нестойкие хеш-функции либо имеют очевидные дыры, которые можно вычислить криптоанализом, либо просто имеют большее чем задумано создателями алгоритма количество в несколько ином смысле естественных коллизий, которых может быть можно найти еще больше уже и криптоанализом). Или я ошибаюсь? Т.е. получается, что стойкость шифрования против полного перебора резко уменьшается. Заслуживает ли информация, которую я читал, внимания?
Спасибо.
p/s я сделал допущение, что "iterated and salted key setup" не применяется.
— Гость (16/08/2006 17:13) Практический вопрос.
Насколько правомерно для подсчета условной энтропии ключа исходить из приведенного ниже правила и проводить аналогии с длиной двоичного ключа
Энтропия = K ^ N,
Где К – количество знакомест
N – количество символов
Например если использовать случайный пароль из букв одного регистра длиной 10 символов, то энтропия будет равна 30^10 = 590490000000000, что примерно соответствует ключевому полю в 47…49 бит, т.е. шифру с такой длиной ключа.
Если использовать случайный пароль из букв разных регистров длиной 10 символов, то энтропия будет равна 60^10 = 604661760000000000, что примерно соответствует ключевому полю в 57…59 бит, т.е. шифру с такой длиной ключа.
И так далее, применительно к длине пароля 12, 14 … символов.
— unknown (28/08/2006 09:12) А зачем так точно считать? У вас будут остатки при операциях с модулем 2.
Выберите двоичное основание и подберите по нему ближайший результат.
Например:
2^6=64
(2^6)^10=2^60=1152921504606846976
2 Вий: в системе может рассматриваться какой угодно вид атаки. Например атака со связанными ключами. Если ключи связаны, то при коллизии их хэши тожу могут быть связаны.
— Гость (16/09/2006 21:19) А все таки, как считать правильнее, так как описано в моем посте от 16.08.2006 или если учитывать каждый сивмол за 7 бит? Если я правильно понимаю таким образом сравнивать не совсем верно, потому что в случае со знакоместами мы говорим об энотропии, а в случае с 7-ю битами о конкретных программах и вычислительных системах. И все же какой метод лучше выбрать на практике, например при выборе пароля архиву.
— Гость (04/10/2006 18:36) Если мы возмем 10 символов, то при подсчете методом описанном в моем первом посте получиться энтропия эквивалентная ключу 47...49 бит.
Если считать что кажддый символ 7 бит, то получим 7*10=70 бит.
Разница очень большая. Как правильно считать практическ
— unknown (12/10/2006 15:43) Изменяя регистр мы вносим дополнительный бит информации на каждое знакоместо.
Сравните (2^5)^10 и (2^6)^10
50 и 60 бит.
— Вий (12/06/2011 15:47) Предположим, что мы имеем 128 битный ключ. При этом мы не знаем только 3 бита этого ключа, причем не знаем, какие это биты по счету. Какова сложность подбора ключа в этом случае?
Как я понимаю, это (128^2)*(128^2)*(128^2). Верно это или нет?
2. Прошу прощения, я пока новичек в этой теме – еще один неясный момент. А чем PGP отличается от тех систем шифрования, что представляются Outlook Express стандартно? Там ведь специально программу ставить не нужно, только сертификат получить. И Outlook получателя почты сам проверяет скажем подлинность, обращаясь в центр сертификации?
Спасибо.
GnuPG точно может, значит и PGP скорее всего тоже.
Так и Ворде есть шифрование. И в архиваторах. Везде где не лень его пихают в виде дополнительной возможности. Глядишь скоро и в блокнот с калькулятором добавят. Но как бы авторы-программеры не старались, никакой хорошей репутации у него по определению быть не может.
Я конечно Вас ни за что не агитирую, но смотрите сами, чего Вам ближе и какой уровень защиты для Вас достаточный.
Georgiy, лучший способ выяснить, что программа может, а чего — нет, это пробежаться по [url=www.pgpru.com/manuals/guide/]Руководству[/url]. Отвечая на поставленный вопрос, да, программа это умеет.
По поводу второго вопроса, почитайте список основных фич PGP[link1]. Если что-то останется непонятным, спрашивайте.
Кстати, Microsloth'овская реализация S/MIME (стандарт шифрования в Аутлуке) весьма дырявая; например, возможен вариант принятия определённым образом сформированного поддельного сертификата X.509 за подлинный. Если понадобится, могу и материалы по этой теме откопать.
Я хотел сказать вот о чем. Если я поставил подпись не с помощью PGP а с помощью средств Outlook, может ли получатель проверить ее без установки дополнительных программных средств, т.е. автоматизирует ли Outlook эту работу – запрос в центре сертификации?
Он сможет сверить подпись в любой программе, поддерживающей S/MIME. Удостоверяющий центр тут не при чём, он только заверяет сертификаты Х.509 и их открытые ключи (так что в конечном счёте пользователь вынужден доверять УЦ, что тот не сделал липовую подпись). Подпись с письма сверяется Вашим открытым ключом, который Вы передаёте получателю. Большинство мэйл-клиентов с поддержкой S/MIME позволяют прикрепить ключ (сертификат) к отправляемому сообщению.
Уважаемый администратор.
простите за может быть наивный еще один вопросец. В описании проги ничего найти не удалось. Я сделал ключи и пытаюсь отправить письмо с цифровой подписью. Какую лицензию от pgp.com с меня требует программа? У меня свободня версия.
Georgiy, не испоользуйте (или удалите) плагин PGP для Аутлука. Это коммерческий компонент, для работы которого нужна платная лицензия.
http://www.pgpru.com/faq/license/#3
Для шифрования/расшифрования почты используйте функции работы с активным окном.
http://www.pgpru.com/manuals/guide/04.shtml#1_1
Я попытался зашифровать несколько файлов с помощью PGP, поочередно. Методом самораспаковывающегося архива. При этом один файл я не смог расшифровать. Реакция на ввод пароля не такая как при вводе неверного пароля когда окнго подергивается. Окно просто исчезло с экрана, дальше никакой реакции. Это может быть связано с тем, что имя этого файла слишком длинное. (сохраненная интернет страница). С файлами с короткими именами сбоев нет. Та же картина с шифрованием папок. Несколько отдельных файлов то же нормально.
При таком методе шифровки ключи не используются? Только пароль?
RTFM http://www.pgpru.com/manuals/guide/04.shtml#3_2
Скажите пожалуйста, чисто теоретически интересно, какой вид шифрования все же является более стойким – симметричный или ассиметричный.
Чисто теоретически на эту тему можно написать большую книжку, а в конце добавить вывод, что сравнивать эти методы шифрования вообще некорректно. У каждого свои достоинства-недостатки.
Если очень-очень обобщать, то симметричные алгоритмы вроде бы надежнее. Увеличив длину ключа до 256 бит можно не беспокоится о переборе грубой силой. Даже если у противника будет бесконечно быстрый компьютер, ему не хватит ни энергии ни вещества для его работы.
Но для симметричных шифров есть огромное число методов криптоанализа и это число постоянно растет, появляются все новые и новые методики, о которых не было известно на момент создания шифра.
С ассиметричными алгоритмами тоже противоречивая ситуация. С одной стороны в их основе лежит хорошо изученная математическая задача и если ее в течении сотен лет никто не решил, то наверное ее не смогут решить и далее.
Однако, если такую задачу решить удасться, то множество ассиметричных алгоритмов сразу же будет взломано.
Увеличивается и скорость численных методов решения сложных задач (целочисленная факторизация и т.д.). В итоге, какой большой ключ не выбери, всегда есть опасения, что он окажется недостаточным не только из-за роста быстродействия компьютеров, но и из-за нахождения все более быстрых алгоритмов вычислений.
А выбрать ассиметричный ключ сколь-угодно большим нельзя (как для симметричных алгоритмов). С ростом ключа слишком сильно падает и скорость ассиметричного шифрования.
В целом считают, что чисто симметричное шифрование вроде бы надежнее. Но это очень большое упрощение, (допущение, обобщение)...
unknown, :D скажите пожалуйста, не очень я разбираюсь в этих вопросах, если я использую парольную фразу длиной к примеру 30 знаков, при симметричном шифровании, какому количеству бит это соответствует, или я не верно ставлю свой вопрос? :?:
Гость, соответствует длине ключа текущего алгоритма. Пароль (какой бы длины он ни был) конкатенируется с salt, итеративно хэшируется, а результирующее хэш-значение используется как ключ. http://www.pgpru.com/faq/tech/#6
Это опечатка была, да?
Длина ключа, как уже было сказано, все равно будет приведена к стандартному значению (какую бы Вы фразу не выбрали).
Можно посчитать условную энтропию фразы. Один символ – восемь бит. Один бит при наборе знаков практически никогда не используется.
7*30=210 бит.
Это если фраза состоит из абсолютно статистически случайного и несвязанного набора из множества всех печатаемых символов.
Поскольку запомнить такую ключевую последовательность нереально, можно пойти другим путем для запоминания ключа гарантированной энтропии.
Составляется словарь из нескольких тысяч коротких слов. Случайным образом выбирается сочетание из нужного количества слов. Словарь составлен так, что фраза из 10 слов даст 128-битную энтропию ключевого пространства (после хэширования), из 20 слов – 256 битную.
Словари и методику выбора слов можно брать отсюда:
http://www.diceware.com
http://world.std.com/~reinhold/diceware.html
Не совсем ясно. В реализации PGP симметричное шифрование (не SDA) происходит секретным ключем (который защищен паролем)? Или все же самим паролем? К примеру пользователь шифрует файл и вводит пароль длиной 8 символв. В стандарте указано, что метод шифрования AES-256. Тогда 256 бит откуда?
Насколько мне представляется шифрование ключем, который защищен паролем, много надежнее, т.к. нужно располагать как паролем так и ключом. В случае шифрования только паролем достаточно украсть (подобрать/вычислить и пр.) только сам пароль.
См. в FAQ вопрос о защите закрытого ключа. PGP всегда шифрует сеансовым ключом. При симметричном шифровании этот сеансовый ключ шифруется не открытым ключом получателя, а другим симметричным ключом, вырабатываемым из пароля по алгоритму IT-S2K. Кстати, SDA это касается в равной мере.
Касаемо атаки Мистера-Цуккерато, описание которой цитируете, невозможность её проведения при шифровании открытым ключом исходит из особенностей формирования OpenPGP-пакета в этом режиме. Дело не в пароле, как таковом. Атака не использует методики взлома "по словарю" и подобные; она основана только на подборе шифртекста.
А схэшировать пароль несколько раз нельзя?
Сколько ни подавай битов на вход хэш-функции (или каскада) на выходе-то
всегда будет одинаковое число бит.
Например 256
IT-S2K – собственно это оно и есть.
Хотя фактическая энтропия ключа будет ~ равна энтропии пароля, эсли у злоумышленника есть файл какого-либо ключа этим паролем зашифрованный.
Тогда какой смысл в первом сеансовом ключе? Если получив пароль злоумышленник однозначно получит в свое распоряжение и сеансовый ключ, которым зашифровано сообщение. В ассимметричной схеме злоумышленнику необходимо иметь сам ключ. Как написал unknown, фактическая энтропия ключа будет ~ равна энтропии пароля. Выходит для надежной защиты нужно применять очень длинные пароли, которые очень трудно запомнить, в противном случае появляется возможность подбора хотя бы части его по словарю.
Я бы предоставил пользователю выбор. Для SDA использовал бы метод получения ключа по алгоритму IT-S2K, а для обычного симметричного шифрования использовал бы схему реализованную ныне или, на выбор пользователя, не сеансовый секретный ключ, а постоянный ключ, хранящийся в секрете, – на связке вместе с секретным ключом ассиметричной схемы, с последующим повторным (опять же можно на выбор) шифрованием информации ключом, полученным из пароля по алгоритму IT-S2K.
Тогда надежность системы шифрования увеличиться и зашифрованную информацию можно будет открыть располагая как секретным ключом, так и паролем.
Смысл в формировании пакета OpenPGP, в стандартизации и совместимости формата. Думайте сами — создавать полностью различные схемы упаковки под symmetric и public key или идентичные стандартизированные схемы с различающимися тэгами. Степень безопасности подобный подход всё равно не понижает.
Это значит лишь то, что безусловная энтропия будет равна энтропии пароля. О "трудности" запоминания парольных фраз я уже писал. Подсчитайте пространство комбинаций и энтропию фразы из ста знаков даже при использовании только латинских букв обоих регистров и цифр (запоминать такое и не надо, надо использовать то, что уже в голове лежит). И о каком подборе части пароля Вы говорите? Расчёт хэша производится по полному вводу, а не по его частям, поэтому если злоумышленник не имеет точных данных, что в составе парольной фразы есть те или иные слова и словоформы, условная энтропия снижена не будет, и при переборе по словарю ему всё равно придётся тестировать все возможные сочетания слов, словоформ и символов.
(Я опечатался, не IT-S2K, а IS-S2K от iterated-salted string-to-key.)
То есть Вам только S2K не нравится? Ну так введите в качестве пароля 16, 32 (в зависимости от длины сим. ключа) или чуть больше абсолютно случайных символов — и будет Вам безусловная энтропия ключа ~ энтропии пароля (немного снижена из-за итеративного хэширования). И не придётся никому из-за таких мелочей стандарт переписывать. А запомнить даже 30 случайных символов не так уж и трудно.
Кстати, формально, согласно стандарту, ничто не мешает шифровать "голым" симметричным ключом. Другое дело, поступают ли так какие-нибудь реализации? Мне о таких не известно. Может GnuPG умеет, если хорошо его об этом попросить. Подобный подход всегда считался небезопасным, т.е. хранение незащищённых симметричных (да и вообще любых) ключей, поэтому, вероятно, и не озаботился никто.
Да, а Вы считаете, что в контексте системы безопасности надёжнее хранить незащищённый случайный ключ на незащищённой связке, чем шифровать непредсказуемым, но детерменированным ключом, секрет которого нигде кроме головы не хранится? Какой вектор выберет злоумышленник, чтобы дешифровать шифртекст: раздобудет связку или займётся взломом по словарю? Вопрос риторический, отвечать не надо.
Если следователь Вашей логике, что любая детерменированность неприемлемо снижает безопасность, то информация, зашифрованная и полностью случайным ключом, и ключом, полученным из пароля, будет просто вскрыта по подобранному паролю. Тогда чем предложенная схема способна повысить безопасность? Не пойму...
В действительности, функционально похожая схема в OpenPGP закреплена — public-symmetric session key encryption, но это просто гибридная модель, где сеансовый ключ шифруется и открытыми ключами получателей, и симметричным ключом, выработанным из заданного пароля.
Кажется я понял, что предлагал наш Гость. В loop-aes (одной из систем шифрования дисков под Linux) можно стандартно зашифровать диск ключем, полученным итерационным хэшированием пароля с "сОлью".
А можно так: сгенерировать полностью случайный ключ, зашифровать его паролем и хранить этот файл отдельно от шифроконтейнера (обычно на флэшке или на смард-карте).
При пересылке, удаленном хранении противнику нету смысла заниматься подбором пароля, пока он не получил доступ к носителю ключа.
Получаем комбинацию: секрет состоит из того, что знаем (пароль) и того, что имеем (ключ на флэшке).
Безопасность увеличивается, надежность падает. (Хотя ключ можно еще как-то разделить и спрятать по разным местам, чтобы не потерять – но тогда безопасность потенциально снизится).
Кстати для реализации всей этой схемы в loop-aes используется как раз GnuPG.
unknown, я это и имел в виду. Кстати в системе WebMoney используется примерно такая же схема, ключ на носителе, плюс пароль на вход в систему, но там реализация видимо сделана иначе. Ключ там кажется незашифрован, а можно было бы, если уровень секретности слишком высок. В общем я предлагал варианты на выбор пользователя.
Если так просто раздобыть связку, то это то же вопрос риторический, к тому же я предлагал дополнительное шифрование паролем. В целом Ваши ответы то же ясны, спасибо.
Еще один вопрос. По каким соображениям не поддерживается ввод пароля (фразы) из буфера обмена?
Я Вам за разработчиков не скажу, но, возможно, по той причине, что содержимое буфера обмена легко перехватить как любому системному процессу, так и джава-скрипту с посещённой веб-страницы. Раз уж они реализовали некоторую защиту от кейлоггеров, вероятно, сочли, что пропускание пароля через буфер создаст лишние риски. Впрочем, это только мои предположения. У меня самого такое положение вещей иногда вызывало неудобства. Хорошо, что помимо PGP всегда можно воспользоваться какой-нибудь иной реализацией стандарта.
Касаемо схемы симметричного шифрования, то, как я сказал, стандарт никаких ограничений здесь не накладывает, Ваши предложения вполне реализуемы, а возможно и реализованы в GnuPG. PGP изначально на такую гибкость не рассчитывался, он выдержан в рамках тесных рекомендаций стандарта, поэтому вряд ли разработчики пойдут на воплощение столь неоднозначной схемы.
Конкретно про это мне неизвестно. Скорее всего стандартно такой возможности нет.
Я привел обратный пример. Loop-aes основан на альтернативной реализации crypto-API в ядре.
Но по какой-то причине разработчики не стали включать схему шифрования случайного ключа
паролем ни в свой патч к ядру, ни в свои утилиты, а использовали для этой цели уже существующие
возможности GnuPG.
В принципе, предложенную схему можно реализовать как комбинацию команд в Unix, по аналогии
с тем, как это сделано в работе loop-aes. Если все сделать очень аккуратно и продуманно,
то схема будет (относительно) безопасной.
Генерация случайного ключа (из криптостойкого источника системной энтропии) и его шифрование с парольной фразой:
Шифрование файла file.txt с использованием пароля и ключевого файла file.key:
Расшифрование файла file.txt.gpg с использованием пароля и ключевого файла file.key:
Чтобы не набирать длинные команды каждый раз в консоли, можно завести в системе одну alias-комманду на каждое действие.
Для (рас) шифрования нужен и файл ключа и пароль.
Поскольку данные ключа передаются в pipe не через переменные или echo, то в принципе использование стандартного файлового дескриптора ввода представляется безопасным ?.
(По крайней мере не более опасным, чем обычная работа с данными через коммандную строку
таким способом).
Я не ручаюсь, что в придуманном мной сходу примере нет фатальных ошибок (!!!) – например передача
пустого ключа при неправильном пароле или еще чего. Но это надо уже тщательно проверять и создавать скрипт или свою программу для таких действий (как сделали авторы loop-aes).
По крайней мере похожии комбинации комманд действительно используются при работе loop-aes.
Также мне встречались похожие примеры при работе с OpenSSL и mcrypt – там можно делать еще
более сложные и удивительные вещи, например работать со списками ключей, сгенерированных на
определенный период времени и все через одну комманду!
Простая, но тщательно продуманная команда может делать очень мощные вещи
(речь конечно о 'nix-системах).
В примере выше я попытался использовать возможность работы gpg через файловые дескрипторы. Это безопаснее (не во всех конечно случаях), чем буфер обмена.
Хотя в Win-подобных системах и работа буфера обмена и работа коммандной строки представляют собой печальное зрелище ;-)
Как с точки зрения безопасности, так и функциональности.
Приведенные выше примеры были показаны для ознакомления и иллюстрации возможности работы с симметричными ключами.
Так что, уважаемые зрители нашего маленького шоу, не пытайтесь воспроизводить опасные опыты в домашних условиях без специальной подготовки.
Unknown, спасибо за столь подробную информацию, во всем этом еще предстоит разбираться, хочется освоить. Разрешите пока вернуться к более ранним Вашим сообщениям. Исходя из данных, приведенных Вами, при вводе пароля, состоящего из случайной комбинации 8 символов, энтропия ключа получается 7*8=56 бит, что при современном уровне развития ЭВМ не обеспечивает надежной защиты информации само по себе. Мне не приходится шифровать какую-либо сверх ценную информацию, поэтому мой вопрос продиктован в большей части теоретическим интересом.
Эквивалентны ли полученные 56 бит абсолютно-случайному ключу, или энтропия такого ключа получается дополнительно заниженной, что, по моему мнению, может быть обусловлено эффектом некоторого «сита», которым можно сразу отбросить часть ключей за счет факта определенных и известных комбинаций битов для каждого символа вводимого с клавиатуры?
Я исхожу их такого (возможно ошибаюсь) расчета:
Беру 30…40 наиболее распространенных в использовании символов – букв, умножаю на 2 (2 регистра) + 10 цифр, т.е. 40*2+10=90 комбинаций на один символ. Полное число комбинаций 2^7=128. 90<128, значит 128-90=38 комбинаций можно выбросить.
Насколько безопасен caches PGP в данном случае? Может в опциях лучше отключить хранение в нем парольной фразы, пусть временное?
Ну почему как у пользователя серьезный вопрос или значительный интерес к теме, так сразу оправдываться? Желание серьезно разобраться в каком-либо вопросе ценно уже само по себе и вызывает уважение. Никто на этом форуме над "манией секретности" смеяться не будет. Ну разве что чуть-чуть и по-доброму.
Формально, это перебор по словарю или по наиболее вероятным парольным комбинациям. Для борьбы с этой атакой используется "iterated and salted key setup", о котором говорилось выше. Для вычисления ключа из пароля используется так много итераций, что перебор паролей становится намного более медленным чем даже перебор ключа. На выходе медленного итеративного алгоритма получается псевдослучайный ключ, не несущий отпечатков закономерностей пароля.
Но в послденее время, среди проффесиональных криптографов (насколько я могу об этом судить), все больше распространяются взгляды, сходные с изложенными Вами. Шифровать данные нужно только истинно случайным ключем. Ключ должен быть на защищенном отчуждаемом носителе. А пароль – это последний барьер защиты ключа, а не его замена.
Сейчас так проектируются *UKS-системы (unified key setup) – дла управления симметричными ключами. Ключи могут как добавляться в сам файл с данными, зашифрованными паролем, так и хранится отдельно от него.
Еще один плюс отдельного хранения – возможность более легкого уничтожения ключа. А то раньше было так неудобно – приходилось каждый раз уничтожать пользователя, знавшего пароль. ;-) Главное, чтобы он не успел наделать копии.
Кэш PGP — это не буфер обмена, а выделенная область ОЗУ, заблокированная приложением на доступ иных процессов и выгрузку в своп. Правда, возможность считать содержимое этой памяти всё-таки есть (kernel rootkits, например), поэтому, в идеале, кэширование включать не стоит.
Вы какую методику предпочитаете? Трёхразовое уничтожение по DoD или более надёжное 32-разовое по Гутману? В зависимости от объёмов пользователя, последний вариант иногда может отнимать целую уйму времени, что в критичной ситуации непозволительно.
Вот именно! Из-за этого приходилось действовать по-старинке: прятать их в потайных местах, закапывать в лесу вместе с носителями. Сплошное "security-trough-obscurity". А теперь не страшно – если ключ легко может быть уничтожен, то не так жалко, если они попадут в плен к врагам. Приятного для них все равно мало, но зато секреты с их помощью уже не расшифруешь.
Так что 32-разовое уничтожение не нужно. Но если представить, что информация сохраняется в останках, то это уже шиза полная. Но по весне еще и не так крышу бывает срывает.
Добрый день!
В одной из публикаций в интернете читал, что при нахождении коллизий в нестойких хеш-функциях противнику легче определить симметричный ключ шифрования, вырабатываемый из пароля. Интересно вот что. При поиске коллизий по открытому тексту для подмены цифровой подписи все кажется более менее понятным – криптоаналитик использует открытый текст, а так же найденные «дыры» алгортима хеша для получения коллизии. Можно ли упростить получение симметричного ключа, зная способ определения коллизии? Ведь ключ злоумышленнику изначально неизвестен, как открытый текст. На основе чего тогда возможен поиск ключа, если нет исходных данных для поиска? Я могу лишь предположить, что для поиска будет использоваться тот же полный перебор, но исходя из информации из топика «хеш-функции», можно будет перебрать лишь некоторую часть парольных фраз/паролей общим пространством гораздо меньшим, чем до достижения «естественной» коллизии (получается, что нестойкие хеш-функции либо имеют очевидные дыры, которые можно вычислить криптоанализом, либо просто имеют большее чем задумано создателями алгоритма количество в несколько ином смысле естественных коллизий, которых может быть можно найти еще больше уже и криптоанализом). Или я ошибаюсь? Т.е. получается, что стойкость шифрования против полного перебора резко уменьшается. Заслуживает ли информация, которую я читал, внимания?
Спасибо.
p/s я сделал допущение, что "iterated and salted key setup" не применяется.
Практический вопрос.
Насколько правомерно для подсчета условной энтропии ключа исходить из приведенного ниже правила и проводить аналогии с длиной двоичного ключа
Энтропия = K ^ N,
Где К – количество знакомест
N – количество символов
Например если использовать случайный пароль из букв одного регистра длиной 10 символов, то энтропия будет равна 30^10 = 590490000000000, что примерно соответствует ключевому полю в 47…49 бит, т.е. шифру с такой длиной ключа.
Если использовать случайный пароль из букв разных регистров длиной 10 символов, то энтропия будет равна 60^10 = 604661760000000000, что примерно соответствует ключевому полю в 57…59 бит, т.е. шифру с такой длиной ключа.
И так далее, применительно к длине пароля 12, 14 … символов.
А зачем так точно считать? У вас будут остатки при операциях с модулем 2.
Выберите двоичное основание и подберите по нему ближайший результат.
Например:
2^6=64
(2^6)^10=2^60=1152921504606846976
2 Вий: в системе может рассматриваться какой угодно вид атаки. Например атака со связанными ключами. Если ключи связаны, то при коллизии их хэши тожу могут быть связаны.
А все таки, как считать правильнее, так как описано в моем посте от 16.08.2006 или если учитывать каждый сивмол за 7 бит? Если я правильно понимаю таким образом сравнивать не совсем верно, потому что в случае со знакоместами мы говорим об энотропии, а в случае с 7-ю битами о конкретных программах и вычислительных системах. И все же какой метод лучше выбрать на практике, например при выборе пароля архиву.
Если мы возмем 10 символов, то при подсчете методом описанном в моем первом посте получиться энтропия эквивалентная ключу 47...49 бит.
Если считать что кажддый символ 7 бит, то получим 7*10=70 бит.
Разница очень большая. Как правильно считать практическ
Изменяя регистр мы вносим дополнительный бит информации на каждое знакоместо.
Сравните (2^5)^10 и (2^6)^10
50 и 60 бит.
Предположим, что мы имеем 128 битный ключ. При этом мы не знаем только 3 бита этого ключа, причем не знаем, какие это биты по счету. Какова сложность подбора ключа в этом случае?
Как я понимаю, это (128^2)*(128^2)*(128^2). Верно это или нет?
Число возможных позиций – это число сочетаний без повторений, т.е. n!/m!/(n-m)!, где n – общее число бит, m – число неизвестных бит.
Далее ещё нужно учесть число возможных значений этих трёх бит – это 2^3 или 2^m в общем случае.
Итого: 2^(m)*n!/m!/(n-m)! = 2731008 комбинаций.