Уязвимость подписи закрытым ключом RSA?

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

Для проверки того что открытый ключ принадлежит именно тому адресату который нам нужен используют цифровую подпись

Не верно. Для проверки того что открытый ключ принадлежит именно тому адресату который нам нужен используют аутентификацию ключа по 3му каналу (например, позвонить по телефону и попросить адресата продиктовать хэш его ключа, если его голос вам знаком). Вопрос о доверии ключу – принципиальный в PGP, и это доверие достигается, если угодно, "сторонними средствами".

может ли злоумышленник использовать зашифрованное закрытым ключом сообщение для того чтобы попытаться подобрать закрытый ключ или получить какую-то информацию о закрытом ключе?

Да, может. Поэтому в стандарте всё сделано хитрее, читаем unknown'а:

Потому что сначала генерируется сеансовый случайный симметричный ключ (по умолчанию AES), им шифруется всё сообщение, а уже этот ключ (а не само сообщение) шифруется асимметрикой. Расшифровывается естественно в обратном порядке. Иначе шифрование происходило бы очень медленно (до 10000 раз), а алгоритмы типа RSA неустойчивы к атакам с подобранным открытым текстом – кто-нибудь попросил бы вас перешифровать текст вашим ключом и переслать ему шифртекст, а из результата смог бы вычислить закрытый ключ.

А также читаем "Модель случайного оракула для чайников" (книжка в красочной мягкой обложке, дешёвом переплёте и карманном формате) под авторством unknown'а (для нас, – самых-самых ленивых). Там рассмотрен пример симметрики, но сказанное верно и для асимметрики.

Думаю, это снимает все ваши вопросы.

Нее.. Стойкость ассиметричных методов типа RSA – это одно. А я спрашиваю об участии электронной подписи в этих методах. Зачем она нужна, если выдает дополнительную информацию о закрытом ключе?

Если как вы говорите открытый и закрытый ключи равнозначны, то посылая сообщение для проверки подписи, закриптованное закрытым ключом вместе с открытым мы даем злоумышленнику лишнюю информацию. И если сравнить 2 метода: 1) посылать только окрытый ключ и 2) посылать открытый ключ и подпись(сообщение закриптованное закрытым ключом+хеш...) то второй явно хуже и дает злоумышленнику возможность получить некую информацию о закрытом ключе.

Еще раз спрашиваю зачем тогда используется подпись в приницие? Зачем предоставлять лишнюю информацию? Ведь можно и без нее обойтись. И зачем тогда электронная подпись используется в системах обмена информацией "открытый-закрытый ключ"?

Для Гость (23/04/2009 11:12
О симметричных методов(AES и т.д.), которые используются вместе с ассимметричными(RSA) я вроде бы и не спрашивал...

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

Подпись нужна затем, чтобы знать, что сообщение вам пришло именно от того, кто заявляет своё авторство на послание. Ваш корреспондент подписывает сообщение своим ключом (закрытым), шифрует (например, поверх) вашим (открытым) и посылает вам. Вы расшифровываете своим закрытым, и видите подпись к тексту, истиность которой и проверяете, если у вас есть открытый ключ ей соответствующий (т.е. принадлежащий вам пославшему). Без подписи не будет аутентификации сообщени. Любой может вашим открытым ключом зашифровать какое-то сообщение и вам отправить – никто кроме вас прочитать его не сможет, но вот вы же заинтересованы в достоверности источника откуда оно пришло? Здесь я рассматриваю классическую схему, когда ваш открытый ключ известен всем (такая схема имеет ряд преимуществ и недостатков). Если же предположить, что вы с кем-то договорились никому не показывать свои открытые (публичные) ключи – то да, можно подписи вообще не использовать.

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

Вы какжется в основах пока путаетесь. Вы всё ж почитайте сообщения, на которые ссылки вам указали.

О симметричных методов(AES и т.д.), которые используются вместе с ассимметричными(RSA) я вроде бы и не спрашивал...

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

"шифрует (например, поверх) вашим (открытым)"-Гость

Вот это да. То что можно подпись еще и открытым ключои шифрануть я не подумал. Ok. Приму к сведению. Но здесь сразу возникает задача о том, что ключ открытый должен быть как-то подтвержден, например, как здесь уже предлагалось через 3 канал. А как можно подтвердить валидность открытого ключа не прибегая к 3 каналу и к использованию стандартного 3 лица подписавшего ключ, есть какие-то методы?

PS:Да знаю я про то что сначала криптится AES, а потом ключ AES шифруется RSA. И про хеши где и когда используются тоже знаю.

А как можно подтвердить валидность открытого ключа не прибегая к 3 каналу и к использованию стандартного 3 лица подписавшего ключ, есть какие-то методы?

1. Стать мазохистом и начать участвовать в PGP-сети доверия.
2. По уже устанлвенному защищённому каналу спросить отпечаток ключа у 3го лица, которому вы доверяете. Если у вас есть 2 абонента которые между собой общаются, и вы им доверяете, а PGP у вас только с одним из них – вы можете попросить того, с которым у вас PGP, выслать отпечаток другого абонента по защищёному каналу (как ни странно, мне часто приходится прибегать к этой схеме). – Это частный случай согласования по 3му каналу.

Вообще, все методы сводятся к концептуальным 2ум: либо к "PGP-сети доверия", либо к третьему каналу.

Еще раз спрашиваю зачем тогда используется подпись в приницие? Зачем предоставлять лишнюю информацию? Ведь можно и без нее обойтись. И зачем тогда электронная подпись используется в системах обмена информацией "открытый-закрытый ключ"?

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

"так как RSA неидеален, используются две пары открытых/закрытых ключей – одна для шифрования, другая для подписи и они независимы." – unknown

А можно поподробнее об использовании 2-х пар открытых/закрытых ключей, как это работает? Я слышал это именно RSA ver.4, да?

Вот если используется одна, то упрощенно так (конкретные алгоритмы только для примера, если неправ поправьте):
1. Допустим установили доверие – обменялись открытыми ключами(3 канал, 3-е лицо)
2. Надо передать файл: Добавляем случайное число(>1024 бит) к файлу, чтобы нельзя было подобрать хеш к документу. Оно потом при приеме отрезается.
3. Считаем хеш файла.
4. Архивируем файл.
5. Шифруем файл сеансовым ключом методом AES.
6. Шифруем сеансовый ключ AES и хеш файла своим закрытым ключом RSA. Далее для защиты шифруем полученное значение открытым ключом корреспондента.
7. Передаем то что получили на 5 этапе и на 6 этапе.

Расскажите, пожалуйста, если знаете, примерную подобную схему для 2-х пар ключей?

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

Есть ещё такое понятие как padding – дополнение, а ещё есть хитрые схемы, где RSA используется как-бы внутри сети Фейстеля. Нужно смотреть какой конкретно стандарт реализует та или иная программа.

примерную подобную схему для 2-х пар ключей?

6. Шифруем сеансовый ключ AES и хеш файла своим закрытым ключом для подписи. Далее для защиты шифруем полученное значение открытым ключом корреспондента для шифрования.

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

А где схема-то для 2-х пар откр./закр. ключей??? Я то привел только для одной пары...

"а каждый такой "внутренний ключ" может быть "парой пар" ключей – одной зашифровываем/расшифровываем, другой подписываем/проверяем. Есть ещё такое понятие как padding – дополнение, а ещё есть хитрые схемы, где RSA используется как-бы внутри сети Фейстеля." – unknown

Вы можете, если знаете, конечно, объяснить смысл применения второй пары – открытый/закрытый ключ. То есть преимущество, по сравнению, с применением одной пары как я это схематично написал? На примере?

PS: или у вас тут приняты шифровки на сайте вместо помощи в ответе на вопрос... :)

