RFC Errata
Found 13 records.
Status: Verified (10)
RFC 3447, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", February 2003
Note: This RFC has been obsoleted by RFC 8017
Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec
Errata ID: 592
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 7.1.2 says:
C ciphertext to be decrypted, an octet string of length k,
where k = 2hLen + 2
It should say:
C ciphertext to be decrypted, an octet string of length k,
where k >= 2hLen + 2
Notes:
In the "Input:" section, near the top of the page, the condition
specified for 'k' is too restrictive. {This becomes clear from
the context - see e.g. 'step 1. c.' in mid-page 22.}
Errata ID: 594
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 8.2.2 says:
c. Convert the message representative m to an encoded message
EM of length k octets (see Section 4.1):
EM' = I2OSP (m, k).
It should say:
c. Convert the message representative m to an encoded message
EM of length k octets (see Section 4.1):
EM = I2OSP (m, k).
Notes:
In 'step 2. c.', in fact "EM" is computed, not "EM'" -- as stated
in the text; see also 'step 3.' below.
Errata ID: 595
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 9.1 says:
+-----------+
| M |
+-----------+
|
V
Hash
|
V
+--------+----------+----------+
M' = |Padding1| mHash | salt |
+--------+----------+----------+
|
+--------+----------+ V
DB = |Padding2|maskedseed| Hash
+--------+----------+ |
| |
V | +--+
xor <--- MGF <---| |bc|
| | +--+
| | |
V V V
+-------------------+----------+--+
EM = | maskedDB |maskedseed|bc|
+-------------------+----------+--+
It should say:
+-----------+
| M |
+-----------+
|
V
Hash
|
V
+--------+----------+----------+
M' = |Padding1| mHash | salt |
+--------+----------+----------+
|
+--------+----------+ V
DB = |Padding2| salt | Hash
+--------+----------+ |
| |
V | +--+
xor <--- MGF <---| |bc|
| | +--+
| | |
V V V
+-------------------+----------+--+
EM = | maskedDB | H |bc|
+-------------------+----------+--+
Notes:
Figure 2 names two fields "maskedseed" which in fact are _very_
different, and this nomenclature matches neither the figure
caption given nor the subsequent text -- see e.g. 'step 6.' and
'step 8.' on page 39 and 'step 12.' on page 40.
Errata ID: 633
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 7.1.1 says:
+----------+---------+-------+
DB = | lHash | PS | M |
+----------+---------+-------+
|
+----------+ V
| seed |--> MGF ---> xor
+----------+ |
| |
+--+ V |
|00| xor <----- MGF <-----|
+--+ | |
| | |
V V V
+--+----------+----------------------------+
EM = |00|maskedSeed| maskedDB |
+--+----------+----------------------------+
It should say:
+----------+--------+--+-------+
DB = | lHash | PS |01| M |
+----------+--------+--+-------+
|
+----------+ V
| seed |--> MGF ---> xor
+----------+ |
| |
+--+ V |
|00| xor <----- MGF <-----|
+--+ | |
| | |
V V V
+--+----------+------------------------------+
EM = |00|maskedSeed| maskedDB |
+--+----------+------------------------------+
Errata ID: 635
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section A.2.3 says:
* maskGenAlgorithm identifies the mask generation function. It
shall be an algorithm ID with an OID in the set
PKCS1MGFAlgorithms (see Appendix A.2.1). The default mask
generation function is MGF1 with SHA-1. For MGF1 (and more
generally, ...
It should say:
* maskGenAlgorithm identifies the mask generation function. It
shall be an algorithm ID with an OID in the set
PKCS1MGFAlgorithms (see Appendix A.2.1). The default mask
generation function is MGF1 with SHA-1. For MGF1 (and more
generally, ...
Notes:
The bulleted section for 'maskGenAlgorithm' contains an unexpected
blank line within the second sentence.
Errata ID: 636
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section B.1 says:
Six hash functions are given as examples for the encoding methods in this document: MD2 [33], MD5 [41], SHA-1 [38], and the proposed algorithms SHA-256, SHA-384, and SHA-512 [39].
It should say:
Six hash functions are given as examples for the encoding methods in this document: MD2 [33], MD5 [41], and the algorithms SHA-1, SHA-256, SHA-384, and SHA-512 [38'].
Notes:
RFC 3447 has been published on Feb 04, 2003 (according to the
time stamp of rfc3447.txt on <ftp://ftp.rfc-editor.org/in-notes/>).
The new "Secure Hash Standard", FIPS Pub 180-2 had been published
on "2002 August 1" and became "effective on February 1, 2003" as
specified on page ii of FIPS 180-2, "9. Implementation Schedule".
Both events predate the publishing date of RFC 3447.
Therefore, the first sentence of the second paragraph on page 53 should be as noted above.
Errata ID: 638
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section F says:
[38] National Institute of Standards and Technology (NIST).
FIPS Publication 180-1: Secure Hash Standard. April 1994.
[39] National Institute of Standards and Technology (NIST).
Draft FIPS 180-2: Secure Hash Standard. Draft, May 2001.
Available from http://www.nist.gov/sha/.
It should say:
[38] National Institute of Standards and Technology (NIST).
FIPS Publication 180-2: Secure Hash Standard. August
2002.
Notes:
RFC 3447 has been published on Feb 04, 2003 (according to the
time stamp of rfc3447.txt on <ftp://ftp.rfc-editor.org/in-notes/>).
The new "Secure Hash Standard", FIPS Pub 180-2 had been published
on "2002 August 1" and became "effective on February 1, 2003" as
specified on page ii of FIPS 180-2, "9. Implementation Schedule".
Both events predate the publishing date of RFC 3447.
The reference should be updated as noted above.
Errata ID: 2176
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Verifier Name: Sean Turner
Date Verified: 2011-06-02
Section 7.1.2 says:
K recipient's RSA private key (k denotes the length in octets
of the RSA modulus n)
C ciphertext to be decrypted, an octet string of length k,
where k = 2hLen + 2
It should say:
K recipient's RSA private key (k denotes the length in octets
of the RSA modulus n), where k >= 2hLen + 2
C ciphertext to be decrypted, an octet string of length k
Notes:
k >= 2hLen + 2 belongs to K, not to C.
The >= is already reported in #592.
Errata ID: 593
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 7.1.2 says:
b. Apply the RSADP decryption primitive (Section 5.1.2) to the
RSA private key K and the ciphertext representative c to
produce an integer message representative m:
It should say:
b. Apply the RSADP decryption primitive (Section 5.1.2) to the
RSA private key K and the ciphertext representative c to
produce an integer message representative m:
Notes:
The first line of 'step 2. b.', is indented too much (by 3 chars)
Errata ID: 596
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2003-08-28
Section 9.2 says:
SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00
04 40 || H.
It should say:
SHA-512: (0x)30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00
04 40 || H.
Notes:
The second line of the last example of 'Note 1.' (for SHA-512) is indented too much (by 3 chars).
Status: Held for Document Update (1)
RFC 3447, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", February 2003
Note: This RFC has been obsoleted by RFC 8017
Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec
Errata ID: 2582
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-10-20
Held for Document Update by: Sean Turner
Section 8.1.2 says:
4. If Result = "consistent," output "valid signature." Otherwise,
output "invalid signature."
It should say:
4. If Result = "consistent", output "valid signature". Otherwise,
output "invalid signature".
Notes:
This report acually addresses a previous report, EID=2177,
and provides an improved version of the corrected text.
Note to Verifier: Please merge this Errata Note with EID=2177;
i.e. update the Corrected Text there as shown above, and reject
this Errata Note.
Status: Rejected (2)
RFC 3447, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", February 2003
Note: This RFC has been obsoleted by RFC 8017
Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec
Errata ID: 3716
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Wigginton
Date Reported: 2013-09-02
Rejected by: Kathleen Moriarty
Date Rejected: 2015-03-31
Section 7.1.2 says:
3. EME-OAEP decoding:
a. If the label L is not provided, let L be the empty string. Let
lHash = Hash(L), an octet string of length hLen (see the note
in Section 7.1.1).
b. Separate the encoded message EM into a single octet Y, an octet
string maskedSeed of length hLen, and an octet string maskedDB
of length k - hLen - 1 as
EM = Y || maskedSeed || maskedDB.
c. Let seedMask = MGF(maskedDB, hLen).
It should say:
3. EME-OAEP decoding:
a. If the label L is not provided, let L be the empty string. Let
lHash = Hash(L), an octet string of length hLen (see the note
in Section 7.1.1).
b. Separate the encoded message EM into a single octet Y, an octet
string maskedSeed of length hLen, and an octet string maskedDB
of length k - hLen - 1 as
EM = Y || maskedSeed || maskedDB.
c. Check to see if Y is 00.
Notes:
Per <https://tools.ietf.org/html/rfc3447#page-21> the first byte of EM should be 00 so shouldn't RSAES-OAEP-DECRYPT / EME-OAEP decoding check that?
--VERIFIER NOTES--
Step g includes the check for Y = 0
If there is no octet with hexadecimal value 0x01 to separate PS
from M, if lHash does not equal lHash', or if Y is nonzero,
output "decryption error" and stop. (See the note below.)
Errata ID: 2177
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Constantin Hagemeier
Date Reported: 2010-04-28
Rejected by: Sean Turner
Date Rejected: 2011-06-02
Section 8.1.2 says:
4. If Result = "consistent," output "valid signature." Otherwise,
output "invalid signature."
It should say:
4. If Result = "consistent", output "valid signature", Otherwise,
output "invalid signature."
Notes:
obvious
--VERIFIER NOTES--
This is addressed in errata #2582.