симметиричное шифрование

скажите пожалуйста, не очень я разбираюсь в этих вопросах, если я использую парольную фразу длиной к примеру 30 знаков, при симметричном шифровании, какому количеству бит это соответствует, или я не верно ставлю свой вопрос?

Длина ключа, как уже было сказано, все равно будет приведена к стандартному значению (какую бы Вы фразу не выбрали).

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

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-пакета в этом режиме. Дело не в пароле, как таковом. Атака не использует методики взлома "по словарю" и подобные; она основана только на подборе шифртекста.

Anonymous:

Взломщик имеет в своём распоряжении сообщение, симметрично зашифрованное парольной фразой (это важно: сообщение, зашифрованное открытым ключом, не поддаётся такой атаке).

Не совсем ясно. В реализации PGP симметричное шифрование (не SDA) происходит секретным ключем (который защищен паролем)? Или все же самим паролем? К примеру пользователь шифрует файл и вводит пароль длиной 8 символв. В стандарте указано, что метод шифрования AES-256. Тогда 256 бит откуда?
Насколько мне представляется шифрование ключем, который защищен паролем, много надежнее, т.к. нужно располагать как паролем так и ключом. В случае шифрования только паролем достаточно украсть (подобрать/вычислить и пр.) только сам пароль.

А схэшировать пароль несколько раз нельзя?
Сколько ни подавай битов на вход хэш-функции (или каскада) на выходе-то
всегда будет одинаковое число бит.
Например 256

IT-S2K – собственно это оно и есть.

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

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

Тогда какой смысл в первом сеансовом ключе? Если получив пароль злоумышленник однозначно получит в свое распоряжение и сеансовый ключ, которым зашифровано сообщение. В ассимметричной схеме злоумышленнику необходимо иметь сам ключ. Как написал unknown, фактическая энтропия ключа будет ~ равна энтропии пароля. Выходит для надежной защиты нужно применять очень длинные пароли, которые очень трудно запомнить, в противном случае появляется возможность подбора хотя бы части его по словарю.
Я бы предоставил пользователю выбор. Для SDA использовал бы метод получения ключа по алгоритму IT-S2K, а для обычного симметричного шифрования использовал бы схему реализованную ныне или, на выбор пользователя, не сеансовый секретный ключ, а постоянный ключ, хранящийся в секрете, – на связке вместе с секретным ключом ассиметричной схемы, с последующим повторным (опять же можно на выбор) шифрованием информации ключом, полученным из пароля по алгоритму IT-S2K.
Тогда надежность системы шифрования увеличиться и зашифрованную информацию можно будет открыть располагая как секретным ключом, так и паролем.

Тогда какой смысл в первом сеансовом ключе?

Смысл в формировании пакета 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, но это просто гибридная модель, где сеансовый ключ шифруется и открытыми ключами получателей, и симметричным ключом, выработанным из заданного пароля.

Кажется я понял, что предлагал наш Гость. В loop-aes (одной из систем шифрования дисков под Linux) можно стандартно зашифровать диск ключем, полученным итерационным хэшированием пароля с "сОлью".

А можно так: сгенерировать полностью случайный ключ, зашифровать его паролем и хранить этот файл отдельно от шифроконтейнера (обычно на флэшке или на смард-карте).

При пересылке, удаленном хранении противнику нету смысла заниматься подбором пароля, пока он не получил доступ к носителю ключа.

Получаем комбинацию: секрет состоит из того, что знаем (пароль) и того, что имеем (ключ на флэшке).

Безопасность увеличивается, надежность падает. (Хотя ключ можно еще как-то разделить и спрятать по разным местам, чтобы не потерять – но тогда безопасность потенциально снизится).

Кстати для реализации всей этой схемы в loop-aes используется как раз GnuPG.

При пересылке, удаленном хранении противнику нету смысла заниматься подбором пароля, пока он не получил доступ к носителю ключа.

unknown, я это и имел в виду. Кстати в системе WebMoney используется примерно такая же схема, ключ на носителе, плюс пароль на вход в систему, но там реализация видимо сделана иначе. Ключ там кажется незашифрован, а можно было бы, если уровень секретности слишком высок. В общем я предлагал варианты на выбор пользователя.

Какой вектор выберет злоумышленник, чтобы дешифровать шифртекст: раздобудет связку или займётся взломом по словарю?

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

Еще один вопрос. По каким соображениям не поддерживается ввод пароля (фразы) из буфера обмена?

Я Вам за разработчиков не скажу, но, возможно, по той причине, что содержимое буфера обмена легко перехватить как любому системному процессу, так и джава-скрипту с посещённой веб-страницы. Раз уж они реализовали некоторую защиту от кейлоггеров, вероятно, сочли, что пропускание пароля через буфер создаст лишние риски. Впрочем, это только мои предположения. У меня самого такое положение вещей иногда вызывало неудобства. Хорошо, что помимо PGP всегда можно воспользоваться какой-нибудь иной реализацией стандарта.

Касаемо схемы симметричного шифрования, то, как я сказал, стандарт никаких ограничений здесь не накладывает, Ваши предложения вполне реализуемы, а возможно и реализованы в GnuPG. PGP изначально на такую гибкость не рассчитывался, он выдержан в рамках тесных рекомендаций стандарта, поэтому вряд ли разработчики пойдут на воплощение столь неоднозначной схемы.

Ваши предложения вполне реализуемы, а возможно и реализованы в GnuPG.

Конкретно про это мне неизвестно. Скорее всего стандартно такой возможности нет.
Я привел обратный пример. Loop-aes основан на альтернативной реализации crypto-API в ядре.
Но по какой-то причине разработчики не стали включать схему шифрования случайного ключа
паролем ни в свой патч к ядру, ни в свои утилиты, а использовали для этой цели уже существующие
возможности GnuPG.

В принципе, предложенную схему можно реализовать как комбинацию команд в Unix, по аналогии
с тем, как это сделано в работе loop-aes. Если все сделать очень аккуратно и продуманно,
то схема будет (относительно) безопасной.

Генерация случайного ключа (из криптостойкого источника системной энтропии) и его шифрование с парольной фразой:

dd if=/dev/[u]random bs=1c count=42 | uuencode - | head -n2 | tail -n1 | gpg -c > file.key



Шифрование файла file.txt с использованием пароля и ключевого файла file.key:

cat file.key | gpg -d | gpg --passphrase-fd 0 -c file.txt > file.txt.gpg


Расшифрование файла file.txt.gpg с использованием пароля и ключевого файла file.key:

cat file.key | gpg -d | gpg --passphrase-fd 0 -d file.txt.gpg > file.txt2

Чтобы не набирать длинные команды каждый раз в консоли, можно завести в системе одну 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 комбинаций можно выбросить.

В примере выше я попытался использовать возможность работы gpg через файловые дескрипторы. Это безопаснее (не во всех конечно случаях), чем буфер обмена. Хотя в Win-подобных системах и работа буфера обмена и работа коммандной строки представляют собой печальное зрелище

Насколько безопасен caches PGP в данном случае? Может в опциях лучше отключить хранение в нем парольной фразы, пусть временное?

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

Ну почему как у пользователя серьезный вопрос или значительный интерес к теме, так сразу оправдываться? Желание серьезно разобраться в каком-либо вопросе ценно уже само по себе и вызывает уважение. Никто на этом форуме над "манией секретности" смеяться не будет. Ну разве что чуть-чуть и по-доброму.

Эквивалентны ли полученные 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) – дла управления симметричными ключами. Ключи могут как добавляться в сам файл с данными, зашифрованными паролем, так и хранится отдельно от него.

Еще один плюс отдельного хранения – возможность более легкого уничтожения ключа. А то раньше было так неудобно – приходилось каждый раз уничтожать пользователя, знавшего пароль. ;-) Главное, чтобы он не успел наделать копии.

Насколько безопасен caches PGP в данном случае? Может в опциях лучше отключить хранение в нем парольной фразы, пусть временное?

Кэш PGP — это не буфер обмена, а выделенная область ОЗУ, заблокированная приложением на доступ иных процессов и выгрузку в своп. Правда, возможность считать содержимое этой памяти всё-таки есть (kernel rootkits, например), поэтому, в идеале, кэширование включать не стоит.

А то раньше было так неудобно – приходилось каждый раз уничтожать пользователя, знавшего пароль. Wink

Вы какую методику предпочитаете? Трёхразовое уничтожение по DoD или более надёжное 32-разовое по Гутману? В зависимости от объёмов пользователя, последний вариант иногда может отнимать целую уйму времени, что в критичной ситуации непозволительно.

Вы какую методику предпочитаете? Трёхразовое уничтожение по DoD или более надёжное 32-разовое по Гутману? В зависимости от объёмов пользователя, последний вариант иногда может отнимать целую уйму времени, что в критичной ситуации непозволительно.

Вот именно! Из-за этого приходилось действовать по-старинке: прятать их в потайных местах, закапывать в лесу вместе с носителями. Сплошное "security-trough-obscurity". А теперь не страшно – если ключ легко может быть уничтожен, то не так жалко, если они попадут в плен к врагам. Приятного для них все равно мало, но зато секреты с их помощью уже не расшифруешь.

Так что 32-разовое уничтожение не нужно. Но если представить, что информация сохраняется в останках, то это уже шиза полная. Но по весне еще и не так крышу бывает срывает.