Fact-checked by Grok 2 weeks ago

PKCS

The Public-Key Cryptography Standards (PKCS) are a suite of specifications for public-key cryptography developed by RSA Laboratories to promote interoperability among applications and systems using cryptographic techniques such as encryption, digital signatures, and key management.^[1] First released on June 3, 1991, and revised in 1993, the standards were designed to extend beyond earlier formats like Privacy-Enhanced Mail (PEM) while ensuring compatibility with emerging protocols such as those in the Open Systems Interconnection (OSI) model.^[1] The PKCS series addresses key challenges in public-key cryptography by defining precise syntax and mechanisms using Abstract Syntax Notation One (ASN.1) and Basic Encoding Rules (BER), facilitating secure data exchange across diverse platforms.^[1] Originally comprising standards numbered #1 through #10, the suite has expanded over time through collaboration with industry partners including Microsoft, Apple, and Sun Microsystems, resulting in up to 15 standards by the early 2000s, though some (such as #2, #4, and #6) have been deprecated or phased out in favor of alternatives like X.509 version 3 certificates.^[2] Among the most influential standards, PKCS #1 specifies RSA cryptography for encryption schemes (e.g., RSAES-OAEP) and signature schemes (e.g., RSASSA-PSS), with its latest version (2.2) published as RFC 8017 in 2016 to update hashing algorithms and transfer maintenance to the Internet Engineering Task Force (IETF).^[3] PKCS #7 provides a general syntax for cryptographically protected messages, including signed and enveloped data, widely used in protocols like S/MIME.^[2] PKCS #11, known as the Cryptographic Token Interface, defines a platform-independent API for interacting with hardware security modules and cryptographic tokens, now maintained by OASIS.^[4] Other notable standards include PKCS #5 for password-based encryption, PKCS #8 for private-key information syntax, PKCS #10 for certification requests, and PKCS #12 for personal information exchange syntax, enabling secure storage and transport of keys and certificates in formats like .pfx files.^[2] These standards underpin modern cybersecurity applications, including secure email, web browsing via SSL/TLS, and digital certificates, ensuring robust protection against eavesdropping and tampering.

Overview

Definition and Purpose

Public-Key Cryptography Standards (PKCS) is a suite of specifications for public-key cryptography, designed to promote interoperability among diverse cryptographic systems and implementations. Originally developed by RSA Laboratories, PKCS provides standardized formats, algorithms, and protocols that ensure compatibility in handling public-key operations across different platforms, vendors, and applications. By defining common structures using Abstract Syntax Notation One (ASN.1) and Basic Encoding Rules (BER), PKCS facilitates the exchange of encrypted data, keys, and certificates without proprietary dependencies.^[1] The core purposes of PKCS include enabling secure data encryption, digital signatures, key management, and certificate handling in asymmetric cryptography environments. These standards address fundamental challenges such as secure key exchange—through mechanisms like Diffie-Hellman key agreement—and data integrity via signature schemes, allowing systems to verify authenticity and prevent tampering. PKCS emphasizes practical interoperability to support widespread adoption of public-key techniques, including encryption and signing with algorithms like RSA, thereby reducing implementation errors and enhancing security in networked communications.^[1] PKCS standards are organized in a numbering system from PKCS #1 to PKCS #15, each targeting specific aspects of public-key cryptography rather than broad theoretical principles. This focus on actionable guidelines prioritizes real-world deployment, such as standardizing key formats and message syntaxes to streamline integration in protocols like secure email and web security. For example, underlying methods like the RSA algorithm are incorporated to provide concrete encryption and signature primitives.^[1]^[5]

Importance in Modern Cryptography

PKCS standards underpin foundational internet security protocols, most notably TLS/SSL, by providing essential specifications for certificate formats and encoding that ensure secure web communications. The binary structure of digital certificates in TLS/SSL relies on PKCS-defined rules, using ASN.1 notation and Distinguished Encoding Rules (DER) to standardize content representation and binary translation across diverse systems. This integration has enabled widespread secure data transmission over the internet, protecting billions of daily transactions from eavesdropping and tampering.^[6] In enterprise settings, PKCS facilitates robust key management and data protection, aligning with regulatory demands such as FIPS 140-2 compliance for cryptographic modules. Standards like PKCS #11 allow organizations to enforce FIPS-approved algorithms and key sizes, restricting operations to verified secure methods in environments handling sensitive information, such as financial systems and government networks. This compliance mode supports token-level controls, enabling selective enforcement to balance security and operational flexibility.^[7] PKCS #12 has become the de facto format for personal information exchange, including private keys and certificates, and is widely used in major web browsers for client authentication and certificate storage in enterprise deployments. Its standardized structure supports secure import and management in tools like Firefox and Chrome. By promoting interoperability, PKCS reduces vendor lock-in, as its open interfaces like PKCS #11 enable applications to interact uniformly with hardware security modules (HSMs) and tokens across proprietary and open-source ecosystems, regardless of manufacturer.^[8]^[9] As cryptography evolves toward post-quantum resilience, PKCS standards are adapting to incorporate quantum-resistant algorithms, ensuring continued relevance in PKI transitions. For instance, updated PKCS #11 implementations now support lattice-based signatures like Dilithium, allowing seamless integration of post-quantum keys into existing hardware and software infrastructures without major overhauls. This adaptation positions PKCS as a bridge for migrating legacy systems to quantum-safe operations by 2035, as recommended by NIST timelines.^[10]^[11]

History

Origins at RSA Laboratories

The Public-Key Cryptography Standards (PKCS) originated in 1991 at RSA Laboratories, a division of RSA Data Security, Inc., as a initiative to develop interoperable specifications for public-key cryptography amid the rapid expansion of the internet and emerging needs for secure digital communications.^[12] This effort was driven by the recognition that without standardized formats, cryptographic implementations from vendors like RSA and others would suffer from incompatibility, hindering commercial adoption and increasing the risk of implementation errors.^[13] RSA Laboratories aimed to create practical, de facto standards that could serve as a foundation for widespread use in computer systems, drawing on input from early adopters to ensure real-world viability.^[3] The initial development involved collaborative meetings with a select group of public-key technology pioneers, resulting in the first public release on June 3, 1991, which included drafts of several core standards.^[3] Between 1991 and 1993, RSA Laboratories published versions of PKCS #1 through #7, covering foundational elements such as RSA encryption (PKCS #1), Diffie-Hellman key agreement (PKCS #3), password-based encryption (PKCS #5), extended-certificate syntax (PKCS #6), cryptographic message syntax (PKCS #7), and private-key information (initially PKCS #8, though the full set up to #7 was prioritized early).^[12] During this phase, RSA Laboratories retained sole responsibility for maintenance and refinement, issuing bulletins and updates to incorporate feedback from developers. Central to these origins was Burton S. Kaliski Jr., Chief Scientist at RSA Laboratories, who authored key documents and coordinated the drafting process with collaborators, ensuring the standards aligned with existing formats like ASN.1 for broad compatibility.^[12] Kaliski's leadership helped position PKCS as a response to the era's challenges in standardizing cryptography for an increasingly networked world, where interoperability was essential for protocols like Privacy-Enhanced Mail (PEM) and X.509 certificates.^[14]

Evolution and Standardization Transfers

