RFC 2898
PKCS #5: Password-Based Cryptography Specification Version 2.0
RFC 2898 🎀 Part 1 of 6
Network Working Group 🌸 Request for Comments: 2898 ✨ Author: B. Kaliski, RSA Laboratories 💅 Category: Informational 🦋 (it gives "here's info, not a rule" energy) Date: September 2000 📅 Obsoletes / Updates: Neither is listed in this header 🙈
Okay bestie, this one is PKCS #5: Password-Based Cryptography Specification, Version 2.0 🔐 It was written by B. Kaliski at RSA Laboratories and dropped in September 2000. Its status is Informational, which means it's sharing knowledge with the Internet community, not setting a standard. 💖
Status of this Memo ✨
This memo provides information for the Internet community. It is not an Internet standard of any kind. Distribution is unlimited, so share it with everyone 🌈
Copyright Notice 💜
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract 🦋
Okay so this is a republication of PKCS #5 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series 📚 Change control stays inside the PKCS process, and the body of the document (except the security considerations section) comes straight from that spec.
It gives recommendations for implementing password-based cryptography. That covers key derivation functions, encryption schemes, message-authentication schemes, and the ASN.1 syntax that names all these techniques 🍓
The recommendations are meant for general use in computer and communications systems, so they're pretty flexible 🧚 They're especially aimed at protecting sensitive info like private keys, as in PKCS #8 [25]. Application standards and implementation profiles built on these specs may add extra constraints 💅
Other password-based techniques, like password-based key entity authentication and key establishment protocols [4][5][26], are out of scope here, and so are guidelines for choosing passwords 🙈
Table of Contents 🗂️
1. Introduction ............................................... 3
2. Notation ................................................... 3
3. Overview ................................................... 4
4. Salt and iteration count ................................... 6
4.1 Salt ................................................... 6
4.2 Iteration count ........................................ 8
5. Key derivation functions ................................... 8
5.1 PBKDF1 ................................................. 9
5.2 PBKDF2 ................................................. 9
6. Encryption schemes ......................................... 11
6.1 PBES1 .................................................. 12
6.1.1 Encryption operation ............................ 12
6.1.2 Decryption operation ............................ 13
6.2 PBES2 .................................................. 14
6.2.1 Encryption operation ............................ 14
6.2.2 Decryption operation ............................ 15
7. Message authentication schemes ............................. 15
7.1 PBMAC1 ................................................. 16
7.1.1 MAC generation .................................. 16
7.1.2 MAC verification ................................ 16
8. Security Considerations .................................... 17
9. Author's Address............................................ 17
A. ASN.1 syntax ............................................... 18
A.1 PBKDF1 ................................................. 18
A.2 PBKDF2 ................................................. 18
A.3 PBES1 .................................................. 20
A.4 PBES2 .................................................. 20
A.5 PBMAC1 ................................................. 21
B. Supporting techniques ...................................... 22
B.1 Pseudorandom functions ................................. 22
B.2 Encryption schemes ..................................... 23
B.3 Message authentication schemes ......................... 26
C. ASN.1 module ............................................... 26
Intellectual Property Considerations ............................ 30
Revision history ................................................ 30
References ...................................................... 31
Contact Information & About PKCS ................................ 33
Full Copyright Statement ........................................ 341. Introduction 🎀
This doc gives recommendations for implementing password-based cryptography. It covers:
- key derivation functions 🔑
- encryption schemes 🔐
- message-authentication schemes 💌
- ASN.1 syntax identifying the techniques 🧾
Same vibe as the abstract: these recommendations are for general use in computer and communications systems, so they're flexible 💖 They're especially meant to protect sensitive info like private keys, as in PKCS #8 [25]. Application standards and implementation profiles may add more constraints on top ✨
Other password-based techniques, like password-based key entity authentication and key establishment protocols [4][5][26], are outside this document's scope. So are guidelines for picking passwords 🙈
This document supersedes PKCS #5 version 1.5 [24], but it keeps compatible techniques too 🦋
2. Notation 🔣
Here's the notation cheat sheet, copied exactly so nothing gets lost in translation 📝
C ciphertext, an octet string
c iteration count, a positive integer
DK derived key, an octet string
dkLen length in octets of derived key, a positive integer
EM encoded message, an octet string
Hash underlying hash function
hLen length in octets of pseudorandom function output, a positive
integer
l length in blocks of derived key, a positive integer
IV initialization vector, an octet string
K encryption key, an octet string
KDF key derivation function
M message, an octet string
P password, an octet string
PRF underlying pseudorandom function
PS padding string, an octet string
psLen length in octets of padding string, a positive integer
S salt, an octet string
T message authentication code, an octet string
T_1, ..., T_l, U_1, ..., U_c
intermediate values, octet strings
01, 02, ..., 08
octets with value 1, 2, ..., 8
\xor bit-wise exclusive-or of two octet strings
|| || octet length operator
|| concatenation operator
<i..j> substring extraction operator: extracts octets i through j,
0 <= i <= j3. Overview 🌸
Okay so in lots of public-key crypto apps, user security depends on one or more secret text values, aka passwords 🔐 A password can't be used directly as a key for a conventional cryptosystem, so it has to be processed first. And since passwords tend to come from a pretty small pool, that processing needs extra care to defend against search attacks 🕵️♀️
The general approach, described by Morris and Thompson [8] for protecting password tables, is to mix a password with a salt to make a key 🧂 The salt works like an index into a big set of keys derived from the password, and it doesn't have to stay secret 🤫 An attacker could try building a table of possible passwords (a so-called "dictionary attack"), but building a table of possible keys is much harder, since each password has many possible keys. So the attacker is stuck searching passwords separately for each salt 💅
Another approach is to make key derivation kind of expensive, which raises the cost of exhaustive search 💸 One way is to include an iteration count, saying how many times to run the underlying function that derives keys. Around 1000 iterations isn't much of a burden for legit parties computing a key, but it's a big burden for attackers 😤
Salt and iteration count were the foundation of password-based encryption in PKCS #5 v1.5, and they're carried over here for the various crypto operations too 🎀 So password-based key derivation in this doc is a function of a password, a salt, and an iteration count, where the salt and count don't need to be secret 🦋
From a password-based key derivation function, you can easily define password-based encryption and message authentication schemes 🧁 Like PKCS #5 v1.5, the password-based encryption schemes sit on top of an underlying conventional encryption scheme, with the conventional key derived from the password 🔑 The password-based message authentication scheme works the same way, on top of a conventional scheme. This two-layer setup keeps the password-based techniques modular, since they can be built on different underlying techniques 🧩
Password-based key derivation functions could also be useful beyond the encryption and MAC schemes here. For example, you could derive a whole set of keys with one application of a KDF, instead of running it separately for each key. The keys would be substrings of the KDF output, and this could be part of key establishment in a session-oriented protocol 🌈 Another use is password checking, where the KDF output is stored with the salt and iteration count so a password can be verified later 💜
In this document, a password is an octet string of arbitrary length, and its interpretation as text isn't specified. For interoperability, though, applications should follow some common text encoding rules. ASCII and UTF-8 [27] are two options, and ASCII is a subset of UTF-8 ✨ Password selection is outside this document's scope, but guidelines have been published [17] that may well be worth considering 🙈
4. Salt and Iteration Count 🧂
Salt and iteration count are central to the techniques in this document, so they deserve a closer look 🔍 Stay tuned, because the deeper dive is coming up 🎀
4.1 Salt 🧂
Okay bestie, salt time ✨ In password-based crypto, the salt traditionally exists to give you a huge pile of possible keys from one password, and then the salt helps you pick one at random. You get one key out of that pile by running a key derivation function, KDF, like this:
DK = KDF (P, S)Here DK is the derived key, P is the password, and S is the salt. There are two big perks 💅
- It's super hard for an opponent to precompute all the keys for a dictionary of passwords, or even just the most likely ones. If the salt is 64 bits long, for instance, there are as many as
2^64keys for each password. So an opponent is stuck searching for passwords after a password-based operation has happened and the salt is known. Iconic defense 🛡️ - It's unlikely the same key gets picked twice. Again with a 64-bit salt, the chance of a "collision" between keys doesn't become significant until about
2^32keys have been produced, per the Birthday Paradox 🎂 This helps with worries about interactions between multiple uses of the same key, which can matter for some encryption and authentication techniques.
In password-based encryption, the party encrypting a message can feel confident these perks are actually happening just by picking a large, sufficiently random salt when deriving an encryption key from a password. A party generating a message authentication code can get that same confidence in a similar way 🫶
BUT the party decrypting a message or verifying a message authentication code can't be sure that a salt from another party was actually generated at random 😬 For instance, the salt might have been copied from a different password-based operation, trying to exploit interactions between multiple uses of the same key. Say two legit parties swap an encrypted message, where the encryption key is an 80-bit key derived from a shared password with some salt. An opponent could grab the salt from that encryption and hand it to one of the parties as though it were for a 40-bit key. If that party reveals the decryption result made with the 40-bit key, the opponent may be able to solve for the 40-bit key. And if that 40-bit key is the first half of the 80-bit key, the opponent can then easily solve for the remaining 40 bits of the 80-bit key. Not me getting spooked 💀
To defend against these attacks, either the interaction between multiple uses of the same key should be carefully analyzed, or the salt should contain data that explicitly distinguishes between different operations. For example, the salt might have an extra, non-random octet that says whether the derived key is for encryption, for message authentication, or for some other operation 🌸
So, based on all that, the following is recommended for salt selection:
- If there's no concern about interactions between multiple uses of the same key (or a prefix of that key) with the password-based encryption and authentication techniques supported for a given password, then the salt may be generated at random and need not be checked for a particular format by the party receiving the salt. It should be at least eight octets (64 bits) long. 🎀
- Otherwise, the salt should contain data that explicitly distinguishes between different operations and different key lengths, in addition to a random part that is at least eight octets long. This data should be checked or regenerated by the party receiving the salt. For example, the salt could have an additional non-random octet that specifies the purpose of the derived key. Or it could be the encoding of a structure that specifies detailed info about the derived key, like the encryption or authentication technique and a sequence number among the different keys derived from the password. The particular format of the additional data is left to the application ✨
Note. If a random number generator or pseudorandom generator isn't available, a deterministic alternative for generating the salt (or the random part of it) is to apply a password-based key derivation function to the password and the message M to be processed. For example, the salt could be computed with a key derivation function as S = KDF (P, M). This approach is not recommended if the message M is known to belong to a small message space (e.g., "Yes" or "No"), however, since then there will only be a small number of possible salts 🙈
4.2 Iteration Count 🔁
An iteration count traditionally exists to make producing keys from a password more expensive, which also makes attacking harder 💪 For the methods in this document, a minimum of 1000 iterations is recommended. This makes exhaustive password search way more expensive, without a noticeable impact on the cost of deriving individual keys. Big win 👑
5. Key Derivation Functions 🔑
A key derivation function produces a derived key from a base key and other parameters. In a password-based key derivation function, the base key is a password, and the other parameters are a salt value and an iteration count, as outlined in Section 3 🌈
The main use of the password-based key derivation functions defined here is in the encryption schemes in Section 6 and the message authentication scheme in Section 7. Other applications are totally possible, which is why these functions are defined independently 🦋
Two functions are specified in this section: PBKDF1 and PBKDF2. PBKDF2 is recommended for new applications. PBKDF1 is included only for compatibility with existing applications and is not recommended for new applications. Choose wisely, bestie 💖
A typical application of the key derivation functions defined here might include the following steps:
- Select a salt S and an iteration count c, as outlined in Section 4.
- Select a length in octets for the derived key, dkLen.
- Apply the key derivation function to the password, the salt, the iteration count, and the key length to produce a derived key.
- Output the derived key.
Any number of keys may be derived from a password by varying the salt, as described in Section 3 ✨
5.1 PBKDF1 🕰️
PBKDF1 applies a hash function, which shall be MD2 [6], MD5 [19] or SHA-1 [18], to derive keys. The length of the derived key is bounded by the length of the hash function output, which is 16 octets for MD2 and MD5 and 20 octets for SHA-1. PBKDF1 is compatible with the key derivation process in PKCS #5 v1.5 🧁
PBKDF1 is recommended only for compatibility with existing applications, since the keys it produces may not be large enough for some applications 🥺
PBKDF1 (P, S, c, dkLen)
Options: Hash underlying hash function
Input: P password, an octet string
S salt, an eight-octet string
c iteration count, a positive integer
dkLen intended length in octets of derived key,
a positive integer, at most 16 for MD2 or
MD5 and 20 for SHA-1
Output: DK derived key, a dkLen-octet string
Steps:
1. If dkLen > 16 for MD2 and MD5, or dkLen > 20 for SHA-1, output
"derived key too long" and stop.
2. Apply the underlying hash function Hash for c iterations to the
concatenation of the password P and the salt S, then extract
the first dkLen octets to produce a derived key DK:
T_1 = Hash (P || S) ,
T_2 = Hash (T_1) ,
...
T_c = Hash (T_{c-1}) ,
DK = Tc<0..dkLen-1>
3. Output the derived key DK.5.2 PBKDF2 🌟
PBKDF2 applies a pseudorandom function (see Appendix B.1 for an example) to derive keys. The length of the derived key is essentially unbounded. (However, the maximum effective search space for the derived key may be limited by the structure of the underlying pseudorandom function. See Appendix B.1 for further discussion.) PBKDF2 is recommended for new applications 💜
PBKDF2 (P, S, c, dkLen)
Options: PRF underlying pseudorandom function (hLen
denotes the length in octets of the
pseudorandom function output)
Input: P password, an octet string
S salt, an octet string
c iteration count, a positive integer
dkLen intended length in octets of the derived
key, a positive integer, at most
(2^32 - 1) * hLen
Output: DK derived key, a dkLen-octet string
Steps:
1. If dkLen > (2^32 - 1) * hLen, output "derived key too long" and
stop.
2. Let l be the number of hLen-octet blocks in the derived key,
rounding up, and let r be the number of octets in the last
block:
l = CEIL (dkLen / hLen) ,
r = dkLen - (l - 1) * hLen .
Here, CEIL (x) is the "ceiling" function, i.e. the smallest
integer greater than, or equal to, x.
3. For each block of the derived key apply the function F defined
below to the password P, the salt S, the iteration count c, and
the block index to compute the block:
T_1 = F (P, S, c, 1) ,
T_2 = F (P, S, c, 2) ,
...
T_l = F (P, S, c, l) ,
where the function F is defined as the exclusive-or sum of the
first c iterates of the underlying pseudorandom function PRF
applied to the password P and the concatenation of the salt S
and the block index i:
F (P, S, c, i) = U_1 \xor U_2 \xor ... \xor U_c
where
U_1 = PRF (P, S || INT (i)) ,
U_2 = PRF (P, U_1) ,
...
U_c = PRF (P, U_{c-1}) .
Here, INT (i) is a four-octet encoding of the integer i, most
significant octet first.
4. Concatenate the blocks and extract the first dkLen octets to
produce a derived key DK:
DK = T_1 || T_2 || ... || T_l<0..r-1>
5. Output the derived key DK.Note. The construction of the function F follows a "belt-and-suspenders" approach 🩳 The iterates U_i are computed recursively to remove a degree of parallelism from an opponent. They are exclusive-ored together to reduce concerns about the recursion degenerating into a small set of values. Genius, honestly 👑
6. Encryption Schemes ✨
okay so bestie, let's talk encryption schemes 💅🎀 in the symmetric world, a scheme has an encryption operation and a decryption operation. encryption takes a message and a key and spits out a ciphertext, and decryption takes that ciphertext and the same key and gets the message back 🦋 in a password-based encryption scheme, the key is literally a password, which is so relatable 🙈
one main use case is protecting private keys, like in PKCS #8 📦 where the message holds private-key info. the schemes here would be solid algorithms for that job 🔐
there are two schemes in this section: PBES1 and PBES2. PBES2 is the one you should reach for in new stuff 👑 PBES1 is only here so older apps keep working, and it is NOT RECOMMENDED for new applications 💀
6.1. PBES1
PBES1 pairs the PBKDF1 function (Section 5.1) with an underlying block cipher. that cipher has to be either DES [15] or RC2(tm) [21], both in CBC mode [16] 🌸 it's compatible with the encryption scheme in PKCS #5 v1.5 ✨
ngl, PBES1 is only recommended for compatibility with existing apps 😭 it only supports those two ciphers, and each has a key size of 56 or 64 bits, which might not be big enough for some apps 🥺
6.1.1. Encryption Operation
here's how the encryption operation for PBES1 goes, where we encrypt a message M under a password P to get a ciphertext C 🧚
- Select an eight-octet salt S and an iteration count c, as outlined in Section 4.
- Apply the PBKDF1 key derivation function (Section 5.1) to the password P, the salt S, and the iteration count c to make a derived key DK of length 16 octets:
DK = PBKDF1 (P, S, c, 16) .- Split the derived key DK into an encryption key K, which is the first eight octets of DK, and an initialization vector IV, which is the next eight octets:
K = DK<0..7> ,
IV = DK<8..15> .- Stick M and a padding string PS together to form an encoded message EM:
EM = M || PS ,where the padding string PS is 8-(||M|| mod 8) octets, each with the value 8-(||M|| mod 8). the padding string PS will match one of these statements:
PS = 01, if ||M|| mod 8 = 7 ;
PS = 02 02, if ||M|| mod 8 = 6 ;
...
PS = 08 08 08 08 08 08 08 08, if ||M|| mod 8 = 0.the length of the encoded message in octets will be a multiple of eight, and it will be possible to get M back out of the encoded message unambiguously 🎀 (this padding rule is borrowed from RFC 1423 [3] 💅)
- Encrypt the encoded message EM with the underlying block cipher (DES or RC2) in cipher block chaining mode, using the encryption key K and initialization vector IV, to make the ciphertext C. for DES, the key K SHALL be treated as a 64-bit encoding of a 56-bit DES key with parity bits ignored (see [9]) 🔥 for RC2, the "effective key bits" SHALL be 64 bits 🔥
- Output the ciphertext C.
the salt S and iteration count c MAY be passed to whoever is decrypting, inside an AlgorithmIdentifier value (see Appendix A.3) 🫶
6.1.2. Decryption Operation
and here's the decryption side, where we decrypt a ciphertext C under a password P to get the message M back 🌈
- Get the eight-octet salt S and the iteration count c.
- Apply the PBKDF1 key derivation function (Section 5.1) to the password P, the salt S, and the iteration count c to make a derived key DK of length 16 octets:
DK = PBKDF1 (P, S, c, 16)- Split the derived key DK into an encryption key K, which is the first eight octets of DK, and an initialization vector IV, which is the next eight octets:
K = DK<0..7> ,
IV = DK<8..15> .- Decrypt the ciphertext C with the underlying block cipher (DES or RC2) in cipher block chaining mode, using the encryption key K and initialization vector IV, to get back an encoded message EM. if the length of the ciphertext C in octets is not a multiple of eight, output "decryption error" and stop 🙈
- Split the encoded message EM into a message M and a padding string PS:
EM = M || PS ,where the padding string PS is some number psLen of octets, each with the value psLen, and psLen has to be between 1 and 8. if it's not possible to split the encoded message EM this way, output "decryption error" and stop 💀
- Output the recovered message M ✨
6.2. PBES2
PBES2 pairs a password-based key derivation function, which SHALL be PBKDF2 (Section 5.2) for this version of PKCS #5, with an underlying encryption scheme (see Appendix B.2 for examples) 🦋 the key length and other parameters for the underlying encryption scheme depend on that scheme 💜
PBES2 is recommended for new applications 👑
6.2.1. Encryption Operation
here's the encryption operation for PBES2, where we encrypt a message M under a password P to get a ciphertext C, using a selected KDF and a selected underlying encryption scheme 🌸
- Select a salt S and an iteration count c, as outlined in Section 4.
- Select the length in octets, dkLen, for the derived key for the underlying encryption scheme.
- Apply the selected key derivation function to the password P, the salt S, and the iteration count c to make a derived key DK of length dkLen octets:
DK = KDF (P, S, c, dkLen) .- Encrypt the message M with the underlying encryption scheme under the derived key DK to make a ciphertext C. (this step MAY involve picking parameters like an initialization vector and padding, depending on the underlying scheme 🧚)
- Output the ciphertext C.
the salt S, iteration count c, key length dkLen, and identifiers for the key derivation function and the underlying encryption scheme MAY be passed to whoever is decrypting, inside an AlgorithmIdentifier value (see Appendix A.4) 🎀
6.2.2. Decryption Operation
and the decryption side for PBES2, where we decrypt a ciphertext C under a password P to get the message M back 💖
- Get the salt S for the operation.
- Get the iteration count c for the key derivation function.
- Get the key length in octets, dkLen, for the derived key for the underlying encryption scheme.
- Apply the selected key derivation function to the password P, the salt S, and the iteration count c to make a derived key DK of length dkLen octets:
DK = KDF (P, S, c, dkLen) .- Decrypt the ciphertext C with the underlying encryption scheme under the derived key DK to recover a message M. if the decryption function outputs "decryption error," then output "decryption error" and stop 🙈
- Output the recovered message M 🌈
7. Message Authentication Schemes 🔐
okay so a message authentication scheme has a MAC (message authentication code) generation operation and a MAC verification operation 🦋 the generation operation makes a MAC from a message under a key, and the verification operation checks that MAC under that same key 💅 in a password-based message authentication scheme, the key is a password 🙈
one scheme is specified in this section: PBMAC1 ✨
7.1. PBMAC1
PBMAC1 pairs a password-based key derivation function, which SHALL be PBKDF2 (Section 5.2) for this version of PKCS #5, with an underlying message authentication scheme (see Appendix B.3 for an example) 🌸 the key length and other parameters for that underlying scheme depend on the scheme 💜
7.1.1. MAC Generation
here's the MAC generation operation for PBMAC1, where we process a message M under a password P to generate a message authentication code T, using a selected KDF and a selected underlying message authentication scheme 🧚
- Select a salt S and an iteration count c, as outlined in Section 4.
- Select a key length in octets, dkLen, for the derived key for the underlying message authentication function.
- Apply the selected key derivation function to the password P, the salt S, and the iteration count c to make a derived key DK of length dkLen octets:
DK = KDF (P, S, c, dkLen) .- Process the message M with the underlying message authentication scheme under the derived key DK to generate a message authentication code T.
- Output the message authentication code T.
the salt S, iteration count c, key length dkLen, and identifiers for the key derivation function and underlying message authentication scheme MAY be passed to whoever is doing the verification, inside an AlgorithmIdentifier value (see Appendix A.5) 🎀
7.1.2. MAC Verification
and here's the MAC verification operation for PBMAC1, where we process a message M under a password P to verify a message authentication code T 🫶
- Get the salt S and the iteration count c.
- Get the key length in octets, dkLen, for the derived key for the underlying message authentication scheme.
- Apply the selected key derivation function to the password P, the salt S, and the iteration count c to make a derived key DK of length dkLen octets:
DK = KDF (P, S, c, dkLen) .- Process the message M with the underlying message authentication scheme under the derived key DK to verify the message authentication code T.
- If the message authentication code verifies, output "correct"; otherwise output "incorrect." 💖
8. Security Considerations 💀🔐
okay bestie, this part is SERIOUS 😭 password-based cryptography can only give you so much security, especially with methods like the ones in this document, where an off-line password search is possible 🙈 salt and iteration count can make attacks harder (see Section 4 for recommendations), but it is ESSENTIAL that passwords are picked well, and relevant guidelines (e.g., [17]) SHOULD be taken into account 🔥 passwords also need to be protected well if they get stored 🥺
in general, different keys should be derived from a password for different uses, to cut down on the chance of unintended interactions 🦋 for password-based encryption with a single algorithm, a random salt is enough to make sure different keys come out 💅 in certain other situations, as Section 4 explains, a structured salt is NECESSARY 👑 so the recommendations in Section 4 SHOULD be taken into account when picking the salt value ✨
9. Author's Address 🎀
Burt Kaliski RSA Laboratories 20 Crosby Drive Bedford, MA 01730 USA
EMail: bkaliski@rsasecurity.com
APPENDICES 🌈
A. ASN.1 Syntax ✨
okay so this section is the ASN.1 syntax for the key derivation functions, the encryption schemes, the message authentication scheme, and some supporting bits 💅 the vibe is that it's meant for PKCS #8 and other key management, encrypted data, and integrity-protected data 🔐 (ASN.1 itself is specified in a bunch of ISO/IEC standards [9][10][11][12][13][14] if you wanna go deep 🤓)
the OID pkcs-5 is the arc of the OID tree that every PKCS #5-specific OID in this section comes from 🌳
rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549}
pkcs OBJECT IDENTIFIER ::= {rsadsi 1}
pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5}A.1 PBKDF1
no OID for PBKDF1 🙈 the PBES1 OIDs are already enough for existing apps, and PBKDF2 is recommended for new apps 🎀
A.2 PBKDF2
the OID id-PBKDF2 identifies the PBKDF2 key derivation function (Section 5.2) 🔑
id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12}the parameters field attached to this OID in an AlgorithmIdentifier shall have type PBKDF2-params 📋
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}}
},
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT
algid-hmacWithSHA1 }here's what the fields of PKDF2-params mean 👀
- salt is the salt value, or where the salt value comes from. it shall either be an octet string, or an algorithm ID with an OID in the set PBKDF2-SaltSources, which is reserved for future versions of PKCS #5.
the salt-source approach is meant to show how the salt gets generated from the parameters in the algorithm ID, the application data, or both 🧂 for example, it might say the salt comes from encoding a structure with detailed info about the derived key (like Section 4.1 suggests). some of that info could live somewhere else, like the encryption algorithm ID, but those features are pushed to a future version of PKCS #5 🫠
in this version, an application can get the benefits from Section 4.1 by picking a particular interpretation of the salt value in the specified alternative ✨
PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... }- iterationCount is the iteration count. the max allowed depends on the implementation, and it's expected that implementation profiles may tighten those bounds further 🔁
- keyLength is an optional field, and it's the length in octets of the derived key. the max key length also depends on the implementation, and it's expected that implementation profiles may tighten those bounds too 📏 this field is just for convenience, and the key length is not cryptographically protected 🙅♀️ if you're worried about operations with different key lengths for the same salt (see Section 4.1), the salt should tell the different key lengths apart 💜
- prf is the underlying pseudorandom function. it shall be an algorithm ID with an OID in the set PBKDF2-PRFs, which for this version of PKCS #5 shall consist of id-hmacWithSHA1 (see Appendix B.1.1) plus any other OIDs the application defines 🌸
PBKDF2-PRFs ALGORITHM-IDENTIFIER ::=
{ {NULL IDENTIFIED BY id-hmacWithSHA1}, ... }the default pseudorandom function is HMAC-SHA-1 🦋
algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::=
{algorithm id-hmacWithSHA1, parameters NULL : NULL}A.3 PBES1
different OIDs identify the PBES1 encryption scheme (Section 6.1) depending on the underlying hash function in the key derivation function and the underlying block cipher 🍓 here's the summary table:
Hash Function Block Cipher OID
MD2 DES pkcs-5.1
MD2 RC2 pkcs-5.4
MD5 DES pkcs-5.3
MD5 RC2 pkcs-5.6
SHA-1 DES pkcs-5.10
SHA-1 RC2 pkcs-5.11pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1}
pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4}
pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3}
pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6}
pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10}
pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11}for each OID, the parameters field attached to it in an AlgorithmIdentifier shall have type PBEParameter 🎀
PBEParameter ::= SEQUENCE {
salt OCTET STRING (SIZE(8)),
iterationCount INTEGER }the PBEParameter fields mean:
- salt is the salt value, an eight-octet string 🧂
- iterationCount is the iteration count 🔁
A.4 PBES2
the OID id-PBES2 identifies the PBES2 encryption scheme (Section 6.2) 🔐
id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13}the parameters field attached to this OID in an AlgorithmIdentifier shall have type PBES2-params 📋
PBES2-params ::= SEQUENCE {
keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}},
encryptionScheme AlgorithmIdentifier {{PBES2-Encs}} }the PBES2-params fields mean:
- keyDerivationFunc identifies the underlying key derivation function. it shall be an algorithm ID with an OID in the set PBES2-KDFs, which for this version of PKCS #5 shall consist of id-PBKDF2 (Appendix A.2) 🗝️
PBES2-KDFs ALGORITHM-IDENTIFIER ::=
{ {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... }- encryptionScheme identifies the underlying encryption scheme. it shall be an algorithm ID with an OID in the set PBES2-Encs, and its definition is left up to the application 🫶 example underlying encryption schemes are in Appendix B.2 💖
PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... }A.5 PBMAC1
the OID id-PBMAC1 identifies the PBMAC1 message authentication scheme (Section 7.1) 🦋
id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14}the parameters field attached to this OID in an AlgorithmIdentifier shall have type PBMAC1-params 📋
PBMAC1-params ::= SEQUENCE {
keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}},
messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}} }the keyDerivationFunc field means the same thing as the matching field in PBES2-params (Appendix A.4), except that the set of OIDs is PBMAC1-KDFs 👑
PBMAC1-KDFs ALGORITHM-IDENTIFIER ::=
{ {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... }the messageAuthScheme field identifies the underlying message authentication scheme. it shall be an algorithm ID with an OID in the set PBMAC1-MACs, and its definition is left up to the application 🧚 example underlying encryption schemes are given in Appendix B.3 🌈
PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... }B. Supporting Techniques 🧰
this section has some example functions and schemes that support the password-based schemes in Sections 5, 6 and 7 🌷
these supporting techniques are fine for applications to implement, but none of them is required to be implemented 🙌 it's expected though that profiles for PKCS #5 will get written that pin down particular supporting techniques 📝
this section also gives OIDs for the supporting techniques. the OIDs digestAlgorithm and encryptionAlgorithm are the arcs that a bunch of the algorithm OIDs in this section come from 🌳
digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2}
encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3}B.1 Pseudorandom functions
an example pseudorandom function for PBKDF2 (Section 5.2) is HMAC-SHA-1 🦋
B.1.1 HMAC-SHA-1
HMAC-SHA-1 is the pseudorandom function that matches the HMAC message authentication code [7], which is built on the SHA-1 hash function [18] 💜 the PRF is the same function the MAC gets computed with, just with full-length output. (the first argument to the PRF serves as HMAC's "key", and the second serves as HMAC's "text". for PBKDF2, the "key" is the password and the "text" is the salt 🔑🧂) HMAC-SHA-1 has a variable key length and a 20-octet (160-bit) output value 📏
ok this part is kinda important 🚨 the key length for HMAC-SHA-1 is basically unbounded, but the effective search space for PRF outputs can get limited by the structure of the function. specifically, when the key is longer than 512 bits, HMAC-SHA-1 hashes it down to 160 bits first 😳 so even if a long derived key is made from several PRF outputs, the effective search space for that derived key is at most 160 bits. the exact limit for other key sizes depends on the details of the HMAC construction, but to be conservative, you should assume the effective search space is limited to 160 bits for other key sizes too 🫣
(the 160-bit limitation shouldn't usually be a practical problem for password-based cryptography, since the search space for a password is unlikely to be bigger than 160 bits 🙃)
the OID id-hmacWithSHA1 identifies the HMAC-SHA-1 PRF 🏷️
id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7}the parameters field attached to this OID in an AlgorithmIdentifier shall have type NULL. this OID is used in the object set PBKDF2-PRFs (Appendix A.2) 🌸
Note. HMAC-SHA-1 was designed as a message authentication code, but its proof of security can be easily adjusted to meet the requirements of a pseudorandom function, under stronger assumptions 🧠
a hash function can also meet the requirements of a pseudorandom function under certain assumptions 🤔 for instance, applying a hash function directly to the concatenation of the "key" and the "text" might be appropriate, as long as the "text" has the right structure to prevent certain attacks 🛡️ still, HMAC-SHA-1 is the better pick, because it treats "key" and "text" as separate arguments and doesn't require the "text" to have any structure 💅
B.2 Encryption Schemes
example pseudorandom functions for PBES2 (Section 6.2) are DES-CBC-Pad, DES-EDE2-CBC-Pad, RC2-CBC-Pad, and RC5-CBC-Pad 🎀
the OIDs given in this section are meant to be used in the object set PBES2-Encs (Appendix A.4) 💖
B.2.1 DES-CBC-Pad
DES-CBC-Pad is single-key DES [15] in CBC mode [16], using the RFC 1423 padding operation (see Section 6.1.1) 🍰 DES-CBC-Pad has an eight-octet encryption key and an eight-octet initialization vector 🔐 the key is treated as a 64-bit encoding of a 56-bit DES key, with the parity bits ignored 🙈
the OID desCBC (defined in the NIST/OSI Implementors' Workshop agreements) identifies the DES-CBC-Pad encryption scheme 🏷️
desCBC OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) oiw(14) secsig(3)
algorithms(2) 7}the parameters field attached to this OID in an AlgorithmIdentifier shall have type OCTET STRING (SIZE(8)), which specifies the initialization vector for CBC mode 🌈
B.2.2 DES-EDE3-CBC-Pad ✨
okay so DES-EDE3-CBC-Pad is three-key triple-DES in CBC mode [1] with the RFC 1423 padding operation 💅 It has a 24-octet encryption key and an eight-octet initialization vector. The key is basically three eight-octet keys stuck together, and each one is a 64-bit encoding of a 56-bit DES key with the parity bits ignored 🎀
The object identifier des-EDE3-CBC identifies the DES-EDE3-CBC-Pad encryption scheme:
des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7}The parameters field tied to this OID in an AlgorithmIdentifier SHALL have type OCTET STRING (SIZE(8)), and that's where the initialization vector for CBC mode goes 🦋
Note. An OID for DES-EDE3-CBC without padding is given in ANSI X9.52 [1]; the one given here is preferred since it specifies padding. 🙈
B.2.3 RC2-CBC-Pad 🌸
RC2-CBC-Pad is the RC2(tm) encryption algorithm [21] in CBC mode with the RFC 1423 padding operation. Its key length is variable, anywhere from one to 128 octets. It also has a separate "effective key bits" parameter, from one to 1024 bits, that limits the effective search space no matter how long the key is. Then there's an eight-octet initialization vector 🧚
The object identifier rc2CBC identifies the RC2-CBC-Pad encryption scheme:
rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2}The parameters field tied to OID in an AlgorithmIdentifier SHALL have type RC2-CBC-Parameter:
RC2-CBC-Parameter ::= SEQUENCE {
rc2ParameterVersion INTEGER OPTIONAL,
iv OCTET STRING (SIZE(8)) }The fields of type RC2-CBCParameter mean the following:
- rc2ParameterVersion is a proprietary RSA Security Inc. encoding of the "effective key bits" for RC2. These encodings are defined:
Effective Key Bits Encoding
40 160
64 120
128 58
b >= 256 bIf the rc2ParameterVersion field is omitted, the "effective key bits" defaults to 32. (This is for backward compatibility with certain very old implementations.) 👑
- iv is the eight-octet initialization vector. 🍓
B.2.4 RC5-CBC-Pad 🦋
RC5-CBC-Pad is the RC5(tm) encryption algorithm [20] in CBC mode with a generalization of the RFC 1423 padding operation. This scheme is fully specified in [2]. Its key length is variable, from 0 to 256 octets, and it supports both a 64-bit block size and a 128-bit block size. The 64-bit version has an eight-octet initialization vector, and the 128-bit version has a 16-octet one. RC5-CBC-Pad also has a variable number of "rounds" in the encryption operation, from 8 to 127 🔥
Note: The generalization of the padding operation works like this. For RC5 with a 64-bit block size, the padding string is as defined in RFC 1423. For RC5 with a 128-bit block size, the padding string is 16-(||M|| mod 16) octets, each with value 16-(||M|| mod 16) ✨
The object identifier rc5-CBC-PAD [2] identifies RC5-CBC-Pad encryption scheme:
rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9}The parameters field tied to this OID in an AlgorithmIdentifier SHALL have type RC5-CBC-Parameters:
RC5-CBC-Parameters ::= SEQUENCE {
version INTEGER {v1-0(16)} (v1-0),
rounds INTEGER (8..127),
blockSizeInBits INTEGER (64 | 128),
iv OCTET STRING OPTIONAL }The fields of type RC5-CBC-Parameters mean the following:
- version is the version of the algorithm, which SHALL be
v1-0. 🌈 - rounds is the number of rounds in the encryption operation, which SHALL be between 8 and 127. 💜
- blockSizeInBits is the block size in bits, which SHALL be 64 or 128. 🫶
- iv is the initialization vector: an eight-octet string for 64-bit RC5 and a 16-octet string for 128-bit RC5. The default is a string of the appropriate length made of zero octets. 🍓
B.3 Message Authentication Schemes 🎀
An example message authentication scheme for PBMAC1 (Section 7.1) is HMAC-SHA-1. 💖
B.3.1 HMAC-SHA-1 ✨
HMAC-SHA-1 is the HMAC message authentication scheme [7] based on the SHA-1 hash function [18]. It has a variable key length and a 20-octet (160-bit) message authentication code 🔥
The object identifier id-hmacWithSHA1 (see Appendix B.1.1) identifies the HMAC-SHA-1 message authentication scheme. (The object identifier is the same for both the pseudorandom function and the message authentication scheme. The distinction is to be understood by context.) This object identifier is meant to be used in the object set PBMAC1-Macs (Appendix A.5). 🧚
C. ASN.1 Module 💅
For reference purposes, the ASN.1 syntax in the preceding sections is presented as an ASN.1 module here. 🫶
-- PKCS #5 v2.0 ASN.1 Module
-- Revised March 25, 1999
-- This module has been checked for conformance with the
-- ASN.1 standard by the OSS ASN.1 Tools
PKCS5v2-0 {iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-5(5) modules(16) pkcs5v2-0(1)}
DEFINITIONS ::= BEGIN
-- Basic object identifiers
rsadsi OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 113549}
pkcs OBJECT IDENTIFIER ::= {rsadsi 1}
pkcs-5 OBJECT IDENTIFIER ::= {pkcs 5}
-- Basic types and classes
AlgorithmIdentifier { ALGORITHM-IDENTIFIER:InfoObjectSet } ::=
SEQUENCE {
algorithm ALGORITHM-IDENTIFIER.&id({InfoObjectSet}),
parameters ALGORITHM-IDENTIFIER.&Type({InfoObjectSet}
{@algorithm}) OPTIONAL
}
ALGORITHM-IDENTIFIER ::= TYPE-IDENTIFIER
-- PBKDF2
PBKDF2Algorithms ALGORITHM-IDENTIFIER ::=
{ {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ...}
id-PBKDF2 OBJECT IDENTIFIER ::= {pkcs-5 12}
algid-hmacWithSHA1 AlgorithmIdentifier {{PBKDF2-PRFs}} ::=
{algorithm id-hmacWithSHA1, parameters NULL : NULL}
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource AlgorithmIdentifier {{PBKDF2-SaltSources}}
},
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier {{PBKDF2-PRFs}} DEFAULT
algid-hmacWithSHA1
}
PBKDF2-SaltSources ALGORITHM-IDENTIFIER ::= { ... }
PBKDF2-PRFs ALGORITHM-IDENTIFIER ::=
{ {NULL IDENTIFIED BY id-hmacWithSHA1}, ... }
-- PBES1
PBES1Algorithms ALGORITHM-IDENTIFIER ::= {
{PBEParameter IDENTIFIED BY pbeWithMD2AndDES-CBC} |
{PBEParameter IDENTIFIED BY pbeWithMD2AndRC2-CBC} |
{PBEParameter IDENTIFIED BY pbeWithMD5AndDES-CBC} |
{PBEParameter IDENTIFIED BY pbeWithMD5AndRC2-CBC} |
{PBEParameter IDENTIFIED BY pbeWithSHA1AndDES-CBC} |
{PBEParameter IDENTIFIED BY pbeWithSHA1AndRC2-CBC},
...
}
pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1}
pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4}
pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3}
pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6}
pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10}
pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11}
PBEParameter ::= SEQUENCE {
salt OCTET STRING (SIZE(8)),
iterationCount INTEGER
}
-- PBES2
PBES2Algorithms ALGORITHM-IDENTIFIER ::=
{ {PBES2-params IDENTIFIED BY id-PBES2}, ...}
id-PBES2 OBJECT IDENTIFIER ::= {pkcs-5 13}
PBES2-params ::= SEQUENCE {
keyDerivationFunc AlgorithmIdentifier {{PBES2-KDFs}},
encryptionScheme AlgorithmIdentifier {{PBES2-Encs}}
}
PBES2-KDFs ALGORITHM-IDENTIFIER ::=
{ {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... }
PBES2-Encs ALGORITHM-IDENTIFIER ::= { ... }
-- PBMAC1
PBMAC1Algorithms ALGORITHM-IDENTIFIER ::=
{ {PBMAC1-params IDENTIFIED BY id-PBMAC1}, ...}
id-PBMAC1 OBJECT IDENTIFIER ::= {pkcs-5 14}
PBMAC1-params ::= SEQUENCE {
keyDerivationFunc AlgorithmIdentifier {{PBMAC1-KDFs}},
messageAuthScheme AlgorithmIdentifier {{PBMAC1-MACs}}
}
PBMAC1-KDFs ALGORITHM-IDENTIFIER ::=
{ {PBKDF2-params IDENTIFIED BY id-PBKDF2}, ... }
PBMAC1-MACs ALGORITHM-IDENTIFIER ::= { ... }
-- Supporting techniques
digestAlgorithm OBJECT IDENTIFIER ::= {rsadsi 2}
encryptionAlgorithm OBJECT IDENTIFIER ::= {rsadsi 3}
SupportingAlgorithms ALGORITHM-IDENTIFIER ::= {
{NULL IDENTIFIED BY id-hmacWithSHA1} |
{OCTET STRING (SIZE(8)) IDENTIFIED BY desCBC} |
{OCTET STRING (SIZE(8)) IDENTIFIED BY des-EDE3-CBC} |
{RC2-CBC-Parameter IDENTIFIED BY rc2CBC} |
{RC5-CBC-Parameters IDENTIFIED BY rc5-CBC-PAD},
...
}
id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7}
desCBC OBJECT IDENTIFIER ::=
{iso(1) identified-organization(3) oiw(14) secsig(3)
algorithms(2) 7} -- from OIW
des-EDE3-CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 7}
rc2CBC OBJECT IDENTIFIER ::= {encryptionAlgorithm 2}
RC2-CBC-Parameter ::= SEQUENCE {
rc2ParameterVersion INTEGER OPTIONAL,
iv OCTET STRING (SIZE(8))
}
rc5-CBC-PAD OBJECT IDENTIFIER ::= {encryptionAlgorithm 9}
RC5-CBC-Parameters ::= SEQUENCE {
version INTEGER {v1-0(16)} (v1-0),
rounds INTEGER (8..127),
blockSizeInBits INTEGER (64 | 128),
iv OCTET STRING OPTIONAL
}
ENDIntellectual Property Considerations ⚖️
RSA Security makes no patent claims on the general constructions described in this document, although specific underlying techniques may be covered. Among the underlying techniques, the RC5 encryption algorithm (Appendix B.2.4) is protected by U.S. Patents 5,724,428 [22] and 5,835,600 [23]. 😭
RC2 and RC5 are trademarks of RSA Security. 🎀
License to copy this document is granted provided that it is identified as RSA Security Inc. Public-Key Cryptography Standards (PKCS) in all material mentioning or referencing this document. 🌸
RSA Security makes no representations regarding intellectual property claims by other parties. Such determination is the responsibility of the user. 🫶
Revision history 🕰️
Versions 1.0-1.3
Versions 1.0-1.3 were distributed to participants in RSA Data Security Inc.'s Public-Key Cryptography Standards meetings in February and March 1991. 🌷
Version 1.4
Version 1.4 was part of the June 3, 1991 initial public release of PKCS. Version 1.4 was published as NIST/OSI Implementors' Workshop document SEC-SIG-91-20. 🍓
Version 1.5
Version 1.5 incorporated several editorial changes, including updates to the references and the addition of a revision history. ✨
Version 2.0
Version 2.0 incorporates major editorial changes in terms of the document structure, and introduces the PBES2 encryption scheme, the PBMAC1 message authentication scheme, and independent password-based key derivation functions. This version continues to support the encryption process in version 1.5. 👑🌈
References 📚
Okay bestie, here's the whole bibliography, every single source this spec leans on 💅
- [1] American National Standard X9.52 - 1998, Triple Data Encryption Algorithm Modes of Operation. Working draft, Accredited Standards Committee X9, July 27, 1998.
- [2] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms", RFC 2040, October 1996.
- [3] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993.
- [4] S.M. Bellovin and M. Merritt. Encrypted key exchange: Password-based protocols secure against dictionary attacks. In Proceedings of the 1992 IEEE Computer Society Conference on Research in Security and Privacy, pages 72-84, IEEE Computer Society, 1992.
- [5] D. Jablon. Strong password-only authenticated key exchange. ACM Computer Communications Review, October 1996.
- [6] Kaliski, B., "The MD2 Message-Digest Algorithm", RFC 1319, April 1992.
- [7] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [8] Robert Morris and Ken Thompson. Password security: A case history. Communications of the ACM, 22(11):594-597, November 1979.
- [9] ISO/IEC 8824-1:1995: Information technology - Abstract Syntax Notation One (ASN.1) - Specification of basic notation. 1995.
- [10] ISO/IEC 8824-1:1995/Amd.1:1995 Information technology - Abstract Syntax Notation One (ASN.1) - Specification of basic notation - Amendment 1 - Rules of extensibility. 1995.
- [11] ISO/IEC 8824-2:1995 Information technology - Abstract Syntax Notation One (ASN.1) - Information object specification. 1995.
- [12] ISO/IEC 8824-2:1995/Amd.1:1995 Information technology - Abstract Syntax Notation One (ASN.1) - Information object specification - Amendment 1 - Rules of extensibility. 1995.
- [13] ISO/IEC 8824-3:1995 Information technology - Abstract Syntax Notation One (ASN.1) - Constraint specification. 1995.
- [14] ISO/IEC 8824-4:1995 Information technology - Abstract Syntax Notation One (ASN.1) - Parameterization of ASN.1 specifications. 1995.
- [15] National Institute of Standards and Technology (NIST). FIPS PUB 46-2: Data Encryption Standard. December 30, 1993.
- [16] National Institute of Standards and Technology (NIST). FIPS PUB 81: DES Modes of Operation. December 2, 1980.
- [17] National Institute of Standards and Technology (NIST). FIPS PUB 112: Password Usage. May 30, 1985.
- [18] National Institute of Standards and Technology (NIST). FIPS PUB 180-1: Secure Hash Standard. April 1994.
- [19] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [20] R.L. Rivest. The RC5 encryption algorithm. In Proceedings of the Second International Workshop on Fast Software Encryption, pages 86-96, Springer-Verlag, 1994.
- [21] Rivest, R., "A Description of the RC2(r) Encryption Algorithm", RFC 2268, March 1998.
- [22] R.L. Rivest. Block-Encryption Algorithm with Data-Dependent Rotations. U.S. Patent No. 5,724,428, March 3, 1998.
- [23] R.L. Rivest. Block Encryption Algorithm with Data-Dependent Rotations. U.S. Patent No. 5,835,600, November 10, 1998.
- [24] RSA Laboratories. PKCS #5: Password-Based Encryption Standard. Version 1.5, November 1993.
- [25] RSA Laboratories. PKCS #8: Private-Key Information Syntax Standard. Version 1.2, November 1993.
- [26] T. Wu. The Secure Remote Password protocol. In Proceedings of the 1998 Internet Society Network and Distributed System Security Symposium, pages 97-111, Internet Society, 1998.
- [27] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
Contact Information & About PKCS 📞
The Public-Key Cryptography Standards are specifications produced by RSA Laboratories in cooperation with secure systems developers worldwide, all to speed up how fast public-key cryptography gets deployed 🔐 They were first published in 1991, following meetings with a small group of early adopters of public-key technology, and the PKCS documents have become widely referenced and implemented 🌸 Contributions from the PKCS series have become part of many formal and de facto standards, including ANSI X9 documents, PKIX, SET, S/MIME, and SSL. Iconic 👑
Further development of PKCS happens through mailing list discussions and occasional workshops, and suggestions for improvement are welcome 💌 To get in touch, contact:
PKCS Editor
RSA Laboratories
20 Crosby Drive
Bedford, MA 01730 USA
pkcs-editor@rsasecurity.com
http://www.rsalabs.com/pkcs/Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2000). All Rights Reserved. 🦋
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ♾️
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 🌈✨
📦 where this page comes from
- ietf: rfc2898 2000-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms