= Сообщение: 181 из 2735 ==================================== RU.FTN.DEVELOP =
От : Pavel Gulchouck 2:463/68 18 Jan 14 15:41:26
Кому : Ivan Agarkov 18 Jan 14 15:41:26
Тема : Fido over SSL
FGHI : area://RU.FTN.DEVELOP?msgid=2:463/68+52da8cd8
На : area://RU.FTN.DEVELOP?msgid=2:5020/849.1+52da7df7
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FTN.DEVELOP?msgid=2:5020/849.1+52da96b6
==============================================================================
Hi Ivan!
18 Jan 14, Ivan Agarkov ==> Pavel Gulchouck:
IA> Pavel Gulchouck писал(а) Ivan Agarkov в 13:35 18 янв 14
PG>> gpg разве умеет кодировать поток, как это делает ssh? Я думал, что он
PG>> только пакетно работает. Key server - не более чем идея, но в готовом
IA> А ему и не нужно. GPG может подписать адрес узла приватным ключем узла и зашифровать сессионный ключ публичным ключем
IA> второй стороны. А дальше - потоковое шифрование чем угодно, хоть XOR'ом.
Это наколенные решения, которые могут оказаться уязвимыми.
Например, "подписать адрес узла приватным ключом узла" - и что? Типа, если я получу твой адрес, подписанный твоим приватным ключом, то я буду уверен, что это звонишь мне ты, а не кто-то другой? Но если я этот твой подписанный адрес запомню и потом предъявлю его кому-то другому, он тоже будет уверен, что ему звонишь ты, а не я? ;-)
Правильнее, чтобы отвечающая сторона отправляла случайную строку, звонящая подписывала её своим ключом и отправляла подпись обратно.
"Шифровать чем угодно, хоть XOR-ом" - тоже с большой вероятностью такое шифрование может оказаться вскрываемым. Да и понятие "сессионный ключ" (вместо keypair, который уже и так есть) - тоже не добавляет изящности и секьюрности решению.
PG>> виде для нужд fido неприменим, потому что, опять же, для запроса и
PG>> проверки подписей ключей нужна ручная работа и подтверждения, совсем
PG>> автоматически это не получится. Так, чтобы я тебе позвонил, ты
IA> Hет, все не так. Я выпускаю ключ и кладу на сервер его публичную часть.
IA> Ты, убедившись что ключ мой, подписываешь мой публичный ключ ( получив его с сервера ) своим приватным ключем и выгружаешь
IA> подпись на сервер. Hикакой централизации RC->NC->Hub->Node не нужно :-)
Централизация ZC->RC->NC->Hub->Node нужна для фазы "убедившись, что ключ мой". В твоей схеме она никак не решается.
Если убеждаться предлагается, связавшись каким-то образом лично, тогда можно и ключ передать непосредственно, без всяких кейсерверов.
PG>> Если напишешь такую команду-пайп - да, это будет решением вопроса. Я
PG>> не напишу, потому и сказал, что надо подумать/поискать.
IA> Hу в принципе это не сложно. Hадо пошуркать в libgpg :-)
Если несложно - напиши. :)
PG>> Поэтому, например, gzip в этот пайп добавить нельзя, сессия залипнет,
PG>> когда одна сторона передала что-то (например, пароль) и ждёт ответа, а
PG>> вторая сторона этот пароль ещё не получила, потому что ждёт
PG>> дополнительных данных.
IA> Hа это существует nonblocking i/o.
Нет, я не об этом.
gzip/gunzip (как и любую другую компрессию) добавить в пайп не получится, потому что один байт на входе может дать больше или меньше одного байта на выходе.
Я передал "M_NUL", после компрессии оно преобразовалось в какое-нибудь \x23\x56, после декомпрессии будет "M_NU" и определённое состояние декомпрессора. Принимающая сторона получит символ "L" только после того, как передающая отправит ещё один (или несколько) символов в поток, чтобы появился следующий байт в компрессированном потоке.
Для корректной работы протокола binkp отправка каждого одного байта в поток должна вызывать передачу (как минимум) одного байта на транспортном уровне, и приём этого одного байта на удалённой стороне, без ожидания, что пошлёт отправитель дальше.
На самом деле, такое деление достаточно на уровне binkp-пакетов, но утилита, организующая транспорт, ничего о них не знает, поэтому должна обеспечивать консистентность в любой момент.
PG>> То, о чём ты говорил вначале - отключил CRAM-MD5 и собрал все пароли?
PG>> ;-)
IA> Hо не забывай про полиси: нетмейл должен ходить независимо от CRAM-MD5 :-)
Нет такого в полиси.
PG>> Скорее, наоборот: в этом случае можно пробовать разные транспорты для
PG>> доступа к узлу, а если это binkp extension, то только tcp и никак
PG>> иначе (даже ipv6 нужно отдельно реализовывать).
IA> Можно просто использовать чуть более высокоуровневые библиотеки.
IA> У меня например изкаропки ipv6 работает.
Фактически вызов внешней утилиты для организации соединения мало чем отличается от вызова высокоуровневой библиотеки. :)
Только внешняя утилита - несколько более гибкий и переносимый способ.
Lucky carrier,
Паша
aka gul@gul.kiev.ua
--- GoldED+/LNX 1.1.5
* Origin: Опыт - это то, что мы получаем вместо того, что хотели (2:463/68)
|
