Обсуждение:Сравнение криптографических библиотек

Надувной замок проверен и сертифицирован

Я пытался обновить эту страницу, чтобы уточнить, что Bouncy Castle 1.0.0 (последняя версия — 1.0.1) был проверен на соответствие FIPS 140-2 и был сертифицирован. Я не настолько хорош в разметке, используемой в Википедии, чтобы исправить это. Может кто-нибудь помочь? Источник: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm#2768 — Предыдущий неподписанный комментарий добавлен Omarkj ( обсуждение • вклад ) 22:38, 17 июня 2017 (UTC) [ ответить ]

Раздел для легких блочных шифров

Легкие блочные шифры с дизайном ARX становятся все более популярными. Эти шифры представляют большой интерес для устройств с ограниченными ресурсами и Интернета вещей. К шифрам относятся CHAM, LEA, Simon и Speck. Возможно, было бы хорошей идеей добавить новый раздел для современных дизайнов легких блочных шифров.

Добавление Tink и TinyCrypt?

У меня нет времени добавлять его сейчас, но я думаю, что Tink и TinyCrypt должны быть включены на эту страницу: https://github.com/google/tink https://github.com/intel/tinycrypt — Предыдущий неподписанный комментарий добавлен 205.209.193.6 ( обсуждение ) 17:46, 15 февраля 2019 (UTC) [ ответить ]

OpenSSL не поддерживает Blake2-MAC

Это задокументировано в ветке Master, но не в 1.1.1, и проверка журнала изменений (и исходного кода 1.1.1) подтверждает это.

Таким образом, он *будет* поддерживаться, но пока не поддерживается. 16:56, 6 февраля 2020 (UTC) — Предыдущий неподписанный комментарий добавлен 62.2.246.66 ( обсуждение )

Криптобиблиотека и сертификация FIPS 140-2

Информация, предоставленная для Crypto Library, неточна и вводит в заблуждение. Например, Open SSL не сертифицирован как автономный. Он сертифицирован как интегрированный с RedHat, Ubuntu IBM и т. д. и т. п. Невозможно протестировать библиотеку, вы можете запустить ее на некоторых ОС.

Каждая криптосистема, сертифицированная по стандарту NIST CMVP и прошедшая его, получает номер сертификата проверки, который публикуется в https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search., которая является общедоступной и доступной для поиска базой данных.

Если нет номера сертификата, он не проверен. Результат поиска Open SSL не показал сертификат. Поэтому сама библиотека Open SSL не сертифицирована. Вместо этого, например, Opel SSL интегрирован с сертифицированными интеграциями.

3667 TrendMicro Inc. Deep Discovery Analyzer Программное обеспечение OpenSSL Cryptographic Module 06/04/2020 3657 Metaswitch Networks Ltd OpenSSL Cryptographic Module для Perimeta SBC Software 05/26/2020 3638 Super Micro Computer, Inc. Supermicro FIPS Object Module для OpenSSL Software 03/31/2020 3622 Canonical Ltd. Ubuntu 18.04 OpenSSL Cryptographic Module Software 02/25/2020

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

В криптографии дьявол кроется в деталях. В криптографической безопасности вы либо защищены, либо не защищены (1 или 0). Не существует такого понятия, как 1/0! — Предыдущий неподписанный комментарий добавлен 2600:1700:1C00:2E80:B07C:2EB4:9FB3:3690 (обсуждение) 21:17, 18 июня 2020 (UTC) [ ответить ]

Добавление форков OpenSSL? (BoringSSL и LibreSSL?)

Я думаю, что нам следует добавить BoringSSL и LibreSSL, хотя они являются ответвлениями OpenSSL и не имеют собственных статей (даже Википедия перенаправляет boredssl на openssl). Они используются для реальных приложений и стали допустимыми и популярными альтернативами OpenSSL. Отсутствие их в таблице создает ложное впечатление, что они несопоставимы с другими библиотеками. Chibby0ne ( обсуждение ) 22:45, 7 августа 2020 (UTC) [ ответить ]

У LibreSSL есть статья, а у Boring — нет. Нам следует включить Libre и убрать Boring. - MrOllie ( обсуждение ) 23:20, 7 августа 2020 (UTC) [ ответить ]

Поставщик с несколькими реализациями

Я хотел бы мирно протестовать против отмены One per customer, please done by MrOllie . На этой странице столбец Implementation используется для идентификации реализации , а не клиента или поставщика. Фактически, клиент или поставщик уже идентифицирован столбцом Initiative . Когда кто-то пишет реализацию алгоритма, эта реализация может быть на C, Java, Ruby и т. д. Каждая из реализаций отличается. Поэтому, по моему мнению, каждая реализация должна иметь свою собственную строку.

Обратите внимание также, что, удалив строки Crypto-C ME, пользователи упустят тот факт, что Crypto-J (реализация Java) и Crypto-C ME (реализация C) предоставляют разные возможности . Пожалуйста, вернитесь к старой версии в разделах Стандарты криптографии с открытым ключом и Хэш-функция , и вы увидите, что разные реализации предоставляют разные возможности .

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

Bouncy Castle должен делать то же самое, поскольку у них есть реализация на C# и Java. - Безопасность в мыслях ( обсуждение ) 13:37, 16 июля 2021 (UTC) [ ответить ]

Основная ценность этой статьи — помощь в навигации по другим статьям Википедии, в частности, мы ссылаемся только на библиотеки, которые являются независимо известными. Поскольку известность — это WP:NOTINHERITED , если есть вариантные библиотеки под тем же названием продукта, здесь должна быть указана только основная, известная. Если бы обе были независимо известными (что не так в данном случае), то у нас было бы две разные статьи для ссылок. - MrOllie ( talk ) 15:42, 21 июля 2021 (UTC) [ ответить ]
Основная ценность этой статьи — помощь в навигации . Я не согласен. Как следует из названия статьи, основная ценность этой статьи — сравнение реализаций различных библиотек . Тот факт, что есть реализация/библиотека Java и C , и что они предоставляют разные возможности, должен убедить вас, что они независимо примечательны. Совместное использование одного и того же префиксного имени не является веской причиной думать, что они одинаковы. Пользователи, заходящие на эту страницу, используют ее для сравнения функций и возможностей. Как бы вы решили эту проблему, чтобы сохранить уровень детализации и качества, предоставляемый страницей? — Безопасность в мыслях ( обсуждение ) 16:43, 21 июля 2021 г. (UTC) [ ответить ]

Вот от 3O. Эта статья далеко за пределами моей области знаний, но поскольку она висит на 30, я вмешаюсь. Насколько я понимаю, есть разногласия относительно объема или ценности статьи. Прежде чем высказать свое мнение, могу ли я спросить: является ли тема значимой? Cinadon 36 12:30, 23 июля 2021 (UTC) [ ответить ]

Cinadon36 , BSAFE исторически примечателен — это была главная криптобиблиотека до 2000 года или около того. У нее была почти монополия из-за истекшего патента. Эти варианты, которые появились после истечения срока действия патента, на самом деле не примечательны. Поскольку Security in mind забыл упомянуть об этом при открытии этого раздела, я также отмечу, что у них есть COI в отношении BSAFE. MrOllie ( talk ) 12:42, 23 июля 2021 (UTC) [ ответить ]
Пожалуйста, перефразируйте, забыл упомянуть , что не знал о правилах COI в Википедии , поэтому у меня не возникло проблем с добавлением этого тега COI на страницу обсуждения пользователя . Мне нечего скрывать. Не все такие эксперты в редактировании (или удалении) Википедии, как MrOllie . Безопасность в мыслях ( обсуждение ) 12:51, 23 июля 2021 г. (UTC) [ ответить ]
исправление: добавление этого тега COI на мою страницу обсуждения пользователя сразу же после того, как MrOllie сообщил мне об этом . - Безопасность в мыслях ( обсуждение ) 12:55, 23 июля 2021 (UTC) [ ответить ]
Ну, я предполагал, что вы уже прочитали руководство по COI и просто забыли это положение. - MrOllie ( обсуждение ) 13:01, 23 июля 2021 (UTC) [ ответить ]
Я сделал. С этого момента я буду судьей, чтобы решить, использовать ли мне , или я сам внесу изменения, если я знаю, что изменения не вызовут никаких возражений. Редакции от пользователей в COI настоятельно не приветствуются , но не запрещены . - Безопасность в мыслях ( обсуждение ) 13:19, 23 июля 2021 (UTC) [ ответить ]{{request edit}}
Cinadon36 , как MrOllie упомянул выше, в этой теме есть примечательность. Обсуждение идет о том, должны ли две разные реализации, предоставляющие разные возможности, иметь свои собственные строки / детали. C и Java — два совершенно разных языка программирования. Их нельзя считать похожими, поэтому они должны иметь свои собственные детали, уникально задокументированные, иначе эта статья теряет свою ценность для документирования различий между разными реализациями. - Безопасность в мыслях ( обсуждение ) 13:19, 23 июля 2021 (UTC) [ ответить ]

