(2020-07-10 21:42:34 отредактировано sanyo)

Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

Добрый день,

Пожалуйста, подскажите, сравнивал ли кто-то безопасность ГОСТовых асимметричных алгоритмов с

Curve25519/ED25519, E-382, M-383, Curve383187, Curve41417, Ed448-Goldilocks, M-511, E-521

Я так понимаю, при аутентификации новой сессии SSH важна безопасность именно аппаратной асимметричной криптографии.

А потом уже после генерации сессионного ключа используется только софтовая симметричная криптография на CPU хоста.

Выдержка из обсуждения NitroKey Pro:
https://web.archive.org/web/20200710183 … 21-aes-256

On the home page you proudly write "No NSA - no backdoors". And at the same time you use the ECC curves, which are all considered unsafe. The weaknesses of these curves are listed, for example, on the "Safe Curves" website. All curves that Nitrokey offers are known to be suspected of being influenced by NSA. Nitrokey does not offer a curve that is considered safe: Curve25519, E-382, M-383, Curve383187, Curve41417, Ed448-Goldilocks, M-511, E-521. Therefore, when you see the list of supported curves, you think that "Made in Germany" is not complete and that the following would be more correct: "Made in Germany, approved by NSA". For years, manufacturers have been able to order chips that implement specific functionality. Among other thingsyou could order making chips with a few sure curves. The chips may be a little more expensive because they are not mass-produced. But at least the customers would have a choice: a cheaper Nitrokey only with NIST curves or a slightly more expensive Nitrokey with safe curves. Why don't you order making chips with safe curves?
Reply

Submitted by Jan Suhr on February 11, 2020 - 5:31 pm
The criteria by which Safe Curves is rated are practical criteria and do not claim that NIST curves have NSA back doors. After all, the website is called "Safe Curves" and not "Secure Curves". In addition, I do not know any reputable cryptologist who strongly advises against NIST curves because of concerns about NSA back door. Ultimately, however, everyone can decide for themselves which curves they want to use. Our Nitrokey Start supports Curve25519, among others. The reason why Curve25519 is not supported by all of our models is that the NXP chip cards used do not support this curve. There are currently no other realistic chip cards that support Curve25519. As soon as that changes, our other models will also support the Curve25519.

Насколько я понял из этого обсуждения, относительно безопасным можно считать алгоритм Curve25519?
Но он мало где реализован в аппаратном крипто, например в YubiKey 5 по спецификации OpenPGP Smart Card 3.4: https://support.yubico.com/support/solu … -4-support

Но насколько я знаю, американская криптография, экспортируемая за пределы США, всегда содержит закладки АНБ, почему тот же YubiKey не рекомендовали использовать по сравнению с NitroKey, но разницы похоже нет :)

Будет ли канал связи OpenSSH между двумя хостами лучше защищен, если на каждом хосте будет Rutoken ECP2 по сравнению с NitroKey PRO? Подразумевается, что приватные ключи клиента и сервера для аутентификации сессии, каждый неизвлекаемый и хранится в своем аппаратном крипто. Насколько я понял, если серверный ключ не хранить в аппаратном крипто, то относительно легко устроить MITM в случае утечки ключа.

OpenSSH позволяет сделать многофакторную гибридную аутентификацию одновременно несколькими ключами,  что еще из аппаратного крипто  можно добавить в схему аутентификации кроме Рутокен ЭЦП2?

Продается ли в РФ аппаратное крипто, стойкое к квантовому взлому? Например, в США такое уже доступно.

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

sanyo пишет:

Пожалуйста, подскажите, сравнивал ли кто-то безопасность ГОСТовых асимметричных алгоритмов с

Curve25519/ED25519, E-382, M-383, Curve383187, Curve41417, Ed448-Goldilocks, M-511, E-521

Мне не известно, проводятся ли вообще сравнительные исследования алгоритмов. Обычно исследуется конкретный алгоритм, а уже результаты исследований сравниваются, если их возможно сравнить.

sanyo пишет:

Но насколько я знаю, американская криптография, экспортируемая за пределы США, всегда содержит закладки АНБ,

И готовы на это поставить деньги? И доказательства у есть? Или highly likely? :)

sanyo пишет:

Будет ли канал связи OpenSSH между двумя хостами лучше защищен, если на каждом хосте будет Rutoken ECP2 по сравнению с NitroKey PRO?

Наверное в зависимости от того, какая криптография используется. Корректно ли сравнивать RSA и EC? Или сравниваем EC и ГОСТ?

sanyo пишет:

OpenSSH позволяет сделать многофакторную гибридную аутентификацию одновременно несколькими ключами,  что еще из аппаратного крипто  можно добавить в схему аутентификации кроме Рутокен ЭЦП2?

