Name Description Size
config.mk 1486
exports.gyp 1009
fips_algorithms.h Vendors should replace this header file with the file containing those algorithms which have NIST algorithm Certificates. 11549
fipsaudt.c This file implements audit logging required by FIPS 140-2 Security Level 2. 13240
fipstest.c different platforms have different ways of calling and initial entry point when the dll/.so is loaded. Most platforms support either a posix pragma or the GCC attribute. Some platforms suppor a pre-defined name, and some platforms have a link line way of invoking this function. 32973
fipstokn.c This file implements PKCS 11 on top of our existing security modules For more information about PKCS 11 See PKCS 11 Token Inteface Standard. This implementation has two slots: slot 1 is our generic crypto support. It does not require login (unless you've enabled FIPS). It supports Public Key ops, and all they bulk ciphers and hashes. It can also support Private Key ops for imported Private keys. It does not have any token storage. slot 2 is our private key support. It requires a login before use. It can store Private Keys and Certs as token objects. Currently only private keys and their associated Certificates are saved on the token. In this implementation, session objects are only visible to the session that created or generated them. 63967
jpakesftk.c XXX: SEC_ERROR_INVALID_ARGS might be caused by invalid template parameters. 12157
kbkdf.c Overview: This file contains implementations of the three KDFs from NIST SP800-108 "Recommendation for Key Derivation Using Pseudorandom Functions": 1. KDF in Counter Mode (section 5.1) 2. KDF in Feedback Mode (section 5.2) 3. KDF in Double-Pipeline Iteration Mode (section 5.3) These KDFs are a form of negotiable building blocks for KDFs: protocol designers can choose various fields, their endianness, and the underlying PRF. These constructs are generic enough to handle creation of arbitrary, (but known ahead of time) length outputs. The families of PRFs described here are used, among other places, in Kerberos and GlobalPlatform's Secure Channel Protocol 03. The PKCS#11 v3.0 design for this KDF facilitates a wide range of uses. Implementation Details: We reuse the new sftk_MACCtx for handling the underlying MACing; with a few safe restrictions, we can reuse whatever it gives us to use as a PRF. We implement the core of the KDF in the *Raw(...) version of the function call. The PKCS#11 key handling happens in the non-Raw version. This means we need a single large allocation upfront (large enough to store the entire key stream), but means we can share key parsing logic and enable the creation of data objects. 61434
kem.c Assumes pMechanism has been validated with sftk_kem_ValidateMechanism 10769
kem.h 1423
legacydb
lgglue.c The following code handles the storage of PKCS 11 modules used by the NSS. This file is written to abstract away how the modules are stored so we can deside that later. 11668
lgglue.h This code defines the glue layer between softoken and the legacy DB library 2984
lowkey.c ASN1 Templates for new decoder/encoder 21278
lowkeyi.h See bugzilla bug 125359 Since NSS (via PKCS#11) wants to handle big integers as unsigned ints, all of the templates above that en/decode into integers must be converted from ASN.1's signed integer type. This is done by marking either the source or destination (encoding or decoding, respectively) type as siUnsignedInteger. 2308
lowkeyti.h Typedef for callback to get a password "key". 2895
lowpbe.c how much a crypto encrypt/decryption may expand a buffer 55451
lowpbe.h used for V2 PKCS 12 Draft Spec 3391
Makefile 2618
manifest.mn 1346
padbuf.c Prepare a buffer for any padded CBC encryption algorithm, growing to the appropriate boundary and filling with the appropriate padding. blockSize must be a power of 2. NOTE: If arena is non-NULL, we re-allocate from there, otherwise we assume (and use) XP memory (re)allocation. 1534
pkcs11.c This file implements PKCS 11 on top of our existing security modules For more information about PKCS 11 See PKCS 11 Token Inteface Standard. This implementation has two slots: slot 1 is our generic crypto support. It does not require login. It supports Public Key ops, and all they bulk ciphers and hashes. It can also support Private Key ops for imported Private keys. It does not have any token storage. slot 2 is our private key support. It requires a login before use. It can store Private Keys and Certs as token objects. Currently only private keys and their associated Certificates are saved on the token. In this implementation, session objects are only visible to the session that created or generated them. 190846
pkcs11c.c This file implements PKCS 11 on top of our existing security modules For more information about PKCS 11 See PKCS 11 Token Inteface Standard. This implementation has two slots: slot 1 is our generic crypto support. It does not require login. It supports Public Key ops, and all they bulk ciphers and hashes. It can also support Private Key ops for imported Private keys. It does not have any token storage. slot 2 is our private key support. It requires a login before use. It can store Private Keys and Certs as token objects. Currently only private keys and their associated Certificates are saved on the token. In this implementation, session objects are only visible to the session that created or generated them. 330519
pkcs11i.h Internal data structures and functions used by pkcs11.c 38774
pkcs11ni.h pkcs11ni.h This file contains softoken private exports for NSS 525
pkcs11u.c Internal PKCS #11 functions. Should only be called by pkcs11.c 76895
sdb.c This file implements PKCS 11 on top of our existing security modules For more information about PKCS 11 See PKCS 11 Token Inteface Standard. This implementation has two slots: slot 1 is our generic crypto support. It does not require login. It supports Public Key ops, and all they bulk ciphers and hashes. It can also support Private Key ops for imported Private keys. It does not have any token storage. slot 2 is our private key support. It requires a login before use. It can store Private Keys and Certs as token objects. Currently only private keys and their associated Certificates are saved on the token. In this implementation, session objects are only visible to the session that created or generated them. 76049
sdb.h This file implements PKCS 11 on top of our existing security modules For more information about PKCS 11 See PKCS 11 Token Inteface Standard. This implementation has two slots: slot 1 is our generic crypto support. It does not require login. It supports Public Key ops, and all they bulk ciphers and hashes. It can also support Private Key ops for imported Private keys. It does not have any token storage. slot 2 is our private key support. It requires a login before use. It can store Private Keys and Certs as token objects. Currently only private keys and their associated Certificates are saved on the token. In this implementation, session objects are only visible to the session that created or generated them. 3147
sftkdb.c The following code handles the storage of PKCS 11 modules used by the NSS. For the rest of NSS, only one kind of database handle exists: SFTKDBHandle There is one SFTKDBHandle for the each key database and one for each cert database. These databases are opened as associated pairs, one pair per slot. SFTKDBHandles are reference counted objects. Each SFTKDBHandle points to a low level database handle (SDB). This handle represents the underlying physical database. These objects are not reference counted, an are 'owned' by their respective SFTKDBHandles. 99687
sftkdb.h raw database stuff 3785
sftkdbt.h 357
sftkdbti.h private defines 3390
sftkdhverify.c This file makes sure a prime given to us matches one of the known approved primes for diffie-helman. It also checks if a prime is a safe prime for the case where we don't match an approved prime. 108946
sftkhmac.c sftk_HMACMechanismToHash converts a PKCS#11 MAC mechanism into a freebl hash type. 14761
sftkike.c This file implements PKCS 11 on top of our existing security modules For more information about PKCS 11 See PKCS 11 Token Inteface Standard. This implementation has two slots: slot 1 is our generic crypto support. It does not require login. It supports Public Key ops, and all they bulk ciphers and hashes. It can also support Private Key ops for imported Private keys. It does not have any token storage. slot 2 is our private key support. It requires a login before use. It can store Private Keys and Certs as token objects. Currently only private keys and their associated Certificates are saved on the token. In this implementation, session objects are only visible to the session that created or generated them. 48934
sftkmessage.c This file implements PKCS 11 on top of our existing security modules Implement the PKCS #11 v3.0 Message interfaces 13296
sftkpars.c The following code handles the storage of PKCS 11 modules used by the NSS. This file is written to abstract away how the modules are stored so we can deside that later. 9947
sftkpwd.c The following code handles the storage of PKCS 11 modules used by the NSS. For the rest of NSS, only one kind of database handle exists: SFTKDBHandle There is one SFTKDBHandle for the each key database and one for each cert database. These databases are opened as associated pairs, one pair per slot. SFTKDBHandles are reference counted objects. Each SFTKDBHandle points to a low level database handle (SDB). This handle represents the underlying physical database. These objects are not reference counted, an are 'owned' by their respective SFTKDBHandles. 45476
softkver.c Library identity and versioning 474
softkver.h Softoken's major version, minor version, patch level, build number, and whether this is a beta release. The format of the version string should be "<major version>.<minor version>[.<patch level>[.<build number>]][ <ECC>][ <Beta>]" 806
softoken.gyp 2653
softoken.h Convenience wrapper for doing a single PKCS#1 v1.5 RSA operations where the encoded digest info is computed internally, rather than by the caller. The HashSign variants expect as input the value of H, the computed hash from RFC 3447, Section 9.2, Step 1, and will compute the DER-encoded DigestInfo structure internally prior to signing/verifying. 9805
softokn.def 1464
softokn.rc 1950
softoknt.h bytes 1219
tlsprf.c size of allocated block, in bytes. 6594