Я просто спрашиваю, является ли это заметным, чтобы посмотреть, как RS относится к этой проблеме. Я не собираюсь отправлять статью в AfD или добавлять баннер заметности или что-то в этом роде. Кроме того, статья кажется технической, не отвечающей потребностям широкой общественности. В любом случае, я спрашивал о заметности, потому что Me Ollie сказал выше: «Основная ценность этой статьи — как навигационное средство для других статей Википедии...» Я не знал, что WP размещает статьи, которые являются инструментами или вспомогательными средствами для других статей WP. Теперь, что касается вашего аргумента о безопасности, то то, что C и Java — это совершенно разные языки программирования, может быть правдой, но широкая публика об этом не знает, и пока статья не объясняет, почему это так, аргумент слабеет. Cinadon 36 15:29, 23 июля 2021 (UTC) [ ответить ]

Согласен, что это техническая статья. Однако она не предназначена для объяснения разницы между C и Java, поскольку Programming_language#Implementation уже позаботится об этом. Пользователи, переходящие на эту страницу, будут иметь или должны иметь технические знания, чтобы понимать разницу между Java и C. В этой статье сравниваются реализации и функции различных криптографических библиотек. Безопасность в мыслях ( обсуждение ) 15:36, 23 июля 2021 г. (UTC) [ ответить ]

В свете недавних обсуждений ниже, возможно ли получить мнение Tim-Weller-wolfSSL по этому запросу здесь? Хотя я понимаю, что WolfSSL и BSAFE Crypto-C ME / Micro Edition Suite являются конкурирующими продуктами, я был бы очень признателен, если бы вы могли предоставить свое экспертное мнение по предметной области о возможности документирования как реализации BSAFE Java (Crypto-J), так и реализации C (Crypto-C ME / MES) в разных строках. К сожалению, откаты, которые были сделаны некоторое время назад, удалили подробности о реализации C. Теперь эта страница, похоже, подразумевает, что реализации C и Java предоставляют те же функции, что неверно. Однако я пойму, если вы откажетесь помогать продукту-конкуренту WolfSSL. - Безопасность в мыслях ( обсуждение ) 15:10, 19 апреля 2023 (UTC) [ ответить ]

JCA / JCE не является реализацией

@Valerie.peng, я думаю, что использование « JCA / JCE » для имени реализации несколько вводит в заблуждение или сбивает с толку, поскольку оба являются скорее фреймворком, чем реализацией. Я бы предпочел использовать «Oracle SunJSSE», что является реализацией JCA/JCE от Oracle. Есть OpenJDK, который мог бы указать «OpenJDK SunJSSE» в качестве имени реализации, если Oracle добавит свои собственные настройки в свою реализацию по сравнению с общедоступным исходным кодом OpenJDK. Кроме того, в разделе с аппаратной поддержкой, что на самом деле обеспечивает аппаратную поддержку? Это JCA/JCE (поставщик SunJSSE от Oracle) или сама JRE обеспечивает аппаратную поддержку? Открыто для обсуждения. - Безопасность в мыслях ( обсуждение ) 19:17, 26 января 2022 (UTC) [ ответить ]


@ Безопасность в мыслях "Oracle SunJSSE" - это не реализация JCA/JCE от Oracle, а реализация JSSE от Oracle (изначально это было расширение Java Secure Socket Extension, которое стало частью JDK). Реализация JCA/JCE от Oracle поддерживается несколькими поставщиками, например, SUN, SunRsaSign, SunJCE, SunPKCS11 и многими другими. Большинство из этих поставщиков также доступны в OpenJDK. Что касается раздела с аппаратной поддержкой, если вы имели в виду PKCS11, то он предоставляется через библиотеку PKCS11/поставщика SunPKCS11, который может работать со сторонней библиотекой PKCS11 для фактической функциональности. Если вы говорили об аспекте ускорения, то он осуществляется через встроенные функции JRE/hotspot. Я открыт для других предложений, лучших, чем "JCA/JCE", но "SunJSSE" просто не является правильным выбором. Valerie.peng — Предыдущий недатированный комментарий добавлен 00:10, 29 января 2022 (UTC)[ отвечать ]
@Valerie.peng, я всегда думал, что в самом поставщике SunJSSE реализовано немного криптоалгоритмов, но я определенно доверяю вам в этом, поскольку я знаю о вашем участии в этой конкретной теме. И пока я писал свой ответ, я заметил (новое??) примечание в документации JDK 11, в котором говорится: « Поставщик SunJSSE предназначен для обратной совместимости со старыми версиями и больше не должен использоваться для KeyPairGenerator ». Думаю, мне нужно поторопиться! В любом случае, мне бы очень хотелось увидеть, как эта страница различает возможности всех этих библиотек / поставщиков (Sun, SunRsaSign, SunJCE, SunEC и т. д.), поскольку поставщик SUN не предоставляет ECDSA, а SunEC предоставляет. Итак, хотя было бы совершенно разумно иметь одну строку на библиотеку (на поставщика), и я бы поддержал эту правку, некоторые википедисты с нулевыми знаниями в разработке ПО и криптографии отменят это лучшее изменение, чтобы вернуть его к «одной строке на поставщика», хотя эта статья должна быть о «одной строке на реализацию».. Итак, вернемся к «имени реализации». Между собой, когда мы меняем приложение Java с использования «поставщика Java JCE по умолчанию» на использование, я не знаю, скажем, кхм, BSAFE Crypto-J , мы говорим, что используем реализацию Crypto-J. И когда командам разработчиков нужно вернуться к реализации по умолчанию, мы часто называем ее «поставщиком Java JCE по умолчанию». Будет ли « поставщики Java JCE » названием реализации, которое вам понравится? Или это должно быть «поставщики Hotspot JCE»? Я также открыт для любых предложений. Что касается аппаратной поддержки, я изначально думал об аппаратном ускорении, и я полагаю, вы подтверждаете, что это обеспечивается Hotspot JRE, верно? Так должно ли имя реализации для всех строк быть просто Hotspot? - Безопасность в мыслях ( обсуждение ) 20:48, 30 января 2022 (UTC) [ ответить ]
@ Безопасность в мыслях , ну, я не уверен, что перечисление отдельных поставщиков будет уровнем детализации, подходящим для этой страницы. Я уточню этот JCA/JCE с помощью дополнительных терминов, таких как «Поставщики JDK JCA/JCE по умолчанию», чтобы сделать это более понятным. Для точки доступа у него есть встроенный код и логика, чтобы они срабатывали при выполнении определенных условий, но это НЕ упаковано как поставщик, поэтому «Поставщики JCE точки доступа» могут не совсем соответствовать требованиям. Есть еще предложения или комментарии для «Поставщиков JDK JCA/JCE по умолчанию»? - Valerie.peng — Предыдущий недатированный комментарий добавлен 21:25, 7 февраля 2022 (UTC)[ отвечать ]
"Поставщики JDK JCA/JCE по умолчанию", хотя и длинные, для меня звучат хорошо. Я думаю, так будет точнее. А что касается ускорения HW, что если оставить название "Поставщики JDK JCA/JCE по умолчанию", добавить сноску в таблицу "При использовании Hotspot JVM" или что-то в этом роде? - Безопасность в мыслях ( обсуждение ) 21:41, 7 февраля 2022 (UTC) [ ответить ]
@ Безопасность в мыслях Конечно, звучит разумно, я обновлю, как вы предложили. Спасибо - Valerie.peng