Подозреваю, что OpenSSH такого не умеет.

sanyo пишет:

Продается ли в РФ аппаратное крипто, стойкое к квантовому взлому? Например, в США такое уже доступно.

Вы имеете в виду "постквантовые" криптоалгоритмы? В России практически наверняка нет. Но нет и принятых стандартов.

(2020-07-10 12:13:24 отредактировано sanyo)

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

Vladimir Ivanov пишет:
sanyo пишет:

Но насколько я знаю, американская криптография, экспортируемая за пределы США, всегда содержит закладки АНБ,

И готовы на это поставить деньги? И доказательства у есть? Или highly likely? :)

Я про ту криптографию, что стандартизована FIPS.

В сети много упоминаний типа таких:
https://support.nitrokey.com/t/spectre- … bility/850

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

Vladimir Ivanov пишет:
sanyo пишет:

Будет ли канал связи OpenSSH между двумя хостами лучше защищен, если на каждом хосте будет Rutoken ECP2 по сравнению с NitroKey PRO?

Наверное в зависимости от того, какая криптография используется. Корректно ли сравнивать RSA и EC? Или сравниваем EC и ГОСТ?

EC и ГОСТ, - чем они вообще отличаются принципиально "для чайника"?

Vladimir Ivanov пишет:
sanyo пишет:

OpenSSH позволяет сделать многофакторную гибридную аутентификацию одновременно несколькими ключами,  что еще из аппаратного крипто  можно добавить в схему аутентификации кроме Рутокен ЭЦП2?

Подозреваю, что OpenSSH такого не умеет.

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

Ответ на вопрос относительно использования одновременно четырех ключей (двух софтовых обычного и постквантового, двух аппаратных Nitrokey и Rutoken) для формирования одного сессионного ключа SSH:

От кого: Damien Miller @mindrot.org

this is pretty much possible now, by enabling the experimental support
for the XMSS PQ signature algorithm, specifying

AuthenicationMethods=publickey,publickey,publickey,publickey

and by setting the required public keys in authorized_keys.

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

sanyo пишет:

EC и ГОСТ, - чем они вообще отличаются принципиально "для чайника"?

ГОСТ основан на математическом аппарате эллиптических кривых. Статьи на эту тему можно
поискать в сети. Например вот: https://www.cryptopro.ru/blog/2014/01/2 … oi-podpisi



sanyo пишет:

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

Тут комментировать не возьмусь. Как устаканится процесс с постквантовыми алгоритмами, тогда и будет предмет для разговора.

(2020-07-11 00:59:01 отредактировано sanyo)

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

Vladimir Ivanov пишет:

ГОСТ основан на математическом аппарате эллиптических кривых. Статьи на эту тему можно
поискать в сети. Например вот: https://www.cryptopro.ru/blog/2014/01/2 … oi-podpisi

Насколько, я понимаю, в обоих случаях и для Rutoken ECP2 и для Nitrokey Pro2 используются эллиптические кривые:

https://shop.nitrokey.com/shop/product/ … ey-pro-2-3

Elliptic curves: NIST P-256, P-384, P-521 (secp256r1/prime256v1, secp384r1/prime384v1, secp521r1/prime521v1), brainpoolP256r1, brainpoolP384r1, brainpoolP512r1

Мой вопрос был в том, чем отличаются их кривые от ГОСТовых в плане безопасности?

Для какого асимметричного алгоритма сложнее в real time без использования квантовых компьютеров:

  • Подделать подпись ?

  • Устроить незаметный MITM для сессии OpenSSH?

(2020-07-11 02:45:13 отредактировано sanyo)

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

А эллиптическая криптография Rutoken ECP2 вообще работает с OpenSSH?

https://www.linux.org.ru/forum/security/12951987

В вашей документации приводится только пример для RSA.

Есть ли реализации SSH или хотя бы каких-нибудь других туннелей с использованием КриптоПро CSP -> PKCS 11? И желательно с поддержкой ФКН2.

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

Ваш VPN:

https://www.rutoken.ru/products/all/rut … advantages

тоже чтоли только по RSA работает?

(2020-07-11 03:20:49 отредактировано sanyo)

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

https://www.cryptopro.ru/products/other/stunnel

или

https://www.cryptopro.ru/products/other/stunnel-msspi

работает через цепочку КриптоПРО 5 -> PKCS 11 ?

Шифрование какое-то слабенькое у него, поди еще через PKCS 11, а не сессионным ключом на CPU как в SSH?
а MITM возможен?

(2020-07-11 04:15:02 отредактировано sanyo)

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

А вот:

http://web.archive.org/web/202007110018 … og/477650/

