Неиллюзорный адъ криптографии

[metaclass]

Разбирался, как из rsa-ключа, сделанного openssl или ssh-keygen сделать ключ в xml-формате для C# RSACryptoServiceProvider. Типа реализовать интероперабилити между .NET и тулсами из юниксового мира.


Честно вам скажу, все-таки в микрософте люди работают более вменяемые, чем те, кто придумал формат rsa-ключа. В C# все просто - ключик в xml-файле/строке, отдельные xml-тэги, Modulus, Exponent для паблик-ключа и плюс P,Q,DP,DQ,InverseQ,D - для приватного. В тэгах - значения в base64. Читабельно, понятно и доступно тому, кто слышал как эта асимметричная криптография работает. И парсится легко.

Формат же ключа, который создает ssh-keygen и openssl genrsa, хотя и стандартный и описан в rfc - это смерть, жопа и сатана.

Во-первых, описание этого формата я еле откопал, хотя оно и в rfc. Причем толку от описания было мало, быстрее получилось дампить ключ с помощью openssl asn1parse и смотреть содержимое.

Во-вторых, начало и конец оформлено строками -----BEGIN/END RSA PRIVATE KEY-----, а между ними - base64 блок. Т.е. формат меняется прямо внутри файла - строки конца и начала ни разу не являются валидным base64.

В-третьих, в base64 блок упихнуты все компоненты ключа, в виде ASN1 последовательности, формат, известный своей "адекватностью" для парсинга.

И, что самое интересное, openssl rsa in key -noout -text показывает компоненты ключа странно - дописывает в начало некоторых лишний ноль. При этом, openssl asn1parse показывает правильно - без нуля.

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

Comments

[arush-damage.livejournal.com]

И чем же плох ФТП?

[vp.livejournal.com]

Реализацией управления командами по одному порту, а дататрансфера - по совсем другому параллельному порту. Сущее безумие, которое вообще могло родиться только в кошмаре разработчика.

[arush-damage.livejournal.com]

И что же в этом безумного?

[metaclass.livejournal.com]

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

[arush-damage.livejournal.com]

И в чем же заморочка при передаче в одном соединении и данных и команд? :)

Схема реализованная в ФТП позволяет делать вещи хоть и не часто требуемые но весьма полезные. Например используя только ФТП можно с системы А соединиться с системами В и С и передать файл с В на С. :)

Не стоит также забывать что FTP разработан в 1985 году.
Telnet и DNS - в 1983, TCP в 1981.

И до сих пор все эти протоколы активно используются, несмотря на то что прошло уже больше 20-ти лет.

ЗЫ. А что значит "Практически, они переложили решение с себя на других"? Какое решение?

[vp.livejournal.com]

Вот про это и речь, что народ мыслит категориями 1985 года, что везде реальные адреса и привет. Когда сервер-сервер, одним когцом вставленные в интернет - безусловно проблем нету. Но не в реальной жизни.

[golosptic.livejournal.com]

При том, что характерно, есть Kermit, работающий поверх чего угодно в одном потоке и вытесненный нафиг из использования в результате свободной конкуренции с FTP. Интересно, почему? :D

[arush-damage.livejournal.com]

Вот для того чтобы можно было работать из-за файрвола и существует пассивный режим.
Дело не в том что кто-то мыслит категориями 1985-го года, а в том что почему то за более чем 20 лет этот "безумный" ФТП не был задавлен более удобным протоколом, как например случилось ч тем же гофером.
Может все же проблема не в ФТП, а? %))

[golosptic.livejournal.com]

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

Практически, они переложили решение с себя на других.
Да-да. Настоящие самураи внутрь каждой утилиты встраивают целиком операционную систему собственного написания ;-)

[arush-damage.livejournal.com]

Кстати да.
Ведь всем очевидно, что реализовать обмен командами и данными по одному сокету на порядки проще чем заморачиваться с безумным и непонятным IPC! :)
А уж написание сервера то как облегчается :)))