📄 rfc2437.txt
字号:
Steps:
1. Apply the EME-OAEP encoding operation (Section 9.1.1.2) to the
message M and the encoding parameters P to produce an encoded message
EM of length k-1 octets:
EM = EME-OAEP-ENCODE (M, P, k-1)
If the encoding operation outputs "message too long," then output
"message too long" and stop.
2. Convert the encoded message EM to an integer message
representative m: m = OS2IP (EM)
3. Apply the RSAEP encryption primitive (Section 5.1.1) to the public
key (n, e) and the message representative m to produce an integer
ciphertext representative c:
c = RSAEP ((n, e), m)
4. Convert the ciphertext representative c to a ciphertext C of
length k octets: C = I2OSP (c, k)
5. Output the ciphertext C.
7.1.2 Decryption operation
RSAES-OAEP-DECRYPT (K, C, P)
Input:
K recipient's RSA private key
C ciphertext to be decrypted, an octet string of length
k, where k is the length in octets of the modulus n
P encoding parameters, an octet string that may be empty
Output:
M message, an octet string of length at most k-2-2hLen,
where hLen is the length in octets of the hash
function output for EME-OAEP; or "decryption error"
Kaliski & Staddon Informational [Page 14]
RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998
Steps:
1. If the length of the ciphertext C is not k octets, output
"decryption error" and stop.
2. Convert the ciphertext C to an integer ciphertext representative
c: c = OS2IP (C).
3. Apply the RSADP decryption primitive (Section 5.1.2) to the
private key K and the ciphertext representative c to produce an
integer message representative m:
m = RSADP (K, c)
If RSADP outputs "ciphertext out of range," then output "decryption
error" and stop.
4. Convert the message representative m to an encoded message EM of
length k-1 octets: EM = I2OSP (m, k-1)
If I2OSP outputs "integer too large," then output "decryption error"
and stop.
5. Apply the EME-OAEP decoding operation to the encoded message EM
and the encoding parameters P to recover a message M:
M = EME-OAEP-DECODE (EM, P)
If the decoding operation outputs "decoding error," then output
"decryption error" and stop.
6. Output the message M.
Note. It is important that the error messages output in steps 4 and 5
be the same, otherwise an adversary may be able to extract useful
information from the type of error message received. Error message
information is used to mount a chosen-ciphertext attack on PKCS #1
v1.5 encrypted messages in [4].
7.2 RSAES-PKCS1-v1_5
RSAES-PKCS1-v1_5 combines the RSAEP and RSADP primitives with the
EME-PKCS1-v1_5 encoding method. It is the same as the encryption
scheme in PKCS #1 v1.5. RSAES-PKCS1-v1_5 can operate on messages of
length up to k-11 octets, although care should be taken to avoid
certain attacks on low-exponent RSA due to Coppersmith, et al. when
long messages are encrypted (see the third bullet in the notes below
and [7]).
Kaliski & Staddon Informational [Page 15]
RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998
RSAES-PKCS1-v1_5 does not provide "plaintext aware" encryption. In
particular, it is possible to generate valid ciphertexts without
knowing the corresponding plaintexts, with a reasonable probability
of success. This ability can be exploited in a chosen ciphertext
attack as shown in [4]. Therefore, if RSAES-PKCS1-v1_5 is to be used,
certain easily implemented countermeasures should be taken to thwart
the attack found in [4]. The addition of structure to the data to be
encoded, rigorous checking of PKCS #1 v1.5 conformance and other
redundancy in decrypted messages, and the consolidation of error
messages in a client-server protocol based on PKCS #1 v1.5 can all be
effective countermeasures and don't involve changes to a PKCS #1
v1.5-based protocol. These and other countermeasures are discussed in
[5].
Notes. The following passages describe some security recommendations
pertaining to the use of RSAES-PKCS1-v1_5. Recommendations from
version 1.5 of this document are included as well as new
recommendations motivated by cryptanalytic advances made in the
intervening years.
-It is recommended that the pseudorandom octets in EME-PKCS1-v1_5 be
generated independently for each encryption process, especially if
the same data is input to more than one encryption process. Hastad's
results [13] are one motivation for this recommendation.
-The padding string PS in EME-PKCS1-v1_5 is at least eight octets
long, which is a security condition for public-key operations that
prevents an attacker from recovering data by trying all possible
encryption blocks.
-The pseudorandom octets can also help thwart an attack due to
Coppersmith et al. [7] when the size of the message to be encrypted
is kept small. The attack works on low-exponent RSA when similar
messages are encrypted with the same public key. More specifically,
in one flavor of the attack, when two inputs to RSAEP agree on a
large fraction of bits (8/9) and low-exponent RSA (e = 3) is used to
encrypt both of them, it may be possible to recover both inputs with
the attack. Another flavor of the attack is successful in decrypting
a single ciphertext when a large fraction (2/3) of the input to RSAEP
is already known. For typical applications, the message to be
encrypted is short (e.g., a 128-bit symmetric key) so not enough
information will be known or common between two messages to enable
the attack. However, if a long message is encrypted, or if part of a
message is known, then the attack may be a concern. In any case, the
RSAEP-OAEP scheme overcomes the attack.
Kaliski & Staddon Informational [Page 16]
RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998
7.2.1 Encryption operation
RSAES-PKCS1-V1_5-ENCRYPT ((n, e), M)
Input:
(n, e) recipient's RSA public key
M message to be encrypted, an octet string of length at
most k-11 octets, where k is the length in octets of the
modulus n
Output:
C ciphertext, an octet string of length k; or "message too
long"
Steps:
1. Apply the EME-PKCS1-v1_5 encoding operation (Section 9.1.2.1) to
the message M to produce an encoded message EM of length k-1 octets:
EM = EME-PKCS1-V1_5-ENCODE (M, k-1)
If the encoding operation outputs "message too long," then output
"message too long" and stop.
2. Convert the encoded message EM to an integer message
representative m: m = OS2IP (EM)
3. Apply the RSAEP encryption primitive (Section 5.1.1) to the public
key (n, e) and the message representative m to produce an integer
ciphertext representative c: c = RSAEP ((n, e), m)
4. Convert the ciphertext representative c to a ciphertext C of
length k octets: C = I2OSP (c, k)
5. Output the ciphertext C.
7.2.2 Decryption operation
RSAES-PKCS1-V1_5-DECRYPT (K, C)
Input:
K recipient's RSA private key
C ciphertext to be decrypted, an octet string of length k,
where k is the length in octets of the modulus n
Output:
M message, an octet string of length at most k-11; or
"decryption error"
Kaliski & Staddon Informational [Page 17]
RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998
Steps:
1. If the length of the ciphertext C is not k octets, output
"decryption error" and stop.
2. Convert the ciphertext C to an integer ciphertext representative
c: c = OS2IP (C).
3. Apply the RSADP decryption primitive to the private key (n, d) and
the ciphertext representative c to produce an integer message
representative m: m = RSADP ((n, d), c).
If RSADP outputs "ciphertext out of range," then output "decryption
error" and stop.
4. Convert the message representative m to an encoded message EM of
length k-1 octets: EM = I2OSP (m, k-1)
If I2OSP outputs "integer too large," then output "decryption error"
and stop.
5. Apply the EME-PKCS1-v1_5 decoding operation to the encoded message
EM to recover a message M: M = EME-PKCS1-V1_5-DECODE (EM).
If the decoding operation outputs "decoding error," then output
"decryption error" and stop.
6. Output the message M.
Note. It is important that only one type of error message is output
by EME-PKCS1-v1_5, as ensured by steps 4 and 5. If this is not done,
then an adversary may be able to use information extracted form the
type of error message received to mount a chosen-ciphertext attack
such as the one found in [4].
8. Signature schemes with appendix
A signature scheme with appendix consists of a signature generation
operation and a signature verification operation, where the signature
generation operation produces a signature from a message with a
signer's private key, and the signature verification operation
verifies the signature on the message with the signer's corresponding
public key. To verify a signature constructed with this type of
scheme it is necessary to have the message itself. In this way,
signature schemes with appendix are distinguished from signature
schemes with message recovery, which are not supported in this
document.
Kaliski & Staddon Informational [Page 18]
RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998
A signature scheme with appendix can be employed in a variety of
applications. For instance, X.509 [6] employs such a scheme to
authenticate the content of a certificate; the signature scheme with
appendix defined here would be a suitable signature algorithm in that
context. A related signature scheme could be employed in PKCS #7
[21], although for technical reasons, the current version of PKCS #7
separates a hash function from a signature scheme, which is different
than what is done here.
One signature scheme with appendix is specified in this document:
RSASSA-PKCS1-v1_5.
The signature scheme with appendix given here follows a general model
similar to that employed in IEEE P1363, by combining signature and
verification primitives with an encoding method for signatures. The
signature generation operations apply a message encoding operation to
a message to produce an encoded message, which is then converted to
an integer message representative. A signature primitive is then
applied to the message representative to produce the signature. The
signature verification operations apply a signature verification
primitive to the signature to recover a message representative, which
is then converted to an octet string. The message encoding operation
is again applied to the message, and the result is compared to the
recovered octet string. If there is a match, the signature is
considered valid. (Note that this approach assumes that the signature
and verification primitives have the message-recovery form and the
encoding method is deterministic, as is the case for RSASP1/RSAVP1
and EMSA-PKCS1-v1_5. The signature generation and verification
operations have a different form in P1363 for other primitives and
encoding methods.)
Editor's note. RSA Laboratories is investigating the possibility of
including a scheme based on the PSS encoding methods specified in
[3], which would be recommended for new applications.
8.1 RSASSA-PKCS1-v1_5
RSASSA-PKCS1-v1_5 combines the RSASP1 and RSAVP1 primitives with the
EME-PKCS1-v1_5 encoding method. It is compatible with the IFSSA
scheme defined in the draft P1363 where the signature and
verification primitives are IFSP-RSA1 and IFVP-RSA1 and the message
encoding method is EMSA-PKCS1-v1_5 (which is not defined in P1363).
The length of messages on which RSASSA-PKCS1-v1_5 can operate is
either unrestricted or constrained by a very large number, depending
on the hash function underlying the message encoding method.
Kaliski & Staddon Informational [Page 19]
RFC 2437 PKCS #1: RSA Cryptography Specifications October 1998
Assuming that the hash function in EMSA-PKCS1-v1_5 has appropriate
properties and the key size is sufficiently large, RSASSA-PKCS1-v1_5
provides secure signatures, meaning that it is computationally
infeasible to generate a signature without knowing the private key,
and computationally infeasible to find a message with a given
signature or two messages with the same signature. Also, in the
encoding method EMSA-PKCS1-v1_5, a hash function identifier is
embedded in the encoding. Because of this feature, an adversary must
invert or find collisions of the particular hash function being used;
attacking a different hash function than the one selected by the
signer is not useful to the adversary.
8.1.1 Signature generation operation
RSASSA-PKCS1-V1_5-SIGN (K, M)
Input:
K signer's RSA private ke
M message to be signed, an octet string
Output:
S signature, an octet string of length k, where k is the
length in octets of the modulus n; "message too long" or
"modulus too short"
Steps:
1. Apply the EMSA-PKCS1-v1_5 encoding operation (Section 9.2.1) to
the message M to produce an encoded message EM of length k-1 octets:
EM = EMSA-PKCS1-V1_5-ENCODE (M, k-1)
If the encoding operation outputs "message too long," then output
"message too long" and stop. If the encoding operation outputs
"intended encoded message length too short" then output "modulus too
short".
2. Convert the encoded message EM to an integer message
representative m: m = OS2IP (EM)
3. Apply the RSASP1 signature primitive (Section 5.2.1) to the
private key K and the message representative m to produce an integer
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -