CERT_PKIXVerifyCert() and end certs with no trust

I've come across what seems to be a strange quirk with CERT_PKIXVerifyCert(): Start with a local keystore that contains an end-cert and a completely unrelated CA cert ... - receive an unknown blob (DER) over the wire (it's the same end-cert but lets pretend we don't know this) - convert the blob

Re: are CN=.# and CN== valid?

It looks like: CN=\#. as well. scanVal() strips off the \ leaving '#', ParseRFC1485AVA(), seeing a leading '#' then wrongly concludes it is the hex encoded BER. On Tue, 1 Oct 2019 at 16:27, Andrew Cagney wrote: > > CERT_AsciiToName() rejects both because the '=' and '#' appear > u

are CN=.# and CN== valid?

CERT_AsciiToName() rejects both because the '=' and '#' appear un-escaped in the RHS per SPECIAL_CHAR() macro. It would appear that one of the changes from https://tools.ietf.org/html/rfc2253 to https://tools.ietf.org/html/rfc4514#section-2.4 was to drop this as a requirement: - one of the

Re: how do I test if NSS supports an algorithm at build time?

On 7 February 2018 at 11:45, Andrew Cagney <andrew.cag...@gmail.com> wrote: > On 7 February 2018 at 10:41, Franziskus Kiefer <fkie...@mozilla.com> wrote: >> You should probably try to detect this at runtime. >> At compile time you can simply check if SEC_OID_CURVE2551

Re: how do I test if NSS supports an algorithm at build time?

e you could try using SEC_OID_CURVE25519 (with your own define to > 355) and have a fallback if NSS gives you an error on using it. > > On Wed, Feb 7, 2018 at 4:30 PM, Paul Wouters <p...@cypherpunks.ca> wrote: > >> On Wed, 7 Feb 2018, Andrew Cagney wrote: >> >> I'd like to use SEC_

how do I test if NSS supports an algorithm at build time?

