![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Неиллюзорный адъ криптографии
Разбирался, как из 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 фреймворке я его не нашел), сопоставил секции в последовательности и компоненты ключа и сгенерил таки из линуксового ключа дотнетовский. Причем ноль в начале данных компонент пришлось вырезать руками, потому-что парсер из моно тоже возвращает этот лишний ноль.
Честно вам скажу, все-таки в микрософте люди работают более вменяемые, чем те, кто придумал формат 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 фреймворке я его не нашел), сопоставил секции в последовательности и компоненты ключа и сгенерил таки из линуксового ключа дотнетовский. Причем ноль в начале данных компонент пришлось вырезать руками, потому-что парсер из моно тоже возвращает этот лишний ноль.
no subject
Затем, что софт (и ключи эти всякие к нему комплектные) часто работает не сам по себе, а его приходится прикручивать к другому софту (и так 15 раз). А разработчики проприетарного софта на самом деле - люди отмороженные и про "все библиотеки понимают" - эт Вы сильно погорячились. Т.е. понимать то они может и понимают, но когда обратно выдают результат - это всё в пропорции к объёмом абсента, потреблённым в процессе кодописания аффтарами.
Что в свои сертфикаты/ключи для доступа к ихним информационным системам всякие банки засовывают - это ж, например, просто уму непостижимо. И когда обёртку пишешь, чтобы одно с другим стыкануть - лучше бы хотя бы приблизительно представлять, какие поля тебе прислали, а какие - решили что ты без них перебьёшься.
С этой точки зрения XML представление с отдельными полями - явно лучше, чем base64-style блок, в котором то ли стандартный ключ, то ли, например, кроме самого ключика - IP-адрес твоей системы заXORенный с фазой луны дня окончания действия ключа.
no subject
no subject