(Disclaimer: Not a FIPS compliance expert) Here's NIST position - https://csrc.nist.rip/groups/STM/cmvp/notices.html . As per the document "*At least one of the RSA modulus lengths supported by the module for RSA signature generation shall be 2048, 3072, or 4096 bits. The RSA signature algorithm implementations shall be tested by a CST lab for all implemented RSA modulus lengths where CAVS testing is available.*". As of last month such a testing to validate RSA 4096 bit keys is available is being tested (scroll down to RSA section) - https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/details?product=12388 .
In summary dev.boringcrypto needs a fix to honor RSA 4096 bit keys to the least and reject anything less than 2048 bits. This will certainly benefit the projects using dev.boringcrypto and looking for FIPS validation. Regards, Bhagya On Monday, May 4, 2020 at 8:32:08 AM UTC-7, pradee...@gmail.com wrote: > > We are facing similar issues with dev.broingCrypto branch when using RSA > 4096. > > See Page 195 of following link > https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf > > Question/Problem SP 800-131A Rev1 provides only the lower bound, 2048 > bits, for the RSA modulus size used in signature generation. Does this > imply that the RSA modulus sizes other than 2048 and 3072 may be used to > generate the RSA signatures in the approved mode? In particular, is the use > of the 4096-bit modulus approved and, if so, what are the testing > requirements for the RSA key generation if the key pair used in the RSA > signature algorithm is generated by the module? > > Resolution > > When performing an RSA signature generation, a module may use any modulus > size greater than or equal to 2048 bits. At least one of the RSA modulus > lengths supported by the module for RSA signature generation shall be 2048, > 3072, or 4096 bits. > > On Monday, May 4, 2020 at 8:40:37 AM UTC+5:30, Bhagya Prasad NR wrote: >> >> (Disclaimer: Not a FIPS compliance expert) >> >> Couple of observations. I looked at how others are treating this by >> taking an example of OpenSSL 1.1.1 and Go's 1.12.4 distribution from CentOS >> 8.1 (which is derived from RHEL 8.1 and RHEL is inline for FIPS 140-2 >> validation as we speak). >> >> [1]. OpenSSL 1.1.1 FIPS patch (source: >> http://vault.centos.org/8.1.1911/BaseOS/Source/SPackages/openssl-1.1.1c-2.el8.src.rpm >> >> ) allows RSA public key modulus bits greater than 1024 bits in size via >> OPENSSL_RSA_FIPS_MIN_MODULUS_BITS >> (whose value is defined in rsa.h as 1048) >> >> >> [2]. CentOS 8.1 's go lang distribution (source: >> http://vault.centos.org/8.1.1911/AppStream/Source/SPackages/golang-1.12.12-4.module_el8.1.0+271+e71148fc.src.rpm; >> >> File: src/crypto/tls/boring.go) allows RSA public key modules bits greater >> than 2048 and its size divisible by 512 as valid RSA public keys. >> >> >> Attaching relevant screenshots below. Does this tell there is a need for >> a patch in golang's dev.boringcrypto branch to allow RSA 4096 bit keys? >> Has anyone encountered the issue by using dev.boringcrypto distribution? >> >> Thanks! >> Bhagya >> >> On Thursday, April 30, 2020 at 11:13:18 AM UTC-7, mohit....@gmail.com >> wrote: >>> >>> Summary - Trying Boring Go in FIPS mode to connect to Microsoft services >>> (Azure). Intermediate CA Certificate for Microsoft has a 4096 bit public >>> key that is not allowed by Boring Go (Code here >>> <https://github.com/golang/go/blob/2b0d842f4b24b3be4bcf02c7a796e3a4d3d952f6/src/crypto/tls/boring.go#L98> >>> >>> ), Is there any workaround without having to turn off FIPS mode ? >>> >>> go version go1.14b4 linux/amd64 >>> >>> Hi all, >>> So I am working on an application that requires to be run in FIPS mode >>> and has to connect to Azure services. I looked up the boring Go branch, got >>> version 1.14 and started using it. >>> While trying to connect to Azure services (for eg. >>> graph[dot]microsoft[dot]com or even microsoft[dot]com), I was getting an >>> incompatible certificate usage issue. Here is the sample code I am using - >>> `package main >>> >>> import ( >>> "fmt" >>> "io/ioutil" >>> "net/http" >>> _ "crypto/tls/fipsonly" //Code works without this but we need the >>> application to run in FIPS >>> ) >>> func main() { >>> url := "https: //microsoft.com" //Space put here because of two >>> link limit >>> fmt.Printf("HTML code of %s ...\n", url) >>> client := &http.Client{} >>> resp, err := client.Get(url) >>> >>> if err != nil { >>> panic(err) >>> } >>> >>> defer resp.Body.Close() >>> >>> html, err := ioutil.ReadAll(resp.Body) >>> if err != nil { >>> panic(err) >>> } >>> >>> fmt.Printf("%s\n", html) >>> }` >>> >>> The error I get is as follows - >>> HTML code of https: //microsoft.com ... panic: Get "https: // >>> microsoft.com": x509: certificate specifies an incompatible key usage >>> goroutine 1 [running]: main.main() /usr/local/go/bin/test.go:15 +0x26c exit >>> status 2 >>> >>> I checked the golang code and found that a certificate with a 4096 bit >>> public key is not a valid certificate according to the IsBoringCertificate >>> function The intermediate certificate in Microsoft’s Certificate Chain has >>> a 4096 bit public key. >>> [image: Screen Shot 2020-04-27 at 12.35.20 PM] >>> <https://forum.golangbridge.org/uploads/default/original/2X/5/5ee810d6e3d7c0397d6414aed64851342df3f843.png> >>> >>> So, my question is as follows : >>> >>> 1. Is this intended behavior ? >>> 2. If yes, is here any workaround via which I can keep FIPS mode on >>> and connect to these services ? This workaround can be code changes or >>> using different tools. However, I can’t turn off FIPS mode. >>> >>> Thanks for going through this ! >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b460994e-4be3-42ca-9e03-6ee7ad1238de%40googlegroups.com.
