Implementation Guidance for the PKCS #1 RSA Cryptography Specification
draft-irtf-cfrg-rsa-guidance-01
This document is an Internet-Draft (I-D) that has been submitted to the Internet Research Task Force (IRTF) stream.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Alicja Kario | ||
| Last updated | 2024-09-03 (Latest revision 2024-03-04) | ||
| Replaces | draft-kario-rsa-guidance | ||
| RFC stream | Internet Research Task Force (IRTF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | IRTF state | (None) | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-irtf-cfrg-rsa-guidance-01
Internet Engineering Task Force A. Kario
Internet-Draft Red Hat, Inc.
Updates: 8017 (if approved) 3 September 2024
Intended status: Informational
Expires: 7 March 2025
Implementation Guidance for the PKCS #1 RSA Cryptography Specification
draft-irtf-cfrg-rsa-guidance-01
Abstract
This document specifies additions and amendments to RFC 8017.
Specifically, it provides guidance to implementers of the standard to
protect against side-channel attacks. It also deprecates the RSAES-
PKCS-v1_5 encryption scheme, but provides an alternative depadding
algorithm that protects against side-channel attacks raising from
users of vulnerable APIs. The purpose of this specification is to
increase security of RSA implementations.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 March 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kario Expires 7 March 2025 [Page 1]
Internet-Draft RSA Implementation Guidance September 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
4. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Side channel attacks . . . . . . . . . . . . . . . . . . . . 4
6. General recommendations . . . . . . . . . . . . . . . . . . . 5
7. Side-channel free modular exponentiation . . . . . . . . . . 5
7.1. General recommendations . . . . . . . . . . . . . . . . . 5
7.2. Montgomery ladder . . . . . . . . . . . . . . . . . . . . 6
7.3. Montgomery reduction in multiplication . . . . . . . . . 6
8. Base blinding . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Exponent blinding . . . . . . . . . . . . . . . . . . . . . . 7
10. Modulus blinding . . . . . . . . . . . . . . . . . . . . . . 8
11. Depadding . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. IRPRF . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.2. Implicit rejection . . . . . . . . . . . . . . . . . . . 10
12. Safe API . . . . . . . . . . . . . . . . . . . . . . . . . . 13
13. Non-fixes . . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Random delays . . . . . . . . . . . . . . . . . . . . . 13
13.2. Returing random value from API . . . . . . . . . . . . . 14
14. Deprecated Algorithms . . . . . . . . . . . . . . . . . . . . 14
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
16. Security Considerations . . . . . . . . . . . . . . . . . . . 15
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
17.1. Normative References . . . . . . . . . . . . . . . . . . 15
17.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 17
A.1. 2048 bit key . . . . . . . . . . . . . . . . . . . . . . 17
A.1.1. Private key . . . . . . . . . . . . . . . . . . . . . 17
A.1.2. Valid . . . . . . . . . . . . . . . . . . . . . . . . 18
A.1.3. Valid . . . . . . . . . . . . . . . . . . . . . . . . 19
A.1.4. Valid with ciphertext starting with a zero byte . . . 19
A.1.5. Invalid decrypting to empty . . . . . . . . . . . . . 19
A.1.6. Invalid decrypting to max size . . . . . . . . . . . 20
A.1.7. Invalid with second to last length . . . . . . . . . 20
A.1.8. Invalid first byte of padding . . . . . . . . . . . . 20
A.1.9. Invalid second byte of padding . . . . . . . . . . . 21
Kario Expires 7 March 2025 [Page 2]
Internet-Draft RSA Implementation Guidance September 2024
A.1.10. Invalid with zero length PS . . . . . . . . . . . . . 21
A.1.11. Invalid with null byte at the eight byte of
padding . . . . . . . . . . . . . . . . . . . . . . . 22
A.1.12. Invalid with padding separator missing . . . . . . . 22
A.2. 2049 bit key . . . . . . . . . . . . . . . . . . . . . . 22
A.3. 3072 bit key . . . . . . . . . . . . . . . . . . . . . . 22
A.4. 4096 bit key . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
The PKCS #1 [RFC8017] describes the RSA cryptosystem, providing
guidance on implementing encryption schemes and signature schemes.
Unfortunately, straight-forward implementation of the RSA encryption
schemes leave it vulnerable to side-channel attacks. Protections
against them are not documented in RFC 8017, and attacks are
mentioned only in passing.
2. Rationale
The RSAES-PKCS-v1_5 encryption scheme is known to be problematic
since 1998, when Daniel Bleichenbacher published his attack
[Bleichenbacher98]. Side-channel attacks against public key
algorithms, including RSA, are known to be possible since 1996 thanks
to work by Paul Kocher [Kocher96].
Despite those results, side-channel attacks against RSA
implementations have proliferated for the next 25 years. Including
attacks against simple exponentiation implementations
[Dhem98][Schindler01], implementations that use the Chinese Remainder
Theorem optimisation [Schindler00][Brumley03] [Aciicmez05], and
implementations that use either base or exponent blinding exclusively
[Aciicmez07][Aciicmez08] [Schindler14].
Similarly, side-channel free handling of the errors from the RSAES-
PKCS-v1_5 decryption operation is something that implementations
struggle with [Bock18][Kario23].
We thus provide guidance how to implement those algorithms in a way
that should be secure against at least the simple timing side channel
attacks.
3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Kario Expires 7 March 2025 [Page 3]
Internet-Draft RSA Implementation Guidance September 2024
4. Notation
In this document we reuse the notation from RFC 8017, in addition, we
define the following:
AL alternative message length, non-negative integer, 0 <= AL <= k -
11
AM alternative encoded message, an octet string
bb base blinding factor, a positive integer
bbInv base un-blinding factor, a positive integer,
bbInv = bb^(-1) mod n
D octet string representation of d
DH an octet string of a SHA-256 hash of D
KDK an octet string containing a Key Derivation Key for a specific
ciphertext C
l length in octets of the message M
b_i an exponent blinding factor for i-th prime, non-negative
integer.
g_i a modulus blinding factor for the i-th prime, non-negative
integer.
5. Side channel attacks
Cryptographic implementations may provide a lot of indirect signals
to the attacker that includes information about the secret processed
data. Depending on type of information, those leaks can be used to
decrypt data or retrieve private keys. Most common side-channels
that leak information about secret data are:
1. Different errors returned
2. Different processing times of operations
3. Different patterns of jump instructions and memory accesses
4. Use of hardware instructions that take different amount time to
execute depending on operands or result
Kario Expires 7 March 2025 [Page 4]
Internet-Draft RSA Implementation Guidance September 2024
Some of those leaks may be detectable over the network, while others
may require closer access to the attacked system. With closer
access, the attacker may be able to measure power usage,
electromagnetic emanations, or sounds and correlate them with
specific bits of secret information.
Recent research into network based side channel detection has shown
that even very small side channels (of just few clock cycles) can be
reliably detected over the network. The detectability depends on the
sample size the attacker is able to collect, not on size of the side-
channel.
6. General recommendations
As a general rule, all operations that process secret information (be
it parts of the private key or parts of encrypted message) MUST be
performed with code that doesn't have secret data dependent branch
instructions, secret data dependent memory accesses, or uses non-
constant time machine instructions (which ones are those is
architecture dependant, but division is commonly non-constant time).
Special care should be placed around the code that handles the
conversion of the numerical representation to the octet string
representation in RSA decryption operations.
All operations that use private keys SHOULD additionally employ both
base blinding and exponent blinding as protections against leaks
inside modular exponentiation code.
7. Side-channel free modular exponentiation
The underlying modular exponentiation algorithm MUST be constant time
with regards to the exponent in all uses of the private key.
For private key decryption the modular exponentiation algorithm MUST
be constant time with regards to the output of the exponentiation.
In case the Chinese remainder theorem optimisation is used the
modular exponentiation algorithm must also be constant time with
regards to the used moduli.
7.1. General recommendations
It's especially important to make sure that all values that are
secret to the attacker are stored in memory buffers that have sizes
determined by the public modulus.
Kario Expires 7 March 2025 [Page 5]
Internet-Draft RSA Implementation Guidance September 2024
For example, the private exponents should be stored in memory buffers
that have sizes determined by the public modulus value, not the
numerical values of the exponents themselves.
Similarly, the size of the output buffer for multiplication should
always be equal to the sum of buffer sizes of multiplicands. The
output size of the modular reduction operation should similarly be
equal to the size of the modulus and not depend on bit size of the
output.
7.2. Montgomery ladder
For the modular exponentiation algorithm to be side-channel free
every step of the calculation MUST NOT depend on the bits of the
exponent. In particular, use of simple square and multiply algorithm
will leak information about bits of the exponent through lack of
multiplication operation in individual exponentiation steps.
The recommended workaround against it, is the use of the Montgomery
ladder construction.
While that approach ensures that both the square and multiply
operations are performed, the fact that the results of them are
placed in different memory locations based on bits of the secret
exponent will provide enough information for an attacker to recover
the bits of the exponent. To counteract it, the implementation
should ensure that both memory locations are accessed and updated on
every step.
7.3. Montgomery reduction in multiplication
As multiplication operations quickly make the intermediate values in
modular exponentiation large, performing a modular reduction after
every multiplication or squaring operation is a common optimisation.
To further optimise the modular reduction, the Montgomery modular
multiplication is used for performing the combined multiply-and-
reduce operation. The last step of that operation is conditional on
the value of the output. A side-channel free implementation should
perfom the subtraction in all cases and then copy the result or the
first operand of the subtraction based on sign of the result of the
subtraction in side-channel free manner.
8. Base blinding
As a protection against multiple attacks, it's RECOMMENDED to perform
all operations involving the private key with the use of blinding
[Kocher96].
Kario Expires 7 March 2025 [Page 6]
Internet-Draft RSA Implementation Guidance September 2024
It should be noted that for decryption operations the unblinding
operation MUST be performed using side-channel free code that does
not leak information about the result of this multiplication and
reduction modulo operation.
To implement base blinding, select a number bb uniformly at random
such that it is relatively prime to n and smaller than n.
Compute multiplicative inverse of bb modulo n.
bbInv = bb^(-1) mod n
In the RSADP() operation, after performing step 1, multiply c by bb
mod n. Use the result as new c for all the remaining operations.
Before returning the value m in step 3, multiply it by bbInv mod n.
Note: multiplication by bbInv and reduction modulo n MUST be
performed using side-channel free code with respect to value m.
As calculating multiplicative inverse is expensive, implementations
MAY calculate new values of bb and bbInv by squaring them:
new bb = bb^2 mod n
new bbInv = bbInv^2 mod n
A given pair of blinding factors (bb, bbInv) MUST NOT be used for
more than one RSADP() operation.
Unless the multiplication (squaring) and reduction modulo operations
are verified to be side-channel free, it's RECOMMENDED to generate
completely new blinding parameters every few hundred private key
operations.
9. Exponent blinding
To further protect against private key leaks, it's RECOMMENDED to
perform the blinding of the used exponents [Kocher96].
When performing the RSADP() operation, the blinding depends on the
form of the private key.
If the key is in the first form, the pair (n, d), then the exponent d
should be modified by adding a multiple of Euler phi(n): m = c^(d +
b*phi(n)) mod n. Where b is a 64 bit long uniform random number.
A new value b MUST be selected for every RSADP() operation.
Kario Expires 7 March 2025 [Page 7]
Internet-Draft RSA Implementation Guidance September 2024
If the key is the second form, the quintuple (p, q, dP, dQ, qInv)
with optional sequence of triplets (r_i, d_i, t_i), i = 3, ..., u,
then each exponent used MUST be blinded individually.
1. The m_1 = c^(dP + b_1 * phi(p)) mod p
2. The m_2 = c^(dQ + b_2 * phi(q)) mod q
3. If u > 3, then m_i = c^(d_i + b_i * phi(r_i)) mod (r_i)
Where b_1, b_2, ..., b_i are all uniformly selected random numbers at
least 64 bits long (or at least 2 machine word sizes, whichever is
greater).
As Euler phi(p) for an argument p that's a prime is equal p - 1, it's
simple to calculate in this case.
Note: the selection of random b_i values, multiplication of them by
the result of phi() function, and addition to the exponent MUST be
performed with side-channel free code.
Use of smaller blinding factor is NOT RECOMMENDED, as values shorter
than 64 bits have been shown to still be vulnerable to side-channel
attacks[Bauer12][Schindler11].
The b_1, b_2, ..., b_i factors MUST NOT be reused for multiple
RSADP() operations.
10. Modulus blinding
To protect against private key leaks, it's RECOMMENDED to perform
blinding of the used modulus values in the CRT implementations.
When the key is in the first form, the pair (n, d), then the used
modulus is public, thus no blinding is necessary.
If the key is in the second form, the quintuple (p, q, dP, dQ, qInv)
with the optional sequence f triplets (r_i, d_i, t_i), i = 3, ..., u,
then each modulus used MUST be blinded individually.
1. The m_1 = c^dP mod (g_1 * p)
2. The m_2 = c^dQ mod (g_2 * q)
3. If u > 3, then m_i = c^d_i mod (g_3 * r_i)
Kario Expires 7 March 2025 [Page 8]
Internet-Draft RSA Implementation Guidance September 2024
Where g_1, g_2, ..., g_i are all uniformely selected random number at
least 64 bits long (or at least 2 machine word sizes, whicher is
greater).
Before step 3 of the original algorithm, reduce the returned value m
mod n.
11. Depadding
In case of RSA-OAEP, the padding is self-verifying, thus the
depadding operation needs to follow the standard algorithm to provide
a safe API to users.
It MUST ignore the value of the very fist octet of padding and
process the remaining bytes as if it was equal zero.
The RSAES-PKCS-v1_5 encryption scheme is considered deprecated, and
should be used only to process legacy data. It MUST NOT be used as
part of online protocols or API endpoints.
For implementations that can't remove support for this padding mode
it's RECOMMENDED to implement an implicit rejection mechanism that
completely hides from the calling code whether the padding check
failed or not.
It should be noted that the algorithm MUST be implemented as stated,
otherwise in case of heteregonous environments where two
implementations use the same key but implement the implicit rejection
differently, it may be possible for the attacker to compare behaviour
between the implementations to guess if the padding check failed or
not.
The basic idea of the implicit rejection is to prepare a random but
deterministic message to be returned in case the standard RSAES-PKCS-
v1_5 padding checks fail. To do that, use the private key and the
provided ciphertext to derive a static, but unknown to the attacker,
random value. It's a combination of the method documented in the TLS
1.2 (RFC 5246[RFC5246]) and the deterministic (EC)DSA signatures (RFC
6979 [RFC6979]).
11.1. IRPRF
For the calculation of the random message for implicit rejection we
define a Pseudo-Random Function (PRF) as follows:
IRPRF( KDK, label, length )
Input:
Kario Expires 7 March 2025 [Page 9]
Internet-Draft RSA Implementation Guidance September 2024
KDK the key derivation key
label a label making the output unique for a given KDK
length requested length of output in octets
Output: derived key, an octet string
Steps:
1. If KDK is not 32 octets long, or if length is larger than 8192
return error and stop.
2. The returned value is created by concatenation of subsequent
calls to a SHA-256 HMAC function with the KDK as the HMAC key and
following octet string as the message:
P_i = I || label || bitLength
3. Where the I is an iterator value encoded as two octet long big
endian integer, label is the passed in label, and bitLength is
the length times 8 (to represent number of bits of output)
encoded as two octet big endian integer. The iterator is
initialised to 0 on first call, and then incremented by 1 for
every subsequent HMAC call.
4. The HMAC is iterated until the concatenated output is shorter
than length
5. The output is the length left-most octets of the concatenated
HMAC output
11.2. Implicit rejection
For implementations that cannot remove support for the RSAES-PKCS-
v1_5 encryption scheme nor provide a usage-specific API, it's
possible to implement an implicit rejection algorithm as a protection
measure. It should be noted that implementing it correctly is hard,
thus it's RECOMMENDED instead to disable support for RSAES-PKCS-v1_5
padding instead.
To implement implicit rejection, the RSAES-PKCS1-V1_5-DECRYPT from
section 7.2.2 of RFC 8017 needs to be implemented as follows:
1. Length checking: If the length of the ciphertext C is not k
octets (or if k < 11), output "decryption error" and stop.
2. RSA decryption:
Kario Expires 7 March 2025 [Page 10]
Internet-Draft RSA Implementation Guidance September 2024
a. Convert the ciphertext C to an integer ciphertext
representative c:
c = OS2IP (C).
b. Apply the RSADP decryption primitive to the RSA private key
(n, d) and the ciphertext representative c to produce an
integer message representative m:
m = RSADP ((n, d), c).
Note: the RSADP MUST be constant-time with respect of message
m.
If RSADP outputs "ciphertext representative out of range"
(meaning that c >= n), output "decryption error" and stop.
c. Convert the message representative m to an encoded message EM
of length k octets:
EM = I2OSP (m, k).
Note: I2OSP MUST be constant-time with respect of m.
3. Derivation of alternative message
1. Derive the Key Derivation Key (KDK)
a. Convert the private exponent d to a string of length k
octets:
D = I2OSP (d, k).
b. Hash the private exponent using the SHA-256 algorithm:
DH = SHA256 (D).
Note: This value MAY be cached between the decryption
operations, but MUST be considered private-key
equivalent.
c. Use the DH as the SHA-256 HMAC key and the provided
ciphertext C as the message. If the ciphertext C is not
k octets long, it MUST be left padded with octets of
value zero.
KDK = HMAC (DH, C, SHA256).
Kario Expires 7 March 2025 [Page 11]
Internet-Draft RSA Implementation Guidance September 2024
2. Create the candidate lengths and the random message
a. Use the IRPRF with key KDK, "length" as six octet label
encoded with UTF-8, to generate 256 octet output.
Interpret this output as 128 two octet long big-endian
numbers.
CL = IRPRF (KDK, "length", 256).
b. Use the IRPRF with key KDK, "message" as a seven octet
label encoded with UTF-8 to generate k octet long output
to be used as the alternative message:
AM = IRPRF (KDK, "message", k).
3. Select the alternative length for the alternative message.
Note: this must be performed in side-channel free way.
a. Iterate over the 128 candidate CL lengths. For each zero
out high order bits so that they have the same bit length
as the maximum valid message size (k - 11).
b. Select the last length that's not larger than k - 11, use
0 if none are. Save it as AL.
4. EME-PKCS1-v1_5 decoding: Separate the encoded message EM into an
octet string PS consisting of nonzero octets and a message M as
EM = 0x00 || 0x02 || PS || 0x00 || M.
If the first octet of EM does not have hexadecimal value 0x00, if
the second octet of EM does not have hexadecimal value 0x02, if
there is no octet with hexadecimal value 0x00 to separate PS from
M, or if the length of PS is less than 8 octets, the check
variable must remember if any of those checks failed.
Irrespective of the check variable value, the code should also
return length of message M: L. If there is no octet with
hexadecimal value 0x00 to separate PS from M, then L should equal
0.
Note: All those checks MUST be performed irrespective if previous
checks failed or not. A common technique for that is to have a
check variable that is OR-ed with the results of subsequent
checks.
Kario Expires 7 March 2025 [Page 12]
Internet-Draft RSA Implementation Guidance September 2024
5. Decision which message to return: in case the check variable is
set, the code should return the last AL octets of AM, in case the
check variable is unset the code should return the last L octets
of EM.
Note: The decision which length to use MUST be performed in side-
channel free manner. While the length of the returned message is
not considered sensitive, the read memory location is. As such,
when returning message M both EM and AM memory locations MUST be
read.
12. Safe API
Performing all actions in a way that doesn't leak the status of the
padding check includes the API provided to 3rd party code. In
particular, if the RSA decryption implementation doesn't implement
implicit rejection, then all three pieces of information: the padding
check, the length of returned message, and the value of the message
are sensitive information, useful in mounting an attack. As such,
any API that returns an error in substantially different manner than
a successful decryption (e.g. raising an exception, returning a null
pointer, returning a different type of structure) is vulnerable to
side-channel attacks.
13. Non-fixes
While there are infinite ways to implement those algorithms
incorrectly few common ideas to work-around side-channel attacks are
repeated. We list few of them as examples of approaches that don't
work and thus MUST NOT be used.
13.1. Random delays
Commonly proposed workaround for timing attacks is to add a random
delay to procesing of encrypted data. For such mitigation to be
effective in practice (raise attacker's work factor to gain
meaningful safety margin) it would need to be in the order of at
least few seconds if not tens of seconds. Effective sizes and
distributions of delays have not been subject of extensive study.
It should also be noted that such a delay would need to be applied in
addition to the regular mitigation (generate random key, use it in
case RSAES-PKCS-v1_5 padding checks). That is, it needs to be
implemented in the calling code, not in the depadding code.
At the same time, performing a simple wait masks only the timing side
channel. It doesn't mitigate other side-channels, like ones that
depend on power usage or memory access pattern.
Kario Expires 7 March 2025 [Page 13]
Internet-Draft RSA Implementation Guidance September 2024
13.2. Returing random value from API
A simpler variant of the proposed implicit rejection algorithm, where
the decryption API returns a random message in case the padding check
fails or the decrypted message has unexpected length, as described in
[RFC5246], isn't a universal mitigation.
In case of a Bleichenbacher like attack, the attacker is trying to
differentiate two classes of ciphertexts: ones that decrypt to
message of specific size and ones that have invalid padding or
decrypt to a message of unexpected size. That translates to two kind
of values being returned to calling code: either the same message
always for every decryption, or a different message for every
decryption.
If that message is later used in any operation that is not side-
channel free (key derivation, symmetric padding removal, message
parsing), then the attacker will be able to observe two kinds of
behaviour: consistent one for static messages and erratic one for
randomly generated messages.
Use of such a message as a key with block cipher modes that require
padding, like AES-CBC with PKCS #7 padding, is particularly leaky as
it has about 1 in 256 chance of successful decryption with random
key.
The simple implicit rejection with random message may be implemented
safely in TLS 1.2 because both static messages and randomly generated
messages are mixed together with the random nonce generated by the
server, thus the attacker is unable to differentiate if the
randomness originates in the nonce or in the randomisation of the
message.
14. Deprecated Algorithms
Current protocol deployments MUST NOT use encryption with RSAES-PKCS-
v1_5 padding. Support for RSAES-PKCS-v1_5 SHOULD be disabled in
default configuration of any implementation of RSA cryptosystem. All
new protocols MUST NOT specify RSAES-PKCS-v1_5 as a valid encryption
padding for RSA keys.
15. IANA Considerations
This memo includes no request to IANA.
Kario Expires 7 March 2025 [Page 14]
Internet-Draft RSA Implementation Guidance September 2024
16. Security Considerations
This whole document specifies security considerations for RSA
implementations.
17. References
17.1. Normative References
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
17.2. Informative References
[Aciicmez05]
Acıiçmez, O., Schindler, W., and Ç. K. Koç, "Improving
Brumley and Boneh timing attack on unprotected SSL
implementations", Proceedings of the 12th ACM conference
on Computer and communications security CCS '05, 2005,
<https://doi.org/10.1145/1102120.1102140>.
[Aciicmez07]
Acıiçmez, O. and W. Schindler, "A Major Vulnerability in
RSA Implementations due to MicroArchitectural Analysis
Threat", Cryptology ePrint Archive Paper 2007/336, 2007,
<https://eprint.iacr.org/2007/336>.
[Aciicmez08]
Acıiçmez, O. and W. Schindler, "A Vulnerability in RSA
Implementations Due to Instruction Cache Analysis and Its
Demonstration on OpenSSL", Lecture Notes in Computer
Science vol 4964, 2007,
<https://doi.org/10.1007/978-3-540-79263-5_16>.
[Bauer12] Bauer, S., "Attacking Exponent Blinding in RSA without
CRT", Lecture Notes in Computer Science vol 7275, 2012,
<https://doi.org/10.1007/978-3-642-29912-4_7>.
[Bleichenbacher98]
Bleichenbacher, D., "Chosen Ciphertext Attacks Against
Protocols Based on the RSA Encryption Standard PKCS#1",
Lecture Notes in Computer Science vol 1462,
<https://doi.org/10.1007/BFb0055716>.
Kario Expires 7 March 2025 [Page 15]
Internet-Draft RSA Implementation Guidance September 2024
[Bock18] Böck, H., Somorovsky, J., and C. Young, "Return Of
Bleichenbacher's Oracle Threat (ROBOT)", 27th USENIX
Security Symposium USENIX Security 18, 2018,
<https://www.usenix.org/conference/usenixsecurity18/
presentation/bock>.
[Brumley03]
Brumley, D. and D. Boneh, "Remote timing attacks are
practical", Computer Networks Volume 48, Issue 5, 2003,
<https://doi.org/10.1016/j.comnet.2005.01.010>.
[Dhem98] Dhem, J., Koeune, F., Leroux, P., Mestré, P., Quisquater,
J., and J. Willems, "A Practical Implementation of the
Timing Attack", Lecture Notes in Computer Science vol
1820, 1998, <https://doi.org/10.1007/10721064_15>.
[Kario23] Kario, H., "Everlasting ROBOT: the Marvin Attack", 28th
European Symposium on Research in Computer Security ,
2023, <https://eprint.iacr.org/2023/1442>.
[Kocher96] Kocher, P. C., "Timing Attacks on Implementations of
Diffie-Hellman, RSA, DSS, and Other Systems.", Lecture
Notes in Computer Science vol 1109, 1996,
<https://doi.org/10.1007/3-540-68697-5_9>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>.
[Schindler00]
Schindler, W., "A Timing Attack against RSA with the
Chinese Remainder Theorem", Lecture Notes in Computer
Science vol 1965, 2000,
<https://doi.org/10.1007/3-540-44499-8_8>.
Kario Expires 7 March 2025 [Page 16]
Internet-Draft RSA Implementation Guidance September 2024
[Schindler01]
Schindler, W., Koeune, F., and J. Quisquater, "Improving
Divide and Conquer Attacks against Cryptosystems by Better
Error Detection / Correction Strategies.", Lecture Notes
in Computer Science vol 2260, 2001,
<https://doi.org/10.1007/3-540-45325-3_22>.
[Schindler11]
Schindler, W. and K. Itoh, "Exponent Blinding Does Not
Always Lift (Partial) Spa Resistance to Higher-Level
Security", Lecture Notes in Computer Science vol 6715,
2011, <https://doi.org/10.1007/978-3-642-21554-4_5>.
[Schindler14]
Schindler, W. and A. Wiemers, "Power attacks in the
presence of exponent blinding.", Journal of Cryptographic
Engineering 4, 2014,
<https://doi.org/10.1007/s13389-014-0081-y>.
Appendix A. Test Vectors
A.1. 2048 bit key
«for verification of test vectors see: https://github.com/tlsfuzzer/
tlslite-ng/blob/master/unit_tests/test_tlslite_utils_rsakey.py#L1694»
A.1.1. Private key
Private key to use for decryption of following test data
Kario Expires 7 March 2025 [Page 17]
Internet-Draft RSA Implementation Guidance September 2024
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDIzIOXFAmNpWyq
I2QPk9yJl8FjcpaPwbDG31ETwclOiyHkitIpfmVBkBG05tj15zsbeLJXQAMh0e9r
YC1OyM6NFByUkF60rTBmOaSSBlNLbn8mB0I+l9/9EzyI1yE5ne+8fpbM3L1/Oq4f
6JJxK/tJKYF9URZmRAofrLeiCPXqFlkQrdij8tSXICNgzLYyAk8NBxacGRjzFveU
sUOu9U7IdSKkwCl4+WiZgL/79knDB+gYGb/4hAljjUi9lL4VK1n/ZJ+gvWKdD/oY
E8Or9LVr08LqVGXf+hRYkpKp2KJK0mvn7gUQdBtjgtQ8g9W/pApGYT0GK+RFUX28
rwy04adpAgMBAAECggEAFFUBDg8tWHZjpmam/xzNu/Dt2BAGRtAqAjkikImSxK05
5VZZKXJu9lCMOnEVjvC2/3UdOdB1gLstLwYyEEQtBgP/UNu9ezX+LJuxmkehr4Wk
wkkB4CyotYt5GbIO3zKqz79RrbS8S2G5t+loyqTVcPcO8Y2AYyKIk+R9Q578p5Ml
m88s0Qij2GiM3weOeseZlp8jOdLB9SK5aWhGKakzuq7CaBYl6rhPTlb0RH6diPua
GZz3ECPg4lexREGzPITTvGfKgDHSYSYYEDp6CkCEQmL3XYiQzWFuUfkDVIj9bgmd
6P9tZaT/EYJUgHyfWNL7uouhUdyMaL40nJd6IE4EwQKBgQD49a1rqCiTG+pFm4o/
bcBB0jSCQJwlcelj8x90hgKiVjcbOIPtRZ7PlwUmRZ7dFuBVIvWkXZR1Gy7C2vJy
x/iBalLADRgIAXFjTaiZ15cyIvUbk3YwVIaWqffYwkpZSXwe/NRVz7l+6G0rbTSX
KzMv2jA/BJmbTra1zAuzPndh3QKBgQDOei47SakLljMKEtxoK9+9+66N1twDthR6
771XV0Pw9tpNhiNQYbca/ZytLTQCXlashrD3dD6zXhrLyiN4lUJEZbcG7SIXXlcY
yMcLZwPqj2tRD5Rb5I5aNrs8PJFzK1id/AXXLYCQMZRFK9ohNIZH7HKUPxGoRuYv
rr6OtTaw/QKBgHb+FfGK4jnN8d9rRFykvGu5aNeIwhkzpPXc0oADPWcSBizAim3y
BMH70L5GMHRD5t1KZFY3VCnU4DjKJW+vHJvekcaxe3b4GZX5HEjLvrx78ONJTAg1
nk6M1qWH17ltYiH9fg+1xVdfCC7ld2l5gHGyu7SjIjgVG0cxS7ZUeQMRAoGBAJmI
SLBVSZoQCcvH0pSzax/98gIObnNkBT6U3hoADck0BYf34nJ29ozfYI11O2M3ewO2
9AhNLAJ8SziWCmIzup7Zc4t28Q6nW+RWB4v3AfZ8xrPz/cGG5kM2x2s3LoCRDsgL
CtzCPQL7muEEhqKCSAdbTqflbd/POILkUVYUcaKRAoGAZDv3RkKffYNmegZTAhNH
77/AXmNR+CGp3rtg4OzN5QBa2ensMeVY9+ksKTKOdFadfO98dMq8KzVe1AGhoJFL
Tjy7BkhOWBlgURae0UyqLvpuoETgVNJhRMwWKcVQEFWKBOEz9Et8JE2sJb+RPFe4
kO5J9UglnNY0BP72hZ3Pl1o=
-----END PRIVATE KEY-----
A.1.2. Valid
Hex encoded ciphertext:
8bfe264e85d3bdeaa6b8851b8e3b956ee3d226fd3f69063a86880173a273d9f2
83b2eebdd1ed35f7e02d91c571981b6737d5320bd8396b0f3ad5b019daec1b0a
ab3cbbc026395f4fd14f13673f2dfc81f9b660ec26ac381e6db3299b4e460b43
fab9955df2b3cfaa20e900e19c856238fd371899c2bf2ce8c868b76754e5db3b
036533fd603746be13c10d4e3e6022ebc905d20c2a7f32b215a4cd53b3f44ca1
c327d2c2b651145821c08396c89071f665349c25e44d2733cd9305985ceef643
0c3cf57af5fa224089221218fa34737c79c446d28a94c41c96e4e92ac53fbcf3
84dea8419ea089f8784445a492c812eb0d409467f75afd7d4d1078886205a066
ASCII encoded decrypted message:
lorem ipsum dolor sit amet
Kario Expires 7 March 2025 [Page 18]
Internet-Draft RSA Implementation Guidance September 2024
A.1.3. Valid
Hex encoded ciphertext:
443ad9c5f00a1f4e9601717d274aacc93a824cb4d99b3c6a42e2b017e52e0184
43bd77d34a80703cd9b6acf523cd3b2cd1fea31940a68fba828836f1c3ed2fef
071e95e0922ff0f47d0e81dacc13ecdeda3db6476f41e5b3f9ccfcfdf9155800
7b68ffbbe5e93bb088f1e4f0bb39bc7d8600b38930ecd00a341d8cc76955837e
fff0f0797c4b46fb1b375bba49bcdc877f39aaadb045c56b836072383eec6627
ae280ad4f9a45d6e5b4cc7cf61d42b194ff0b9c9167c621e5380d8333e3b7f20
c8d564c9ec6c2805f77c0146adea2f688a943b67ce8889f4a6353e6396d551c3
6a6dbf19359a825d14b69ccc4fd747cf14a1ca8578d7f0a67dc14b37f5e17ca3
The result of decryption is a message of length 0.
A.1.4. Valid with ciphertext starting with a zero byte
Hex encoded ciphertext:
00a2e8f114ea8d05d12dc843e3cc3b2edc8229ff2a028bda29ba9d55e3cd0291
1902fef1f42a075bf05e8016e8567213d6f260fa49e360779dd81aeea3e04c2c
b567e0d72b98bf754014561b7511e083d20e0bfb9cd23f8a0d3c88900c49d2fc
d5843ff0765607b2026f28202a87aa94678aed22a0c20724541394cd8f44e373
eba1d2bae98f516c1e2ba3d86852d064f856b1daf24795e767a2b90396e50743
e3150664afab131fe40ea405dcf572dd1079af1d3f0392ccadcca0a12740dbb2
13b925ca2a06b1bc1383e83a658c82ba2e7427342379084d5f66b544579f0766
4cb26edd4f10fd913fdbc0de05ef887d4d1ec1ac95652397ea7fd4e4759fda8b
ASCII encoded message:
lorem ipsum
A.1.5. Invalid decrypting to empty
Hex encoded ciphertext:
20aaa8adbbc593a924ba1c5c7990b5c2242ae4b99d0fe636a19a4cf754edbcee
774e472fe028160ed42634f8864900cb514006da642cae6ae8c7d087caebcfa6
dad1551301e130344989a1d462d4164505f6393933450c67bc6d39d8f5160907
cabc251b737925a1cf21e5c6aa5781b7769f6a2a583d97cce008c0f8b6add5f0
b2bd80bee60237aa39bb20719fe75749f4bc4e42466ef5a861ae3a92395c7d85
8d430bfe38040f445ea93fa2958b503539800ffa5ce5f8cf51fa8171a91f36cb
4f4575e8de6b4d3f096ee140b938fd2f50ee13f0d050222e2a72b0a3069ff3a6
738e82c87090caa5aed4fcbe882c49646aa250b98f12f83c8d528113614a29e7
The result of decryption is a message of length 0.
Kario Expires 7 March 2025 [Page 19]
Internet-Draft RSA Implementation Guidance September 2024
A.1.6. Invalid decrypting to max size
Hex encoded ciphertext:
48cceab10f39a4db32f60074feea473cbcdb7accf92e150417f76b44756b190e
843e79ec12aa85083a21f5437e7bad0a60482e601198f9d86923239c8786ee72
8285afd0937f7dde12717f28389843d7375912b07b991f4fdb0190fced8ba665
314367e8c5f9d2981d0f5128feeb46cb50fc237e64438a86df198dd0209364ae
3a842d77532b66b7ef263b83b1541ed671b120dfd660462e2107a4ee7b964e73
4a7bd68d90dda61770658a3c242948532da32648687e0318286473f675b412d6
468f013f14d760a358dfcad3cda2afeec5e268a37d250c37f722f468a70dfd92
d7294c3c1ee1e7f8843b7d16f9f37ef35748c3ae93aa155cdcdfeb4e78567303
Hex encoded decrypted message:
22d850137b9eebe092b24f602dc5bb7918c16bd89ddbf20467b119d205f9c2e4
bd7d2592cf1e532106e0f33557565923c73a02d4f09c0c22bea89148183e6031
7f7028b3aa1f261f91c979393101d7e15f4067e63979b32751658ef769610fe9
7cf9cef3278b3117d384051c3b1d82c251c2305418c8f6840530e631aad63e70
e20e025bcd8efb54c92ec6d3b106a2f8e64eeff7d38495b0fc50c97138af4b1c
0a67a1c4e27b077b8439332edfa8608dfeae653cd6a628ac550395f7e74390e4
2c11682234870925eeaa1fa71b76cf1f2ee3bda69f6717033ff8b7c95c9799e7
a3bea5e7e4a1c359772fb6b1c6e6c516661dfe30c3
A.1.7. Invalid with second to last length
The length of the synthetic message comes from second to last value
from the PRF output as the last value is too long for this key size.
Hex encoded ciphertext:
1439e08c3f84c1a7fec74ce07614b20e01f6fa4e8c2a6cffdc3520d8889e5d9a
950c6425798f85d4be38d300ea5695f13ecd4cb389d1ff5b82484b494d6280ab
7fa78e645933981cb934cce8bfcd114cc0e6811eefa47aae20af638a1cd163d2
d3366186d0a07df0c81f6c9f3171cf3561472e98a6006bf75ddb457bed036dcc
e199369de7d94ef2c68e8467ee0604eea2b3009479162a7891ba5c40cab17f49
e1c438cb6eaea4f76ce23cce0e483ff0e96fa790ea15be67671814342d0a23f4
a20262b6182e72f3a67cd289711503c85516a9ed225422f98b116f1ab080a80a
bd6f0216df88d8cfd67c139243be8dd78502a7aaf6bc99d7da71bcdf627e7354
Hex encoded decrypted message:
0f9b
A.1.8. Invalid first byte of padding
Otherwise valid plaintext, but with first byte equal to 0x01 instead
of 0x00.
Kario Expires 7 March 2025 [Page 20]
Internet-Draft RSA Implementation Guidance September 2024
Hex encoded ciphertext:
9b2ec9c0c917c98f1ad3d0119aec6be51ae3106e9af1914d48600ab6a2c0c0c8
ae02a2dc3039906ff3aac904af32ec798fd65f3ad1afa2e69400e7c1de81f572
8f3b3291f38263bc7a90a0563e43ce7a0d4ee9c0d8a716621ca5d3d081188769
ce1b131af7d35b13dea99153579c86db31fe07d5a2c14d621b77854e48a8df41
b5798563af489a291e417b6a334c63222627376118c02c53b6e86310f728734f
fc86ef9d7c8bf56c0c841b24b82b59f51aee4526ba1c4268506d301e4ebc498c
6aebb6fd5258c876bf900bac8ca4d309dd522f6a6343599a8bc3760f422c10c7
2d0ad527ce4af1874124ace3d99bb74db8d69d2528db22c3a37644640f95c05f
Hex encoded message:
a1f8c9255c35cfba403ccc
A.1.9. Invalid second byte of padding
Otherwise valid plaintext, but with the second byte equal to 0x01
instead of 0x02.
Hex encoded ciphertext:
782c2b59a21a511243820acedd567c136f6d3090c115232a82a5efb0b178285f
55b5ec2d2bac96bf00d6592ea7cdc3341610c8fb07e527e5e2d20cfaf2c7f23e
375431f45e998929a02f25fd95354c33838090bca838502259e92d86d568bc2c
db132fab2a399593ca60a015dc2bb1afcd64fef8a3834e17e5358d822980dc44
6e845b3ab4702b1ee41fe5db716d92348d5091c15d35a110555a35deb4650a5a
1d2c98025d42d4544f8b32aa6a5e02dc02deaed9a7313b73b49b0d4772a3768b
0ea0db5846ace6569cae677bf67fb0acf3c255dc01ec8400c963b6e49b106772
8b4e563d7e1e1515664347b92ee64db7efb5452357a02fff7fcb7437abc2e579
Hex encoded decrypted message:
e6d700309ca0ed62452254
A.1.10. Invalid with zero length PS
Hex encoded ciphertext:
0096136621faf36d5290b16bd26295de27f895d1faa51c800dafce73d001d607
96cd4e2ac3fa2162131d859cd9da5a0c8a42281d9a63e5f353971b72e36b5722
e4ac444d77f892a5443deb3dca49fa732fe855727196e23c26eeac55eeced826
7a209ebc0f92f4656d64a6c13f7f7ce544ebeb0f668fe3a6c0f189e4bcd5ea12
b73cf63e0c8350ee130dd62f01e5c97a1e13f52fde96a9a1bc9936ce734fdd61
f27b18216f1d6de87f49cf4f2ea821fb8efd1f92cdad529baf7e31aff9bff407
4f2cad2b4243dd15a711adcf7de900851fbd6bcb53dac399d7c880531d06f25f
7002e1aaf1722765865d2c2b902c7736acd27bc6cbd3e38b560e2eecf7d4b576
Kario Expires 7 March 2025 [Page 21]
Internet-Draft RSA Implementation Guidance September 2024
Hex encoded decrypted message:
ba27b1842e7c21c0e7ef6a
A.1.11. Invalid with null byte at the eight byte of padding
This creates a plaintext with PS of 7 bytes
Hex encoded ciphertext:
a7a340675a82c30e22219a55bc07cdf36d47d01834c1834f917f18b517419ce9
de2a96460e745024436470ed85e94297b283537d52189c406a3f533cb405cc6a
9dba46b482ce98b6e3dd52d8fce2237425617e38c11fbc46b61897ef200d01e4
f25f5f6c4c5b38cd0de38ba11908b86595a8036a08a42a3d05b79600a97ac18b
a368a08d6cf6ccb624f6e8002afc75599fba4de3d4f3ba7d208391ebe8d21f82
82b18e2c10869eb2702e68f9176b42b0ddc9d763f0c86ba0ff92c957aaeab76d
9ab8da52ea297ec11d92d770146faa1b300e0f91ef969b53e7d2907ffc984e9a
9c9d11fb7d6cba91972059b46506b035efec6575c46d7114a6b935864858445f
Hex encoded decrypted message:
63cb0bf65fc8255dd29e17
A.1.12. Invalid with padding separator missing
Hex encoded ciphertext:
3d1b97e7aa34eaf1f4fc171ceb11dcfffd9a46a5b6961205b10b302818c1fcc9
f4ec78bf18ea0cee7e9fa5b16fb4c611463b368b3312ac11cf9c06b7cf72b54e
284848a508d3f02328c62c2999d0fb60929f81783c7a256891bc2ff4d91df2af
96a24fc5701a1823af939ce6dbdc510608e3d41eec172ad2d51b9fc61b4217c9
23cadcf5bac321355ef8be5e5f090cdc2bd0c697d9058247db3ad613fdce87d2
955a6d1c948a5160f93da21f731d74137f5d1f53a1923adb513d2e6e1589d44c
c079f4c6ddd471d38ac82d20d8b1d21f8d65f3b6907086809f4123e08d86fb38
729585de026a485d8f0e703fd4772f6668febf67df947b82195fa3867e3a3065
Hex encoded decrypted message:
6f09a0b62699337c497b0b
A.2. 2049 bit key
«provide test vectors here
A.3. 3072 bit key
«provide test vectors here»
Kario Expires 7 March 2025 [Page 22]
Internet-Draft RSA Implementation Guidance September 2024
A.4. 4096 bit key
«provide test vectors here»
Author's Address
Alicja Kario
Red Hat, Inc.
Purkynova 115
61200 Brno
Czech Republic
Email: hkario@redhat.com
Kario Expires 7 March 2025 [Page 23]