RFC 8121
Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)
RFC 8121: Mutual Authentication Protocol for HTTP 💖
Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3) 🎀
Bestie, this one is from the IETF, published April 2017, and it's an Experimental doc (ISSN 2070-1721) 🧪. It's written by Y. Oiwa, H. Watanabe, H. Takagi (ITRI, AIST), K. Maeda, T. Hayashi (Lepidum), and Y. Ioku. Oiwa, Watanabe, Takagi, and Hayashi are listed with their affiliations. Maeda and Ioku are listed as Individual Contributors. The title block doesn't list anything it obsoletes or updates ✨.
Abstract
This doc specifies the cryptographic algorithms for the Mutual user authentication method for HTTP. So basically it's the crypto math behind the login handshake 🔐💅
Status of This Memo
Okay so this is not an Internet Standards Track spec. It's published so people can examine it, try it out in experimental implementations, and evaluate it 🧪
It defines an Experimental Protocol for the Internet community. It's a product of the IETF and represents IETF consensus. It got public review and was approved for publication by the IESG. Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🤓
If you want the current status, errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc8121 🌸
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 🦋
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc. Any Code Components pulled out of this doc must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 📜
Table of Contents
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Cryptographic Overview (Non-normative) ..........................3
3. Authentication Algorithms .......................................4
3.1. Support Functions and Notations ............................5
3.2. Functions for Discrete-Logarithm Settings ..................6
3.3. Functions for Elliptic-Curve Settings ......................7
4. IANA Considerations .............................................9
5. Security Considerations .........................................9
5.1. General Implementation Considerations ......................9
5.2. Cryptographic Assumptions and Considerations ..............10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................12
Appendix A. (Informative) Group Parameters for Algorithms Based
on the Discrete Logarithm .............................13
Appendix B. (Informative) Derived Numerical Values ................16
Authors' Addresses ................................................171. Introduction ✨
This doc specifies algorithms for the Mutual authentication protocol for HTTP [RFC8120] (hereafter the "core specification") 🌈 These algorithms are built on augmented password-based authenticated key exchange (augmented PAKE) techniques. Specifically, they use one of three key exchange algorithms from ISO 11770-4 ("Information technology - Security techniques - Key management - Part 4: Mechanisms based on weak secrets") [ISO.11770-4.2006] as their base 🧠
Quick recap: the Mutual authentication protocol swaps four values, K_c1, K_s1, VK_c, and VK_s, to do the authenticated key exchanges. It uses the password-derived secret pi and its "augmented version" J(pi). This doc defines the K_c1, K_s1, and J functions for one specific algorithm family 💜
Heads up, from the crypto literature's point of view, the original augmented PAKE functionality gets split up. K_c1 and K_s1 are defined here, and VK_c and VK_s are the "default functions" from Section 12.2 of [RFC8120]. If you're doing security analysis, look at those functions too 🔍
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎯
Throughout this doc, "natural numbers" means non-negative integers, zero included 🔢
This doc treats both the input (domain) and the output (codomain) of hash functions as octet strings. When a natural-number output of a hash function H is needed, it gets written like INT(H(s)) 🧁
2. Cryptographic Overview (Non-normative) 🔮
The cryptographic primitive in this spec is based on a variant of augmented PAKE called "APKAS-AMP" (augmented password-authenticated key agreement scheme, version AMP). T. Kwon proposed it and it was originally submitted to [IEEE-1363.2_2008]. The diagram below shows the general flow of a successful exchange. It's just for informative purposes 🦋 Multiplicative notation is used for group operators, and all modulus operations for finite groups (mod q and mod r) are left out.
C: S_c1 = random
C: K_c1 = g^(S_c1)
----- ID, K_c1 ----->
C: t_1 = H1(K_c1) S: t_1 = H1(K_c1)
S: fetch J = g^pi by ID
S: S_s1 = random
S: K_s1 = (J * K_c1^(t_1))^(S_s1)
<----- K_s1 -----
C: t_2 = H2(K_c1, K_s1) S: t_2 = H2(K_c1, K_s1)
C: z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi))
S: z' = (K_c1 * g^(t_2))^(S_s1)
(assumption at this point: z = z' if authentication succeeded)
C: VK_c = H4(K_c1, K_s1, z) S: VK_c' = H4(K_c1, K_s1, z')
----- VK_c ------->
S: assert(VK_c = VK_c')
C: VK_s' = H3(K_c1, K_s1, z) S: VK_s = H3(K_c1, K_s1, z')
<----- VK_s ------
C: assert(VK_s = VK_s')Note that the concrete (binary) message formats, which map onto HTTP messages, plus the formal equations for the last two messages, are defined in the core specification [RFC8120] 📨 The formal definitions for the values behind the first two messages come in the sections that follow 🌸
3. Authentication Algorithms 💅
This doc specifies one family of algorithms based on APKAS-AMP, meant to be used with [RFC8120]. The family has four authentication algorithms. They only differ in their underlying mathematical groups and security parameters, and they don't add any extra parameters. Here are their tokens 🎀
iso-kam3-dl-2048-sha256: for the 2048-bit discrete-logarithm setting with the SHA-256 hash function.iso-kam3-dl-4096-sha512: for the 4096-bit discrete-logarithm setting with the SHA-512 hash function.iso-kam3-ec-p256-sha256: for the 256-bit prime-field elliptic-curve setting with the SHA-256 hash function.iso-kam3-ec-p521-sha512: for the 521-bit prime-field elliptic-curve setting with the SHA-512 hash function.
For the discrete-logarithm settings, the groups are the 2048-bit and 4096-bit Modular Exponential (MODP) groups from [RFC3526]. Appendix A has the exact specs for the groups and their parameters 🧮 Hash function H is SHA-256 for the 2048-bit group and SHA-512 for the 4096-bit group, as defined in FIPS PUB 180-4 [FIPS.180-4.2015]. The hash iteration count nIterPi is 16384. The parameters "kc1", "ks1", "vkc", and "vks" are represented as base64-fixed-number 🍓
For the elliptic-curve settings, the groups are the elliptic curves over the prime fields P-256 and P-521, as specified in Appendix D.1.2 of FIPS PUB 186-4 [FIPS.186-4.2013] 🌈 Hash function H is SHA-256 for the P-256 curve and SHA-512 for the P-521 curve. The cofactors of these curves are 1. The hash iteration count nIterPi is 16384. The parameters "kc1", "ks1", "vkc", and "vks" are represented as hex-fixed-number ✨
Note: This algorithm is based on the Key Agreement Mechanism 3 (KAM3) as defined in Section 6.3 of ISO/IEC 11770-4 [ISO.11770-4.2006], with a few modifications and improvements. However, implementers should consider this document as normative, because several minor details of the algorithm have changed and major improvements have been made 🚨
3.1. Support Functions and Notations 🧩
The algorithm definitions use the support functions and notations defined below 💖
Decimal notation is used for integers in this spec by default. Integers in hexadecimal notation are prefixed with 0x 🔢
In this doc, the octet(), OCTETS(), and INT() functions are used as defined in the core specification [RFC8120] 📦
Note: The definition of OCTETS() is different from the function GE2OS_x in the original ISO specification. GE2OS_x takes the shortest representation without preceding zeros 🙈
All of the algorithms in this spec use the default functions from Section 12.2 of [RFC8120] to compute the values pi, VK_c, and VK_s 🫶
3.2. Functions for Discrete-Logarithm Settings 💖
okay so this part is where the discrete-log math gets real 🧮 first, the notation: an equation like (x / y mod z) means a natural number w less than z that satisfies (w * y) mod z = x mod z. it's division, but make it modular 🤓
we refer to some domain parameters with these symbols:
- q: for "the prime" that defines the MODP group 🎀
- g: for "the generator" associated with the group 🦋
- r: for the order of the subgroup generated by g 🌸
the function J is defined as:
J(pi) = g^(pi) mod qK_c1 is derived like this:
K_c1 = g^(S_c1) mod qwhere S_c1 is a random integer in the range [1, r-1], and r is the size of the subgroup generated by g. also, S_c1 MUST be larger than log(q)/log(g) (so that g^(S_c1) > q) ✨ this one is a must, no cap.
the server MUST check the condition 1 < K_c1 < q-1 upon reception 🫶
let's make an intermediate value t_1:
t_1 = INT(H(octet(1) | OCTETS(K_c1)))now K_s1 comes from J(pi) and K_c1:
K_s1 = (J(pi) * K_c1^(t_1))^(S_s1) mod qwhere S_s1 is a random number in the range [1, r-1]. the value of K_s1 MUST satisfy 1 < K_s1 < q-1. if that condition isn't held, the server MUST reject the exchange. the client MUST check this condition upon reception 👑
next, another intermediate value, t_2:
t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1)))the client side gets z with this equation:
z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi) mod r) mod qand the server side gets z with this one:
z = (K_c1 * g^(t_2))^(S_s1) mod q(note: the original ISO specification had a message pair that checked the value z along with the "transcript" of the protocol exchange. that job now lives in the functions VK_c and VK_s. 🔍)
3.3. Functions for Elliptic-Curve Settings 🦋
for the elliptic-curve settings, we use these symbols for some domain parameters:
- q: for the prime used to define the group 💜
- G: for the point defined in the underlying group, called "the generator" 🌿
- h: for the cofactor of the group 🍓
- r: for the order of the subgroup generated by G 🧚
the function P(p) turns a curve point p into an integer that represents it, by computing x * 2 + (y mod 2), where (x, y) are the coordinates of point p. P'(z) is the inverse of P, so it turns an integer z back into a point p that satisfies P(p) = z. if such a p exists, it's uniquely defined. if not, z just isn't a valid curve point 🙈
the "+" operator is the elliptic-curve group operation, and [x] * p means integer multiplication of point p. it calculates p + p + ... (x times) ... + p. for the exact algorithms behind those functions, see the literature on elliptic-curve cryptography (for example, Section 3 of [RFC6090]; just know that [RFC6090] uses different notation). 0_E is the infinity point. and (x / y mod z) means the same thing as before: a natural number w less than z that satisfies (w * y) mod z = x mod z 💅
J is defined as:
J(pi) = [pi] * GK_c1 is derived like this:
K_c1 = P(K_c1'), where K_c1' = [S_c1] * Gwhere S_c1 is a random number in the range [1, r-1]. the server MUST check that (1) the received K_c1 represents a valid curve point and (2) [h] * K_c1' is not equal to 0_E 🔥
let's make an intermediate integer t_1:
t_1 = INT(H(octet(1) | OCTETS(K_c1)))K_s1 is derived from J(pi) and K_c1' = P'(K_c1):
K_s1 = P([S_s1] * (J(pi) + [t_1] * K_c1'))where S_s1 is a random number in the range [1, r-1]. the value of K_s1 MUST represent a valid curve point and satisfy [h] * P'(K_s1) <> 0_E. if that isn't satisfied, the server MUST reject the exchange. the client MUST check this condition upon reception 🫶
next, the intermediate integer t_2:
t_2 = INT(H(octet(2) | OCTETS(K_c1) | OCTETS(K_s1)))the client side derives z like this:
z = P([(S_c1 + t_2) / (S_c1 * t_1 + pi) mod r] * P'(K_s1))and the server side derives z like this:
z = P([S_s1] * (P'(K_c1) + [t_2] * G))4. IANA Considerations 🎀
this document adds four new tokens to the "HTTP Mutual Authentication Algorithms" registry 📋
+-------------------------+-----------------------------+-----------+
| Token | Description | Reference |
+-------------------------+-----------------------------+-----------+
| iso-kam3-dl-2048-sha256 | ISO-11770-4 KAM3, | RFC 8121 |
| | 2048-bit DL | |
| | | |
| iso-kam3-dl-4096-sha512 | ISO-11770-4 KAM3, | RFC 8121 |
| | 4096-bit DL | |
| | | |
| iso-kam3-ec-p256-sha256 | ISO-11770-4 KAM3, | RFC 8121 |
| | 256-bit EC | |
| | | |
| iso-kam3-ec-p521-sha512 | ISO-11770-4 KAM3, | RFC 8121 |
| | 521-bit EC | |
+-------------------------+-----------------------------+-----------+5. Security Considerations 🔐
bestie, this section is serious 😭 for the algorithm-independent stuff, go read the Security Considerations section of the core spec, [RFC8120] 🫶
5.1. General Implementation Considerations 🛡️
- during the exchange, the value VK_s, defined in [RFC8120], MUST only be sent when the server has received a correct (expected) value of VK_c. this is a cryptographic requirement, as stated in [ISO.11770-4.2006] 💀
- all random numbers used in these algorithms MUST be cryptographically secure against forward and backward guessing attacks 🎲
- to prevent timing-based side-channel attacks, computation times of all numerical operations on discrete-logarithm group elements and elliptic-curve points MUST be normalized and made independent of the exact values ⏱️
5.2. Cryptographic Assumptions and Considerations 🧠
this subsection is for the people who analyze the security of this algorithm, and for anyone who wants to make a derived work from this spec 🤓
- the treatment of an invalid K_s1 value in the exchange has changed from the original ISO specification, which said the sender should retry with another random S_s1 value. we specify that the exchange must be rejected. why? this condition is less likely to come from an unlucky random S_s1, and more likely from a systematic failure caused by an invalid J(pi) value (which could even mean possible denial-of-service attacks) 😬
- the usual construction of authenticated key exchange algorithms has a key exchange phase and a key verification phase. to avoid security risks or vulnerabilities from mixing values across two or more key exchanges, the verification phase usually involves some kind of exchange transaction to be verified. in the algorithms defined here, those verification steps are part of the generalized definitions of VK_c and VK_s in [RFC8120]. if the algorithm above gets used in other protocols, this aspect MUST be given careful consideration 🔍
- the domain parameters in this document rest on a few assumptions. in the discrete-logarithm setting, q has to be a safe prime (
[(q - 1) / 2]must also be prime), and r should be the largest possible value[(q - 1) / 2]. in the elliptic-curve setting, r has to be prime. implementers who define a variation of this algorithm with different domain parameters SHOULD be attentive to these conditions 🌈
6. References 📚
6.1. Normative References 💜
[FIPS.180-4.2015]
National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
[FIPS.186-4.2013]
National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS PUB 186-4,
DOI 10.6028/NIST.FIPS.186-4, July 2013,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
Diffie-Hellman groups for Internet Key Exchange (IKE)",
RFC 3526, DOI 10.17487/RFC3526, May 2003,
<http://www.rfc-editor.org/info/rfc3526>.
[RFC8120] Oiwa, Y., Watanabe, H., Takagi, H., Maeda, K., Hayashi,
T., and Y. Ioku, "Mutual Authentication Protocol for
HTTP", RFC 8120, DOI 10.17487/RFC8120, April 2017,
<http://www.rfc-editor.org/info/rfc8120>.6.2. Informative References 🦋
[IEEE-1363.2_2008]
IEEE, "IEEE Standard Specifications for Password-Based
Public-Key Cryptographic Techniques", IEEE 1363.2-2008,
DOI 10.1109/ieeestd.2009.4773330,
<http://ieeexplore.ieee.org/servlet/
opac?punumber=4773328>.
[ISO.11770-4.2006]
International Organization for Standardization,
"Information technology -- Security techniques -- Key
management -- Part 4: Mechanisms based on weak secrets",
ISO Standard 11770-4, May 2006,
<http://www.iso.org/iso/iso_catalogue/catalogue_tc/
catalogue_detail.htm?csnumber=39723>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
<http://www.rfc-editor.org/info/rfc6090>.Appendix A. (Informative) Group Parameters for Algorithms Based on the Discrete Logarithm ✨
Okay so this is where the actual numbers live, bestie 🧚 These are the MODP groups that the iso-kam3-dl-2048-sha256 and iso-kam3-dl-4096-sha512 algorithms are built on. Yes, they're giant hex blobs. No, you don't have to memorise them 💀 You just copy them exactly, character for character, because one wrong digit and everything breaks 🙈
The prime for the 2048-bit group is:
q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AACAA68 FFFFFFFF FFFFFFFFThe generator is:
g = 2And the size of the subgroup generated by g is:
r = (q - 1) / 2 =
0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E
E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF
C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36
B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D
F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964
EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288
0AB9472D 45565534 7FFFFFFF FFFFFFFFNow the 4096-bit group, which is the bigger, badder sibling 👑 Its prime is:
q = 0xFFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
670C354E 4ABC9804 F1746C08 CA18217C 32905E46 2E36CE3B
E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
15728E5A 8AAAC42D AD33170D 04507A33 A85521AB DF1CBA64
ECFB8504 58DBEF0A 8AEA7157 5D060C7D B3970F85 A6E1E4C7
ABF5AE8C DB0933D7 1E8C94E0 4A25619D CEE3D226 1AD2EE6B
F12FFA06 D98A0864 D8760273 3EC86A64 521F2B18 177B200C
BBE11757 7A615D6C 770988C0 BAD946E2 08E24FA0 74E5AB31
43DB5BFC E0FD108E 4B82D120 A9210801 1A723C12 A787E6D7
88719A10 BDBA5B26 99C32718 6AF4E23C 1A946834 B6150BDA
2583E9CA 2AD44CE8 DBBBC2DB 04DE8EF9 2E8EFC14 1FBECAA6
287C5947 4E6BC05D 99B2964F A090C3A2 233BA186 515BE7ED
1F612970 CEE2D7AF B81BDD76 2170481C D0069127 D5B05AA9
93B4EA98 8D8FDDC1 86FFB7DC 90A6C08F 4DF435C9 34063199
FFFFFFFF FFFFFFFFThe generator is:
g = 2And the size of its subgroup is:
r = (q - 1) / 2 =
0x7FFFFFFF FFFFFFFF E487ED51 10B4611A 62633145 C06E0E68
94812704 4533E63A 0105DF53 1D89CD91 28A5043C C71A026E
F7CA8CD9 E69D218D 98158536 F92F8A1B A7F09AB6 B6A8E122
F242DABB 312F3F63 7A262174 D31BF6B5 85FFAE5B 7A035BF6
F71C35FD AD44CFD2 D74F9208 BE258FF3 24943328 F6722D9E
E1003E5C 50B1DF82 CC6D241B 0E2AE9CD 348B1FD4 7E9267AF
C1B2AE91 EE51D6CB 0E3179AB 1042A95D CF6A9483 B84B4B36
B3861AA7 255E4C02 78BA3604 650C10BE 19482F23 171B671D
F1CF3B96 0C074301 CD93C1D1 7603D147 DAE2AEF8 37A62964
EF15E5FB 4AAC0B8C 1CCAA4BE 754AB572 8AE9130C 4C7D0288
0AB9472D 45556216 D6998B86 82283D19 D42A90D5 EF8E5D32
767DC282 2C6DF785 457538AB AE83063E D9CB87C2 D370F263
D5FAD746 6D8499EB 8F464A70 2512B0CE E771E913 0D697735
F897FD03 6CC50432 6C3B0139 9F643532 290F958C 0BBD9006
5DF08BAB BD30AEB6 3B84C460 5D6CA371 047127D0 3A72D598
A1EDADFE 707E8847 25C16890 54908400 8D391E09 53C3F36B
C438CD08 5EDD2D93 4CE1938C 357A711E 0D4A341A 5B0A85ED
12C1F4E5 156A2674 6DDDE16D 826F477C 97477E0A 0FDF6553
143E2CA3 A735E02E CCD94B27 D04861D1 119DD0C3 28ADF3F6
8FB094B8 67716BD7 DC0DEEBB 10B8240E 68034893 EAD82D54
C9DA754C 46C7EEE0 C37FDBEE 48536047 A6FA1AE4 9A0318CC
FFFFFFFF FFFFFFFFAppendix B. (Informative) Derived Numerical Values 🎀
This section gives you a bunch of numbers you need when you're actually implementing this stuff. They're all derived from the stuff back in Section 3. Quick heads up: these values are for information only, so they're helpful, not the law 💅
+----------------+---------+---------+---------+---------+----------+
| | dl-2048 | dl-4096 | ec-p256 | ec-p521 | |
+----------------+---------+---------+---------+---------+----------+
| Size of K_c1, | 2048 | 4096 | 257 | 522 | (bits) |
| etc. | | | | | |
| | | | | | |
| hSize, size of | 256 | 512 | 256 | 512 | (bits) |
| H(...) | | | | | |
| | | | | | |
| Length of | 256 | 512 | 33 | 66 | (octets) |
| OCTETS(K_c1), | | | | | |
| etc. | | | | | |
| | | | | | |
| Length of kc1, | 344* | 684* | 66 | 132 | (octets) |
| ks1 param. | | | | | |
| values | | | | | |
| | | | | | |
| Length of vkc, | 44* | 88* | 64 | 128 | (octets) |
| vks param. | | | | | |
| values | | | | | |
| | | | | | |
| Minimum | 2048 | 4096 | 1 | 1 | |
| allowed S_c1 | | | | | |
+----------------+---------+---------+---------+---------+----------+(The numbers marked with an "*" do not include any enclosing quotation marks. Hot tip from me to you 💖)
Authors' Addresses 🌸
Yutaka Oiwa National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: y.oiwa@aist.go.jp
Hajime Watanabe National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: h-watanabe@aist.go.jp
Hiromitsu Takagi National Institute of Advanced Industrial Science and Technology Information Technology Research Institute Tsukuba Central 1 1-1-1 Umezono Tsukuba-shi, Ibaraki Japan Email: takagi.hiromitsu@aist.go.jp
Kaoru Maeda Individual Contributor Email: kaorumaeda.ml@gmail.com
Tatsuya Hayashi Lepidum Co. Ltd. Village Sasazuka 3, Suite #602 1-30-3 Sasazuka Shibuya-ku, Tokyo Japan Email: hayashi@lepidum.co.jp
Yuichi Ioku Individual Contributor Email: mutual-work@ioku.org
📦 where this page comes from
- ietf: rfc8121 2017-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms