id: Гость   вход   регистрация
текущее время 22:09 28/03/2024
создать
просмотр
редакции
ссылки

Шифрование, подпись, уничтожение данных


Оглавление документа:

"Status: Good / Bad / Unknown / Invalid" при сверке подписи – что это?

При сличении цифровой подписи с письма или файла, PGP уведомляет вас о её состоянии одним из четырёх сообщений:


GoodИнформация была получена вами ровно в том виде, в каком была подписана и отправлена автором.
BadПодписанная информация была каким-то образом изменена (искажена). Причиной тому могло послужить не только злонамеренное вмешательство, но и более тривиальные вещи, например, плохое качество связи, повлекшее искажение информации в процессе передачи, случайное редактирование сообщения автором уже после подписания, изменение, внесённое почтовой программой отправителя или вашей. В любом случае, к подобного рода сообщениям следует относиться с большой осторожностью; желательно также в кратчайшие сроки выяснить причину происшедшего.
UnknownЭто говорит о том, что на Вашей связке ключей отсутствует тот, которым информация была подписана, и, следовательно, программа не может сверить подпись. В таких случаях PGP пытается самостоятельно связаться с сервером-депозитарием, чтобы найти соответствующий открытый ключ (если не пытается, откройте Options > вкладка Servers > раздел Synchronize with server upon > поставьте галку на Verification).
InvalidТак PGP уведомит вас о том, что ключ автора сообщения есть на вашей связке, но не признан подлинным. За дополнительными сведениями относительно модели доверия PGP обращайтесь к материалам "Введение в криптографию" и "Web of Trust", а также к этому вопросу FAQ.

Я зашифровал и отправил сообщение, но мой корреспондент ответил, что не может его расшифровать.

Скорее всего причина в том, что вы забыли указать открытый ключ получателя, зашифровав сообщение только своим. Это типичная ошибка. Чтобы сообщение было расшифровано получателем, оно должно быть обязательно зашифровано его открытым ключом (также зашифруйте и своим, чтобы иметь возможность прочитать отправленное сообщение в будущем).

Я хочу отправить зашифрованное сообщение сразу нескольким адресатам. Нужно ли мне зашифровывать его для каждого по отдельности?

Не обязательно, можно зашифровать сразу для всех, указав ключи всех получателей в диалоговом окне Key Selection Dialog, а затем отправить полученный шифртекст каждому из адресатов.

В окне выбора ключей получателей (Key Selection Dialog) почему-то гораздо больше ключей, чем есть на моей связке.

В окне Key Selection Dialog перечислены не отдельные открытые ключи, находящиеся на вашей связке, а все сертификаты (имена и адреса, привязанные к конкретному ключу) с этих ключей. Это сделано для более лёгкой идентификации получателя: можете выбрать любую из записей сертификата с его именем и контактным адресом — сообщение будет зашифровано соответствующим ключом (или ключами).

Зашифрование сообщения для нескольких корреспондентов не допускает анонимной передачи: при расшифровании сообщения каждый из получателей может видеть, какими ключами оно было зашифровано. Есть альтернативы?

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


Альтернатива первая: если получателей немного, можно зашифровать сообщение для каждого индивидуально. Разумеется, это малопродуктивно и неприменимо в больших масштабах.


Альтернатива вторая: если получателей много, и рассылка осуществляется регулярно, можно придумать некий пароль, отправить его всем получателям, зашифровав индивидуально их ключами (см. "альтернатива первая"), и впоследствии использовать этот пароль для шифрования сообщений симметричным алгоритмом (conventional encryption). В этом случае получатели не смогут определить, кому ещё отправлялось сообщение. Минусы такой методики очевидны: при исключении кого-либо из списка рассылки Вам придётся менять этот согласованный пароль, поскольку иначе исключённый по-прежнему сможет перехватывать и читать конфиденциальную рассылку; кроме того, пароль может быть с лёгкостью скомпрометирован (возможно, у кого-то из получателей окажется слишком длинный язык: согласитесь, своим закрытым ключом он бы рисковать не стал), и тогда рассылку сможет читать кто угодно.


Альтернатива третья: прибегнуть к параметрам GnuPG, позволяющим скрыть список получателей сообщения: --throw-keyids, --hidden-recipient [id] или --hidden-encrypt-to [id]. Детали их применения можно найти в документации новых (1.4.x, 1.3.x) версий GnuPG.

Использую PGP в Windows2000/NT. При подписании какого-либо текста русские буквы в нём превращается в непонятную абракадабру вроде Заофс.

NT-совместимые операционные системы имеют особенность сохранять параметры раскладки клавиатуры и кодировки индивидуально для каждого приложения. Таким образом, в некоторых ситуациях PGP берёт текст в буфер обмена, ОС перекодирует кириллические символы из второй половины ASCII-таблицы в соответствие западно-европейским буквенным символам, которые и подписывает PGP, выдавая в итоге странный результат.


Проблему можно обойти так: после ввода ключевой фразы для подписания текста не нажимайте OK, переключите раскладку клавиатуры в русский режим (на индикаторе раскладки в системном трее в правом нижнем углу экрана должно значиться "Ru") и только после этого нажимайте OK.

При расшифровании файла с русскими буквами в имени, они превращаются в прочерк _.

Это общая проблема всех версий PGP до 8.0, не несущая угрозы безопасности. Просто не используйте нелатинских буквенных символов в именах шифруемых файлов.

Не могу удалить файл "мимо корзины" (Shift+Delete) – файл исчезает, но после обновления содержимого каталога снова появляется.

Вполне возможно, что это связано с установленной у вас программой PGP: похожим образом проявляется баг в функции PGP Wipe on delete. По некоторым свидетельствам он возникает в Windows NT-совместимых системах (NT, 2000, XP) с установленными продуктами Symantec, например, Norton AntiVirus или Norton Internet Security, но может быть и не связан с последними. Решение проблемы с "воскресающими файлами" — выключить в настройках PGP опцию Automatically wipe on delete (вкладка General). Если это не приводит к позитивному результату, причина вашей ситуации, вероятно, кроется в чём-то другом.

При сверке цифровой подписи программа показывает строку Verified с указанием текущего времени. Зачем это нужно?

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


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

*** Status: Good Signature
*** Signer: Ваш друг Вася (0xDEADBEEF)

и т.д. В заголовке *** PGP SIGNATURE VERIFICATION *** он заменяет одну из английских букв русской со схожим начертанием (например, английскую "пи" на русскую "эр"), чтобы ваша программа не заметила подвоха. Ниже он пишет текст своего сообщения и замыкает его финальным хидером *** END PGP DECRYPTED/VERIFIED MESSAGE ***. Остаётся зашифровать (только зашифровать) всё сообщение вашим открытым ключом и, по желанию, ключом вашего доверенного корреспондента, от имени которого злоумышленник обращается к вам.


Теперь, расшифровав полученное сообщение, вы увидите текст, выглядящий так, словно действительно был подписан вашим постоянным корреспондентом. А раз текст криптографически подписан, подумаете вы, то его содержанию можно доверять. Однако не спешите со скорополительными выводами и обратите внимание на строку *** Verified: (дата/время сличения подписи). Сравните дату, указанную в ней, с текущим показанием системных часов. Маловероятно, что злоумышленник мог предугадать с точностью до секунд, когда именно вы откроете послание, а значит указанная дата будет иметь серьёзное расхождение с действительностью.


Вывод: будьте бдительны, обращайте внимание на строку *** Verified: при расшифровании сообщений и ни в коем случае не доверяйте тем, в которых этот показатель не совпадает с временем, указанным на ваших часах!

Забыл пароль к своему ключу. Как мне теперь расшифровать свои файлы?

Без правильной парольной фразы это невозможно. Если бы PGP имел лазейки или обходные пути, им бы не пользовались десятки и сотни тысяч людей. Единственный совет — постарайтесь вспомнить пароль или хотя бы его часть. Если вы помните большую его часть, воспользуйтесь подборщиком паролей pgppass[создать]. Так или иначе, это крайнаяя мера, и если вы использовали сложную комплексную ключевую фразу, процесс перебора даже по известным элементам может занять огромное количество времени.

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

Если не можете перекодировать сообщение в мэйл-клиенте, воспользуйтесь любым из многочисленных конвертеров кодировок. Для Windows это, в частности, мощный и бесплатный инструмент Штирлиц IV.

Шифрую PGP/GnuPG один и тот же открытый текст одним и тем же ключом, но блок шифртекста получается всегда разным. Почему?

PGP/GnuPG шифруют данные сеансовым симметричным ключом, а уже этот ключ зашифровывается указанным открытым ключом. Всякий раз при шифровании данных программа генерирует новый сеансовый ключ и новый вектор инициализации, так что зашифровать открытый текст одним и тем же ключом в принципе невозможно; шифртекст всегда будет разным. Более того, даже при шифровании только паролем (conventional encryption) сеансовый ключ из этой схемы не исчезает, просто вместо открытого ключа применяется заданный пароль (формально, симметричный ключ, выработанный из пароля).


 
На страницу: 1, 2 След.
Комментарии [скрыть комментарии/форму]
— spinore (15/08/2007 22:47, исправлен 15/08/2007 23:21)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
SATtva, я же вам уже несколько раз говорил, "подписание" звучит не по-русски.

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

Не рассказали про самую основную причину появления "bad"-подписей: подпись должна сличаться в той же кодировке, в которой было исходное сообщение. При расшифровывании сообщения в Linux, подписанного в Windows, или наоборот: при расшифровывании подписанного в Linux сообщения в Windows такая ситуация возникает почти всегда из-за того что умолчальные кодировки в этих системах разные. Для сличения подписи требуется перекодировать текст в родную кодировку, а только потом сличать подписи. В частности, для корректной сверки подписи сообщения в Linux, подписанного в Windows (а также с учётом вышеописанной атаки) в GnuPG следует делать так (в редких случаях может понадобиться другая перекодировка):

Вставляется текст, по окончании пишется на новой строке EOF. Выполнение команды приведёт к тому, что в file.txt будет содержаться сообщение в удобочитаемой русской кодировке, а в файле signatura.txt – информация о состоянии подписи (или и о том, как было зашифровано сообщение, если это имело место быть). В качестве обходного пути можно обмениваться сообщениями, написанными исключительно на латинице, что устранит проблему с кодировками.

Альтернатива третья: прибегнуть к параметрам GnuPG, позволяющим скрыть список получателей сообщения: --throw-keyids, --hidden-recipient [id] или --hidden-encrypt-to [id]. Детали их применения можно найти в документации новых (1.4.x, 1.3.x) версий GnuPG.

Основная проблема "многих получателей" сводится к тому, что длина сообщения оказывается слишком большой. Если файл размером 5 мегабайт требуется отправить 50-ти пользователям, его длина (как я понимаю) будет порядка 250мегабайт, которые каждый обязан скачать, чтобы получить расшифрованное сообщение (или файл). "Третья адьтернатива" сохраняет эту проблему?

(при условии, что вы используете именно PGP до версии 9.x; к другим программам атака неприменима)

как бы ни так, как бы ни так...
— SATtva (16/08/2007 01:00)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Если файл размером 5 мегабайт требуется отправить 50-ти пользователям, его длина (как я понимаю) будет порядка 250мегабайт

Неверно. Пакет будет сформирован из субпакета симметрично зашифрованных данных (это 5 Мб или, возможно, меньше из-за сжатия) и 50 субпакетов асимметрично зашифрованного сеансового ключа (по несколько килобайт для каждого получателя, в зависимости от длины его открытого ключа). В общем, в итоге будет или чуть больше 5 Мб или, скорее всего, даже меньше, во-первых, благодаря сжатию и, во-вторых, тому, что не сообщение шифруется для каждого из получателей индивидуально, а только сеансовый ключ.

(при условии, что вы используете именно PGP до версии 9.x; к другим программам атака неприменима)

Убрал эту глупость. :-)
— spinore (16/08/2007 01:57, исправлен 16/08/2007 02:03)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Неверно. Пакет будет сформирован из субпакета симметрично зашифрованных данных (это 5 Мб или, возможно, меньше из-за сжатия) и 50 субпакетов асимметрично зашифрованного сеансового ключа (по несколько килобайт для каждого получателя, в зависимости от длины его открытого ключа). В общем, в итоге будет или чуть больше 5 Мб или, скорее всего, даже меньше, во-первых, благодаря сжатию и, во-вторых, тому, что не сообщение шифруется для каждого из получателей индивидуально, а только сеансовый ключ.

По-видимому, следует прояснить ситуацию так:
  • Идёт обмен текстовыми сообщениями малого размера (например, несколько слов): размер сообщения в ASCII-формате приблизительно равен 50*1кб, то есть имеем порядка 50кб в "арморед"-виде ради передачи двух-трёх слов.
  • Случай такой же, как предыдущий, однако требования формировать "арморед"-представление не надо, тогда сжиматие этих 50кб даст файл рамером порядка килобайта.
  • Идёт обмен большими файлами (несколько мегабайт) – в этих случаях "арморед"-представление в принципе неэффективно, а значит проблемы нет если использовать вышеописанный подход.
Итак, что мы имеем:
  • Если используются программы, автоматически обрабатывающие небольшие текстовые сообщения, то при прочих равных (попытка получить оптимум между удобством и безопасностью) эффективнее "альтернатива третья", если же нет – "альтернатива вторая". Однако, в случае модели "безопасность превыше всего" лучше использовать "альтернативу 3" во всех случаях и обрабатывать вручную длинные "арморед"-тексты. В случае больших файлов всесторонне лучше "альтернатива 3".
SATtva, а вам известны какие-либо программы, реализующие такую PGP-переписку внутри группы анонимных участников (по аналогии со связкой PGP+Jabber для анонимной и шифрованной переписки между двумя пользователями)?

P. S.: если не очень внятно выразился: когда публикуется "арморед"-сообщения в стиле "альтернативы 3" его можно копировать в буфер и скармливать программе-обработчику (что не сделать с "неарморед"-выводом), если же используются файлы для запаковки сообщений, их нужно специально скачивать что существенно менее удобно.
— spinore (16/08/2007 02:31)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Не задумывался глубоко над уязвимостью следующего харктера, и потому просьба высказаться к тем, кому очевидно сразу.

Как хорошо известно, PGP-переписка имеет два существенных недостатка на текущий момент:
  • Если история сообщений хранится на сервере (что, следует заметить, всегда так на почтовых серверах), то после создания квантовых компьютеров вся переписка будет легко прочитана при первой надобности, стойкие же к квантовым компьютерам алгоритмы пока находятся лишь в стадии разработки и не используются в PGP.
  • PGP в типичной схеме обмена ключами не реализует само по себе схему децентрализованного хранения секретов, что архитектурно плохо: достаточно получить приватный ключ пользователя (например, силовым принуждением, что очень широко используется повсеместно), чтобы прочитать всю переписку от начала и до конца.
Вопрос заключается в том, что "можно ли используя симметричное/асимметричное шифрование построить более усточивую к этим вектроам атак схему"? Для простоты предположим, что Алиса может встретиться с Бобом лично и передать ему симметричный ключ (то есть "используя третий канал"), если это нужно, в самом начале коммуникации. Далее хотелось бы получить цепочку необратимого преобразования ключей, такую что "вычисление последнего не давало бы возможность прочесть предыдущий". Сразу могу придумать 2 реализации:
  • Какой-то промежуток времени происходит обычная PGP-переписка, после чего свои приватные ключи участники удаляют, защищаясь, таким образом, от силового принуждения с одной стороны, и, если не публикую свои публичные ключи на общедоступных серверах, то и от атаки со стороны квантовых компьютеров – с другой стороны (это правда?).
  • Алиса и Боб обмениваются одноразовым блокнотом после чего могут общаться ровно столько, пока не будет израсходовн блокнот (использованные части блокнота уничтожаются после использования).
В обоих случаях даже под силовым принуждением можно будет получить доступ только к тем данным, обмен которыми происходил последнее время из-за периодической уничтожаемости шифровальных ключей. Можно ли эту схему доработать и сделать автоматической? Минус первого метода в том, что прийдётся каждый раз встречаться лично для передачи ключа (можно новый публичный ключ посылать по уже шифрованному каналу перед сменой ключа, что довольно эффективно, но не сможет противостоять атаке, когда сохраняются все пересылаемые сообщения на сервере с целью расшифровать их позже с помощью квантовых компьютеров), а блокнот попросту неудобен (я где-то встречал здесь на форуме сообщение, что блокнот тоже уязвим в случае квантовых компьютеров, или мне показалось?). Симметричные ключи, как я понял, при достаточной длинне устойчивы к квантовым алгоритмам (кстати, начиная с какой длины?).
— cooshoo (16/08/2007 09:24)   профиль/связь   <#>
комментариев: 83   документов: 4   редакций: 4
Если первоначально открытые ключи передавались из рук в руки, весь дальнейший обмен информацией зашифрован симметричным алгоритмом (стойкость к "квантовому вскрытию" – дели длину ключа пополам). Перехват и хранение случайного числа, умноженного на случайное число по неизвестному модулю ничего атакующему не даст.
Если используется симметричное шифрование, каждый следующий ключ для нового сообщения можно получать шифруя предыдущий ключ им самим (аналог OFB режима) или шифруя значение счетчика. При рассинхронизации (пропало несколько сообщений) перебираем следующие значения ключа, пока не начнет расшифровываться нормально.
— SATtva (16/08/2007 15:00)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
а вам известны какие-либо программы, реализующие такую PGP-переписку внутри группы анонимных участников (по аналогии со связкой PGP+Jabber для анонимной и шифрованной переписки между двумя пользователями)?

Формат OpenPGP не очень подходит для анонимных переговоров. GnuPG с опцией --throw-keyids — самое близкое решение: отправитель шифрует письмо и широковещательно передаёт группе, каждый участник пробует расшифровать его своим закрытым ключом, у кого получилось — тот и есть получатель.

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

Оба предложенных Вами решения подходят. Вообще всё это хозяйство называется perfect forward secrecy — это такие схемы, в которых шифровальные ключи уничтожаются сразу по завершении сеанса. Ben Laurie (один из разработчиков OpenSSL) написал расширения для OpenPGP, опционально добавляющие в протокол свойства PFS. Скорее всего, они будут реализованы через несколько лет в новой версии спецификаций. А пока можно использовать идеи cooshoo.

Симметричные ключи, как я понял, при достаточной длинне устойчивы к квантовым алгоритмам (кстати, начиная с какой длины?).

Ну, это вопрос из разряда, где кончается река и начинается море? Общепринятая оценка состоит в том, что 256-битовые ключи не могут быть взломаны полным перебором из-за фундаментальных ограничений законов физики: энергии во вселенной не хватит. "Длина ключа и его полный перебор".
— cooshoo (16/08/2007 16:54)   профиль/связь   <#>
комментариев: 83   документов: 4   редакций: 4
А пока можно использовать идеи cooshoo.

