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
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 '
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
On 7 February 2018 at 11:45, Andrew Cagney wrote:
> On 7 February 2018 at 10:41, Franziskus Kiefer wrote:
>> You should probably try to detect this at runtime.
>> At compile time you can simply check if SEC_OID_CURVE25519 exists and fail
>> (or do something els
25519 (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 wrote:
>
>> On Wed, 7 Feb 2018, Andrew Cagney wrote:
>>
>> I'd like to use SEC_OID_CURVE25519 but I noticed older NSS vers
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 autoc
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
> https://lists.mozilla.org/listinfo/dev-tech-c
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
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 release SECKEYE
I'm trying to understand why the PK11_Derive call:
CK_OBJECT_HANDLE key_handle = PK11_GetSymKeyHandle(key);
SECItem key_param = {
.data = (unsigned char*)&key_handle,
.len = sizeof(key_handle)
};
CK_ATTRIBUTE_TYPE operation = CKA_DERIVE;
int key_size = 0;
PK
I created https://bugzilla.mozilla.org/show_bug.cgi?id=1342434
On 22 February 2017 at 16:23, Robert Relyea wrote:
> On 02/22/2017 10:44 AM, Andrew Cagney wrote:
>>
>> Hi,
>>
>> I've got a PK11_Derive() call failing (presumably something silly on
>> my p
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 t
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 D
Hi, according to the NSS documentation, the functions for getting
CKAIDs are deprecated vis:
/**
* New functions which are already deprecated
**/
SECItem *
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 database is
> > open readOnly, the change
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
> as you had suggested.
> Init
On 12 March 2016 at 20:11, Andrew Cagney wrote:
> On 11 March 2016 at 13:23, Andrew Cagney 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 FI
On 18 March 2016 at 13:49, Robert Relyea 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 mode I guess I really mean con
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()?
On 11 March 2016 at 13:23, Andrew Cagney 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 could
> follow sample3 and
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, CKA_SIGN,
FYI,
I solved the CFLAGS mystery:
On 4 February 2016 at 10:59, Andrew Cagney wrote:
> ifdef CROSS_COMPILE
> DEFAULT_GMAKE_FLAGS += \
> NATIVE_CC='$(HOST_CC)' \
> CC='$(CC)' \
> CCC='$(CXX)' \
> LINK='$(LD)
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)' \
L
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 =
d084a30166a50fb7325c3960874a839449ef9741c2f4f947d0201dd8c1269273d79509f37e3ca3eb4fa2fe2a282
[inline]
On 5 May 2015 at 13:18, Robert Relyea 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. Example psuedo
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 PR
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 (whic
27 matches
Mail list logo