Добавляете таблицу функций расширяемого вывода (XOF)?

Привет, было бы разумно добавить новый раздел для функций расширяемого вывода (XOF), чтобы увидеть, какая библиотека поддерживает SHAKE (SHAKE128 и SHAKE256), часть FIPS 202 , и cSHAKE / KMAC, определенный в SP 800-185. В настоящее время эта страница сравнивает только функции хэширования

Есть желающие создать такую ​​таблицу?

Достаточно интересно, что Extendable-output functions неправильно перечисляет SHA-3 как XOF. SHA-3 — это семейство криптографических функций. Некоторые из них являются криптографическими хэш-функциями , а некоторые — Extendable-output functions

- Безопасность в мыслях ( обсуждение ) 20:40, 4 августа 2022 (UTC) [ ответить ]

Здравствуйте, я сотрудник wolfSSL ( платный участник ), которого wolfSSL, Inc попросила просмотреть и предложить обновления для этой страницы. Ниже приведены предложения по изменению строки wolfCrypt в таблице в разделе FIPS-140 :

  • ПРЕДЛОЖЕНИЕ-1 - Ссылка на столбец FIPS 140-2 Validated ( [34] ) помечена как «мертвая ссылка» (?). wolfCrypt FIPS 140-2 в настоящее время защищен сертификатом № 3389, на который есть прямая ссылка: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3389 ... Я предлагаю изменить источник, чтобы использовать прямую ссылку на № 3389, если это будет сочтено лучшим (т.е. не помечено как мертвое)
  • ПРЕДЛОЖЕНИЕ-2 - Ссылка на столбец FIPS 140-3 Validated ( [28] ) - это ссылка на список тестируемых реализаций (IUT) . Реализации, прошедшие тестирование, включая wolfCrypt, перешли на следующий этап процесса проверки, который рассматривается CMVP [1] и перечислены в списке модулей в процессе , https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Modules-In-Process/Modules-In-Process-List ... Я бы предложил добавить новую ссылку на список модулей в процессе и указать новую ссылку в записи столбца FIPS 140-3 Validated строки wolfCrypt .
    • Примечание: ситуация с wolfCrypt может быть схожей и с другими реализациями, т. е. они также могут быть в списке «Модули в процессе» !

Пожалуйста, оставьте отзыв об этих предлагаемых изменениях, спасибо! Tim-Weller-wolfSSL ( обсуждение ) 20:52, 5 декабря 2022 (UTC) [ ответить ]