In the mid-1990s, RSA Laboratories began issuing revisions to several PKCS standards to enhance security and address evolving cryptographic needs. A notable example is PKCS #5 version 2.0, released in 2000, which introduced PBKDF2 (Password-Based Key Derivation Function 2) to provide stronger password-to-key derivation mechanisms resistant to brute-force attacks by incorporating iterative hashing and salting.^[15] During the 2000s, RSA Security facilitated the transition of multiple PKCS standards from proprietary development to open international oversight, promoting broader adoption and interoperability. For instance, PKCS #1 was donated to the Internet Engineering Task Force (IETF), with version 2.0 published as RFC 2437 in October 1998 and later updated to version 2.2 as RFC 8017 in November 2016 to incorporate improved padding schemes and algorithm identifiers.^[16]^[3] Similarly, PKCS #11 was transferred to the Organization for the Advancement of Structured Information Standards (OASIS) in December 2012, leading to the development and approval of version 2.40 in April 2015, which expanded support for additional cryptographic mechanisms and token interfaces.^[17]^[18] Corporate acquisitions impacted RSA Security's structure but did not alter the open nature of the PKCS standards, as many had already been transferred to standards bodies. EMC Corporation acquired RSA Security in September 2006 for $2.1 billion, integrating it as a division focused on security solutions.^[19] Subsequently, Dell Technologies acquired EMC in September 2016 for $67 billion, bringing RSA under its portfolio, yet the standards continued to be maintained independently by IETF and OASIS without proprietary restrictions. As of 2025, no new PKCS designations have been issued since PKCS #15 in April 1999, which defines formats for cryptographic token information.^[20] Maintenance efforts by IETF and OASIS emphasize revisions to existing standards, particularly to incorporate quantum-resistant algorithms in response to advancing threats from quantum computing, aligning with broader initiatives like NIST's post-quantum cryptography standardization.

Active Standards

PKCS #1: RSA Cryptography Specifications

PKCS #1, formally known as the RSA Cryptography Specifications, provides standardized mechanisms for implementing public-key cryptography using the RSA algorithm, focusing on secure encryption and digital signature operations. The current version, 2.2, was published in November 2016 as RFC 8017 by the Internet Engineering Task Force (IETF), superseding earlier iterations to address evolving security needs.^[21] Version 1.5, released in March 1998 via RFC 2313, introduced basic RSA encryption and signing but was vulnerable to padding oracle attacks, including the seminal Bleichenbacher attack demonstrated in 1998, which exploited error messages to decrypt ciphertexts adaptively.^[22] These flaws prompted the development of more robust padding schemes in subsequent versions, emphasizing deterministic and probabilistic methods to achieve provable security properties. At its core, PKCS #1 version 2.2 defines RSAES-OAEP (RSA Encryption Scheme - Optimal Asymmetric Encryption Padding) for encryption, which incorporates a feistel-like transformation with a hash function and mask generation to ensure semantic security against chosen-ciphertext attacks. For digital signatures, it specifies RSASSA-PSS (RSA Signature Scheme - Probabilistic Signature Scheme), a randomized padding method that enhances security by avoiding deterministic structures exploitable in forgery attempts. The standard also outlines supporting encoding primitives: EME (Encryption Method Encoding) for preparing messages before encryption and EMSA (Encoding Method for Signature Append) for formatting digests prior to signing, both leveraging cryptographic hash functions like SHA-256.^[21] The mathematical foundations of PKCS #1 rely on the RSA problem's hardness. Key generation involves selecting two large, distinct prime numbers p and q, computing the modulus n = p \times q, selecting a public exponent e such that $1 < e < \phi(n) and \gcd(e, \phi(n)) = 1 where \phi(n) = (p-1)(q-1), and computing the private exponent d as d \equiv e^{-1} \pmod{\phi(n)}. Encryption transforms a padded message representative m (where $0 \leq m < n) into ciphertext c = m^e \mod n, with decryption recovering m = c^d \mod n. These operations assume proper padding to handle message expansion and prevent information leakage.^[21] Security in PKCS #1 is bolstered by its padding schemes, which mitigate attacks like Bleichenbacher's by eliminating distinguishable error responses and ensuring indistinguishability under adaptive chosen-ciphertext attacks when using OAEP. The standard recommends RSA key sizes of at least 2048 bits for general use as of 2025, providing approximately 112 bits of security, with larger moduli (e.g., 3072 or 4096 bits) advised for long-term protection against advances in factoring algorithms.^[21] Unique to the specification are backward compatibility modes, such as RSAES-PKCS1-v1_5 and RSASSA-PKCS1-v1_5, which retain legacy padding for interoperability while strongly favoring the modern OAEP and PSS variants for new implementations to achieve semantic security and existential unforgeability. It may integrate password-based keys derived via mechanisms from PKCS #5 for hybrid scenarios.^[21]

PKCS #5: Password-Based Cryptography Standard

PKCS #5, formally known as the Password-Based Cryptography Standard, defines mechanisms for deriving secret keys from passwords and using those keys to encrypt octet strings, primarily to enable secure password-based access to encrypted data. The standard's version 2.1, published as RFC 8018 in January 2017, obsoletes version 2.0 from RFC 2898 (September 2000) and introduces minor clarifications while maintaining the core structures. Earlier version 1.5, revised in May 1991 and published in November 1993, provided simpler password-based encryption schemes but relied on now-insecure components. At the heart of PKCS #5 versions 2.0 and 2.1 is the Password-Based Key Derivation Function 2 (PBKDF2), which produces a pseudorandom key from a password by iteratively applying a pseudorandom function (PRF), typically HMAC with a hash like SHA-1 or SHA-256. PBKDF2 computes the derived key as the concatenation of multiple blocks, where each block F(P, S, c, i) is generated by initializing U_1 = \text{PRF}(P, S \Vert \text{INT}(i)) and iterating U_{j+1} = \text{PRF}(P, U_j) for j = 1 to c-1, with F = U_c and INT(i) denoting the four-octet big-endian encoding of the block index i. This process applies the PRF c times per block to increase computational cost, yielding the final key truncated to the desired length. Key parameters for PBKDF2 include a salt of at least eight octets to thwart dictionary attacks via precomputed tables, an iteration count c with a minimum of 1,000 (and preferably much higher, such as 100,000 or more in modern implementations, to resist brute-force attempts), and a configurable output key length in octets. The PRF supports flexible choices, such as HMAC-SHA256, allowing adaptation to stronger hash functions over time. In practice, PBKDF2 enables the Password-Based Encryption Scheme 2 (PBES2) within PKCS #5, which pairs the key derivation with a symmetric encryption algorithm—such as AES in CBC mode—and an optional initialization vector derived similarly, to protect data streams using only a password for key generation. PKCS #5 mechanisms, including PBES2, integrate with PKCS #8 to encrypt private keys in a portable, password-secured format. Security in PKCS #5 hinges on PBKDF2's deliberate computational slowness, enforced by the iteration count, which forces attackers to expend significant resources per password trial and thus elevates the effective entropy of weak user-chosen passwords. Version 1.5 has been deprecated due to its dependence on vulnerable hash functions like MD2 and MD5 in key derivation and its support for short keys, making it susceptible to modern cryptanalytic attacks.

PKCS #7: Cryptographic Message Syntax Standard

