Talk:Comparison of cryptography libraries

This article is rated List-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Articles for creation This article was reviewed by member(s) of WikiProject Articles for creation. The project works to allow users to contribute quality articles and media files to the encyclopedia and track their progress as they are developed. To participate, please visit the project page for more information.Articles for creationWikipedia:WikiProject Articles for creationTemplate:WikiProject Articles for creationAfC This article was accepted on 29 September 2014 by reviewer DGG (talk · contribs). Software: Computing This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware ??? This article has not yet received a rating on the project's importance scale. This article is supported by WikiProject Computing. Cryptography: Computer science This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography ??? This article has not yet received a rating on the importance scale. This article is supported by WikiProject Computer science.

I was trying to update this page to clarify that Bouncy Castle 1.0.0 (latest version is 1.0.1) has been validated to FIPS 140-2 and has been certified. I am not good enough with the markup used on wikipedia to fix this tho. Can someone help? Source: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm#2768 — Preceding unsigned comment added by Omarkj (talk • contribs) 22:38, 17 June 2017 (UTC)[reply]

Lightweight Block Ciphers with ARX design have become increasingly popular. The ciphers have a lot of interest for resource constrained devices and Internet of Things. The ciphers include CHAM, LEA, Simon and Speck. It might be a good idea to add a new section for modern Lightweight Block Ciphers designs.

I don't have time to add it now, but I think Tink and TinyCrypt should be included on this page: https://github.com/google/tink https://github.com/intel/tinycrypt — Preceding unsigned comment added by 205.209.193.6 (talk) 17:46, 15 February 2019 (UTC)[reply]

It is documented in the Master branch, but not in 1.1.1, and inspection of the change log (and the 1.1.1 source code) confirms this.

Thus it *will* be supported - but isn't yet. 16:56, 6 February 2020 (UTC) — Preceding unsigned comment added by 62.2.246.66 (talk)

The information provided for Crypto Library is inaccurate and misleading. For example, Open SSL is not certified as standalone. It is certified integrated with RedHat, Ubuntu IBM, etc., etc., It is not possible to test a library, you to run it on some OS.

Every Crypto system certified under the NIST CMVP and passers gets a validation certificate number and it is published in https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search. which is publicly accessible and searchable database.

If there is not certificate number, it is not validated. Open SSL search result did not show a certificate. Therefore Open SSL library itself is not certified. Instead,Opel SSL integrated with, for example is the following integrations are certified.

3667 TrendMicro Inc. Deep Discovery Analyzer OpenSSL Cryptographic Module Software 06/04/2020 3657 Metaswitch Networks Ltd OpenSSL Cryptographic Module for Perimeta SBC Software 05/26/2020 3638 Super Micro Computer, Inc. Supermicro FIPS Object Module for OpenSSL Software 03/31/2020 3622 Canonical Ltd. Ubuntu 18.04 OpenSSL Cryptographic Module Software 02/25/2020

Whomevercrted this Wikipedia page need to correct the information, because it misleads lots of people.

In cryptography the devil is in the detail. In cryptographic security you either secure or insecure (1 or 0). There is no such thing as 1/0! — Preceding unsigned comment added by 2600:1700:1C00:2E80:B07C:2EB4:9FB3:3690 (talk) 21:17, 18 June 2020 (UTC)[reply]

I think we should add BoringSSL and LibreSSL, even though they are forks of OpenSSL and don't have their own articles (even wikipedia redirects boringssl to openssl). They are being used for real applications, and have become valid and popular alternatives to OpenSSL. Not having them in the table gives the false impression that they are not comparable to the other libraries. Chibby0ne (talk) 22:45, 7 August 2020 (UTC)[reply]

LibreSSL has an article, but Boring doesn't. We should include Libre and leave off Boring. - MrOllie (talk) 23:20, 7 August 2020 (UTC)[reply]

I would like to peacefully protest the revert One per customer, please done by MrOllie. This page uses the Implementation column to identify an implementation, not a customer or vendor. In fact, the customer or vendor is already identified by the Initiative column. When someone writes an implementation of an algorithm, that implementation can be in C, in Java, in Ruby, etc. Each are different implementations. Hence each implementations should have its own row in my opinion.

Note also that by having removed Crypto-C ME rows, users will miss the fact that Crypto-J (Java implementation) and Crypto-C ME (C implementation) provide different capabilities. Please look back at the older version, in the Public key cryptography standards and Hash function section, and you will see that the different implementations provides different capabilities.

Yes they share the same BSAFE name, but they are two completely different implementations, hence I believe each implementation deserves its own row.

Bouncy Castle should do the same, as they have a C# and Java implementation. - Security in mind (talk) 13:37, 16 July 2021 (UTC)[reply]

