LINUX.ORG.RU

Разница между GPG и OpenSSL

 ,


0

2

Долгое время считал, что OpenSSL - это либа, предназначенная для работы с (почти)одноименным протоколом. На поверку оказалось, что это набор тулзов для криптования и подписи.

В чем тогда, собственно, принципиальная разница между GPG и OpenSSL? Т. е., по сути, они являются несовместимой реализацией одного и того же?

Прошу не хейтить, действительно интересно, а википедия толкового ответа не дает.

GnuPG реализует OpenPGP, основана на библиотеке libgcrypt, предоставляет API через библиотеку gpgme для написания своих утилит.

OpenSSL это библиотека, реализующая протокол TLS, и базовые криптопримитивы (реализация алгоритмов шифрования, подписи, проверки целостности), обычно в составе имеет утилиту openssl, которая даёт пользователю доступ к функциям библиотеки без написания своих утилит.

Так что они таки про разное. OpenSSL схожа с libgcrypt тем, что обе содержат в себе реализацию криптопримитивов.

feanor ★★★ ()
Последнее исправление: feanor (всего исправлений: 1)
Ответ на: комментарий от feanor

Ок, примерно понял, что утилита openssl это больше инструмент, который понадобится при использовании либы(для создания ключей, например).

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

tinyager ()
Ответ на: комментарий от tinyager

Зависит от того как пользователь будет подписывать json. Если он будет использовать для этого GnuPG то тогда для проверки в своём приложении надо использовать gpgme.

Если же клиентская подпись реализована каким-то велосипедом то тогда придётся и со стороны сервера велосипедить проверку, что удобнее будет с OpenSSL, т.к. врятли велосипед будет соответствовать стандарту OpenPGP, иначе взяли бы gpgme и велосипеда не было бы.

Лучше конечно велосипеды избегать если они не требуются.

feanor ★★★ ()
Ответ на: комментарий от feanor

Зависит от того как пользователь будет подписывать json

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

Какие здесь будут критерии выбора?

tinyager ()
Ответ на: комментарий от tinyager

Тогда реализовать средствами библиотеки шифрования того языка, на котором будут реализованы сервер и клиент. В почти всех скриптовых и компилируемых языках есть библиотеки криптопримитивов, например в Go это пакет crypto, в других языках должно быть аналогичное. Если язык С то OpenSSL или её форки/аналоги.

feanor ★★★ ()
Ответ на: комментарий от feanor

С обеих сторон NodeJS. У нее тоже есть CryptoAPI, которое умеет RSA, но, в то же время, есть OpenPGP.js, которое тоже умеет RSA не хуже.

tinyager ()
Ответ на: комментарий от tinyager

Посмотри libsodium:

https://download.libsodium.org/doc/public-key_cryptography/public-key_signatu...

https://github.com/wilhelmmatilainen/natrium/blob/master/README.md#sign--verify (один из биндингов)

Это если тебе не подходит TLS с клиентскими сертификатами.

deadNightTiger ★★★★ ()
Последнее исправление: deadNightTiger (всего исправлений: 1)

Низкий уровень (ГСЧ, хэши, шифрование, подпись) дают обе библиотеки, причём с десятками алгоритмов, от RSA и AES до BlowFish и GOST.

Но помимо низкоуровневой криптографии эти библиотеки предлагают и высокоуровневую: протоколы TLS и SSL (OpenSSL), PGP и сеть доверия (GnuPG). Работу с сертификатами предлагают обе библиотеки.

Так как мне нужны были только низкоуровневые функции, а OpenSSL более распространена и почти всегда входит в базовый набор библиотек любого интерпретатора (Php, Python, Ruby), то я её и выбрал в своём проекте (Пандора).

А вот RetroShare например юзает GnuPG и её сеть доверия.

Кроме этих двух монстров, существуют более легковесные (содержат только низкоуровневые функции) либы, среди них NaCl/libsodium или libsecp256k1 - но у них и набор алгоритмов меньше.

Novator ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.