Hi, I'd like to use SEC_OID_CURVE25519 but I noticed older NSS versions don't have it. What is the correct way to check for things like this at build time? As an aside, is there anything I should be doing to sanity check that the runtime SO is valid for my build. Andrew (yes, I know about

Re: AES_XCBC?

Because Variety is the spice of life On 7 December 2017 at 23:41, f masood via dev-tech-crypto wrote: > can you elaborate why you're focusing on NSS not OPENSSL for this task ? > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org >

AES_XCBC?

I'm looking at implementing AES_XCBC using NSS. That is: AES-XCBC-MAC-96: https://tools.ietf.org/html/rfc3566#section-4 AES-XCBC-MAC-PRF: https://tools.ietf.org/html/rfc4434 (the latter adds a recursive rule for building a fixed size key from a variable key) reading NSS's "documentation", I've

Re: [ANNOUNCE] NSS 3.28.3 Release

On 17 February 2017 at 08:52, Kai Engert wrote: > > SECKEYECPublicKey had been extended with a new attribute, named "encoding". If > an application passed type SECKEYECPublicKey to NSS (as part of > SECKEYPublicKey), the NSS library read the uninitialized attribute. With this > NSS

PK11_Derive CKM_CONCATENATE_BASE_AND_KEY fails when KEY is from from CKM_ECDH1_DERIVE

I'm trying to understand why the PK11_Derive call: CK_OBJECT_HANDLE key_handle = PK11_GetSymKeyHandle(key); SECItem key_param = { .data = (unsigned char*)_handle, .len = sizeof(key_handle) }; CK_ATTRIBUTE_TYPE operation = CKA_DERIVE; int key_size = 0;

Re: Should PK11_Derive() save the failure status?

I created https://bugzilla.mozilla.org/show_bug.cgi?id=1342434 On 22 February 2017 at 16:23, Robert Relyea <rrel...@redhat.com> wrote: > On 02/22/2017 10:44 AM, Andrew Cagney wrote: >> >> Hi, >> >> I've got a PK11_Derive() call failing (presumably something silly

Should PK11_Derive() save the failure status?

Hi, I've got a PK11_Derive() call failing (presumably something silly on my part), but frustratingly, PORT_GetError() just returns 0. It seems that all variants of PK11_Derive() don't call: PORT_SetError(PK11_MapError(crv)); with the error status from ->C_DeriveKey(). Should they? Or is

Computing IKEv2's SKEYSEED=PRF(Ni | Nr, {g^ir}) using NSS's CKA_SIGN

Hi, I'm trying to use CKA_SIGN to compute things like: SKEYSEED = PRF(Ni | Nr, {g^ir}) SKEYSEED = PRF({SK_d (old)}, {g^ir (new)} | Ni | Nr) (PRF=HMAC_SHA1 say) where, with my current code: Ni|Nr is raw bytes (nonces put on the wire) {g^ir} and g^ir (new)} are the output from

Replacement for PK11_GetLowLevelKeyIDForCert etc

Hi, according to the NSS documentation, the functions for getting CKAIDs are deprecated vis: /** * New functions which are already deprecated **/ SECItem *

Re: NSS_NoDB_Init(".") and FIPS mode

On 18 March 2016 at 16:55, Wan-Teh Chang wrote: > On Fri, Mar 18, 2016 at 10:49 AM, Robert Relyea > wrote: > > > > Yes, SECMOD_DeleteInternalModule() is a toggle which switches NSS between > > FIPS and non-FIPS. If you don't have a database open, or the

Re: Cross-Compilation of NSS for MIPS platform fails.

On 18 March 2016 at 07:40, wrote: > Hi, >I went through the Firefox makefile and observed that I had set the > flags which are listed there. So, I believe that might not be the problem. > Yet, I shall build Firefox and see the build logs for better understanding >

Re: computing hmac (RFC 2104) when the key isn't secure

On 12 March 2016 at 20:11, Andrew Cagney <andrew.cag...@gmail.com> wrote: > On 11 March 2016 at 13:23, Andrew Cagney <andrew.cag...@gmail.com> wrote: > > Given a clear-text key and clear-text data (lots of it), I'm trying to > > compute a clear-text

Re: NSS_NoDB_Init(".") and FIPS mode

On 18 March 2016 at 13:49, Robert Relyea <rrel...@redhat.com> wrote: > On 03/18/2016 09:14 AM, Andrew Cagney wrote: > >> Is it possible to put NSS (softtoken) in FIPS mode (PK11_IsFIPS()) without >> a "modutil -fips true" database? >> >> By FIPS m

NSS_NoDB_Init(".") and FIPS mode

Is it possible to put NSS (softtoken) in FIPS mode (PK11_IsFIPS()) without a "modutil -fips true" database? By FIPS mode I guess I really mean confirm that NSS has performed some sort of FIPS self-check. An earlier thread mentioned some way of toggling things using SECMOD_DeleteInternalModule()?

Re: computing hmac (RFC 2104) when the key isn't secure

On 11 March 2016 at 13:23, Andrew Cagney <andrew.cag...@gmail.com> wrote: > Given a clear-text key and clear-text data (lots of it), I'm trying to > compute a clear-text RFC 2104 HMAC aka IPSEC prf() > > If the key was all FIPS secure in a PK11SymKey then I believe I coul

computing hmac (RFC 2104) when the key isn't secure

Given a clear-text key and clear-text data (lots of it), I'm trying to compute a clear-text RFC 2104 HMAC aka IPSEC prf() If the key was all FIPS secure in a PK11SymKey then I believe I could follow sample3 and kick things off with: context = PK11_CreateContextBySymKey(CKM_MD5_HMAC,

cross compiling NSS

Hi, I'm trying to understand the "correct" way to cross compile NSS. The first approach I tried is based on firefox's config/external/nss/Makefile.in where I found: ifdef CROSS_COMPILE DEFAULT_GMAKE_FLAGS += \ NATIVE_CC='$(HOST_CC)' \ CC='$(CC)' \ CCC='$(CXX)' \

Re: cross compiling NSS

FYI, I solved the CFLAGS mystery: On 4 February 2016 at 10:59, Andrew Cagney <andrew.cag...@gmail.com> wrote: > ifdef CROSS_COMPILE > DEFAULT_GMAKE_FLAGS += \ > NATIVE_CC='$(HOST_CC)' \ > CC='$(CC)' \ > CCC='$(CXX)' \

PK11SymKey in FIPS mode from nothing

Hi, I'm looking to clean up some test code (IKEv2, NISTs CAVP tests), so that they work in FIPS mode (what ever that means). The test inputs look like: Ni = 3651fef5c9c35e93 Nr = c09a8b90a3f04d59 g^ir =

Re: target parameter to PK11_Derive

[inline] On 5 May 2015 at 13:18, Robert Relyea rrel...@redhat.com wrote: The target Mechanism is the operation you are going to use the target key for, It shouldn't match the mechanism used to derive the key. It is basically used to set the appropriate key type and flags on the resultant key.

target parameter to PK11_Derive

Hi, I'm cleaning up some code (it has a long history) that, among other things, computes IKE's PRF (hmac) and PRF+ (key derivation function). The computation involves the use of PK11_Derive to perform lots of concatenation, padding, xoring, and hashing(1). To get an idea, the prf+ (which uses

target parameter to PK11_Derive

Hi, I'm cleaning up some code (it has a long history) that, among other things, computes IKE's PRF (hmac) and PRF+ (key derivation function). The computation involves the use of PK11_Derive to perform lots of concatenation, padding, xoring, and hashing(1). To get an idea, the PRF+ function