idnits 2.16.02
/tmp/draft-groves-eccsi-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (February 28, 2011) is 3039 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: draft-groves-mikey-sakke has been published as RFC
6509
== Outdated reference: draft-groves-sakke has been published as RFC 6508
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group Groves
3 Internet Draft CESG
4 Intended Status: Informational February 28, 2011
5 Expires: September 01, 2011
7 Elliptic Curve-based Certificate-less Signatures for Identifier Based
8 Encryption (ECCSI)
9 draft-groves-eccsi-01
11 Status of this Memo
13 This Internet-Draft is submitted to IETF in full conformance with the
14 provisions of BCP 78 and BCP 79.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as Internet-
19 Drafts.
21 Internet-Drafts are draft documents valid for a maximum of six months
22 and may be updated, replaced, or obsoleted by other documents at any
23 time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 The list of current Internet-Drafts can be accessed at
27 http://www.ietf.org/ietf/1id-abstracts.txt.
29 The list of Internet-Draft Shadow Directories can be accessed at
30 http://www.ietf.org/shadow.html.
32 This Internet-Draft will expire on September 01, 2011.
34 Copyright Notice
36 Copyright (c) 2011 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with
44 respect to this document. Code Components extracted from this
45 document must include Simplified BSD License text as described in
46 Section 4.e of the Trust Legal Provisions and are provided without
47 warranty as described in the Simplified BSD License.
49 Abstract
51 Many signature schemes currently in use rely on certificates for
52 authentication of identity. In Identifier based cryptography, this
53 adds unnecessary overhead and administration. The ECCSI signature
54 scheme described in this document is certificate-less. This scheme
55 has the additional advantages of low bandwidth and low computational
56 requirements.
58 Table of Contents
60 1. Introduction.....................................................2
61 1.1. Requirements Terminology....................................3
62 2. Architecture.....................................................3
63 3. Notation.........................................................5
64 3.1. Arithmetic..................................................5
65 3.2. Representations.............................................5
66 3.3. Format of material..........................................6
67 4. Parameters.......................................................6
68 4.1. Static Parameters...........................................7
69 4.2. Community Parameters........................................8
70 5. Algorithms.......................................................8
71 5.1. User Key Material...........................................8
72 5.1.1. Algorithm for constructing (SSK,PVT) pair..............8
73 5.1.2. Algorithm for validating a received SSK................9
74 5.2. Signatures..................................................9
75 5.2.1. Algorithm for signing..................................9
76 5.2.2. Algorithm for verifying...............................10
77 6. Security Considerations.........................................11
78 7. IANA Considerations.............................................12
79 8. References......................................................12
80 8.1. Normative References.......................................12
81 8.2. Informative References.....................................13
82 Appendix A. Test data..............................................13
84 1. Introduction
86 Digital signatures provide authentication services across a wide
87 range of applications. A chain of trust for such signatures is
88 usually provided by certificates. However, in low bandwidth or other
89 resource constrained environments, the use of certificates might be
90 undesirable. This document describes an efficient scheme, ECCSI, for
91 elliptic curve-based certificate-less signatures, primarily intended
92 for use with Identifier Based Encryption (IBE) schemes such as
93 [SAKKE]. As certificates are not needed, the need to transmit or
94 store them to authenticate each communication is obviated. The
95 algorithm has been developed by drawing on ideas set out by Arazi
96 [BA] and is originally based upon [ECDSA], one of the most commonly
97 used signature algorithms.
99 The algorithm is for use in the following context:
101 where there are two parties, a Signer and a Verifier;
103 where short unambiguous Identifier strings are naturally
104 associated to each of these parties;
106 where a message is to be signed and then verified (e.g., for
107 authenticating the initiating party during an Identifier-based key
108 establishment);
110 where a common Key Management Server (KMS) provides a root of
111 trust for both parties.
113 The scheme does not rely on any web of trust between users.
115 Authentication is provided in a single simplex transmission without
116 per-session reference to any third party. Thus the scheme is
117 particularly suitable in situations where the receiving party need
118 not be active (or even enrolled) when the message to be authenticated
119 is sent, or in which the number of transmissions is to be minimized
120 for efficiency.
122 Instead of having a certificate, the Signer has an Identifier, to
123 which his Secret Signing Key (see Section 2) will have been
124 cryptographically bound by means of a Public Validation Token (see
125 Section 2) by the KMS. Unlike a traditional public key, this Public
126 Validation Token requires no further explicit certification.
128 The verification primitive within this scheme can be implemented
129 using projective representation of elliptic curve points, without
130 arithmetic field divisions, and without explicitly using the size of
131 the underlying cryptographic group.
133 1.1. Requirements Terminology
135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
137 document are to be interpreted as described in [RFC2119].
139 2. Architecture
141 A Key Management Server (KMS) provisions key material for a set of
142 communicating devices (a "user community"). Each device within the
143 user community MUST have an Identifier (ID) which can be formed by
144 its peers. These Identifiers MUST be unique to devices (or users),
145 and MAY change over time. As such, all applications of this
146 signature scheme MUST define an unambiguous format for Identifiers.
147 We consider the situation where one device (the Signer) wishes to
148 sign a message that it is sending to another (the Verifier). Only
149 the Signer's Identifier is used in the signature scheme.
151 In advance, the KMS chooses its KMS Secret Authentication Key (KSAK),
152 which is the root of trust for all other key material in the scheme.
153 From this, the KMS derives the KMS Public Authentication Key (KPAK),
154 which all devices will require in order to verify Signatures. This
155 will be the root of trust for verification.
157 Before verification of any Signatures, members of the user community
158 are supplied with the KPAK. The supply of the KPAK MUST be
159 authenticated by the KMS and this authentication MUST be verified by
160 each member of the user community. Confidentiality protection MAY
161 also be applied.
163 In the description of the algorithms in this document, it is assumed
164 that there is one KMS, one user community, and hence one KPAK.
165 Applications MAY support multiple KPAKs, and some KPAKs could in fact
166 be "private" to certain communities in certain circumstances. The
167 method for determining which KPAK to use (when more than one is
168 available) is out of scope.
170 The KMS generates and provisions key material for each device. It
171 MUST supply a Secret Signing Key (SSK) along with a Public Validation
172 Token (PVT) to all devices that are to send signed messages. The
173 mechanism by which these SSKs are provided MUST be secure, as the
174 security of the authentication provided by ECCSI Signatures is no
175 stronger than the security of this supply channel.
177 Before using the supplied key material (SSK,KPAK) to form Signatures,
178 the Sender MUST verify the key material (SSK) against the root of
179 trust (KPAK) and against its own Identifier (ID) and its Public
180 Validation Token (PVT) using the algorithm defined in Section 5.1.2.
182 During the signing protocol, once the Signer has formed its message,
183 it signs the message using its SSK. It transmits the Signature
184 (including the PVT), and MAY also transmit the message (in cases
185 where the message is not known to the Verifier). The Verifier MUST
186 then use the message, Signature, and Sender ID in verification
187 against the KPAK.
189 This document specifies
191 an algorithm for creating a KPAK from a KSAK, for a given elliptic
192 curve;
194 a format for transporting a KPAK;
196 an algorithm for creating an SSK and a PVT from a Signer's ID,
197 using the KSAK;
199 an algorithm for verifying an SSK and a PVT against a Signer's ID
200 and KPAK;
201 an algorithm for creating a Signature from a message, using a
202 Signer's ID with a matching SSK and PVT;
204 a format for transporting a Signature;
206 an algorithm for verifying a Signature for a message, using a
207 Signer's ID with the matching KPAK.
209 This document does not specify (but comments on)
211 how to choose a valid and secure elliptic curve;
213 which hash function to use;
215 how to format a Signer's ID;
217 how to format a message for signing;
219 how to manage and install a KPAK;
221 how to transport or install an SSK.
223 As used in [MIKEY-SAKKE], the elliptic curve and hash function are
224 specified in Section 2.1.1 of [MIKEY-SAKKE], the format of
225 Identifiers is specified in Section 3.2 of [MIKEY-SAKKE] and messages
226 for signing are formatted as specified in [RFC3830].
228 3. Notation
230 3.1. Arithmetic
232 ECCSI relies on elliptic curve arithmetic. If P and Q are two
233 elliptic curve points, their addition is denoted P + Q. Moreover,
234 the addition of P with itself k times is denoted [k]P.
236 F_p denotes the finite field of p elements, where p is prime. All
237 elliptic curve points will be defined over F_p.
239 The curve is defined by the equation y^2 = x^3 - 3*x + B modulo p,
240 where B is an element of F_p. Elliptic curve points, other than the
241 group identity (0), are represented in the format P = (Px,Py), where
242 Px and Py are the affine coordinates in F_p satisfying the above
243 equation. In particular, a point P = (Px,Py) is said to lie on an
244 elliptic curve if Py^2 - Px^3 + 3*Px - B = 0 modulo p. The identity
245 point 0 will require no representation.
247 3.2. Representations
248 This section provides canonical representations of values which MUST
249 be used to ensure interoperability of implementations. The following
250 representations MUST be used for input into hash functions and for
251 transmission. In this document concatenation of octet strings s and
252 t is denoted s || t. The logarithm base 2 of a real number a is
253 denoted lg(a).
255 Integers Integers MUST be represented as an octet string,
256 with bit length a multiple of 8. To achieve this,
257 the integer is represented most significant bit
258 first, and padded with zero bits on the left until
259 an octet string of the necessary length is
260 obtained. This is the Octet String representation
261 described in Section 6 of [RFC6090]. There will
262 be no need to represent negative integers. When
263 transmitted or hashed, such octet strings MUST
264 have length N = Ceiling(lg(p)/8).
266 F_p elements Elements of F_p MUST be represented as integers in
267 the range 0 to p-1 using the octet string
268 representation defined above. For use in ECCSI
269 such octet strings MUST have length N =
270 Ceiling(lg(p)/8).
272 Points on E Elliptic Curve Points MUST be represented in
273 Uncompressed representation ("affine coordinates")
274 as defined in Section 2.2 of [RFC5480]. For an
275 elliptic curve point (x,y) with x and y in F_p,
276 this representation is given by 0x04 || x' || y' ,
277 where x' is the N-octet string representing x and
278 y' is the N-octet string representing y.
280 3.3. Format of material
282 This section describes the subfields of the different objects used
283 within the protocol.
285 Signature = r || s || PVT where r and s are octet strings of length
286 N = Ceiling(lg(p)/8) representing
287 integers, and PVT is an octet string of
288 length 2N+1 representing an elliptic
289 curve point, yielding a total signature
290 length of 4N+1 octets. (Note that r and
291 s represent integers rather than elements
292 of F_p, and therefore it is possible that
293 either or both of them could equal or
294 exceed p.)
296 4. Parameters
297 4.1. Static Parameters
299 The following static parameters are fixed for each implementation.
300 They are not intended to change frequently, and MUST be specified for
301 each user community. Note that these parameters MAY be shared across
302 multiple KMSs.
304 n A security parameter, the size in bits of the
305 prime p over which elliptic curve cryptography
306 is to be performed.
308 N = Ceiling(n/8) The number of octets used to represent
309 fields r and s in a Signature. Also the
310 number of octets output by the Hash Function
311 (see below).
313 p A prime number of size n bits. The finite
314 field with p elements is denoted F_p.
316 E An elliptic curve defined over F_p, having a
317 subgroup of prime order q.
319 B An element of F_p, where E is defined by the
320 formula y^2 = x^3 - 3*x + B modulo p.
322 G A point on the elliptic curve E which generates
323 the subgroup of order q.
325 q The prime q is defined to be the order of G in
326 E over F_p.
328 Hash A cryptographic hash function mapping arbitrary
329 strings to strings of N octets. If a, b, c,
330 ... are strings, then hash( a || b || c ||
331 ...) denotes the result obtained by hashing the
332 concatenation of these strings.
334 Identifiers The method for deriving user Identifiers. The
335 format of Identifiers MUST be specified by each
336 implementation. It MUST be possible for each
337 device to derive the Identifier for every
338 device with which it needs to communicate. In
339 this document, ID will denote the correctly
340 formatted Identifier string of the Signer.
341 ECCSI makes use of the Signer Identifier only,
342 though an implementation MAY make use of other
343 Identifiers when constructing the message to be
344 signed. Identifier formats MAY include a
345 timestamp to allow for automatic expiration of
346 key material.
348 It is RECOMMENDED that p, E, and G are chosen to be standardized
349 values. In particular, it is RECOMMENDED to use the curves and
350 base-points defined in [FIPS186-3].
352 4.2. Community Parameters
354 The following community parameter MUST be supplied to devices each
355 time the root of trust is changed.
357 KPAK The KMS Public Authentication Key (KPAK) is the root of trust
358 for authentication. It is derived from the KSAK in the KMS.
359 This value MUST be provisioned in a trusted fashion, such
360 that each device that receives it has assurance that it is
361 the genuine KPAK belonging to its KMS. Before use, each
362 device MUST check that the supplied KPAK lies on the elliptic
363 curve E.
365 The KMS MUST fix the KPAK to be KPAK = [KSAK]G, where KSAK MUST be
366 chosen to be a random secret non-zero integer modulo q. The value
367 KSAK MUST be kept secret to the KMS.
369 5. Algorithms
371 5.1. User Key Material
373 To create Signatures, each Signer requires a Secret Signing Key (SSK)
374 and a Public Validation Token (PVT). The SSK is an integer and the
375 PVT is an elliptic curve point. The SSK MUST be kept secret (to the
376 Signer and KMS), but the PVT need not be kept secret. A different
377 (SSK,PVT) pair will be needed for each Signer ID.
379 5.1.1. Algorithm for constructing (SSK,PVT) pair
381 The KMS constructs a (SSK,PVT) pair from the Signer's ID (ID), the
382 KMS secret (KSAK), and the root of trust (KPAK). To do this, the KMS
383 MUST perform the following procedure:
385 * Choose v, a random (ephemeral) non-zero element of F_q;
387 * Compute PVT = [v]G (this MUST be represented canonically - see
388 Section 3.2);
390 * Compute HS = hash( G || KPAK || ID || PVT ), an N-octet integer;
392 * Compute SSK = ( KSAK + HS * v ) modulo q;
394 * If either SSK or HS is zero modulo q, the KMS MUST erase SSK and
395 abort or restart the procedure with a fresh value of v;
397 * Output the pair ( SSK, PVT ). The KMS MUST then erase the value
398 v.
400 The method for transporting the SSK to the legitimate Signer device
401 is out of scope of this document, but the SSK MUST be provisioned by
402 the KMS using a method that protects its confidentiality.
404 If necessary, the KMS MAY create multiple (SSK,PVT) pairs for the
405 same Identifier.
407 5.1.2. Algorithm for validating a received SSK
409 Every SSK MUST be validated before being installed as a signing key.
410 The Signer uses its ID and the KPAK to validate a received (SSK,PVT)
411 pair. To do this validation, the Signer MUST perform the following
412 procedure, passing all checks:
414 * Validate that PVT lies on the elliptic curve E;
416 * Compute HS = hash( G || KPAK || ID || PVT ), an N-octet
417 integer. The integer HS SHOULD be stored with the SSK for later
418 use;
420 * Validate that KPAK = [SSK]G - [HS]PVT.
422 5.2. Signatures
424 5.2.1. Algorithm for signing
426 To sign a message M, the Signer requires:
428 the KMS Public Authentication Key, KPAK;
430 the Signer's own Identifier, ID;
432 its Secret Signing Key, SSK;
434 its Public Validation Token, PVT = ( PVTx, PVTy ).
436 These values, with the exception of ID, MUST have been provided by
437 the KMS. The value of ID is derived by the Signer using the
438 community defined method for formatting Identifiers.
440 The following procedure MUST be used by the Signer to compute the
441 signature:
443 1) Choose a random (ephemeral) non-zero value j in F_q;
444 2) Compute J = [j]G (this MUST be represented canonically).
445 Viewing J in affine coordinates J = (Jx,Jy), assign to r the
446 N-octet integer representing Jx;
448 3) Recall (or recompute) HS, and use it to compute HE = hash( HS
449 || r || M );
451 4) Verify that HE + r * SSK is non-zero modulo q; if this check
452 fails, the Signer MUST abort or restart this procedure with a
453 fresh value of j;
455 5) Compute s' = ( (( HE + r * SSK )^-1) * j ) modulo q; the Signer
456 MUST then erase the value j;
458 6) If s' is too big to fit within an N-octet integer, then set the
459 N-octet integer s = q - s'; otherwise set the N-octet integer s
460 = s' (note that, since p is less than 2^n, by Hasse's theorem
461 on elliptic curves, q < 2^n + 2^(n/2 + 1) + 1. Therefore, if
462 s' > 2^n, we have q - s' < 2(n/2 + 1) + 1. Thus s is
463 guaranteed to fit within an N-octet integer);
465 7) Output the signature as Signature = ( r || s || PVT ).
467 Note that the reason that step 6) is necessary is that it is possible
468 for q (and hence for elements of F_q) to be too big to fit within N
469 octets. The Signer MAY instead elect to set s to be the least
470 integer of s' and q - s', represented in N octets.
472 5.2.2. Algorithm for verifying
474 The algorithm provided assumes that the Verifier computes points on
475 elliptic curves using affine coordinates. However, the Verifier MAY
476 perform elliptic curve operations using any appropriate
477 representation of points which achieves the equivalent operations.
479 To verify a Signature ( r || s || PVT ) against a Signer's Identifier
480 ID, a message M, and a pre-installed root of trust KPAK, the Verifier
481 MUST perform a procedure equivalent to the following:
483 1) The Verifier MUST check that PVT lies on the elliptic curve E;
485 2) Compute HS = hash( G || KPAK || ID || PVT );
487 3) Compute HE = hash( HS || r || M );
489 4) Y = [HS]PVT + KPAK.
491 5) Compute J = [s]( [HE]G + [r]Y ).
493 6) Viewing J in affine coordinates (Jx,Jy), the Verifier MUST
494 check that Jx = r modulo p, and that Jx modulo p is non-zero,
495 before accepting the Signature as valid.
497 It is anticipated that the Identifier (ID), message (M), and KPAK,
498 will be implicitly understood due to context, but any of these values
499 MAY also be included in signaling.
501 Note that the parameter q is not needed during verification.
503 6. Security Considerations
505 The ECCSI cryptographic algorithm is based upon [ECDSA]. In fact,
506 step '5' in the verification algorithm above is the same as the
507 verification stage in ECDSA. The only difference between ECDSA and
508 ECCSI is that in ECCSI the 'public key', Y, is derived from the
509 Signer ID by the verifier (whereas in ECDSA the public key is
510 fixed). It is therefore assumed that the security of ECCSI depends
511 entirely on the secrecy of the secret keys. In addition, to recover
512 secret keys one will need to perform computationally intensive
513 cryptanalytic attacks.
515 The KMS Secret Authentication Key (KSAK) provides the security for
516 each device provisioned by the KMS. It MUST NOT be revealed to any
517 entity other than the KMS which holds it. Each user's Secret Signing
518 Key (SSK) authenticates the user as being associated with the
519 Identifier (ID) to which the Secret Signing Key is assigned by the
520 KMS. This key MUST NOT be revealed to any entity other than the KMS
521 and the authorized user.
523 The order of the base point G used in ECCSI MUST be a large prime q.
524 If k bits of symmetric security are needed, Ceiling(lg(q)) MUST be at
525 least 2*k.
527 It is RECOMMENDED that the curves and base-points defined in
528 [FIPS186-3] are used since these curves are suitable for
529 cryptographic use. However, if other curves are used, the security
530 of the curves MUST be assessed.
532 In order to ensure that the Secret Signing Key is only received by an
533 authorized device, it MUST be provided through a secure channel. The
534 strength of the authentication offered by this signature scheme is no
535 greater than the security provided by this delivery channel.
537 Identifiers MUST be defined unambiguously by each application of
538 ECCSI. Note that it is not necessary to use a hash function to
539 compose an Identifier string. In this way, any weaknesses that might
540 otherwise be caused by collisions in hash functions can be avoided
541 without reliance on the structure of the Identifier format.
542 Applications of ECCSI MAY include a time/date component in their
543 Identifier format to ensure that Identifiers (and hence Secret
544 Signing Keys) are only valid for a fixed period of time.
546 The use of the ephemeral value r in the hash HE significantly reduces
547 the scope for offline attacks, improving the overall security, as
548 compared to [ECDSA]. Furthermore, if Identifiers are specified to
549 contain date-stamps, then all Identifiers, secret signing keys,
550 signatures, and hash values will become deprecated periodically
551 automatically, reducing the need for revocation and other additional
552 management methods.
554 The randomness of values stipulated to be selected at random as
555 described in this document is essential to the security provided by
556 ECCSI. If the value of KSAK (the KMS Secret Authentication Key) can
557 be predicted, then any signatures can be forged. Similarly, if the
558 value of v used by the KMS to create a user's Secret Signing Key can
559 be predicted, then the value of KSAK could be recovered, which would
560 allow signatures to be forged. If the value of j used by a user is
561 predictable, then the value of his Secret Signing Key could be
562 recovered. This would allow that user's signatures to be forged.
563 Guidance on the generation of random values for security can be found
564 in [RFC4086].
566 Note that in most instances the value s in the Signature can be
567 replaced by q - s. Thus the malleability of ECCSI signatures is
568 similar to that in [ECDSA]; malleability is available but yet also
569 very limited.
571 7. IANA Considerations
573 This document has no IANA actions.
575 8. References
577 8.1. Normative References
579 [ECDSA] X9.62-2005, "Public Key Cryptography for the
580 Financial Services Industry: The Elliptic Curve
581 Digital Signature Standard (ECDSA)", November,
582 2005.
584 [FIPS186-3] Federal Information Processing Standards Publication
585 (FIPS PUB) 186-3, Digital Signature Standard (DSS),
586 June 2009.
588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
589 Requirement Levels", BCP 14, RFC 2119, March 1997.
591 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R. and
592 T. Polk, "Elliptic Curve Cryptography Subject
593 Public Key Information", RFC 5480, March 2009.
595 [RFC6090] McGrew, D., Igoe, K. and M. Salter, "Fundamental
596 Elliptic Curve Cryptography Algorithms", RFC 6090,
597 February 2011.
599 8.2. Informative References
601 [BA] Arazi, Benjamin, paper submitted to P1363 meeting,
602 August 1998, http://grouper.ieee.org/groups/1363/
603 StudyGroup/contributions/arazi.doc.
605 [FIPS180-3] Federal Information Processing Standards Publication
606 (FIPS PUB) 180-3, Secure Hash Standard (SHS),
607 October 2008.
609 [MIKEY-SAKKE] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key
610 Exchange in Multimedia Internet KEYing (MIKEY)",
611 draft-groves-mikey-sakke-01 [work in progress],
612 February 2011.
614 [RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,
615 and K. Norrman, "MIKEY: Multimedia Internet
616 KEYing", RFC 3830, August 2004.
618 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker,
619 "Randomness Requirements for Security", BCP 106,
620 RFC 4086, June 2005.
622 [SAKKE] Groves M., "Sakai-Kasahara Key Establishment
623 (SAKKE)", draft-groves-sakke-01 [work in progress],
624 February 2011.
626 Appendix A. Test data
628 This test data is built from the NIST P256 curve and base-point.
629 SHA-256 (as defined in [FIPS180-3]) is used as the hash function.
630 The keys and ephemerals KSAK, v, j, are arbitrary and for
631 illustration only.
633 // --------------------------------------------------------
634 // Global parameters
636 n := 256;
637 N := 32;
639 p := 0x FFFFFFFF 00000001 00000000 00000000
640 00000000 FFFFFFFF FFFFFFFF FFFFFFFF;
642 Hash := SHA-256;
643 // --------------------------------------------------------
644 // Community parameters
646 B := 0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC
647 651D06B0 CC53B0F6 3BCE3C3E 27D2604B;
649 q := 0x FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
650 BCE6FAAD A7179E84 F3B9CAC2 FC632551;
652 G := 0x 04
653 6B17D1F2 E12C4247 F8BCE6E5 63A440F2
654 77037D81 2DEB33A0 F4A13945 D898C296
655 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16
656 2BCE3357 6B315ECE CBB64068 37BF51F5;
658 KSAK := 0x 12345;
660 KPAK := 0x 04
661 50D4670B DE75244F 28D2838A 0D25558A
662 7A72686D 4522D4C8 273FB644 2AEBFA93
663 DBDD3755 1AFD263B 5DFD617F 3960C65A
664 8C298850 FF99F203 66DCE7D4 367217F4;
666 // --------------------------------------------------------
667 // Signer ID
669 ID := "2011-02\0tel:+447700900123\0",
670 = 0x 3230 31312D30 32007465 6C3A2B34
671 34373730 30393030 31323300;
673 // --------------------------------------------------------
674 // Creating SSK and PVT
676 v := 0x 23456;
677 PVT := 0x 04
678 758A1427 79BE89E8 29E71984 CB40EF75
679 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9
680 A79D2476 92F4EDA3 A6BDAB77 D6AA6474
681 A464AE49 34663C52 65BA7018 BA091F79;
683 HS := hash( 0x 04
684 6B17D1F2 E12C4247 F8BCE6E5 63A440F2
685 77037D81 2DEB33A0 F4A13945 D898C296
686 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16
687 2BCE3357 6B315ECE CBB64068 37BF51F5
688 04
689 50D4670B DE75244F 28D2838A 0D25558A
690 7A72686D 4522D4C8 273FB644 2AEBFA93
691 DBDD3755 1AFD263B 5DFD617F 3960C65A
692 8C298850 FF99F203 66DCE7D4 367217F4
693 32303131 2D303200 74656C3A 2B343437
694 37303039 30303132 3300
695 04
696 758A1427 79BE89E8 29E71984 CB40EF75
697 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9
698 A79D2476 92F4EDA3 A6BDAB77 D6AA6474
699 A464AE49 34663C52 65BA7018 BA091F79 ),
701 = 0x 490F3FEB BC1C902F 6289723D 7F8CBF79
702 DB889308 49D19F38 F0295B5C 276C14D1;
704 SSK := 0x 23F374AE 1F4033F3 E9DBDDAA EF20F4CF
705 0B86BBD5 A138A5AE 9E7E006B 34489A0D;
707 // --------------------------------------------------------
708 // Creating a Signature
710 M := "message\0",
711 = 0x 6D657373 61676500;
713 j := 0x 34567;
714 J := 0x 04
715 269D4C8F DEB66A74 E4EF8C0D 5DCC597D
716 DFE6029C 2AFFC493 6008CD2C C1045D81
717 6DDA6A13 10F4B067 BD5DABDA D741B7CE
718 F36457E1 96B1BFA9 7FD5F8FB B3926ADB;
720 r := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D
721 DFE6029C 2AFFC493 6008CD2C C1045D81;
723 HE := hash( 0x
724 490F3FEB BC1C902F 6289723D 7F8CBF79
725 DB889308 49D19F38 F0295B5C 276C14D1
726 269D4C8F DEB66A74 E4EF8C0D 5DCC597D
727 DFE6029C 2AFFC493 6008CD2C C1045D81
728 6D657373 61676500 ),
730 = 0x 111F90EA E8271C96 DF9B3D67 26768D9E
731 E9B18145 D7EC152C FA9C23D1 C4F02285;
733 s' := 0x E09B528D 0EF8D6DF 1AA3ECBF 80110CFC
734 EC9FC682 52CEBB67 9F413484 6940CCFD;
736 s := 0x E09B528D 0EF8D6DF 1AA3ECBF 80110CFC
737 EC9FC682 52CEBB67 9F413484 6940CCFD;
739 Sig := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D
740 DFE6029C 2AFFC493 6008CD2C C1045D81
741 E09B528D 0EF8D6DF 1AA3ECBF 80110CFC
742 EC9FC682 52CEBB67 9F413484 6940CCFD
743 04
744 758A1427 79BE89E8 29E71984 CB40EF75
745 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9
746 A79D2476 92F4EDA3 A6BDAB77 D6AA6474
747 A464AE49 34663C52 65BA7018 BA091F79;
749 // --------------------------------------------------------
750 // Verifying a Signature
752 Y := 0x 04
753 833898D9 39C0013B B0502728 6F95CCE0
754 37C11BD2 5799423C 76E48362 A4959978
755 95D0473A 1CD6186E E9F0C104 B472499E
756 1A24D6CE 3D85173F 02EBBD94 5C25F604;
757 J := 0x 04
758 269D4C8F DEB66A74 E4EF8C0D 5DCC597D
759 DFE6029C 2AFFC493 6008CD2C C1045D81
760 6DDA6A13 10F4B067 BD5DABDA D741B7CE
761 F36457E1 96B1BFA9 7FD5F8FB B3926ADB;
763 Jx := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D
764 DFE6029C 2AFFC493 6008CD2C C1045D81;
766 Jx = r modulo p.
768 // --------------------------------------------------------
770 Author's Address
772 Michael Groves
773 CESG
774 Hubble Road
775 Cheltenham
776 GL51 8HJ
777 UK
779 Email: Michael.Groves@cesg.gsi.gov.uk
781 Acknowledgement
783 Funding for the RFC Editor function is provided by the IETF
784 Administrative Support Activity (IASA).