PKCS #7, formally known as the Cryptographic Message Syntax Standard, defines a syntax for cryptographically protected messages that supports digital signing, encryption, digestion, and authentication of arbitrary content.^[23] Originally published by RSA Laboratories in version 1.5 in November 1993, it was later standardized by the IETF as RFC 2315 in 1998 and updated in RFC 5652 in September 2009 to address evolving security needs, including support for additional algorithms and content types.^[23] The standard uses the MIME type application/pkcs7-mime for transporting these messages, enabling integration with protocols like email.^[24] The core data types in PKCS #7 include SignedData, which encapsulates content along with digital signatures and signer information for integrity and authenticity verification; EnvelopedData, which encrypts content for specific recipients using their public keys; DigestedData, which computes and includes a one-way hash of the content without signing; EncryptedData, which provides symmetric encryption of content without recipient-specific key management; and AuthenticatedData, which applies a message authentication code (MAC) for integrity protection alongside optional encryption.^[23] These types are structured using Abstract Syntax Notation One (ASN.1) with Distinguished Encoding Rules (DER) for unambiguous binary representation, ensuring interoperability across systems.^[23] The overall message format consists of a content info wrapper that identifies the data type, optionally including certificates, certificate revocation lists (CRLs), and signer attributes; it supports multiple signers per message and nested signing through countersignatures.^[23] PKCS #7 integrates cryptographic algorithms such as RSA encryption from PKCS #1 for signatures and key transport, along with hash functions like SHA-256 for digests.^[23] Key management in types like EnvelopedData uses recipient information structures, which can employ key-encryption keys (KEKs) for symmetric wrapping or key agreement protocols for deriving shared secrets.^[23] Signer attributes may reference types defined in PKCS #9, such as signing time or content hints.^[23] A distinctive feature of PKCS #7 is its support for detached signatures in SignedData, where the original content is omitted from the structure and provided separately during verification, making it suitable for applications like code signing.^[23] It forms the foundation for S/MIME (Secure/Multipurpose Internet Mail Extensions), which applies these mechanisms to secure email messages by wrapping MIME entities in CMS structures.^[24]

PKCS #8: Private-Key Information Syntax Standard

PKCS #8, formally known as the Private-Key Information Syntax Standard, provides a standardized Abstract Syntax Notation One (ASN.1) syntax for encoding private keys associated with public-key algorithms, enabling secure storage and transport of such keys. Originally published by RSA Laboratories as version 1.2 in November 1998, the specification was republished by the Internet Engineering Task Force (IETF) as RFC 5208 in May 2008 to describe the unencrypted private-key information syntax. This was further updated and extended in RFC 5958, published in August 2010, which incorporates enhancements for encrypted private keys and defines corresponding Cryptographic Message Syntax (CMS) content types.^[25] The primary structure for unencrypted private keys is the PrivateKeyInfo type, defined as an ASN.1 SEQUENCE comprising a version number (set to 0), a PrivateKeyAlgorithmIdentifier (an AlgorithmIdentifier specifying the public-key algorithm OID and any associated parameters), the private key itself encoded as an OCTET STRING, and optional attributes. This format supports generic encoding of private keys for algorithms including RSA, DSA, and elliptic curve (EC) cryptography, with the OCTET STRING allowing algorithm-specific internal structures while maintaining interoperability. For completeness in the updated specification, the OneAsymmetricKey variant (which supersedes PrivateKeyInfo) optionally includes public key information derived from the same algorithm parameters.^[25] To enable protection of private keys, PKCS #8 defines the EncryptedPrivateKeyInfo structure as an ASN.1 SEQUENCE containing an EncryptionAlgorithmIdentifier (specifying the encryption scheme and parameters) and the encrypted data as an OCTET STRING.^[25] Encryption employs password-based encryption schemes (PBES) derived from PKCS #5, where a symmetric key is generated from a user-provided password using key derivation functions.^[25] The standard recommends robust combinations, such as AES-256 in CBC mode paired with PBKDF2 for key derivation, to mitigate risks from weak passwords or brute-force attacks.^[25] PKCS #8 distinguishes between generic private key syntax, suitable for broad interoperability, and algorithm-specific extensions within the private key OCTET STRING, allowing detailed parameters for particular key types without altering the outer structure. This design forms the basis for more comprehensive formats, such as PKCS #12, which bundles private keys with certificates and other data for personal information exchange. Security relies on the strength of the underlying encryption; implementers must avoid deprecated algorithms like DES and ensure sufficient iteration counts in password-based key derivation to resist offline attacks.^[25]

PKCS #9: Selected Object Classes and Attribute Types

PKCS #9, formally known as Selected Object Classes and Attribute Types Version 2.0, defines a collection of attribute types and object classes intended for use in public-key cryptography applications, particularly in conjunction with directory services like LDAP and other PKCS standards.^[26] Published as RFC 2985 in November 2000, it represents a republication of the RSA Laboratories' PKCS #9 specification under IETF auspices, with change control retained by RSA Security Inc., which was acquired by a consortium led by [Symphony Technology Group](/page/Symphony Technology Group) in 2020.^[26]^[27] The standard focuses on providing standardized ways to associate metadata, such as identifiers and cryptographic parameters, with certificates, keys, and messages, enhancing interoperability in secure communications and identity management.^[26] At its core, PKCS #9 specifies attribute types categorized by their application contexts, including those for entity identification, cryptographic operations, and S/MIME support. Examples of attribute types include emailAddress (an IA5String for electronic mail addresses), unstructuredName (a sequence of IA5Strings for human-readable names), contentType (an OBJECT IDENTIFIER indicating the type of signed or enveloped data), and messageDigest (an OCTET STRING holding a message digest).^[28] For directory services, it defines auxiliary object classes such as pkcsEntity (to hold PKCS-related attributes for entities like certification authorities or users) and naturalPerson (for personal attributes like dateOfBirth or countryOfCitizenship).^[29] These elements enable the extension of X.500 directory entries with cryptography-specific information without altering core schema structures.^[26] The attributes in PKCS #9 are encoded using ASN.1 notation, specifically as a SEQUENCE comprising an OBJECT IDENTIFIER for the attribute type and a SET OF ANY for its values, allowing flexible multi-valued representations.^[30] This structure, detailed in the PKCS-9 ASN.1 module, supports extensions through the use of registered object identifiers under the pkcs-9 arc (1.2.840.113549.1.9), permitting custom attribute types while maintaining compatibility.^[30] For instance, the challengePassword attribute (type 1.2.840.113549.1.9.7) uses a sequence of printable strings for authentication in key generation processes.^[31] PKCS #9 integrates seamlessly with other standards by providing reusable attribute definitions; for example, it supplies contentType and messageDigest for signerInfo fields in PKCS #7 signed messages.^[32] Similarly, attributes like friendlyName and localKeyId are employed in PKCS #12 for identifying safe contents within personal information exchange structures.^[33] Among its updates from prior versions, PKCS #9 v2.0 introduces the smimeCapabilities attribute (type 1.2.840.113549.1.9.15), a sequence of capabilities indicating S/MIME algorithm preferences, such as support for specific encryption or signing algorithms.^[34] It also adds signingDescription (type 1.2.840.113549.1.9.13) as a human-readable string describing signing operations for S/MIME contexts.^[34] Deprecations include the extendedCertificateAttributes type (1.2.840.113549.1.9.4), which was tied to the historic PKCS #6 extended-certificate syntax and is no longer recommended for use.^[31] While the standard itself does not explicitly deprecate weak hash algorithms like MD2, subsequent cryptographic guidance in related RFCs discourages their use in PKCS #9 attributes such as messageDigest due to vulnerability concerns.^[32]