Что касается Suggestion-1 , я боюсь, что это станет дубликатом Comparison of TLS implementations#Certifications . Кстати, библиотеки TLS редко проходят проверку FIPS. Криптомодуль, используемый библиотекой, проходит. Если бы мы хотели получить четкое решение по вашему предложению, я бы отредактировал таблицу Certifications в Comparison of TLS implementations так, чтобы она указывала на эту страницу, так что страница библиотеки TLS ссылалась бы на криптографическую библиотеку, используемую библиотекой TLS. Как только информация будет возвращена сюда, можно будет принять решение о наличии ссылок на сертификаты FIPS или поисковый инструмент CMVP с использованием имени поставщика. К сожалению, все мои основные правки по этой теме всегда откатываются, поэтому я больше не участвую в редактировании страницы.
Что касается Suggestion-2, я его поддерживаю. Не могли бы вы сделать то же самое для строки BSAFE, пока вы в ней, поскольку в списке Module In Process есть две отдельные криптографические библиотеки BSAFE ?
С уважением - Безопасность в мыслях ( обсуждение ) 19:13, 6 декабря 2022 (UTC) [ ответить ]
Спасибо за ваш отзыв @ Security in mind ! Я согласен, это модуль wolfCrypt (криптобиблиотека), который сертифицирован FIPS, а не wolfSSL (реализация TLS). Спасибо за поддержку, однако, как платный участник, я был отговорен от внесения прямых правок на страницы, связанные с wolfSSL. Tim-Weller-wolfSSL ( обсуждение ) 20:31, 6 декабря 2022 (UTC) [ ответить ]
Я узнал о процессе запроса на изменение , который будет использоваться платными участниками для запроса на редактирование страниц (я все еще учусь!). Я создам два отдельных запроса на изменение для предложений, сделанных в этом комментарии/разделе. Спасибо за ваше терпение! - Тим. Tim-Weller-wolfSSL ( обсуждение ) 12:49, 7 декабря 2022 (UTC) [ ответ ]
  • Конкретный текст, который необходимо добавить или удалить: Обновите таблицу разделов FIPS-140 , строку wolfCrypt , ссылку на проверенное значение столбца FIPS 140-2 (в настоящее время [34] ) следующим образом: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3389
  • Причина изменения: Текущая ссылка помечена как «мертвая ссылка» и является ссылкой на поиск, а не напрямую на соответствующий сертификат.
  • Ссылки, подтверждающие изменение: Прямая ссылка на сертификат, подтверждающий заявление wolfCrypt о проверке FIPS 140-2: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3389

Tim-Weller-wolfSSL ( обсуждение ) 12:46, 7 декабря 2022 (UTC) [ ответить ]

Привет, Tim-Weller-wolfSSL , вы можете продолжить и внести предложенное изменение. Spencer T• C 04:08, 15 апреля 2023 (UTC) [ ответить ]
Привет, Спенсер , я сделал одобренную правку. Спасибо за ваше время и внимание! Tim-Weller-wolfSSL ( обсуждение ) 15:26, 17 апреля 2023 (UTC) [ ответить ]
  • Конкретный текст, который необходимо добавить или удалить: обновить таблицу разделов FIPS-140 , строку wolfCrypt , ссылку на проверенное значение столбца FIPS 140-3 (в настоящее время [28] ) следующим образом: https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Modules-In-Process/Modules-In-Process-List
  • Причина изменения: Текущая ссылка ведет на список тестируемых реализаций (IUT) . Реализации, завершившие тестирование, перешли на следующую стадию процесса проверки, которая рассматривается CMVP, и перечислены в списке модулей в процессе (MIP) . Библиотека wolfCrypt перешла из списка IUT в список MIP и больше не указана в списке IUT, что делает ссылку на список IUT неактуальной в качестве вспомогательной ссылки для процесса wolfCrypt по направлению к сертификации FIPS 140-3 (т. е. вы больше не найдете wolfCrypt в списке IUT!)
  • Ссылки, поддерживающие изменения:
    • https://csrc.nist.gov/projects/cryptographic-module-validation-program — Обзор процесса проверки FIPS 140-3
    • https://csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-process/iut-list - Список IUT (текущая ссылка), в котором нет wolfCrypt
    • https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Modules-In-Process/Modules-In-Process-List - список MIP (предлагаемая ссылка), в котором указан wolfCrypt

Tim-Weller-wolfSSL ( обсуждение ) 13:02, 7 декабря 2022 (UTC) [ ответить ]

Привет, Tim-Weller-wolfSSL, вы также одобрены для реализации этого предложенного изменения. Spencer T• C 04:09, 15 апреля 2023 (UTC) [ ответить ]
Привет Спенсер , эта правка также была сделана. Спасибо еще раз за ваше время! Tim-Weller-wolfSSL ( talk ) 15:42, 17 апреля 2023 (UTC) [ ответить ]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Comparison_of_cryptography_libraries&oldid=1206765096"