Извиняюсь, последний вариант со счетчиком не отвечает поставленной задаче – невозможности восстановления предыдущих ключей. Значит только OFB
— Гость (16/08/2007 17:15)   <#>
Тут ещё надо исследовать устойчивость к расшифровыванию ключа, зашифрованного собою. Может случиться так, что в этом спецальном случае задача упрощается.
— cooshoo (16/08/2007 23:00)   профиль/связь   <#>
комментариев: 83   документов: 4   редакций: 4
Может быть. Ведь много вариантов – если ключ 256 бит, а блок 128, можно шифровать в ECB режиме, CBC или CFB. Каждый из этих вариантов наверняка имеет свои особенности. Можно расчитать SHA-256 от ключа и шифровать им. Можно расчитать SHA-512 и зашифровать одну половину другой. А можно проделать все это одновременно, используя разные алгоритмы шифрования, и сложить полученый результаты по XOR или с переносом... Вычислительных ресурсов тратим минимум, но удовлетворяется практически любая степень паранойи.
— SATtva (16/08/2007 23:19)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Или так: "Вычислительных ресурсов тратим минимум, зато получаем массу удовольствия". :-)
— spinore (18/08/2007 14:29)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Итак, если я правильно всё понял, достаточно на первом этапе обменяться открытыми ключами внутри группы по 3-му каналу (никогда не пересылая их через интернет), чтобы установить схему общения, устойчивую как квантовым компьютерам, так и к раскрытию приватного ключа (используя существующий на какой-то момент шифрованный канал можно обновлять свои ключи раз в какой-то промежуток времени и удалять предыдущие вместе с полученной с помощью них информацией).
А отпечатки публиковать безопасно? Их знание не даст атакующему возможность восстановить ключ, используя квантовый компьютер или не внесёт ли узявимость в означенную схему? Вопрос к тому, что есть jabber. Некоторые умные клиенты джаббера сообщают ID ключа тем, кто в листе, не будет ли это узявимостью... относительно взлома посредством квантовых компов или относительно получения временного открытого ключа (который открыто публиковаться не будет)?
— spinore (18/08/2007 14:32)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Спасибо cooshoo и SATtva – интерсно было узнать ответ...
Видимо, прийдётся менять ключ :(
— SATtva (18/08/2007 20:40)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
А отпечатки публиковать безопасно? Их знание не даст атакующему возможность восстановить ключ, используя квантовый компьютер или не внесёт ли узявимость в означенную схему?

Считается, что такие алгоритмы, как семейства SHA, устойчивы к восстановлению прообраза при любых условиях. Возможно, с информационно-теоретической точки зрения какая-то незначительная утечка ключевой информации в этом случае и происходит, но я сомневаюсь, что её можно обратить даже в чисто теоретическую атаку. Отпечаток — это всего лишь хэш-значение публичных параметров ключа.

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

Если вводить в модель угрозы КК, я бы предпочёл классические симметричные схемы защиты.
— spinore (18/08/2007 21:09)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Мне тем нравится асимметричное крипто, что оно легко интегрируется с существующими программами (ничего менять не надо). Если же переходить на симметричное – надо писать свою реализацию-плагин к jabber :( Вопрос только в этом...
— cooshoo (21/08/2007 07:50)   профиль/связь   <#>
комментариев: 83   документов: 4   редакций: 4
С другой стороны, я не уверен, что пересылка асимметрично зашифрованных данных совсем уж безобидна, если принять во внимание потенциал КК

Насколько я понимаю, квантовый компьютер должен концепционно напоминать старые аналоговые ЭВМ. Устанавливается закон преобразования и выход подается на вход через схему обратной связи. За характеристическое время состояние системы стабилизируется и можно считывать результат. Если никакие параметры кроме шифртекста неизвестны, обратную связь тоже нельзя установить. Даже стандартный заголовок шифропакета (как в GnuPG) не поможет при неизвестном модуле – каждому вероятному простому модулю соответствует свое решение.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3