PKCS #10: Certification Request Syntax Standard

PKCS #10, formally known as the Certification Request Syntax Specification, defines a standardized syntax for certification requests used in public key infrastructure (PKI) to request X.509 certificates from a certification authority (CA).^[35] Version 1.7 of the standard was published in November 2000 as RFC 2986 by the Internet Engineering Task Force (IETF), representing a republication of the original PKCS #10 from RSA Laboratories with change control retained by RSA Security Inc.^[35] This version remains the current specification, with no major updates or obsoletions, though minor extensions have been incorporated in related protocols for enhanced functionality.^[35] The core structure of a PKCS #10 certification request is defined using Abstract Syntax Notation One (ASN.1) as a CertificationRequest sequence, consisting of certificationRequestInfo, signatureAlgorithm, and signature components.^[35] The certificationRequestInfo field is itself a sequence that includes a version number (fixed at v1(0)), the subject's distinguished name (DN), subject public key information (including the algorithm identifier and public key bit string), and an optional attributes field derived from PKCS #9 for additional metadata.^[35] The signatureAlgorithm specifies the cryptographic algorithm used (typically from PKCS #1, such as RSA with SHA-1), and the signature is a bit string computed over the certificationRequestInfo using the subject's private key to ensure integrity and authenticity.^[35] In the certification request process, the subject first generates an asymmetric key pair, then constructs the certificationRequestInfo with their DN and public key, optionally including attributes such as a challengePassword for authentication during revocation.^[35] The subject signs the request with their private key and transmits it to the CA, which verifies the signature, validates the request details, and—if approved—issues a corresponding X.509 certificate binding the public key to the subject's identity.^[35] This process supports extensions via PKCS #9 attributes, such as those indicating key usage or certificate policies, allowing customization without altering the core syntax.^[35] PKCS #10 requests are commonly transported using the MIME media type application/pkcs10, as registered in RFC 5967, facilitating integration in email and web-based submissions.^[36] From a security perspective, the standard ensures the authenticity of the public key binding to the subject's identity through the self-signature, mitigating risks of unauthorized certificate issuance while relying on the CA for trust anchoring.^[35] It is widely implemented in tools like OpenSSL, where the req command generates PKCS #10-formatted certificate signing requests (CSRs) for X.509 certificates.^[37]

PKCS #11: Cryptographic Token Interface

PKCS #11, formally known as the Cryptographic Token Interface and also referred to as Cryptoki, is a platform-independent application programming interface (API) designed for managing cryptographic operations on hardware security modules (HSMs), smart cards, and other cryptographic tokens.^[38] Originally developed by RSA Laboratories as version 1.0 in April 1995, the standard has evolved through multiple revisions, with version 2.40 published in 2015 and the current version 3.1 approved by OASIS on July 23, 2023.^[38]^[39] In December 2012, maintenance of the standard was transferred from RSA Security to the OASIS PKCS #11 Technical Committee to ensure ongoing development and broader industry adoption.^[40] The architecture of PKCS #11 employs a layered model that separates applications from underlying cryptographic hardware, providing abstraction through concepts such as slots (interfaces to devices), tokens (logical cryptographic units), sessions (user interactions with tokens), and objects (entities like keys and certificates defined by attributes, e.g., CKA_CLASS for object type and CKA_LABEL for identification).^[38] Implemented in the C programming language, the API includes function groups for various operations: general-purpose functions like C_Initialize (to start the library) and C_Finalize (to shut it down); slot and token management with C_GetSlotList (to enumerate available slots) and C_GetTokenInfo (to retrieve token details); session handling via C_OpenSession (to establish a session) and C_Login (for authentication); object management including C_CreateObject and C_SetAttributeValue; key generation with C_GenerateKey and C_GenerateKeyPair; encryption/decryption using C_EncryptInit, C_Encrypt, C_DecryptInit, and C_Decrypt; and signing/verification through C_SignInit, C_Sign, C_VerifyInit, and C_Verify.^[38] This structure enables secure, hardware-accelerated cryptographic tasks while isolating applications from device-specific implementations.^[38] PKCS #11 supports a wide range of cryptographic mechanisms, categorized into asymmetric algorithms like RSA (including encryption, signing, and key wrapping as specified in PKCS #1), elliptic curve cryptography (ECC) such as ECDSA and ECDH, and DSA; symmetric algorithms including AES (in modes like ECB, CBC, GCM with key sizes of 128, 192, or 256 bits), DES, and ChaCha20; hashing functions such as SHA-256 and SHA3-256; and key derivation methods like HKDF and PBKDF2.^[38] Unique features include multi-threaded operation support via mutex functions like CK_CREATEMUTEX for concurrent access, full hardware abstraction to promote portability across devices, and token identification using PKCS #11 URIs introduced in version 2.40 and beyond for easier integration in distributed systems.^[38]^[41] The standard is maintained by the OASIS PKCS #11 Technical Committee, which continues to update it for emerging security needs, such as enhanced support for post-quantum cryptography profiles.^[42] It finds widespread application in software ecosystems, including web browsers like Firefox for interfacing with cryptographic modules during secure sessions and protocol implementations such as TLS.^[38]

PKCS #12: Personal Information Exchange Syntax Standard

PKCS #12, formally known as the Personal Information Exchange Syntax Standard, defines a file format for securely storing and transferring personal identity information, such as private keys, certificates, and miscellaneous secrets, in a single encrypted and optionally signed archive.^[43] The standard originated with version 1.0, published by RSA Laboratories in June 1999, and was updated to version 1.1 in July 2014 as RFC 7292 by the Internet Engineering Task Force (IETF), incorporating enhancements for improved security and compatibility.^[43] This format enables the bundling of cryptographic objects for export and import in applications like web browsers, email clients, and digital wallets, facilitating secure key management across systems.^[43] The core structure of a PKCS #12 file, known as a PFX (Personal Information Exchange), is an ASN.1 SEQUENCE consisting of the version and an AuthenticatedSafe, which is itself a SEQUENCE of ContentInfo structures that may be individually encrypted or signed.^[43] The AuthenticatedSafe contains one or more SafeContents bags, each a SEQUENCE of SafeBag objects that encapsulate the actual data, along with optional attributes.^[43] Integrity of the entire PFX is protected by a MAC (Message Authentication Code) generated using PBKDF2 (Password-Based Key Derivation Function 2, from PKCS #5) with supported hash algorithms including SHA-1, SHA-256, SHA-384, and SHA-512.^[43] Encryption employs PBES2 (Password-Based Encryption Scheme 2) for password-based protection of sensitive contents.^[43] Key bag types include CertBag for holding X.509 certificates, KeyBag for private keys formatted according to PKCS #8, and SecretBag for arbitrary secrets not covered by other types; these bags support attributes such as friendly names for user identification and localKeyID for associating keys with certificates.^[43] SafeContents bags allow grouping multiple items, with each SafeBag optionally encrypted individually.^[43] Common file extensions for PKCS #12 files are .p12 and .pfx, which are password-protected to ensure confidentiality during storage and transport.^[43] Version 1.1 introduces support for stronger ciphers, such as AES in various key lengths (e.g., AES-128-CBC, AES-256-CBC), alongside legacy options, to enhance protection against brute-force attacks.^[43] However, the standard warns against using outdated algorithms like RC2 due to their vulnerability to cryptanalytic attacks, recommending modern alternatives for new implementations to maintain robust security.^[43]

