py.user.next

Я конечно rfc не изучал досконально, но кто-то неправ, либо вы, либо книжка (ссылку на которую я указывал выше).

PS. Ан нет похоже книжечка все таки права

noob_saibot
PS. Ан нет похоже книжечка все таки права

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

py.user.next
Там генерится одна пара ключей и любой из них выбирается публичным, а оставшийся - приватным. То, что зашифровано публичным, можно расшифровать только приватным. То, что зашифровано приватным, можно расшифровать только публичным. Потом публичный ключ передаётся по открытому каналу, а приватный не передаётся. И передача подписи как раз и построена на этом принципе - владелец приватного ключа шифрует кусочек информации, а владелец публичного ключа расшифровывает её.

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


PrivateKey(9769124746202614140138067488845521763884470894475422511603820948295846251457469635095644494915195805808074392513602100014868462709593665223547265576603293, 65537, 2966944763239343147310802986068652290894555879634997172146458521978127220813988205545822474550964774391996290849933064375961023457258553135543694303234049, 5954739276398380987717581364872596349785271587494900046431178951680834971737450297, 1640562968881367534819709307125835373854003906917564944810591760602062469)

PublicKey(9769124746202614140138067488845521763884470894475422511603820948295846251457469635095644494915195805808074392513602100014868462709593665223547265576603293, 65537)

cutwater

По приведённой ссылке какое бы вы не выбрали представление, ключи не будут равнозначны, это я к:

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

“An encryption primitive produces a ciphertext representative from a
message representative under the control of a public key, and a
decryption primitive recovers the message representative from the
ciphertext representative under the control of the corresponding
private key.”

py.user.next
владелец приватного ключа шифрует кусочек информации, а владелец публичного ключа расшифровывает её

PS. Сорри за оффтоп.

noob_saibot
но кто-то неправ, либо вы

Да, наверное, они не равны по своим возможностям.
Тут можно почитать. Там пишут, что при n = p * q, где p и q простые, n открывается, а p и q держатся в секрете. И перевернуть это нельзя.

wallet
и публичным нельзя расшифровать зашифрованое приватным

То, что вы только что сказали — одна из самых безумно идиотских вещей, что я когда-либо слышал. Каждый в этой комнате отупел. ©

Да, наверное, они не равны по своим возможностям.

С математической точки зрения можно сказать, что они равнозначны, т.к. любой ключ из пары привантый, публичный может использоваться для преобразования открытый текст -> шифртекст, а другой для обратного преобразования. Объяснение см. далее.

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

Не совсем так, не любой.

В алгоритме RSA и открытый (публичный) и закрытый (приватный) ключ представляют собой пары чисел (n, e) и (n, d), где
n - модуль
e - открытая экспонента
d - закрытая экспонента

Число d является обратным числу e по модулю phi(n), где phi(n) - функция Эйлера. Таким образом выполняется условие .

Операция шифрования математически есть возведение в степень экспоненты (e или d) по модулю n. Операция дешифрования так же есть возведение в степень второй экспоненты. Таким образом операции:
и равнозначны.

Однако т.к. число e имеет меньшую битовую длину, его выбирают в качестве публичного ключа, а число d в качестве приватного ключа.

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

Так что, уважаемые py.user.next и noob_saibot, Вы в какой-то степени оба правы.

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

Или простым языком = шифруешь одним ключом, расшифровываешь другим… Все, грубо говоря, зависит от направления передачи.

Но вы немного недопонимаете в чем вся соль. Проникнитесь словами “публичный” и “приватный”.

cutwater
Таки неправы Вы, уважаемый. Шифрование и цифровая подпись это таки разные вещи. Рекомендую изучить матчасть.

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

Iskatel, после того как Вас ткнули носом в Вашу же некомпетентость, Вы еще имеете наглость хамить?

Iskatel
Или простым языком = шифруешь одним ключом, расшифровываешь другим… Все, грубо говоря, зависит от направления передачи.

Боб передает Салли данные. Чей ключ и какой (открытый или закрытый) применит Боб?

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

Iskatel
ИМХО ты немного путаешь. Хранить конечно надо оба ключа, но для расшифровки нужен “паблик” , чтоб поняли что именно ты это писал.

Шифрование гарантирует конфиденциальность данных, но не аутентичность или целостность.
ЭЦП гарантирует целостность и аутентичность, но не гарантирует конфиденциальность.
Таким образом Ваше утверждение не корректно, а хамство и переход на личности не уместно и нарушает правила поведения на этом форуме.

В реальном же мире все немного сложнее, асимметричные алгоритмы зачастую не используются для шифрования данных. Обычно при помощи асимметричных алгоритмов реализуют ЭЦП и шифруют сеансовые ключи.

Iskatel
Цифровая подпись - это лишь один случай передачи данных.

Цифровая подпись непосредственно к передаче данных не имеет никакого отношения. Ваше утверждение не корректно.

cutwater

Кирби, ты чтоль? (или Псаки)

Я понимаю, пятница, но ум то должен присутствовать.

cutwater
Число d является обратным числу e по модулю phi(n), где phi(n) - функция Эйлера.

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