Comments 24
Вроде бы и не совсем эльфийский… а всё-равно прочесть не удаётся…
Можно как-то, в общих чертах, ближе к русскому объяснить, или показать на примере любого из ЯП (адекватных, разумеется, а не brainfuck'оподобных)?
Можно как-то, в общих чертах, ближе к русскому объяснить, или показать на примере любого из ЯП (адекватных, разумеется, а не brainfuck'оподобных)?
+11
Вот еще недостаток: эта схема требует однозначного идентификатора для пользователя, а что если имена у пользователей одинаковые? Или паспортные данные в двух разных странах одинаковые? Вводить централизованную систему выдающую идентификаторы? Ну так сейчас почти то же самое, только выдают сразу ключи :)
Хотя чисто теоретически схема очень интересная.
Хотя чисто теоретически схема очень интересная.
+2
Идентификаторы Алисы и Боба IDA и IDB известны обоим партнерам.
А откуда они могут быть известны?
0
Предполагается что Боб хочет написать письмо человеку с именем Алиса. Он не заморачивается насчет ключей. Просто использует ее имя — ID.
0
Но тогда получается, что её имя должно быть уникальным, однако Алис много, поэтому ФИО в качестве ID не подходит. Как быть?
0
Добавлять к имени дату рождения например. Проблемы конечно есть но они решаемы. В теории очень красивая система получилась.
0
Открытый ключ… не может служить средством аутентификацииЭм… Вы перепутали понятия. Криптография как раз таки и решает задачу аутентификации. И в чистом виде (без PKI, например) не может решить задачу идентификации.
+2
Эм… это вы что то путаете. Сама по себе асимметриная криптография не решает ни ту ни другую проблему. А вот PKI да решает проблему аутентификации.
-1
Ну так как, объясните каким образом криптография с открытым ключом решает проблему аутентификации без использования PKI?
0
Типичный пример, аутентификация по ключам в SSH.
Вообще процессы аутентификации и идентификации очень тяжело разделить, но всё же эта грань в теории существует, на практике же они слиты воедино.
Вообще процессы аутентификации и идентификации очень тяжело разделить, но всё же эта грань в теории существует, на практике же они слиты воедино.
0
В этом случае либо была аутентификация по логину-паролю, либо админ/оператор (уполномоченное лицо) закинули публичный ключ на сервер, выполнив роль PKI.
+1
Ну если так к делу подходить, то конечно. ИМХО, Вы как-то совсем до безумия объяснение довели.
0
Почему до безумия? Все правильно написали выше. Без pki ssh лишается смысла. Т.к. любой может прислать вам неизвестный открытый ключ и сказать что это ключ от сервера. Поэтому к асимметричной криптографии нужен дополнительный инструмент аутентификации. Сами по себе ключи не способны ни аутентифицировать вас ни идентифицировать.
0
Это всё равно, что рассуждать, что сам по себе карандаш писать не будет, ему нужно(ен) что-то(кто-то) что(кто) будет его применять.
PKI в контексте ssh аутентификации по ключам заменяет заранее известный fingerprint сервера (отнесённый ручками, прописанный в DNS, и т.п.), а не то что публичный ключ оказался на сервере. Должны же быть хоть какие-то начальные условия.
PKI в контексте ssh аутентификации по ключам заменяет заранее известный fingerprint сервера (отнесённый ручками, прописанный в DNS, и т.п.), а не то что публичный ключ оказался на сервере. Должны же быть хоть какие-то начальные условия.
0
То о чем мы сейчас говорим, это несомненно аутентификация с применением криптографического ключа. Тут я с вами согласен. Но вы упускаете то, что прежде чем использовать ключ для аутентификации пользователя, сперва необходимо выполнить аутентификацию самого ключа. В нашем случае, сверить fingerprint.
Не подумайте, что я докапываюсь. Просто есть такое понятие как аутентификация ключа, которую без PKI или дополнительного защищенного канала нельзя произвести. А без аутентификации ключа в свою очередь нельзя произвести аутентификацию пользователя.
Это подводит нас к началу нашей дискуссии. А именно к тому, что ключ не прошедший аутентификацию(PKI или другой метод) не может служить для аутентификации субьекта.
Не подумайте, что я докапываюсь. Просто есть такое понятие как аутентификация ключа, которую без PKI или дополнительного защищенного канала нельзя произвести. А без аутентификации ключа в свою очередь нельзя произвести аутентификацию пользователя.
Это подводит нас к началу нашей дискуссии. А именно к тому, что ключ не прошедший аутентификацию(PKI или другой метод) не может служить для аутентификации субьекта.
+1
Давно хотел спросить и топик подходящий: есть у меня идея использовать в ручной подписи числа в подписи. Допустим сначала пишу число в место «подписать здесь», а потом поверх него уже свой росчерк. Какой алгоритм подобрать без необходимости помнить число, написанное в предыдущем договоре и чтобы в уме достаточно просто считалось?
+1
Эммм, первое, что в голову пришло, с потолка — используйте контрольную сумму по алгоритму, известному только вам по дате или лучше номеру договора, либо по любому другому уникальному контенту в договоре…
+1
Весьма сомнительна практическая часть такого действа, если во многих важных документах будут сравнивать подпись с подписью в паспорте.
Договор № 969\12 от 20.11.14 к примеру можно просто сложить в 3645.
Я вот не люблю ручную подпись тк она в очень редких случаях совпадает с нужным эталоном. За прошлый год мне пришлось поставить свою подпись более 30 000 раз и я помню, что далеко не всегда она была нормальной: сильно зависела от окружающего (настроения, скорости письма и тд).
Можно пойти дальше и к примеру использовать перьевую ручку добавляя в чернила вещества которые светятся в УФ. Осталось только решить проблему — что делать если забыл её дома или закончились чернила.
Договор № 969\12 от 20.11.14 к примеру можно просто сложить в 3645.
Я вот не люблю ручную подпись тк она в очень редких случаях совпадает с нужным эталоном. За прошлый год мне пришлось поставить свою подпись более 30 000 раз и я помню, что далеко не всегда она была нормальной: сильно зависела от окружающего (настроения, скорости письма и тд).
Можно пойти дальше и к примеру использовать перьевую ручку добавляя в чернила вещества которые светятся в УФ. Осталось только решить проблему — что делать если забыл её дома или закончились чернила.
0
Не понял, чем Трент отличается от удостоверяющего центра? Кроме того, что он знает еще больше, сами закрытые ключи, что делает всю систему бесполезной.
+1
Почему сразу бесполезной? Можно использовать в корпоративных сетях, где сервер может выполнять роль Трента.
А про отличие от стандартной PKI с сертификатами. Оно налицо. Процедура аутентификации сокращается до одного шага. Остается только выдача ключа Алисе Трентом. Никаких пересылок сертификатов и их проверок.
А про отличие от стандартной PKI с сертификатами. Оно налицо. Процедура аутентификации сокращается до одного шага. Остается только выдача ключа Алисе Трентом. Никаких пересылок сертификатов и их проверок.
0
А я работал с Ади Шамиром в одной фирме :) Действительно таких людей в мире не много.
0
Sign up to leave a comment.
Личностная криптография: рассказ об одной полезной уязвимости