PKCS #15: Cryptographic Token Information Format

PKCS #15, formally known as the Cryptographic Token Information Syntax Standard, defines a platform-neutral syntax for representing security-related information on cryptographic tokens, such as smart cards, to facilitate interoperability across applications and platforms.^[44] Version 1.1 of the standard was published in 2000 by RSA Laboratories, superseding version 1.0 from 1999, and it remains an active standard with ongoing updates to address modern needs like biometrics and software tokens.^[44]^[45] The standard is frequently paired with PKCS #11 to provide a metadata layer that enables portable access to token contents without specifying the underlying physical storage.^[44] At its core, PKCS #15 employs a logical model that organizes token data into abstract objects, independent of the token's file system or hardware. The TokenInfo structure serves as the primary entry point, containing essential metadata such as a human-readable label (encoded in UTF-8), the manufacturer's identifier (via an object identifier or OID), the token's serial number, supported algorithms, and flags indicating features like read-only access or login requirements.^[44] Logical objects include PrivateKeyObject and PublicKeyObject for asymmetric keys, CertificateObject for digital certificates (supporting formats like X.509), DataObject for arbitrary data, and AuthenticationObject for access controls.^[44] These objects share common attributes, such as CKA_ID for unique identification and CKA_TRUSTED to denote trusted status, while specific attributes define usage (e.g., decrypt, sign for keys) and value encodings.^[44] The standard is encoded using Abstract Syntax Notation One (ASN.1) with Distinguished Encoding Rules (DER) for compactness and portability, allowing objects to be stored in a hierarchical file system on the token.^[44] Elementary Files (EFs) form the basis of this structure: EF(TokenInfo) holds the token metadata, EF(ODF) (Object Directory File) lists directories for different object types, and specialized EFs like EF(PrKDF) for private keys, EF(CDF) for certificates, EF(DODF) for data, and EF(AODF) for authentication objects manage respective contents.^[44] An optional EF(DIR) provides a directory of supported applications on the token.^[44] PIN management is handled through AuthenticationObject, which supports multiple authentication methods including PINs (with attributes like minimum length and padding character) and biometrics, enabling security domains for role-based access control.^[44] PKCS #15 integrates seamlessly with PKCS #11 by mapping its attributes and object types to the token interface, allowing applications to discover and manipulate token data uniformly.^[44] It is widely applied in smart cards to ensure compliance with ISO/IEC 7816 standards for integrated circuit cards, promoting secure storage and retrieval of credentials in environments like public key infrastructure.^[44] A key unique aspect is its extensibility, achieved through optional ASN.1 fields and vendor-specific OIDs, which permit customization without breaking interoperability.^[44]

Legacy Standards

PKCS #3: Diffie-Hellman Key Agreement Standard

PKCS #3, formally titled the Diffie-Hellman Key-Agreement Standard, is a legacy cryptographic standard developed by RSA Laboratories that outlines a method for two parties to establish a shared secret key over an insecure channel without prior shared secrets.^[46] Published in version 1.4 and revised on November 1, 1993, it builds on the foundational Diffie-Hellman protocol introduced in 1976, providing syntax and parameters for practical implementation in secure communication protocols, such as those at the OSI transport or network layers.^[46] The standard emphasizes key agreement but excludes details on key interpretation, random number generation, or higher-level protocol integration.^[46] The mechanism defines key parameters including a large odd prime p, a generator g (where $0 < g < p), and an optional private-value length l in bits, ensuring $2^{l-1} \leq p if specified.^[46] In the exchange process, each party generates a private value (e.g., x) and computes a public value y = g^x \mod p, which is exchanged; the shared secret z is then derived as z = (g^y)^x \mod p = g^{xy} \mod p.^[46] The structure employs an AlgorithmIdentifier ASN.1 type with the object identifier dhKeyAgreement (OID 1.2.840.113549.1.3.1) to encode the parameters p, g, and l, supporting both ephemeral (temporary keys) and static (long-term keys) Diffie-Hellman variants for flexibility in deployment.^[46] PKCS #3's withdrawal stems from its restriction to unauthenticated key agreement, exposing it to man-in-the-middle attacks without complementary authentication like digital signatures, and its lack of provisions for advanced features in evolving standards.^[47] It has been superseded by ANSI X9.42 for enhanced Diffie-Hellman specifications and later by IETF RFC 2631, which provides a more comprehensive framework including key derivation functions.^[48] Historically, it enabled early Diffie-Hellman adoption in virtual private networks (VPNs) through protocols like Internet Key Exchange (IKE); today, it is largely supplanted by Elliptic Curve Diffie-Hellman (ECDH) in modern systems for superior performance with smaller key sizes.^[49]^[50]

PKCS #6: Extended-Certificate Syntax Standard

PKCS #6, formally known as the Extended-Certificate Syntax Standard, defines a syntax for augmenting X.509 public-key certificates with additional attributes to support enhanced functionality in public key infrastructures. Published in version 1.5 and revised on November 1, 1993, by RSA Laboratories, it was developed to address limitations in the original X.509 version 1 format, which lacked a mechanism for including optional extensions or attributes directly within the certificate structure.^[51] The core structure of an extended certificate under PKCS #6 is specified using Abstract Syntax Notation One (ASN.1) as a sequence comprising three primary components: the extended certificate information, the signature algorithm identifier, and the signature itself. The extended certificate information is itself a sequence that includes a version number (an integer indicating the syntax version), the base X.509 certificate (encompassing fields such as serial number, signature algorithm, issuer, validity period, subject, and subject public key), and a set of attributes. These attributes are drawn from PKCS #9 and form a set of attribute type-value pairs, allowing for the inclusion of supplementary data like electronic mail addresses or other object classes without altering the underlying X.509 certificate. The entire extended certificate is then signed to ensure integrity and authenticity in a single verification step, making it compatible with standards like Privacy-Enhanced Mail (PEM).^[51] The extensions in PKCS #6 primarily consist of ASN.1-defined attributes intended to provide information beyond the basic fields of X.509 version 1, such as identifying the certificate holder's email address or other selected object classes from PKCS #9. For instance, attributes like the "electronic-mail-address" type enable the association of contact details with the certificate, facilitating applications in directory services or secure messaging. This approach aimed to extend certificate capabilities for uses like attribute certificates in early cryptographic systems, though it predated the more flexible extension mechanisms in later standards.^[51] PKCS #6 was declared obsolete in 1997 due to redundancy with the evolving X.509 standards, particularly the introduction of version 3 certificates that incorporated a dedicated extensions field for similar purposes. The lack of widespread adoption further contributed to its deprecation, as the X.509 version 3 extensions—standardized in ITU-T recommendations and profiled in RFC 5280—provided a more robust and standardized way to include attributes like key usage and basic constraints directly within the certificate structure. Modern implementations, as specified in RFC 5652 and RFC 5750, explicitly prohibit the use of PKCS #6 extended certificates to avoid compatibility issues and ensure alignment with current Internet security practices.^[13]^[52]^[23] In terms of legacy impact, PKCS #6 saw minor usage in systems predating 2000, particularly in early public key infrastructure deployments that required attribute extensions before X.509 version 3 became prevalent. Attribute handling from PKCS #6 influenced subsequent standards, with migrations often directed toward RFC 2985 for selected object classes and attribute types in certification requests under PKCS #10. Today, its syntax elements are largely historical, with no active role in contemporary cryptographic protocols.^[13]^[26]