The primary value of this article is as a navigational aid to other Wikipedia articles, in particular, we link only to libraries that are independently notable. Since notability is WP:NOTINHERITED, if there are variant libraries under the same product name, only the primary, notable one should be listed here. If both were to be independently notable (which is not the case here), then we would have two different articles to link to. - MrOllie (talk) 15:42, 21 July 2021 (UTC)[reply]

The primary value of this article is as a navigational aid. I disagree. As the title of this article mentions it, the primary value of this article is to compare implementations of different libraries. The fact that there is a Java and a C implementation / library, and that they provide different capabilities, should convince you that those are independently notable. Sharing the same prefix name is not a valid reason to think they are the same. Users reaching this page uses it to compare features and capabilities. How would you address this to maintain the level of details and quality that page provides? - Security in mind (talk) 16:43, 21 July 2021 (UTC)[reply]

Here from 3O. This article is way out of my field of expertise, but since it has been hanging on 30, I 'll jump in. As I understand there is a disagrement on the scope or value of the article. Before providing an opinion, may I ask: is the topic notable? Cinadon36 12:30, 23 July 2021 (UTC)[reply]

Cinadon36, BSAFE is historically notable - it was the main crypto library until 2000 or so. It had a near monopoly because of a now-expired patent. These variants that came about in the wake of the patent expiry are not really notable. Since Security in mind forgot to mention it when opening this section, I'll also note that they have a COI with regard to BSAFE. MrOllie (talk) 12:42, 23 July 2021 (UTC)[reply]

Please rephrase forgot to mention to was unaware of the COI rules in Wikipedia, which is why I had no issues adding that COI tag in my user talk page. I have nothing to hide. Not everyone are experts at Wikipedia edition (or deletion) as MrOllie is. Security in mind (talk) 12:51, 23 July 2021 (UTC)[reply]

correcttion: adding that COI tag in my user talk page immediatelty after being made aware of it by MrOllie. - Security in mind (talk) 12:55, 23 July 2021 (UTC)[reply]

Well, I assumed you had read the COI guidelines by now and had simply forgotten that provision. - MrOllie (talk) 13:01, 23 July 2021 (UTC)[reply]

I have. From now on I will be the judge to decide if I use {{request edit}}, or if I do the edit myself if I know the changes will not create any objections. Editions from users in COI are Strongly discouraged, not prohibited. - Security in mind (talk) 13:19, 23 July 2021 (UTC)[reply]

Cinadon36, as MrOllie mentioned above, there is notability in this topic. The discussion is about whether two different implementations providing different capabilities should have their own rows / details. C and Java are two completely different programming languages. They can't be considered similar, hence should have their own details uniquely documented, else this article loses its value to document differences between different implementations. - Security in mind (talk) 13:19, 23 July 2021 (UTC)[reply]

I am just asking whether it is notable, so to see how RS are treating this issue. I am not going to send the article to AfD or add a notability banner or whatsoever. Also, the article seems to techincal, not addressing the needs of the general public. Anyway, I was asking about notability, because Me Ollie said above "The primary value of this article is as a navigational aid to other Wikipedia articles..." I didn't know that WP hosted articles that were tools or aids to other wp articles. Now, as for your argument Security in mind, that C and Java are totally different programming languages, it might be true, but general public is not aware of it, and as long as the article does not explain why is it so, the argument weakens. Cinadon36 15:29, 23 July 2021 (UTC)[reply]

I agree this is a technical article. However it is not meant to explain the difference between C and Java, as Programming_language#Implementation already takes care of this. Users reaching this page will have, or are expected to have, the technical knowledge to understand the difference between Java and C. This article compares the implementations and features of different cryptographic libraries. Security in mind (talk) 15:36, 23 July 2021 (UTC)[reply]

In light of recent discussions below, would it be possible to get Tim-Weller-wolfSSL's opinion on this request here? While I understand that WolfSSL and BSAFE Crypto-C ME / Micro Edition Suite are competing products, I would deeply appreciate it if you could provide your subject-matter-expert opinion about the possibility of documenting both the BSAFE Java implementation (Crypto-J) and C implementation (Crypto-C ME / MES) into different rows. Quite unfortunately, the reverts that were done some time ago have removed details about the C implementation. Now this page seems to imply that the C and Java implementations provides the same features, which is inaccurate. I will however understand if you say no to helping a WolfSSL competitor product. - Security in mind (talk) 15:10, 19 April 2023 (UTC)[reply]