Как гласит PKCS #1: RSA Cryptography Standard Version 2.1

A generally good cryptographic practice is to employ a given RSA key pair in only one
scheme. This avoids the risk that vulnerability in one scheme may compromise the
security of the other, and may be essential to maintain provable security. While RSAES-
PKCS1-v1_5 (Section 7.2) and RSASSA-PKCS1-v1_5 (Section 8.2) have traditionally
been employed together without any known bad interactions (indeed, this is the model
introduced by PKCS #1 v1.5), such a combined use of an RSA key pair is not
recommended for new applications.

To illustrate the risks related to the employment of an RSA key pair in more than one
scheme, suppose an RSA key pair is employed in both RSAES-OAEP (Section 7.1) and
RSAES-PKCS1-v1_5. Although RSAES-OAEP by itself would resist attack, an opponent
might be able to exploit a weakness in the implementation of RSAES-PKCS1-v1_5 to
recover messages encrypted with either scheme.

Смысл этого текста вот в чём – просто шифрование/подписывание по формуле
C=M^e(mod n) – это криптопримитив. А вот для реальной работы нужны более сложные схемы
с дополнениями типа RSAES-PKCS1-v1_5 и RSASSA-PKCS1-v1_5, где буква "E" в определённом месте
означает encryption (и заодно decryption), а "S" – signature.

RSAEncryption Scheme, RSASignature Scheme (with) Appendix и т.д.

И вот в этих схемах (схема в данном случае – это промежуточное звено между примитивом и протоколом) иногда использование одного и того же ключа безопасно, а иногда фатально, иногда непонятно к чему может привести, поскольку нет "доказуемой безопасности" использования ключа в двух схемах одновременно. Дополнительные уязвимости возникают из-за ошибок реализации.
Поэтому рекомендуют не искушать судьбу и в новых реализациях использовать две раздельные пары ключей –
– одну только для участия в схемах подписи, другую – только для шифрования.

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

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

или у вас тут приняты шифровки на сайте вместо помощи в ответе на вопрос... :)

?
Поидее ваш вопрос был сформулирован так, что правильныv ответом на него был бы RTFM. Вы забыли, что это не коммерческий ресурс и вам здесь никто ничем не обязан? Я заметил последнее время, что участились случаи появления на сайте гостей, которые в ответ на бескорыстную помощь и ответы поливают говном. И, да, здесь как бы люди с тактом. потому не говорят прямо, а подходят к нубам аккуратно. Ряд ваших вопросов были абсолютно тупыми, которые говорили о том, что вы даже не пытались разобраться в основах вопроса. Заметьте, что тем не менее на них формально и точно ответили. Вам, AlexGrad, должно быть стыдно.