PKCS #13: Elliptic Curve Cryptography Standard

PKCS #13, formally titled the Elliptic Curve Cryptography Standard, was proposed by RSA Laboratories as part of the Public Key Cryptography Standards (PKCS) series. A proposal was presented by Burt Kaliski at the RSA PKCS Workshop on October 7, 1998.^[53] The specification aimed to establish standardized mechanisms for elliptic curve cryptography (ECC) within the PKCS framework, focusing on interoperability for public-key operations. However, it remained a draft and was never finalized or published as a complete standard, effectively abandoned due to overlapping efforts by other standards bodies. The intended content of PKCS #13 included definitions for key elliptic curve primitives, such as the Elliptic Curve Digital Signature Algorithm (ECDSA) for digital signing and the Elliptic Curve Diffie-Hellman (ECDH) protocol for key agreement. It was to specify curve parameters, key generation procedures, and encoding formats for ECC components, promoting their use in cryptographic applications. Key generation would involve selecting a private key d and computing the public key via scalar multiplication, such as Q = d \cdot G, where G is the base point (generator) on the elliptic curve defined over a prime field with the equation y^2 = x^3 + ax + b \pmod{p}, where p is a large prime and a, b are curve-specific constants ensuring the curve's security properties. The abandonment of PKCS #13 stemmed from duplication of efforts across organizations, as ECC specifications were advanced more effectively elsewhere: the Standards for Efficient Cryptography Group (SECG) released SEC 1 in 2000 covering domain parameters, key generation, ECDSA, and ECDH; NIST incorporated ECDSA into FIPS 186-2 that same year; and ANSI standardized ECDSA via X9.62, while IETF efforts in RFC 3279 (2002) addressed ECC in public key infrastructures.^[54] This convergence rendered a dedicated PKCS standard redundant. Historically, PKCS #13 represented an early industry push by RSA Laboratories to integrate ECC into the PKCS ecosystem, paving the way for its later adoption in standards like PKCS #11 version 2.40, which added comprehensive ECC mechanism support in 2015.^[41]

Applications

Role in Public Key Infrastructure

PKCS standards play a foundational role in Public Key Infrastructure (PKI) by providing standardized syntax and formats for key generation, certificate requests, issuance, distribution, and management, enabling secure identity and trust establishment across diverse systems. Specifically, PKCS #10 defines the syntax for Certification Request Syntax (CSR), allowing entities to submit public keys and distinguished names to Certification Authorities (CAs) for certificate issuance, ensuring interoperability in request processing. PKCS #7, evolved into the Cryptographic Message Syntax (CMS) in RFC 5652, facilitates certificate distribution through signed and enveloped messages, supporting the secure delivery of X.509 certificates from CAs to end entities. Additionally, PKCS #12 specifies a transfer syntax for bundling private keys, certificates, and related secrets, which is essential for CA operations involving the secure export and import of personal identity information during enrollment and renewal processes. A typical PKI workflow leverages multiple PKCS standards for seamless certificate lifecycle management. An entity begins by generating an asymmetric key pair using PKCS #8 syntax for private-key information, which structures the private key in a format compatible with various cryptographic algorithms. The public key is then incorporated into a CSR formatted per PKCS #10, signed using algorithms from PKCS #1 (RSA Cryptography Specifications), and submitted to the CA. Upon validation, the CA issues an X.509 certificate, often enveloped in a PKCS #7/CMS structure for secure transmission, and the end entity stores the private key and certificate chain in a PKCS #12 file for protected archival and transport. These standards interconnect to enhance PKI functionality, with PKCS #9 providing attribute types for embedding policy information, such as extension requests or challenge passwords, directly into CSRs to enforce organizational policies during issuance. Revocation mechanisms rely on PKCS #7/CMS for signing Certificate Revocation Lists (CRLs), allowing relying parties to verify certificate status efficiently within the PKI trust model. In enterprise deployments, such as Microsoft's Active Directory Certificate Services, PKCS #10 is used for generating and submitting CSRs, while PKCS #12 enables the export of key and certificate bundles for distribution to clients, supporting scalability in environments managing thousands of certificates. This interoperability addresses challenges in multi-vendor PKI ecosystems, as seen in DigiCert's (formerly VeriSign) operations, where adherence to PKCS formats ensures consistent handling of requests and responses across internal and external CAs, reducing integration errors in large-scale trust infrastructures.

Integration in Software and Protocols

PKCS standards are widely integrated into cryptographic software libraries to enable secure handling of keys, certificates, and messages. OpenSSL, a prominent open-source toolkit, provides robust support for PKCS #7 through its CMS (Cryptographic Message Syntax) implementation, allowing creation and verification of signed and enveloped data structures, and for PKCS #12 via dedicated commands for generating and parsing personal information exchange files used in certificate transport.^[55]^[56] Similarly, the Bouncy Castle library, a Java-based cryptography API, incorporates PKCS #7 compatibility through its CMS module for email signing and encryption, and supports PKCS #12 keystores for secure storage of private keys and certificates in Java and .NET environments.^[57]^[58] For hardware token interfaces, PKCS11Interop serves as a managed C# wrapper in .NET, facilitating access to PKCS #11-compliant devices for key generation, signing, and encryption operations without direct unmanaged code.^[59] In communication protocols, PKCS standards underpin secure data exchange. The S/MIME protocol, as defined in RFC 8551, relies on CMS derived from PKCS #7 for signed and enveloped messages in secure email, incorporating PKCS #9 attributes such as email addresses for signer identification within signed data structures.^[60]^[61] TLS 1.3, outlined in RFC 8446, utilizes PKCS #1 for RSASSA-PSS padding in RSA-based digital signatures during certificate verification and optional static RSA key exchange.^[62]^[63] Hardware security modules (HSMs) and smart cards embed PKCS for compliant cryptographic operations. Thales nShield HSMs implement PKCS #11 as a standardized interface for token access and key management, ensuring FIPS 140-2/3 compliance through validated firmware modes that restrict operations to approved algorithms.^[64]^[65] Smart cards adhere to PKCS #15 for structuring cryptographic token information, enabling applet-based storage of certificates, keys, and PINs in a portable format compatible with middleware like OpenSC.^[66] Practical examples illustrate PKCS deployment. Web browsers such as Chrome and Firefox support importing PKCS #12 files to manage personal certificates for client authentication, allowing users to load private keys and chains directly into the browser's certificate store.^[67] The Android Keystore API offers partial compatibility with PKCS #11, enabling integration with hardware tokens for APK signing and key operations via provider extensions, though it abstracts full token management for mobile security.^[68] Looking ahead, libraries are evolving to address quantum threats. OpenSSL 3.0 and later incorporate post-quantum algorithms through providers like liboqs, extending PKCS #1-compatible structures to support hybrid schemes such as ML-KEM for key encapsulation in revised certification requests.^[69]^[70]

