чем посчитать fingerprint публичного ключа?

проще посмотреть исходники ssh-keygen. Вряд ли там будет что-то мудрёное.

А что ты хочешь сделать с fingerprint? Может, тебе просто подойдёт считать md5-сумму или ещё чего у ключа.

ну да, весь код в key.c в key_fingerprint_raw . Там через Evp_Digest делается http://www.openssl.org/docs/crypto/evp.html

сырцы я смотрел. Evp_Digest это уже расчет хеша - дело в том что прежде чем считать он по разному упаковывает разные ключи. не хочется велосипед городить - хочется взять какую то функцию которая будет и дальше работать с другими ключами в будущем.

хочется взять какую то функцию которая будет и дальше работать с другими ключами в будущем.

возьми целиком key.c, сделай из неё либу (думаю, за час вопрос решается) и используй. Как видно из сырцов, парой вызовов из openssl ну никак не обойтись если хочешь считать fingerprint так же как в openssh.

кстати: https://github.com/mfriedl/libopenssh

Fingerprint ключа/сертификата считается как md5/sha1 сумма от ключа/сертификата в кодировке BASE64 без тегов ----BEGIN CERTIFICATE----- и -----END CERTIFICATE----- и без символов разрыва строки. Пруфы тебе предоставит вывод openssl x509 -in <cert> -fingerprint sha1/md5

Да ну? http://www.openssl.org/docs/apps/x509.html

-fingerprint

prints out the digest of the DER encoded version of the whole certificate (see digest options).

возьми целиком key.c, сделай из неё либу (думаю, за час вопрос решается) и используй.

это понятно, но это будет велосипед. введут потом какой нибудь rsa2 и привет, я был уверен что в openssl это встроено

md5/sha1 сумма от ключа/сертификата в кодировке BASE64 без тегов

как минимум для RSA это подругому, а для DSA еще более подругому

введут потом какой нибудь rsa2 и привет

Обновишь key.c и всё будет пучком.

Но я думаю ты сильно перестраховываешься. Мой опыт подсказывает что если так париться по всякому пустяку то проект вообще можно не завершить. Поэтому я стараюсь делать первый костыльный вариант с внесением косяков в TODO а дальше, после того как написана первая рабочая версия, в порядке приоритета допиливаю «как надо».

Я бы вообще сделал через ssh-keygen и не парился пока бы не убедился что затык именно в этом. Ты уверен что тебе нужно будет десятки ключей в секунду проверять? А иначе это не имеет практического смысла (ну кроме как удовлетворить тягу к перфекционизму). Зато если введут новый вид ключей то обновишь ssh и проблема решиться.

Если бы можно было использовать бинари как библиотеки я бы предложил делать dlopen(«ssh-keygen») :)

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

но не красиво это вызывать тулзу

ну почему же, unix-way :). Вообще, я бы остановился на внешней тулзе потому что это

1) минимум кода, причём write once, use forever

2) простота отладки

3) готовое и проверенное решение

4) поддержка новых форматов ключей на плечах других

Я вообще сейчас перешёл на принцип «меньше кода - лучше» :)

есть еще один путь - продвижение нужно функционала в существующие библиотеки. посмотрел я libssh и libssh2 все нет там простого пути скормить им кусок памяти сказав что это публичный ключ и посчитать по нему fingerprint.

В libssh это должен быть файл, в libssh2 нужно открывать соединение.

в существующие библиотеки

как-то эти библиотеки не вызвали у меня доверия. Да и это будет раздувать зависимости твоего приложения, а openssh есть везде.

Кстати, я тут недавно для себя открыл философию unix, может тебе это понравится:

Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.

Rule of Composition: Design programs to be connected to other programs.

Но, если ты в себе чувствуешь силы, то можно и начать переговоры с авторами libssh* и внести нужную фичу. Но, имхо, это будет геморрой. Плюс непонятно как это сопрягать с не-C программами. Я пишу на питоне и уже сыт по горло написанием биндингов к C. Хотя простейшие вещи делаются просто, работа со сложными структурами, макросами и указателями это ад.