что-то похожее:

В этой статье я хочу показать, как настроить Stunnel на использование российских криптографических алгоритмов в протоколе TLS. В качестве бонуса покажу, как шифровать TLS-канал, используя алгоритмы ГОСТ, реализованные в криптоядре Рутокен ЭЦП 2.0.

Но «Скорость шифрования ГОСТ 28147-89: до 109 КБ/сек.» древним алгоритмом, зачем это нужно?

Почему не сделать аппаратное эллиптическое крипто асимметричных ключей Rutoken ECP2 доступным в OpenSSH?
OpenSSH может использовать намного более надежные алгоритмы для симметричных сессионных ключей на быстром CPU, а эллиптическое крипто Rutoken ECP 2 нужно в OpenSSH только для аутентификации.

Можно ли в stunnel использовать симметричный алгоритм на CPU, а асимметричную криптографию Rutoken ECP2 только для аутентификации?

(2020-07-11 22:46:16 отредактировано sanyo)

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

Хм, похоже для других аппаратных алгоритмов та же проблема:

https://news.ycombinator.com/item?id=22193349

Отсутствие поддержки эллиптических кривых на уровне OpenSC?

А хотя вот тут что-то пофиксили для зарубежных эллиптических кривых:

https://github.com/OpenSC/OpenSC/issues/1906

, но релиза еще не было.


И вот список туннельного софта, совместимого с PKCS11:
https://github.com/OpenSC/OpenSC/wiki/U … plications
в начале списка.

Хоть какой-нибудь софт из этого списка: OpenSSH, OpenVPN, IPSec
работает с кривыми ГОСТ2012 Rutoken ECP2 для ТОЛЬКО аутентификации и обычным софтовым крипто для сессии?

Если нет, то когда планируется исправить?

(2020-07-12 12:51:35 отредактировано sanyo)

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

Vladimir Ivanov пишет:
sanyo пишет:

Но насколько я знаю, американская криптография, экспортируемая за пределы США, всегда содержит закладки АНБ,

И готовы на это поставить деньги? И доказательства у есть? Или highly likely? :)

http://web.archive.org/web/202007120945 … rypto.html


SSH can generate DSA, RSA, ECDSA and Ed25519 key pairs. Lets go over these public-key algorithms:

DSA: This algorithm is deprecated due to very poor randomness. OpenSSH version 7.0 and newer even refuse DSA keys smaller than 1024-bits. DSA key pairs should not be used anymore.

RSA: This non-elliptic crypto algorithm which is based on prime numbers generates a relatively insecure key pair when you pick a key size below 2048-bits. The problem with RSA is its source of randomness. RSA is not vulnerable, but the source of entropy is the weakest link in the RSA algorithm. Many manufacturers are likely using the same source of randomness and perhaps even the same seeding. Furthermore, RSA will likely be the first to fall when quantum computations will get more mature.

ECDSA: The elliptic-curve (EC)DSA algorithm is supposed to help us combat these quantum computational attacks, while generating keys with significant smaller key size without compromising the level of security. The size of the elliptic curve determines the difficulty to break the algorithm. However, secure implementations of the ECDSA curves are theoretically possible but very hard in practice. Furthermore, a weakness in RNG was publicly identified but still incorporated by NIST. We later learned from Snowden that the NSA had worked on the standardization process in order to become the sole editor of this Dual_EC_DRBG standard, and concluded that the Dual_EC_DRBG NIST standard did indeed contain a backdoor for the NSA. Why trust NIST curves when there is a more transparent way of doing crypto?


Ed25519: Long story short: it is not NIST and it is not NSA. The long story is that while NIST curves are advertised as being chosen verifiably at random, there is no explanation for the seeds used to generate these NIST curves. The process used to pick Ed25519 curves is fully documented and can be verified independantly. This prevents a malicious party from manipulating the parameters. Furthermore, the Ed25519 algorithm is supposed to be resistant against side-channel attacks.

(2020-07-12 16:56:04 отредактировано sanyo)

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

VKO GOST R 34.10-2012  применяется в каких-то туннелях?

Это ГОСТ-овый аналог выработки симметричного сессионного ключа в OpenSSH?

Можно примеры такого софта, использующего аппартное крипто Rutoken ЭЦП2 для выработки своего сессионного ключа? Есть ли плагины для встройки этого в общеизвестные популярные туннели типа OpenVPN, IPSEC и т.п.?

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

Здравствуйте.
Насколько понимаю актуальные вопросы собраны в последнем сообщении, на них предлагаю и сосредоточиться:

sanyo пишет:

VKO GOST R 34.10-2012  применяется в каких-то туннелях?

Например, в "Stunnel", как описано тут.