References

[1]
[PDF] An Overview of the PKCS Standards
This note gives an overview of the PKCS family of standards for public-key cryptography. These standards cover RSA encryption, Diffie-Hellman key agreement, ...<|control11|><|separator|>
[2]
[PDF] Introduction to the PKCS Standards
The following table lists the currently active PKCS standards. PKCS # 1 The RSA encryption standard. This standard defines mechanisms for encrypting and ...
[3]
RFC 8017 - PKCS #1: RSA Cryptography Specifications Version 2.2
This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC ...
[4]
PKCS#11 Cryptographic Token Interface Base Specification OASIS ...
PKCS #11 defines the Cryptoki interface, a standard for a cryptographic token, which is a device storing cryptographic information.
[5]
What are Public-Key Cryptography Standards (PKCS)? - TechTarget
Jan 11, 2022 · Public-Key Cryptography Standards (PKCS) are standards developed to enable secure information exchange via a public key infrastructure.
[6]
SSL/TLS Strong Encryption: An Introduction - Apache HTTP Server
The binary format of a certificate is defined using the ASN.1 notation [ASN1] [PKCS]. This notation defines how to specify the contents and encoding rules ...Missing: modern | Show results with:modern
[7]
Operating in compliance with FIPS 140-2 - IBM
z/OS PKCS #11 cryptography is designed to meet FIPS 140-2 Level 1 criteria, and can be configured to operate in compliance with FIPS 140-2 specifications.
[8]
RFC 7292 - PKCS #12: Personal Information Exchange Syntax v1.1
PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions.
[9]
What is CSP and PKCS#11? - Encryption Consulting
Jun 12, 2024 · Importance of PKCS#11 PKCS#11 streamlines secure communication between applications and cryptographic hardware, making it easier to protect ...
[10]
Introducing PKCS #11 - Standard Plan - IBM Cloud Docs
The PKCS #11 API provides the Dilithium algorithm for post-quantum cryptography. It is a lattice-based digital signature scheme and can be used for signature ...
[11]
PQC Capabilities Matrix (PQCCM) - PKI Consortium
The PKI Consortium is actively working to promote the adoption of Post-Quantum Cryptography, and the capabilities matrix is a key part of that effort. What the ...
[12]
(PDF) An Overview of the PKCS Standards - ResearchGate
This note gives an overview of the PKCS family of standards for public-key cryptography. These standards cover RSA encryption, Diffie-Hellman key agreement, ...
[13]
[PDF] Public-Key Cryptography Standards: PKCS
PKCS standards are a set of standards, #1 through #15, covering RSA encryption, signature, password-based encryption, and more, published by RSA Laboratories.
[14]
Burt Kaliski Jr. '84, SM '87, PhD '88 | MIT Technology Review
Oct 24, 2012 · As chief scientist at RSA Laboratories, Kaliski led the development of the Public-Key Cryptography Standards (PKCS), among the earliest tools for better ...Missing: origins | Show results with:origins
[15]
RFC 2898 - PKCS #5: Password-Based Cryptography Specification ...
PKCS #5: Password-Based Cryptography Specification Version 2.0. Document, Document type, RFC - Informational September 2000. View errata Report errata.
[16]
RFC 2437 - PKCS #1: RSA Cryptography Specifications Version 2.0
RFC 2437 provides recommendations for RSA-based public-key cryptography, covering cryptographic primitives, encryption, signature schemes, and ASN.1 syntax.
[17]
PKCS#11: Cryptographic Token Interface Standard
The PKCS#11 mailing lists remain unavailable as of July 2015. These RSA Security Inc. Public-Key Cryptography Standards (PKCS) documents were produced from the ...
[18]
PKCS #11 Cryptographic Token Interface Base Specification ...
PKCS #11 Cryptographic Token Interface Base Specification Version 2.40 Errata 01. Edited by Robert Griffin, and Tim Hudson. 13 May 2016. OASIS Approved Errata.
[19]
EMC Completes RSA Security Acquisition Announces ... - Dell
Sep 18, 2006 · RSA Security stockholders approved the acquisition on Thursday, September 14, 2006. EMC also announced it has signed a definitive agreement to ...
[20]
PKCS #15 - a cryptographic token information format standard
May 10, 1999 · {19} RSA Laboratories, "PKCS #15: Cryptographic Token Information Format Standard," version 1.0, April 1999 (Available from ftp://ftp.rsa.com/ ...
[21]
RFC 8017: PKCS #1: RSA Cryptography Specifications Version 2.2
This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm.
[22]
RFC 2313: PKCS #1: RSA Encryption Version 1.5
PKCS #6 RSA Laboratories. PKCS #6: Extended-Certificate Syntax. Version 1.5 ... 1991 initial public release of PKCS. Version 1.4 was published as NIST ...Missing: origins | Show results with:origins
[23]
RFC 5652 - Cryptographic Message Syntax (CMS) - IETF Datatracker
This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message ...
[24]
RFC 8551: Secure/Multipurpose Internet Mail Extensions (S/MIME ...
Media Type for application/pkcs7-mime Type name: application Subtype Name: pkcs7-mime Required Parameters: NONE Optional Parameters: smime-type name ...
[25]
RFC 5958: Asymmetric Key Packages
This document defines the syntax for private-key information and a Cryptographic Message Syntax (CMS) [RFC5652] content type for it.
[26]
RFC 2985 - PKCS #9: Selected Object Classes and Attribute Types ...
RFC 2985 defines object classes and attribute types for public-key cryptography, LDAP, and includes new classes pkcsEntity and naturalPerson.
[27]
https://www.dell.com/en-us/dt/corporate/newsroom/announcements/detailpage.press-releases~usa~2020~02~20200218-redstone.htm
[28]
https://datatracker.ietf.org/doc/html/rfc2985#section-5.1
[29]
https://datatracker.ietf.org/doc/html/rfc2985#section-4
[30]
https://datatracker.ietf.org/doc/html/rfc2985#appendix-A
[31]
https://datatracker.ietf.org/doc/html/rfc2985#section-5.3
[32]
https://datatracker.ietf.org/doc/html/rfc2985#section-5.2
[33]
https://datatracker.ietf.org/doc/html/rfc2985#section-5.4
[34]
RFC 2986 - PKCS #10: Certification Request Syntax Specification ...
RFC 2986 describes a syntax for certification requests, which include a distinguished name, public key, and optional attributes, sent to a certification ...
[35]
RFC 5967: The application/pkcs10 Media Type
This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986.
[36]
req command - OpenSSL
No information is available for this page. · Learn why
[37]
[PDF] pkcs11-spec-v3.1-os.pdf - PKCS #11 Specification Version 3.1
Jul 23, 2023 · This document defines data types, functions and other basic components of the PKCS #11 Cryptoki interface. Page 2. pkcs11-spec-v3.1-os. 23 July ...
[38]
[PDF] PKCS #11: Cryptographic Token Interface Standard - Cryptsoft
Apr 28, 1995 · PC Card Standard. Release. 2.1, July 1993. PKCS #1. RSA Laboratories. RSA Encryption Standard. Version 1.5, November 1993.
[39]
Public-Key Cryptography Standard (PKCS) #11 v 3.0 has ... - Red Hat
Dec 9, 2020 · In 2012, RSA turned the standard over to the OASIS PKCS #11 working group, which released the first new version of the standard in 2015. Since ...
[40]
OASIS PKCS 11 TC
The Technical Committee has produced four new OASIS Standards, encompassing PKCS11 version 3.0. PKCS #11 Cryptographic Token Interface Base Specification ...Announcements · Overview · Technical Work Produced by...
[41]
RFC 7292: PKCS #12: Personal Information Exchange Syntax v1.1
### Summary of RFC 7292: PKCS #12 v1.1
[42]
[PDF] PKCS #15 v1.1: Cryptographic Token Information Syntax Standard
Dec 1, 2021 · First published in 1991 as a result of meetings with a small group of early adopters of public-key technology, the. PKCS documents have become ...
[43]
draft-gutmann-pkcs15-03 - PKCS #15 Updates - IETF Datatracker
Aug 17, 2025 · ... standards. Since the standard, including the updates, remains in active use today, this document gathers the updates in a single location ...
[44]
[PDF] PKCS #3: Diffie-Hellman Key-Agreement Standard - TeleTrusT
This standard describes a method for implementing Diffie-Hellman key agreement, whereby two parties, without any prior arrangements, can agree upon a secret ...
[45]
RFC 2631: Diffie-Hellman Key Agreement Method
Diffie-Hellman is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary ...
[46]
[PDF] Public-Key Cryptography Standards: PKCS - arXiv
Jul 23, 2012 · Cryptographic standards serve two important goals: making different implementations interoperable and avoid- ing various known pitfalls in ...
[47]
Cryptographic Advancements Enabled by Diffie–Hellman - ISACA
Jun 6, 2024 · Internet Key Exchange (IKE)—IKE is a protocol for virtual private network (VPN) connections that uses the Diffie–Hellman algorithm to create a ...
[48]
Java Security Standard Algorithm Names - Oracle Help Center
Diffie-Hellman Key Agreement as defined in PKCS #3: Diffie-Hellman Key-Agreement Standard, RSA Laboratories, version 1.4, November 1993. ECDH, Elliptic Curve ...
[49]
[PDF] PKCS #6: Extended-Certificate Syntax Standard
Nov 1, 1993 · This section gives the syntax for extended certificates. An extended certificate consists of three parts: "extended-certificate information,".Missing: obsolescence | Show results with:obsolescence
[50]
RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and ...
1. Authority Key Identifier The authority key identifier extension provides a means of identifying the public key corresponding to the private key used to sign ...
[51]
US7925898B2 - Systems and methods using cryptography to protect ...
... PKCS #13: Elliptic Curve Crytography Standard, RSA Security, Jan. 12, 1998. PKCS #15 v 1.0: Cryptographic Token Information Format Standard, RSA ...<|control11|><|separator|>
[52]
[PDF] Frequently A s ked Questions about To d ay 's Cry p t o g ra p h y
This document is Version 4.1 of RSA Laboratories' Frequently Asked Questions About Today's Cryptography, a minor editorial update of Version 4.0 from 1998.
[53]
http://ftp.arnes.si/packages/crypto-tools/rsa.com/pkcs/98workshop/pkcs13_proposal.ppt.gz
[54]
[PDF] SEC 1: Elliptic Curve Cryptography
Sep 20, 2000 · X9.63 is only a draft standard, and partly so that the use of ... Standards for Efficient Cryptography Group, September, 2000. Working ...
[55]
openssl-pkcs7
This command processes PKCS#7 files. Note that it only understands PKCS#7 v 1.5 as specified in IETF RFC 2315. It cannot currently parse CMS as described in ...Missing: support | Show results with:support
[56]
openssl-pkcs12 - OpenSSL Documentation
This command allows PKCS#12 files (sometimes referred to as PFX files) to be created and parsed. PKCS#12 files are used by several programs including Netscape, ...
[57]
Introduction to BouncyCastle with Java | Baeldung
Oct 28, 2017 · CMS/PKCS7 Encryption and Decryption. In asymmetric encryption cryptography, each communication requires a public certificate and a private key.<|separator|>
[58]
Bouncy Castle FIPS mode for PKCS#12 KeyStore Format
Aug 11, 2020 · Does Bouncy Castle FIPS support "PKCS12" as KeyStore/trustStore? I read somewhere that in the approved mode it doesn't support PKCS#12 ...bouncycastle - PKCS12 - Bouncy Castle FIPS Mode - Stack OverflowHow do I repackage certificates into pkcs #7 certificate using bouncy ...More results from stackoverflow.com
[59]
Managed .NET wrapper for unmanaged PKCS#11 libraries - GitHub
Pkcs11Interop is a managed library written in C# that brings the full power of the PKCS#11 API to the .NET environment. It loads the unmanaged PKCS#11 library ...Pkcs11Interop · Issues 13 · Pkcs11-logger · Releases 21
[60]
RFC 8551 - Secure/Multipurpose Internet Mail Extensions (S/MIME ...
RFC 8551 defines S/MIME 4.0, which provides a way to send secure MIME data using digital signatures for authentication and encryption for confidentiality.
[61]
Email Security: S/MIME - SpringerLink
Nov 26, 2022 · S/MIME is a standard to encrypt and digitally sign e-mails, which is fully compatible with the MIME data format. It uses PKCS#7/CMS as cryptographic data ...
[62]
RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet.
[63]
TLS 1.3 Status - BearSSL
RSA/PSS: When using RSA signatures, TLS 1.3 now uses PSS (specified in PKCS#1 version 2.1 and later) instead of the old-style “v1.5” format which is used in ...
[64]
PKCS11 :: nShield Docs - Entrust
If HSM Pool mode is enabled, the nShield PKCS #11 library exposes a single pool of HSMs and a single virtual slot for a fixed token with the label accelerator .PKCS #11 with HSM Pool mode · Usage under preload · PKCS #11 without load...
[65]
https://thalesdocs.com/gphsm/luna/7/docs/network/Content/compliance/fips.htm
[66]
Smart-card support in RHEL 8 and later - Red Hat Customer Portal
Sep 10, 2024 · RHEL 8+ supports cards targeted by RHCS (CAC, PIV, CoolKey), selected PKCS#15 cards, and most CCID compatible readers. OpenSC PKCS#11 module is ...
[67]
How to import your certificate to the browser and save a back-up copy
At the left panel, click Your certificates > Manage imported certificates from Windows > at Personal > click Import. gc_import. 4. The Certificate Import Wizard ...
[68]
Sign Android files with Apksigner using PKCS11 library
Apksigner is a command-line tool provided by the Android SDK (Software Development Kit). It is used to sign and verify Android application packages (APKs).
[69]
open-quantum-safe/oqs-provider: OpenSSL 3 provider ... - GitHub
This repository contains code to enable quantum-safe cryptography (QSC) in a standard OpenSSL (3.x) distribution by way of implementing a single shared library ...Issues 38 · Discussions · Pull requests 5 · Releases 18
[70]
Post-Quantum Algorithms in OpenSSL
Sep 17, 2024 · A research project made available a test vehicle enabling TLS1.3 and X.509 support for many pre-standard and other experimental post-quantum algorithms.