Pull to refresh

Comments 24

Вроде бы и не совсем эльфийский… а всё-равно прочесть не удаётся…
Можно как-то, в общих чертах, ближе к русскому объяснить, или показать на примере любого из ЯП (адекватных, разумеется, а не brainfuck'оподобных)?
ИМХО, эльфийский гораздо проще прочитать, чем эту статью :) Думаю, это потому, что тут вникать приходится.
Вот еще недостаток: эта схема требует однозначного идентификатора для пользователя, а что если имена у пользователей одинаковые? Или паспортные данные в двух разных странах одинаковые? Вводить централизованную систему выдающую идентификаторы? Ну так сейчас почти то же самое, только выдают сразу ключи :)

Хотя чисто теоретически схема очень интересная.
Идентификаторы Алисы и Боба IDA и IDB известны обоим партнерам.

А откуда они могут быть известны?
Предполагается что Боб хочет написать письмо человеку с именем Алиса. Он не заморачивается насчет ключей. Просто использует ее имя — ID.
Но тогда получается, что её имя должно быть уникальным, однако Алис много, поэтому ФИО в качестве ID не подходит. Как быть?
Добавлять к имени дату рождения например. Проблемы конечно есть но они решаемы. В теории очень красивая система получилась.
А на практике Трентом будет управлять АНБ (если использовать в глобальных масштабах)
Ну если начать с того, что у человека может быть несколько имён в одно и то же время, имя может не иметь фиксированной длинны, иметь огромную длину или не подлежать записи, а может и не быть имени вовсе…
Открытый ключ… не может служить средством аутентификации
Эм… Вы перепутали понятия. Криптография как раз таки и решает задачу аутентификации. И в чистом виде (без PKI, например) не может решить задачу идентификации.
Эм… это вы что то путаете. Сама по себе асимметриная криптография не решает ни ту ни другую проблему. А вот PKI да решает проблему аутентификации.
Ну так как, объясните каким образом криптография с открытым ключом решает проблему аутентификации без использования PKI?
Типичный пример, аутентификация по ключам в SSH.
Вообще процессы аутентификации и идентификации очень тяжело разделить, но всё же эта грань в теории существует, на практике же они слиты воедино.
В этом случае либо была аутентификация по логину-паролю, либо админ/оператор (уполномоченное лицо) закинули публичный ключ на сервер, выполнив роль PKI.
Ну если так к делу подходить, то конечно. ИМХО, Вы как-то совсем до безумия объяснение довели.
Почему до безумия? Все правильно написали выше. Без pki ssh лишается смысла. Т.к. любой может прислать вам неизвестный открытый ключ и сказать что это ключ от сервера. Поэтому к асимметричной криптографии нужен дополнительный инструмент аутентификации. Сами по себе ключи не способны ни аутентифицировать вас ни идентифицировать.
Это всё равно, что рассуждать, что сам по себе карандаш писать не будет, ему нужно(ен) что-то(кто-то) что(кто) будет его применять.
PKI в контексте ssh аутентификации по ключам заменяет заранее известный fingerprint сервера (отнесённый ручками, прописанный в DNS, и т.п.), а не то что публичный ключ оказался на сервере. Должны же быть хоть какие-то начальные условия.
То о чем мы сейчас говорим, это несомненно аутентификация с применением криптографического ключа. Тут я с вами согласен. Но вы упускаете то, что прежде чем использовать ключ для аутентификации пользователя, сперва необходимо выполнить аутентификацию самого ключа. В нашем случае, сверить fingerprint.

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

Это подводит нас к началу нашей дискуссии. А именно к тому, что ключ не прошедший аутентификацию(PKI или другой метод) не может служить для аутентификации субьекта.
Давно хотел спросить и топик подходящий: есть у меня идея использовать в ручной подписи числа в подписи. Допустим сначала пишу число в место «подписать здесь», а потом поверх него уже свой росчерк. Какой алгоритм подобрать без необходимости помнить число, написанное в предыдущем договоре и чтобы в уме достаточно просто считалось?
Эммм, первое, что в голову пришло, с потолка — используйте контрольную сумму по алгоритму, известному только вам по дате или лучше номеру договора, либо по любому другому уникальному контенту в договоре…
Весьма сомнительна практическая часть такого действа, если во многих важных документах будут сравнивать подпись с подписью в паспорте.
Договор № 969\12 от 20.11.14 к примеру можно просто сложить в 3645.
Я вот не люблю ручную подпись тк она в очень редких случаях совпадает с нужным эталоном. За прошлый год мне пришлось поставить свою подпись более 30 000 раз и я помню, что далеко не всегда она была нормальной: сильно зависела от окружающего (настроения, скорости письма и тд).

Можно пойти дальше и к примеру использовать перьевую ручку добавляя в чернила вещества которые светятся в УФ. Осталось только решить проблему — что делать если забыл её дома или закончились чернила.
Не понял, чем Трент отличается от удостоверяющего центра? Кроме того, что он знает еще больше, сами закрытые ключи, что делает всю систему бесполезной.
Почему сразу бесполезной? Можно использовать в корпоративных сетях, где сервер может выполнять роль Трента.
А про отличие от стандартной PKI с сертификатами. Оно налицо. Процедура аутентификации сокращается до одного шага. Остается только выдача ключа Алисе Трентом. Никаких пересылок сертификатов и их проверок.
А я работал с Ади Шамиром в одной фирме :) Действительно таких людей в мире не много.
Sign up to leave a comment.

Articles