sanyo пишет:

Это ГОСТ-овый аналог выработки симметричного сессионного ключа в OpenSSH?

Верно.

sanyo пишет:

Можно примеры такого софта, использующего аппартное крипто Rutoken ЭЦП2 для выработки своего сессионного ключа? Есть ли плагины для встройки этого в общеизвестные популярные туннели типа OpenVPN, IPSEC и т.п.?

Наш программный "Рутокен VPN" (Enterprise версия, см. ссылку).

(2020-07-15 01:34:37 отредактировано sanyo)

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

Хотелось бы еще оценить стойкость VKO GOST R 34.10-2012 к квантовому взлому:

https://security.stackexchange.com/ques … ntum-world

https://www.f5.com/labs/articles/threat … ting-world

https://sectigo.com/uploads/resources/Q … epaper.pdf

Пишут, что DH ( https://en.wikipedia.org/wiki/Diffie%E2 … y_exchange ) может оказаться самым слабым звеном против квантовых компьютеров.

А когда в РФ планируют принять ГОСТы по квантоворезистентным алгоритмам?

В США, вроде бы с 2022 года их уже внедряют в пром эксплуатацию!

Почему в актуальных версиях Rutoken ECP2 нет поддержки хотя бы RSA 4096 как в Nitrokey PRO2/HSM2 ($50-$70 USD/EURO) ?
Rutoken ECP2 был бы намного привлекательнее Nitrokey при поддержке более длинных RSA ключей, потому что только одна доставка (без учета стоимости самого товара) Nitrokey из Германии без посредников на сегодняшний день стоит как 3шт. Rutoken ECP2.

(2020-07-15 02:06:00 отредактировано sanyo)

Re: Сравнение безопасности алгоритмов ГОСТ для OpenSSH с другими алго

Антон Тихиенко пишет:
sanyo пишет:

Можно примеры такого софта, использующего аппартное крипто Rutoken ЭЦП2 для выработки своего сессионного ключа? Есть ли плагины для встройки этого в общеизвестные популярные туннели типа OpenVPN, IPSEC и т.п.?

Наш программный "Рутокен VPN" (Enterprise версия, см. ссылку).

А как производится аутентификация ОБОИХ сторон в таких туннелях?

Например, в OpenSSH аутентификацию проходят оба хоста (и клиент и сервер), причем сервер может быть настроен на запрос многих разных ключей клиента одновременно (например одновременно RSA 2048 в Rutoken ECP2, несколько алгоритмов  RSA 40xx и ECDSA в Nitrokey PRO2/HSM2, ed25519 в файле, постквантумный в файле и т.д.), если хотя бы один ключ не подойдет, то sshD не пустит к себе. Закрытые ключи и клиента и сервера OpenSSH можно хранить в аппаратных токенах, чтобы предотвратить MITM в случае утечки закрытых аутентификационных ключей от какой-либо из сторон SSH сессии.

Почему-то OpenSSH мне внушает больше доверия с таким разнообразием намного более длинных ключей.
И потом можно ведь использовать в качестве туннельных хостов одноплатники MIPS или Cortex A7 с OpenBSD на борту, что еще больше повысит безопасность в т.ч. как софта, так и аппаратной части в плане Spectre, отсутствия буткитов в т.ч. в TrustZone (кроме малой вероятности их наличия в малюсеньком BROM размером 32КБ - половина оперативки ZX Spectrum 64K 30 летней давности).

Почему бы кому-нибудь не начать продавать такие коробочки? Ведь можно самостоятельно заниматься только лицензиями на свои конфигурационные скрипты без криптоначинки, а криптоначинка бесплатно от OpenBSD либо отдельными сделками с продавцами смарт карт типа Nitrokey и Rutoken :) И никаких лицензий ФСБ и ФАПСИ ненужно, наверно тогда, если непосредтсвенно криптоалгоритмы не входят в сделку?

Скрипты могут сами скачать OpenBSD, настроить ее, прошить и т.п., чтобы криптуха не попала в сделку с юридической точки зрения, это был бы некий DIY набор, с очень простым single click стартом, подождал немного и коробочка прошита и настроена, все законы соблюдены ? :) При этом очень мощная начинка, предположительно недоступная на рынке РФ в виде готового решения для гражданских (чтобы и ключи длинные, и много ключей и аутентификация со всех сторон и масса полезных настроек OpenSSH). Конечно такое решение не для тех, кому надо попсово смотреть 4K фильмы по своей КСПД, а для тех, кому остро необходима безопасность для относительно малого трафика различных консолей типа текстовых и RDP, где важна именно безопасность, а скорость приемлема вообще на уровне модемов прошлого века.

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