@Valerie.peng, I think using "JCA/JCE" for the implementation name is somewhat misleading or confusing, as both are more a framework than an implementation. I'd rather use "Oracle SunJSSE", which is Oracle's implementation of JCA/JCE. There is OpenJDK which could list "OpenJDK SunJSSE" as the implementation name should Oracle add their own tweaks to their implementation compared to the public OpenJDK source. Also, in the hardware-assisted section, what is really providing hardware assistance? Is it the JCA/JCE (Oracle's SunJSSE provider), or is it the JRE itself that provides hardware assistance? Open for discussion. - Security in mind (talk) 19:17, 26 January 2022 (UTC)[reply]

@Security in mind "Oracle SunJSSE" isn't Oracle's implementation of JCA/JCE but rather Oracle's implementation of JSSE (was initially the Java Secure Socket Extension which becomes part of JDK). Oracle's implementation of JCA/JCE is covered by several providers, i.e. SUN, SunRsaSign, SunJCE, SunPKCS11 to name a few. Most of these providers are also available in OpenJDK. As for the hardware assisted section, if you were referring to PKCS11, then it's provided through the PKCS11 library/SunPKCS11 provider which can work with a third party PKCS11 library for the actual functionality. If you were talking about the acceleration aspect, it is through JRE/hotspot intrinsics. I am open for other suggestions better than "JCA/JCE", but "SunJSSE" just isn't the right choice. Valerie.peng — Preceding undated comment added 00:10, 29 January 2022 (UTC)[reply]

@Valerie.peng, I've always thought there was a bit of crypto algorithms implemented in the SunJSSE provider itself, but I will definitely trust you on this as I am aware of your involvement on this specific topic. And while writing my reply I notice the (new??) note in the JDK 11 docs that says "The SunJSSE provider is for backwards compatibility with older releases, and should no longer be used for KeyPairGenerator.". I guess I need to get up to speed on things! Anyhow, I would really love to see this page differentiate the capabilities of all of those libraries / providers (Sun, SunRsaSign, SunJCE, SunEC, etc), as the SUN provider does not provide ECDSA, while the SunEC does. So while it would make perfect sense to have one row per library (per provider), and I would back this edit, some Wikipedians with zero knowledge in software development and cryptography will revert this better change to bring it back to "one row per vendor", even though this article should be about "one row per implementation".. So, back to the "implementation name". Among ourselves, when we change a Java app from using the "default Java JCE provider" to use, I don't know, let's say, hum, BSAFE Crypto-J, we say we use the Crypto-J implementation. And when dev teams need to go back to the default implementation, we often refer to it as "the default Java JCE provider". Would "Java JCE Providers" be an implementation name that pleases you? Or should it be "Hotspot JCE providers"? I am also open to any suggestions. As for hardware assisted, I was initially thinking about hardware acceleration, and I believe you confirm this is provided by the Hotspot JRE, right? So should the implementation name for all rows simply be Hotspot? - Security in mind (talk) 20:48, 30 January 2022 (UTC)[reply]

@Security in mind, Well, I am not sure if naming the individual providers out would be the level of details suitable for this page. I will clarify this JCA/JCE with additional terms, such as "Default JDK JCA/JCE providers" to make this clearer. For hotspot, it has intrinsics code and logic for them to kick in when certain conditions are met, but this is NOT packaged as a provider, so "Hotspot JCE providers" may not quite fit the bill. Any more suggestion or comment for "Default JDK JCA/JCE providers"? - Valerie.peng — Preceding undated comment added 21:25, 7 February 2022 (UTC)[reply]

"Default JDK JCA/JCE providers", though long, sounds good to me. I think it is more accurate this way. And regarding HW acceleration, what if you kept the "Default JDK JCA/JCE providers" name, add a table footnote saying "When using Hotspot JVM", or something like that? - Security in mind (talk) 21:41, 7 February 2022 (UTC)[reply]

@Security in mind Sure, sounds reasonable, I will update as you suggested. Thanks - Valerie.peng

Hi, it would make sense to add a new section for extendable-output functions (XOF) to see which library supports SHAKE (SHAKE128 and SHAKE256), part of FIPS 202, and cSHAKE / KMAC defined in SP 800-185. Currently, this page here only compares Hash functions

Anyone willing to start such table?

Interestingly enough, Extendable-output functions incorrectly lists SHA-3 as an XOF. SHA-3 is a familyof cryptographic functions. Some of them are Cryptographic hash function and some are Extendable-output functions

- Security in mind (talk) 20:40, 4 August 2022 (UTC)[reply]

Hello, I'm an employee of wolfSSL (paid contributor) asked by wolfSSL, Inc to review and suggest updates to this page. The following are suggestions for changes to the wolfCrypt row in the table in the FIPS-140 section:

• SUGGESTION-1 - The FIPS 140-2 Validated column reference ([34]) is tagged as a "dead link" (?). wolfCrypt FIPS 140-2 is currently covered by certificate #3389, which has a direct link: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3389 ... I suggest changing the source to use the direct link to #3389, if that would be considered better (i.e. not tagged dead)

• SUGGESTION-2 - The FIPS 140-3 Validated column reference ([28]) is a link to the Implementation Under Test (IUT) list. Implementations which have completed testing, including wolfCrypt, have moved to the next stage of the validation process, which is review by the CMVP [1] and are listed on the Modules In Process list, https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Modules-In-Process/Modules-In-Process-List ... I would suggest adding a new reference link to the Modules In Process list, and citing the new reference in the wolfCrypt row's FIPS 140-3 Validated column entry.
  • Note: The situation for wolfCrypt may be shared by other implementations, i.e. they may be on the Modules In Process list, too!

Please provide feedback on these suggested changes, thanks! Tim-Weller-wolfSSL (talk) 20:52, 5 December 2022 (UTC)[reply]

With regards to Suggestion-1, I fear this would then become a duplicate of the Comparison of TLS implementations#Certifications. Speaking of which, TLS libraries rarely gets FIPS-validated. The crypto module used by the library does. If we'd wanted a clean resolution to your suggestion, I would edit the Certifications table in Comparison of TLS implementations to be a pointer to this page here, so that the TLS library page refers back to the cryptographic library used by the TLS library. Once the info is brought back here, there can be a decision made to have links to FIPS certificates, or CMVP search tool using the vendor name. Unfortunately, all my major edits on this topic always get reverted, so I no longer contribute to page edits.

Regarding Suggestion-2 I am supportive of it. Could you do the same for the BSAFE row while at it, since there are two distinct BSAFE cryptographic library on the Module In Process list?

Regards - Security in mind (talk) 19:13, 6 December 2022 (UTC)[reply]

Thank-you for your feedback @Security in mind! I agree, it's the wolfCrypt module (crypo library) which is FIPS certified, not wolfSSL (TLS implementation). Thank-you for the support, however, as a paid contributor I have been discouraged from making direct edits to pages related to wolfSSL. Tim-Weller-wolfSSL (talk) 20:31, 6 December 2022 (UTC)[reply]

I have become aware of the Request Change process to be used by paid contributors for requesting edits to pages (I'm still learning!) I will create two separate change requests for the suggestions made in this comment/section. Thank-you for your patience! - Tim. Tim-Weller-wolfSSL (talk) 12:49, 7 December 2022 (UTC)[reply]

An impartial editor has reviewed the proposed edit(s) and asked the editor with a conflict of interest to go ahead and make the suggested changes.

• Specific text to be added or removed: Update FIPS-140 section table, wolfCrypt row, FIPS 140-2 Validated column value's reference (currently [34]) to be: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3389
• Reason for the change: Current reference is tagged as "dead link" and is a link to a search rather than directly to the supporting certificate.
• References supporting change: Direct link to certificate supporting wolfCrypt claim of FIPS 140-2 validation: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3389

Tim-Weller-wolfSSL (talk) 12:46, 7 December 2022 (UTC)[reply]

Hi Tim-Weller-wolfSSL, you are approved to go ahead and make the proposed change. Spencer^T•C 04:08, 15 April 2023 (UTC)[reply]

Hi Spencer, I have made the approved edit. Thank-you for your time and attention! Tim-Weller-wolfSSL (talk) 15:26, 17 April 2023 (UTC)[reply]

An impartial editor has reviewed the proposed edit(s) and asked the editor with a conflict of interest to go ahead and make the suggested changes.

• Specific text to be added or removed: Update FIPS-140 section table, wolfCrypt row, FIPS 140-3 validated column value's reference (currently [28]) to be: https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Modules-In-Process/Modules-In-Process-List
• Reason for the change: The current link is to the Implementation Under Test (IUT) list. Implementations which have completed testing have moved to the next stage of the validation process, which is review by the CMVP and are listed on the Modules In Process (MIP) list. The wolfCrypt library has moved from the IUT list to the MIP list, and is no longer listed on the IUT list, making the link to the IUT list irrelevant as a supporting reference for wolfCrypt's process towards FIPS 140-3 certification (i.e. you cannot find wolfCrypt on the IUT list any more!)
• References supporting change:
  • https://csrc.nist.gov/projects/cryptographic-module-validation-program - Overview of FIPS 140-3 validation process
  • https://csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-process/iut-list - The IUT list (current reference link) which doesn't list wolfCrypt
  • https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Modules-In-Process/Modules-In-Process-List - The MIP list (proposed reference link) which does list wolfCrypt

Tim-Weller-wolfSSL (talk) 13:02, 7 December 2022 (UTC)[reply]

Hi Tim-Weller-wolfSSL you are also approved to go ahead and implement this proposed change too. Spencer^T•C 04:09, 15 April 2023 (UTC)[reply]

Hi Spencer, This edit has also been made. Thanks again for your time! Tim-Weller-wolfSSL (talk) 15:42, 17 April 2023 (UTC)[reply]