RFC 6508
Sakai-Kasahara Key Encryption (SAKKE)
RFC 6508: Sakai-Kasahara Key Encryption (SAKKE) 🎀
Okay bestie, here's the title block 💅 This one is from the Internet Engineering Task Force (IETF). M. Groves from CESG wrote it. It's Informational, which means it's published for info and isn't a Standards Track spec 🧚 It's dated February 2012, and it's ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates.
Abstract ✨
Okay so this doc describes the Sakai-Kasahara Key Encryption (SAKKE) algorithm 🦋 It uses Identity-Based Encryption to pass a shared secret from a Sender to a Receiver. Iconic. 💜
Status of This Memo 📜
Real talk, this is not an Internet Standards Track spec. It's published purely for informational purposes 🌸
It's still an official IETF product, and the IESG approved it for publication. Not every IESG-approved doc is a candidate for an Internet Standard, though. See Section 2 of RFC 5741 for that 💅
If you want the current status, any errata, or a way to send feedback, check http://www.rfc-editor.org/info/rfc6508 🫶
Copyright Notice ©️
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🔥
This document 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. Please actually read these, bestie, because they spell out your rights and restrictions for this doc 🙈
Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, same as the Simplified BSD License says ⭐
Table of Contents 📚
1. Introduction ....................................................2
1.1. Requirements Terminology ...................................3
2. Notation and Definitions ........................................3
2.1. Notation ...................................................3
2.2. Definitions ................................................5
2.3. Parameters to Be Defined or Negotiated .....................6
3. Elliptic Curves and Pairings ....................................7
3.1. E(F_p^2) and the Distortion Map ............................7
3.2. The Tate-Lichtenbaum Pairing ...............................7
4. Representation of Values ........................................9
5. Supporting Algorithms ..........................................10
5.1. Hashing to an Integer Range ...............................10
6. The SAKKE Cryptosystem .........................................11
6.1. Setup .....................................................11
6.1.1. Secret Key Extraction ..............................11
6.1.2. User Provisioning ..................................11
6.2. Key Exchange ..............................................12
6.2.1. Sender .............................................12
6.2.2. Receiver ...........................................12
6.3. Group Communications ......................................13
7. Security Considerations ........................................13
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................15
Appendix A. Test Data..............................................171. Introduction ✨
Okay so this doc defines an efficient way to use Identity-Based Encryption (IBE) built on bilinear pairings 🧚 It describes the Sakai-Kasahara IBE cryptosystem [S-K] for setting up a shared secret value. It also adds to the IBE options already in [RFC5091], giving you an efficient primitive plus an extra family of curves. Main character energy 👑
This doc sticks to one particular family of curves (see Section 2.1). Those curves have a simple, efficient way to calculate the pairing that Sakai-Kasahara IBE is built on 💖
Now the IBE part, which is so cool. In IBE, public and private keys can be derived from Identifiers. The Identifier can even be viewed as the equivalent of a public key or certificate in a regular public key system. The difference is that in IBE, both Sender and Receiver can form the Identifier 🦋 That means you don't need a third party to hand out public keys, and you don't have to send certified public keys every time a session starts. Keys can also be calculated whenever they're needed, and messages can be sent to users who haven't enrolled yet. Iykyk 🙈
The Sakai-Kasahara primitive in this doc supports simplex transmission of messages from a Sender to a Receiver 🌈 The elliptic curve pairing it's built on keeps implementations simple and efficient. Slay 💅
The Sakai-Kasahara Key Encryption scheme in this doc is drawn from the Sakai-Kasahara Key Encapsulation Mechanism (SK-KEM) scheme. That one was modified to support multi-party communications and submitted to the IEEE P1363 Working Group in [SK-KEM] 🎀
1.1. Requirements Terminology 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in [RFC2119]. These are the official requirement words, so they're worth knowing 🫶
2. Notation and Definitions 🧮
2.1. Notation 🔢
Okay, this is the notation list, and it's kind of the backbone of the whole doc. Here's the vibe for each symbol 💜
n: A security parameter. It's the size of the symmetric keys, in bits, that get exchanged by SAKKE.p: A prime, and it's the order of the finite field F_p. In this doc,pis always congruent to 3 modulo 4 ✨F_p: The finite field of orderp.F*: The multiplicative group of the non-zero elements in the fieldF. For example,(F_p)*is the multiplicative group of the finite fieldF_p.q: An odd prime that dividesp + 1. To get the security level we want,lg(q)MUST be greater than2*n🔥E: An elliptic curve defined overF_p, with a subgroup of orderq. This doc uses supersingular curves with the equationy^2 = x^3 - 3 * xmodulop. The curve is picked for its efficiency and simplicity, which are super nice 🌸 The-3coefficient ofxalso gives advantages for elliptic curve arithmetic, and [P1363] explains them. Another reason for this curve is that Barreto's trick [Barreto] applies. It eliminates the computation of the denominators when calculating the pairing, so you save work 🧚E(F): The additive group of points with affine coordinates(x,y), wherexandyare in the fieldFand satisfy the curve equation forE💖P: A point ofE(F_p)that generates the cyclic subgroup of orderq. Its coordinates areP = (P_x,P_y). These coordinates are inF_p, and they satisfy the curve equation 🦋0: The null element of any additive group of points on an elliptic curve. It's also called the point at infinity ✨F_p^2: The degree 2 extension field ofF_p. This doc uses one specific version of it, whereF_p^2 = F_p[i]andi^2 + 1 = 0🎀PF_p: The projectivization ofF_p. It's defined as(F_p^2)*/(F_p)*. Heads up,PF_pis cyclic and has orderp + 1, which is divisible byq👑G[q]: The q-torsion of a groupG. It's the subgroup generated by points of orderqinG🌈< , >: A version of the Tate-Lichtenbaum pairing. In this doc, it's a bilinear map fromE(F_p)[q] x E(F_p)[q]onto the subgroup of orderqinPF_p. The full definition is in Section 3.2 🧚Hash: A cryptographic hash function 🫶lg(x): The base 2 logarithm of the real valuex🍓
Here are the conventions assumed for curve operations 📐
- Point addition: If
AandBare two points on a curveE, their sum is writtenA + B💅 - Scalar multiplication: If
Ais a point on a curve andkis an integer, addingAto itself a total ofktimes is written[k]A✨
Next, here's how the mathematical objects get represented 🧠
- Elements of
F_p: Thepelements are represented directly by the integers from 0 top-1🔢 - Elements of
F_p^2: The elements ofF_p^2 = F_p[i]are written asx_1 + i * x_2, wherex_1andx_2are elements ofF_p🦋 - Elements of
PF_p: These are cosets of(F_p)*in(F_p^2)*. Every element ofF_p^2can be written unambiguously asx_1 + i * x_2, wherex_1andx_2are inF_p. So elements ofPF_p(except the unique element of order 2) can be represented unambiguously byx_2/x_1inF_p. Sinceqis odd, every element ofPF_p[q]can be represented by an element ofF_pthis way 💜
This way of representing PF_p[q] elements makes the group operations efficient, because they can be defined with plain arithmetic in F_p 🌸 If a and b are elements of F_p representing A and B in PF_p[q], then A * B in PF_p[q] is represented by (a + b)/(1 - a * b) in F_p 🔥
2.2. Definitions
okay bestie, time for the vocab 💅✨ every term here is a building block, so let's go one by one 🎀
Identifier - Every user of an IBE system MUST have a unique, unambiguous identifying string that anyone valid can easily work out 🦋 That string is the user's Identifier. An Identifier is an integer in the range 2 to q-1. The method for forming Identifiers MUST be defined for each application 💜
Key Management Service (KMS) - The KMS is a trusted third party for the IBE system 🧚 It derives the system secrets and hands out key material to the people who are allowed to get it. Applications MAY support mutual communication between the users of multiple KMSs. We write KMSs as KMS_T, KMS_S, and so on 🌸
Public parameters - The public parameters are a set of values that every user of an IBE system holds 🌈 The system MAY contain multiple KMSs. Each application of SAKKE MUST define the set of public parameters it uses. The parameters needed are p, q, E, P, g=<P,P>, Hash, and n ✨
Master Secret (z_T) - The Master Secret z_T is the master key that KMS_T generates and keeps private 🔒 It uses this key to generate the private keys of the users it provisions. It's an integer in the range 2 to q-1 👑
KMS Public Key: Z_T = [z_T]P - The KMS Public Key Z_T is used to form Public Key Establishment Keys for every user provisioned by KMS_T 💅 It's a point of order q in E(F_p). It MUST be provisioned by KMS_T to everyone who is authorized to send messages to users of the IBE system. No drama, just a must 🫶
Receiver Secret Key (RSK) - Every user enrolled in an IBE system gets a Receiver Secret Key from its KMS 🎀 The RSK given to a user with Identifier 'a' by KMS_T is written K_(a,T). In SAKKE, the RSK is a point of order q in E(F_p) 🦋
Shared Secret Value (SSV) - The whole point of SAKKE is that the Sender securely sends a shared secret value to the Receiver 🔐 The SSV is an integer in the range 0 to (2^n) - 1 ✨
Encapsulated Data - Encapsulated Data is how the secret info gets sent safely to the Receiver 💌 It can be computed straight from the Receiver's Identifier, the public parameters, the KMS Public Key, and the SSV being sent. In SAKKE, the Encapsulated Data is a point of order q in E(F_p) plus an integer in the range 0 to (2^n) - 1. It's formatted as described in Section 4 🌸
2.3. Parameters to Be Defined or Negotiated
okay so, for an application to actually use the SAKKE algorithm, the communicating hosts MUST agree on values for several of the parameters we just covered 🤝 The curve equation (E) and the pairing (< , >) are constant and used for every application, so those are already sorted 💖
For the following parameters, each application MUST either define an application-specific constant value OR define a mechanism for hosts to negotiate a value 🧚 Here's the list:
npqP = (P_x,P_y)g = <P,P>Hash
3. Elliptic Curves and Pairings
okay this is where the math gets spicy 🔥 E is a supersingular elliptic curve (of j-invariant 1728) 💜 E(F_p) has a cyclic subgroup of order q, written E(F_p)[q]. The bigger object, E(F_p^2), contains the direct product of two cyclic subgroups of order q, written E(F_p^2)[q] ✨
P is a generator of E(F_p)[q] 🦋 It's specified by the (affine) coordinates (P_x,P_y) in F_p, and those coordinates satisfy the curve equation.
Routines for point addition and doubling on E(F_p) can be found in Appendix A.10 of [P1363] 🎀
3.1. E(F_p^2) and the Distortion Map
if (Q_x,Q_y) are (affine) coordinates in F_p for some point (called Q) on E(F_p)[q], then (-Q_x,iQ_y) are (affine) coordinates in F_p^2 for some point on E(F_p^2)[q] 🌈 That latter point is written [i]Q, by analogy with the scalar multiplication definition. The two points P and [i]P together generate E(F_p^2)[q] 💅 The map [i]: E(F_p) -> E(F_p^2) is sometimes called the distortion map 🦋
3.2. The Tate-Lichtenbaum Pairing
now for the pairing < , > that SAKKE uses 🔮 We need to evaluate polynomials f_R that depend on points on E(F_p)[q]. Miller's algorithm [Miller] gives a way to evaluate f_R(X), where X is some element of E(F_p^2)[q], R is some element of E(F_p)[q], and f_R is some polynomial over F_p whose divisor is (q)(R) - (q)(0). Note that f_R is only defined up to scalars of F_p 💜
The version of the Tate-Lichtenbaum pairing used in this document is <R,Q> = f_R([i]Q)^c / (F_p)*. It satisfies the bilinear relation <[x]R,Q> = <R,[x]Q> = <R,Q>^x for all Q, R in E(F_p)[q], for all integers x 🫶 Also, the domain of definition is restricted to E(F_p)[q] x E(F_p)[q] so that certain optimizations come naturally ✨
We provide pseudocode for computing <R,Q>, with elliptic curve arithmetic written in affine coordinates 🎀 We use Barreto's trick [Barreto] to avoid calculating denominators. Note that this section does NOT fully describe the most efficient way to compute the pairing. It's possible to compute the pairing without any explicit reference to the extension field F_p^2, which cuts down on the number and complexity of the operations needed 🌸
<CODE BEGINS>
/*
Copyright (c) 2012 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in
Section 4.c of the IETF Trust's Legal Provisions Relating to
IETF Documents (http://trustee.ietf.org/license-info).
*/
Routine for computing the pairing <R,Q>:
Input R, Q points on E(F_p)[q];
Initialize variables:
v = (F_p)*; // An element of PF_p[q]
C = R; // An element of E(F_p)[q]
c = (p+1)/q; // An integer
for bits of q-1, starting with the second most significant
bit, ending with the least significant bit, do
// gradient of line through C, C, [-2]C.
l = 3*( C_x^2 - 1 ) / ( 2*C_y );
//accumulate line evaluated at [i]Q into v
v = v^2 * ( l*( Q_x + C_x ) + ( i*Q_y - C_y ) );
C = [2]C;
if bit is 1, then
// gradient of line through C, R, -C-R.
l = ( C_y - R_y )/( C_x - R_x );
//accumulate line evaluated at [i]Q into v
v = v * ( l*( Q_x + C_x ) + ( i*Q_y - C_y ) );
C = C+R;
end if;
end for;
t = v^c;
return representative in F_p of t;
End of routine;
Routine for computing representative in F_p of elements of PF_p:
Input t, in F_p^2, representing an element of PF_p;
Represent t as a + i*b, with a,b in F_p;
return b/a;
End of routine;
<CODE ENDS>4. Representation of Values
this section gives the canonical representations of values, and they MUST be used so implementations can actually talk to each other 🫶 The following representations MUST be used for input into hash functions and for transmission 💌
Integers Integers MUST be represented as an octet string,
with bit length a multiple of 8. To achieve this,
the integer is represented most significant bit
first, and padded with zero bits on the left until
an octet string of the necessary length is
obtained. This is the octet string representation
described in Section 6 of [RFC6090].
F_p elements Elements of F_p MUST be represented as integers in
the range 0 to p-1 using the octet string
representation defined above. Such octet strings
MUST have length L = Ceiling(lg(p)/8).
PF_p elements Elements of PF_p MUST be represented as an element
of F_p using the algorithm in Section 3.2. They
are therefore represented as octet strings as
defined above and are L octets in length.
Representation of the unique element of order 2 in
PF_p will not be required.
Points on E Elliptic curve points MUST be represented in
uncompressed form as defined in Section 2.2 of
[RFC5480]. For an elliptic curve point (x,y) with
x and y in F_p, this representation is given by
0x04 || x' || y', where x' is the octet string
representing x, y' is the octet string
representing y, and || denotes concatenation. The
representation is 2*L+1 octets in length.
Encapsulated Data The Encapsulated Data MUST be represented as an
elliptic curve point concatenated with an integer
in the range 0 to (2 ^ n) - 1. Since the length
of the representation of elements of F_p is well
defined given p, these data can be unambiguously
parsed to retrieve their components. The
Encapsulated Data is 2*L + n + 1 octets in length.5. Supporting Algorithms
5.1. Hashing to an Integer Range
we use the function HashToIntegerRange( s, n, hashfn ) to hash strings into an integer range 🌈 Given a string (s), a hash function (hashfn), and an integer (n), this function returns a value between 0 and n - 1 💖
Input:
- an octet string,
s - an integer,
n <= (2^hashlen)^hashlen - a hash function,
hashfn, with output lengthhashlenbits
Output:
- an integer,
v, in the range0ton-1
Method:
- Let
A = hashfn( s ) - Let
h_0 = 00...00, a string of null bits of lengthhashlenbits - Let
l = Ceiling(lg(n)/hashlen) - For each
iin1tol, do:- a) Let
h_i = hashfn(h_(i - 1)) - b) Let
v_i = hashfn(h_i || A), where||denotes concatenation
- a) Let
- Let
v' = v_1 || ... || v_l - Let
v = v' mod n
6. The SAKKE Cryptosystem
this section describes the Sakai-Kasahara Key Encryption algorithm 🦋 It draws from the cryptosystem first described in [S-K] 🔮
6.1. Setup
all users share a set of public parameters with a KMS 🎀 In most circumstances, it is expected that a system will only use a single KMS 💅 However, it IS possible for users provisioned by different KMSs to interoperate, as long as they use a common set of public parameters and each one possesses the necessary KMS Public Keys 🫶 To make that interoperation work, it is anticipated that parameters will be published in application-specific standards ✨
KMS_T chooses its KMS Master Secret, z_T. It MUST randomly select a value in the range 2 to q-1, and assigns this value to z_T. It MUST derive its KMS Public Key, Z_T, by performing the calculation Z_T = [z_T]P 💜
6.1.1. Secret Key Extraction
the KMS derives each RSK from an Identifier and its KMS Master Secret 🔑 It MUST derive an RSK for each user that it provisions.
For Identifier 'a', the RSK K_(a,T) provided by KMS_T MUST be derived by KMS_T as K_(a,T) = [(a + z_T)^-1]P, where 'a' is interpreted as an integer, and the inversion is performed modulo q 🌸
6.1.2. User Provisioning ✨
Okay bestie, so the KMS MUST provide its KMS Public Key to all users through an authenticated channel 🔐. RSKs MUST be supplied to all users through a channel that provides confidentiality and mutual authentication 💖. The security mechanisms for those channels are out of scope here because they're application specific, so that's a whole other vibe 🌸.
Once a user gets their key material, they MUST verify their RSK 🧐. For Identifier 'a', RSKs from KMS_T get checked by making sure < [a]P + Z, K_(a,T) > = g holds, where 'a' is read as an integer 🔢.
6.2. Key Exchange 🦋
Here's the moment: a Sender forms Encapsulated Data, sends it to the Receiver, and the Receiver processes it 💅. The result is a shared secret that can be used as keying material for securing further communications 🔑. We call the Sender A with Identifier 'a' and the Receiver B with Identifier 'b', and the Identifiers get interpreted as integers in the algorithms below 🎀. A is provisioned by KMS_T and B is provisioned by KMS_S 🌈.
6.2.1. Sender 💌
To form Encapsulated Data for device B (provisioned by KMS_S), A needs to hold Z_S 🧚. It's expected that KMS_T gave A Z_S along with its User Private Keys 🗝️. The Sender MUST carry out the following steps:
- Select a random ephemeral integer value for the SSV in the range 0 to
2^n - 1; - Compute
r = HashToIntegerRange( SSV || b, q, Hash ); - Compute
R_(b,S) = [r]([b]P + Z_S)inE(F_p); - Compute the Hint, H;
- a) Compute
g^r. Note that g is an element ofPF_p[q]represented by an element ofF_p. So, to calculateg^r, the operation defined in Section 2.1 for calculation ofA * BinPF_p[q]is to be used as part of a square and multiply (or similar) exponentiation algorithm, rather than the regularF_poperations; - b) Compute
H := SSV XOR HashToIntegerRange( g^r, 2^n, Hash );
- a) Compute
- Form the Encapsulated Data
( R_(b,S), H ), and transmit it to B 📤; - Output SSV for use to derive key material for the application to be keyed ✨.
6.2.2. Receiver 📥
Device B receives Encapsulated Data from device A 💫. To process it, B needs its RSK, K_(b,S), which KMS_S provisioned ahead of time 🗓️. How the KMS provisions keys is application specific 🌷. The Receiver MUST carry out the following steps to derive and verify the SSV:
- Parse the Encapsulated Data
( R_(b,S), H ), and extractR_(b,S)and H; - Compute
w := < R_(b,S), K_(b,S) >. Note that by bilinearity,w = g^r; - Compute
SSV = H XOR HashToIntegerRange( w, 2^n, Hash ); - Compute
r = HashToIntegerRange( SSV || b, q, Hash ); - Compute
TEST = [r]([b]P + Z_S)inE(F_p). If TEST does not equalR_(b,S), then B MUST NOT use the SSV to derive key material 🚫; - Output SSV for use to derive key material for the application to be keyed 🎉.
6.3. Group Communications 👯
SAKKE can be used to exchange SSVs for group communications, and it's giving group chat 💬. To share a secret with multiple Receivers, a Sender MUST form Encapsulated Data for each of their Identifiers and transmit the right data to each Receiver 📨. Any party holding the group SSV MAY extend the group by forming Encapsulated Data for a new group member 🫶.
Forming multiple Encapsulated Data is still a lot of work, but the sending operation skips pairings, so adding more Receivers is way more efficient than with other IBE schemes that make the Sender compute a pairing 🚀.
7. Security Considerations 🛡️
This document describes the SAKKE cryptographic algorithm 💜. We assume that the security this algorithm provides depends entirely on the secrecy of the secret keys it uses. For an adversary to defeat it, they'd need computationally intensive cryptanalytic attacks to recover a secret key 🕵️. Note that a security proof exists for SAKKE in the Random Oracle Model [SK-KEM] 📜.
When defining public parameters, guidance on parameter sizes from [SP800-57] SHOULD be followed 📏. The size of the F_p^2 discrete logarithm that security rests on is 2*lg(p) 🧮. Table 1 shows the bits of security you get from various sizes of p 👀. If k bits of security are needed, then lg(q) SHOULD be chosen to be at least 2*k. Similarly, if k bits of security are needed, then a hash with output size at least 2*k SHOULD be chosen 🍓.
Bits of Security | lg(p)
-------------------------
80 | 512
112 | 1024
128 | 1536
192 | 3840
256 | 7680
Table 1: Comparable Strengths, Taken from Table 2 of [SP800-57]The KMS Master Secret is what gives security to each device the KMS provisions 👑. It MUST NOT be revealed to any other entity 🤐. Each user's RSK protects the SAKKE communications they receive 💖. This key MUST NOT be revealed to any entity other than the trusted KMS and the authorized user 🙅♀️.
To make sure only an authorized device gets the RSK, it MUST be provided through a secure channel 🔒. The security this system offers is no greater than the security of that delivery channel, so choose wisely, bestie 💀.
Note that IBE systems have different properties from other asymmetric cryptographic schemes when it comes to key recovery 🧠. The KMS (and therefore any administrator with the right privileges) can create RSKs for arbitrary Identifiers 😳. Procedures to monitor the creation of RSKs, such as logging administrator actions, SHOULD be defined by any functioning implementation of SAKKE 📋.
Identifiers MUST be defined unambiguously by each application of SAKKE 🎯. It's not necessary to hash the data in a format for Identifiers, except when its size would be greater than that of q 🙈. That way, any weaknesses caused by collisions in hash functions can be avoided without relying on the structure of the Identifier format ✨. Applications of SAKKE MAY include a time/date component in their Identifier format, so that Identifiers (and hence RSKs) are only valid for a fixed period of time ⏰.
Randomness is everything here 🎲. The values stipulated to be selected at random in SAKKE, as described in this document, are essential to the security SAKKE provides 🔐. If the ephemeral value r selected by the Sender is not chosen at random, then the SSV, which provides key material for further communications, could be predictable 😱. Guidance on generating random values for security can be found in [RFC4086] 📚.
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, March 2009.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental
Elliptic Curve Cryptography Algorithms", RFC 6090,
February 2011.
[S-K] Sakai, R., Ohgishi, K., and M. Kasahara, "ID based
cryptosystem based on pairing on elliptic curves",
Symposium on Cryptography and Information Security -
SCIS, 2001.
[SK-KEM] Barbosa, M., Chen, L., Cheng, Z., Chimley, M., Dent, A.,
Farshim, P., Harrison, K., Malone-Lee, J., Smart, N., and
F. Vercauteren, "SK-KEM: An Identity-Based KEM",
submission for IEEE P1363.3, June 2006,
(http://grouper.ieee.org/groups/1363/IBC/
submissions/Barbosa-SK-KEM-2006-06.pdf).
[SP800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid,
"Recommendation for Key Management - Part 1: General
(Revised)", NIST Special Publication 800-57, March 2007.8.2. Informative References
[Barreto] Barreto, P., Kim, H., Lynn, B., and M. Scott, "Efficient
Algorithms for Pairing-Based Cryptosystems", Advances in
Cryptology - Crypto 2002, LNCS 2442, Springer-Verlag
(2002), pp. 354-369.
[Miller] Miller, V., "The Weil pairing, and its efficient
calculation", J. Cryptology 17 (2004), 235-261.
[P1363] IEEE P1363-2000, "Standard Specifications for Public-Key
Cryptography", 2001.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, June 2005.
[RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography
Standard (IBCS) #1: Supersingular Curve Implementations
of the BF and BB1 Cryptosystems", RFC 5091,
December 2007.
[RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption
in Multimedia Internet KEYing (MIKEY)", RFC 6509,
February 2012.Appendix A. Test Data ✨
okay bestie, this is the good stuff 🧚 Appendix A is full of test vectors for SAKKE, using the public parameters from Appendix A of [RFC6509]. So if you're checking your implementation, these are the numbers you compare against 💅 Quick decoder ring: b is the Identifier of the Responder, and mask is the value that masks the SSV, defined as HashToIntegerRange( g^r, 2^n, Hash ) 🦋
// --------------------------------------------------------
// The KMS generates:
z = AFF429D3 5F84B110 D094803B 3595A6E2 998BC99F
Zx = 5958EF1B 1679BF09 9B3A030D F255AA6A
23C1D8F1 43D4D23F 753E69BD 27A832F3
8CB4AD53 DDEF4260 B0FE8BB4 5C4C1FF5
10EFFE30 0367A37B 61F701D9 14AEF097
24825FA0 707D61A6 DFF4FBD7 273566CD
DE352A0B 04B7C16A 78309BE6 40697DE7
47613A5F C195E8B9 F328852A 579DB8F9
9B1D0034 479EA9C5 595F47C4 B2F54FF2
Zy = 1508D375 14DCF7A8 E143A605 8C09A6BF
2C9858CA 37C25806 5AE6BF75 32BC8B5B
63383866 E0753C5A C0E72709 F8445F2E
6178E065 857E0EDA 10F68206 B63505ED
87E534FB 2831FF95 7FB7DC61 9DAE6130
1EEACC2F DA3680EA 4999258A 833CEA8F
C67C6D19 487FB449 059F26CC 8AAB655A
B58B7CC7 96E24E9A 39409575 4F5F8BAE// --------------------------------------------------------
// Creating Encapsulated Data
b = 3230 31312D30 32007465 6C3A2B34
34373730 30393030 31323300
SSV = 12345678 9ABCDEF0 12345678 9ABCDEF0
r = HashToIntegerRange(
12345678 9ABCDEF0 12345678 9ABCDEF0
32303131 2D303200 74656C3A 2B343437
37303039 30303132 3300, q, SHA-256 )
= 13EE3E1B 8DAC5DB1 68B1CEB3 2F0566A4
C273693F 78BAFFA2 A2EE6A68 6E6BD90F
8206CCAB 84E7F42E D39BD4FB 131012EC
CA2ECD21 19414560 C17CAB46 B956A80F
58A3302E B3E2C9A2 28FBA7ED 34D8ACA2
392DA1FF B0B17B23 20AE09AA EDFD0235
F6FE0EB6 5337A63F 9CC97728 B8E5AD04
60FADE14 4369AA5B 21662132 47712096
Rbx = 44E8AD44 AB8592A6 A5A3DDCA 5CF896C7
18043606 A01D650D EF37A01F 37C228C3
32FC3173 54E2C274 D4DAF8AD 001054C7
6CE57971 C6F4486D 57230432 61C506EB
F5BE438F 53DE04F0 67C776E0 DD3B71A6
29013328 3725A532 F21AF145 126DC1D7
77ECC27B E50835BD 28098B8A 73D9F801
D893793A 41FF5C49 B87E79F2 BE4D56CE
Rby = 557E134A D85BB1D4 B9CE4F8B E4B08A12
BABF55B1 D6F1D7A6 38019EA2 8E15AB1C
9F76375F DD1210D4 F4351B9A 009486B7
F3ED46C9 65DED2D8 0DADE4F3 8C6721D5
2C3AD103 A10EBD29 59248B4E F006836B
F097448E 6107C9ED EE9FB704 823DF199
F832C905 AE45F8A2 47A072D8 EF729EAB
C5E27574 B07739B3 4BE74A53 2F747B86
g^r = 7D2A8438 E6291C64 9B6579EB 3B79EAE9
48B1DE9E 5F7D1F40 70A08F8D B6B3C515
6F2201AF FBB5CB9D 82AA3EC0 D0398B89
ABC78A13 A760C0BF 3F77E63D 0DF3F1A3
41A41B88 11DF197F D6CD0F00 3125606F
4F109F40 0F7292A1 0D255E3C 0EBCCB42
53FB182C 68F09CF6 CD9C4A53 DA6C74AD
007AF36B 8BCA979D 5895E282 F483FCD6
mask = HashToIntegerRange(
7D2A8438 E6291C64 9B6579EB 3B79EAE9
48B1DE9E 5F7D1F40 70A08F8D B6B3C515
6F2201AF FBB5CB9D 82AA3EC0 D0398B89
ABC78A13 A760C0BF 3F77E63D 0DF3F1A3
41A41B88 11DF197F D6CD0F00 3125606F
4F109F40 0F7292A1 0D255E3C 0EBCCB42
53FB182C 68F09CF6 CD9C4A53 DA6C74AD
007AF36B 8BCA979D 5895E282 F483FCD6, 2^128, SHA-256 )
= 9BD4EA1E 801D37E6 2AD2FAB0 D4F5BBF7
H = 89E0BC66 1AA1E916 38E6ACC8 4E496507// --------------------------------------------------------
// Receiver processing
// Device receives Kb from the KMS
Kbx = 93AF67E5 007BA6E6 A80DA793 DA300FA4
B52D0A74 E25E6E7B 2B3D6EE9 D18A9B5C
5023597B D82D8062 D3401956 3BA1D25C
0DC56B7B 979D74AA 50F29FBF 11CC2C93
F5DFCA61 5E609279 F6175CEA DB00B58C
6BEE1E7A 2A47C4F0 C456F052 59A6FA94
A634A40D AE1DF593 D4FECF68 8D5FC678
BE7EFC6D F3D68353 25B83B2C 6E69036B
Kby = 155F0A27 241094B0 4BFB0BDF AC6C670A
65C325D3 9A069F03 659D44CA 27D3BE8D
F311172B 55416018 1CBE94A2 A783320C
ED590BC4 2644702C F371271E 496BF20F
588B78A1 BC01ECBB 6559934B DD2FB65D
2884318A 33D1A42A DF5E33CC 5800280B
28356497 F87135BA B9612A17 26042440
9AC15FEE 996B744C 33215123 5DECB0F5
// Device processes Encapsulated Data
w = 7D2A8438 E6291C64 9B6579EB 3B79EAE9
48B1DE9E 5F7D1F40 70A08F8D B6B3C515
6F2201AF FBB5CB9D 82AA3EC0 D0398B89
ABC78A13 A760C0BF 3F77E63D 0DF3F1A3
41A41B88 11DF197F D6CD0F00 3125606F
4F109F40 0F7292A1 0D255E3C 0EBCCB42
53FB182C 68F09CF6 CD9C4A53 DA6C74AD
007AF36B 8BCA979D 5895E282 F483FCD6
SSV = 12345678 9ABCDEF0 12345678 9ABCDEF0
r = 13EE3E1B 8DAC5DB1 68B1CEB3 2F0566A4
C273693F 78BAFFA2 A2EE6A68 6E6BD90F
8206CCAB 84E7F42E D39BD4FB 131012EC
CA2ECD21 19414560 C17CAB46 B956A80F
58A3302E B3E2C9A2 28FBA7ED 34D8ACA2
392DA1FF B0B17B23 20AE09AA EDFD0235
F6FE0EB6 5337A63F 9CC97728 B8E5AD04
60FADE14 4369AA5B 21662132 47712096
TESTx = 44E8AD44 AB8592A6 A5A3DDCA 5CF896C7
18043606 A01D650D EF37A01F 37C228C3
32FC3173 54E2C274 D4DAF8AD 001054C7
6CE57971 C6F4486D 57230432 61C506EB
F5BE438F 53DE04F0 67C776E0 DD3B71A6
29013328 3725A532 F21AF145 126DC1D7
77ECC27B E50835BD 28098B8A 73D9F801
D893793A 41FF5C49 B87E79F2 BE4D56CE
TESTy = 557E134A D85BB1D4 B9CE4F8B E4B08A12
BABF55B1 D6F1D7A6 38019EA2 8E15AB1C
9F76375F DD1210D4 F4351B9A 009486B7
F3ED46C9 65DED2D8 0DADE4F3 8C6721D5
2C3AD103 A10EBD29 59248B4E F006836B
F097448E 6107C9ED EE9FB704 823DF199
F832C905 AE45F8A2 47A072D8 EF729EAB
C5E27574 B07739B3 4BE74A53 2F747B86
TEST == Rb// --------------------------------------------------------
// HashToIntegerRange( M, q, SHA-256 ) example
M = 12345678 9ABCDEF0 12345678 9ABCDEF0
32303131 2D303200 74656C3A 2B343437
37303039 30303132 3300
A = E04D4EF6 9DF86893 22B39AE3 80284617
4A93BEDB 1E3D2A2C 5F2C7EA0 05513EBA
h0 = 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
h1 = 66687AAD F862BD77 6C8FC18B 8E9F8E20
08971485 6EE233B3 902A591D 0D5F2925
h2 = 2B32DB6C 2C0A6235 FB1397E8 225EA85E
0F0E6E8C 7B126D00 16CCBDE0 E667151E
h3 = 12771355 E46CD47C 71ED1721 FD5319B3
83CCA3A1 F9FCE3AA 1C8CD3BD 37AF20D7
h4 = FE15C0D3 EBE314FA D720A08B 839A004C
2E6386F5 AECC19EC 74807D19 20CB6AEB
v1 = FA2656CA 1D2DBD79 015AE918 773DFEDC
24957C91 E3C9C335 40D6BF6D 7C3C0055
v2 = F016CD67 59620AD7 87669E3A DD887DF6
25895A91 0CEE1486 91A06735 B2F0A248
v3 = AC45C6F9 7F83BCE0 A2BBD0A1 4CF4D7F4
CB3590FB FAF93AE7 1C64E426 185710B5
v4 = E65D50BD 551A54EF 981F535E 072DE98D
2223ACAD 4621E026 3B0A61EA C56DB078
v mod q = 13EE3E1B 8DAC5DB1 68B1CEB3 2F0566A4
C273693F 78BAFFA2 A2EE6A68 6E6BD90F
8206CCAB 84E7F42E D39BD4FB 131012EC
CA2ECD21 19414560 C17CAB46 B956A80F
58A3302E B3E2C9A2 28FBA7ED 34D8ACA2
392DA1FF B0B17B23 20AE09AA EDFD0235
F6FE0EB6 5337A63F 9CC97728 B8E5AD04
60FADE14 4369AA5B 21662132 47712096Author's Address 🎀
the author, Michael Groves at CESG, contact details below 🌸
Michael Groves
CESG
Hubble Road
Cheltenham
GL51 8HJ
UK
EMail: Michael.Groves@cesg.gsi.gov.uk📦 where this page comes from
- ietf: rfc6508 2012-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms