[要約] RFC 6507は、"Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)"に関する文書で、公開鍵暗号方式の一種である証明書レス署名方式を定義しています。この方式は、従来の公開鍵基盤(PKI)における証明書の必要性を排除し、IDベースの暗号化と組み合わせることで、より効率的かつ管理が容易なセキュリティシステムを実現します。主に、デジタル署名や暗号化通信などのセキュリティが求められる場面で利用されます。関連するRFCにはRFC 6508 (Sakai-Kasahara Key Encryption (SAKKE))があり、ECCSIと組み合わせて使用されることが多いです。
Internet Engineering Task Force (IETF) M. Groves
Request for Comments: 6507 CESG
Category: Informational February 2012
ISSN: 2070-1721
Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)
アイデンティティベースの暗号化（ECCSI）のための楕円曲線ベースの証明書なし署名
Abstract
概要
Many signature schemes currently in use rely on certificates for authentication of identity. In Identity-based cryptography, this adds unnecessary overhead and administration. The Elliptic Curve-based Certificateless Signatures for Identity-based Encryption (ECCSI) signature scheme described in this document is certificateless. This scheme has the additional advantages of low bandwidth and low computational requirements.
現在使用されている多くの署名スキームは、IDの認証を証明書に依存しています。アイデンティティベースの暗号化では、これにより不要なオーバーヘッドと管理が追加されます。このドキュメントで説明されているアイデンティティベースの暗号化（ECCSI）署名方式の楕円曲線ベースの証明書なしの署名は、証明書なしです。この方式には、帯域幅が低く、計算要件が低いという追加の利点があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 Internet Engineering Steering Group（IESG）による公開が承認されています。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6507.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6507で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Terminology ...................................3
2. Architecture ....................................................3
3. Notation ........................................................5
3.1. Arithmetic .................................................5
3.2. Representations ............................................6
3.3. Format of Material .........................................6
4. Parameters ......................................................7
4.1. Static Parameters ..........................................7
4.2. Community Parameters .......................................8
5. Algorithms ......................................................8
5.1. User Key Material ..........................................8
5.1.1. Algorithm for Constructing (SSK,PVT) Pair ...........8
5.1.2. Algorithm for Validating a Received SSK .............9
5.2. Signatures .................................................9
5.2.1. Algorithm for Signing ...............................9
5.2.2. Algorithm for Verifying ............................10
6. Security Considerations ........................................11
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................13
Appendix A. Test Data..............................................14
Digital signatures provide authentication services across a wide range of applications. A chain of trust for such signatures is usually provided by certificates. However, in low-bandwidth or other resource-constrained environments, the use of certificates might be undesirable. This document describes an efficient scheme, ECCSI, for elliptic curve-based certificateless signatures, primarily intended for use with Identity-Based Encryption (IBE) schemes such as described in [RFC6508]. As certificates are not needed, the need to transmit or store them to authenticate each communication is obviated. The algorithm has been developed by drawing on ideas set out by Arazi [BA] and is originally based upon the Elliptic Curve Digital Signature Algorithm [ECDSA], one of the most commonly used signature algorithms.
デジタル署名は、幅広いアプリケーションに認証サービスを提供します。このような署名の信頼チェーンは通常、証明書によって提供されます。ただし、低帯域幅またはその他のリソースに制約のある環境では、証明書の使用は望ましくない場合があります。このドキュメントでは、[RFC6508]で説明されているように、主にアイデンティティベースの暗号化（IBE）スキームでの使用を目的とした、楕円曲線ベースの証明書なし署名の効率的なスキームであるECCSIについて説明します。証明書は必要ないため、各通信を認証するために証明書を送信または保存する必要はありません。このアルゴリズムは、Arazi [BA]によって提示されたアイデアを利用して開発され、もともとは最も一般的に使用される署名アルゴリズムの1つである楕円曲線デジタル署名アルゴリズム[ECDSA]に基づいています。
The algorithm is for use in the following context:
このアルゴリズムは、次のコンテキストで使用するためのものです。
* where there are two parties, a Signer and a Verifier;
* 署名者と検証者の2つのパーティがある場合。
* where short unambiguous Identifier strings are naturally associated to each of these parties;
* 明確で短い識別子文字列がこれらの各パーティに自然に関連付けられている場合。
* where a message is to be signed and then verified (e.g., for authenticating the initiating party during an Identity-based key establishment);
* メッセージが署名され、検証される場合（たとえば、IDベースの鍵の確立中に開始者を認証するため）;
* where a common Key Management Service (KMS) provides a root of trust for both parties.
* ここで、共通のキー管理サービス（KMS）は、両方の当事者に信頼のルートを提供します。
The scheme does not rely on any web of trust between users.
このスキームは、ユーザー間の信頼関係に依存しません。
Authentication is provided in a single simplex transmission without per-session reference to any third party. Thus, the scheme is particularly suitable in situations where the receiving party need not be active (or even enrolled) when the message to be authenticated is sent, or where the number of transmissions is to be minimized for efficiency.
認証は、サードパーティへのセッションごとの参照なしで、単一のシンプレックス伝送で提供されます。したがって、このスキームは、認証されるメッセージが送信されるときに受信側がアクティブである（または登録さえする）必要がない場合、または効率のために送信数を最小限に抑える必要がある場合に特に適しています。
Instead of having a certificate, the Signer has an Identifier, to which his Secret Signing Key (SSK) (see Section 2) will have been cryptographically bound by means of a Public Validation Token (PVT) (see Section 2) by the KMS. Unlike a traditional public key, this PVT requires no further explicit certification.
署名者は証明書を持っている代わりに、KMSが公開検証トークン（PVT）（セクション2を参照）を使用して秘密署名鍵（SSK）（セクション2を参照）に暗号でバインドした識別子を持っています。従来の公開鍵とは異なり、このPVTはそれ以上の明示的な認証を必要としません。
The verification primitive within this scheme can be implemented using projective representation of elliptic curve points, without arithmetic field divisions, and without explicitly using the size of the underlying cryptographic group.
このスキーム内の検証プリミティブは、楕円曲線ポイントの射影表現を使用して、算術フィールドの除算なしに、および基礎となる暗号グループのサイズを明示的に使用せずに実装できます。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
A KMS provisions key material for a set of communicating devices (a "user community"). Each device within the user community MUST have an Identifier (ID), which can be formed by its peers. These Identifiers MUST be unique to devices (or users), and MAY change over time. As such, all applications of this signature scheme MUST define an unambiguous format for Identifiers. We consider the situation where one device (the Signer) wishes to sign a message that it is sending to another (the Verifier). Only the Signer's ID is used in the signature scheme.
KMSは、一連の通信デバイス（「ユーザーコミュニティ」）のキーマテリアルをプロビジョニングします。ユーザーコミュニティ内の各デバイスには、ピアが形成できる識別子（ID）が必要です。これらの識別子はデバイス（またはユーザー）に固有である必要があり、時間とともに変化する可能性があります。そのため、この署名方式のすべてのアプリケーションは、識別子の明確な形式を定義する必要があります。あるデバイス（署名者）が別のデバイス（検証者）に送信するメッセージに署名したい状況を考えます。署名スキームでは、署名者のIDのみが使用されます。
In advance, the KMS chooses its KMS Secret Authentication Key (KSAK), which is the root of trust for all other key material in the scheme. From this, the KMS derives the KMS Public Authentication Key (KPAK), which all devices will require in order to verify signatures. This will be the root of trust for verification.
事前に、KMSはKMSシークレット認証キー（KSAK）を選択します。これは、スキーム内の他のすべてのキーマテリアルの信頼のルートです。これから、KMSはKMS公開認証キー（KPAK）を取得します。これは、すべてのデバイスが署名を検証するために必要です。これが検証の信頼のルーツになります。
Before verification of any signatures, members of the user community are supplied with the KPAK. The supply of the KPAK MUST be authenticated by the KMS, and this authentication MUST be verified by each member of the user community. Confidentiality protection MAY also be applied.
署名を検証する前に、ユーザーコミュニティのメンバーにKPAKが提供されます。 KPAKの提供はKMSによって認証される必要があり、この認証はユーザーコミュニティの各メンバーによって検証される必要があります。機密保護も適用される場合があります。
In the description of the algorithms in this document, it is assumed that there is one KMS, one user community, and hence one KPAK. Applications MAY support multiple KPAKs, and some KPAKs could in fact be "private" to certain communities in certain circumstances. The method for determining which KPAK to use (when more than one is available) is out of scope.
このドキュメントのアルゴリズムの説明では、KMSが1つ、ユーザーコミュニティが1つ、したがってKPAKが1つあると想定しています。アプリケーションは複数のKPAKをサポートする場合があり、一部のKPAKは実際、特定の状況では特定のコミュニティに対して「プライベート」である場合があります。使用するKPAKを決定する方法（複数使用可能な場合）は範囲外です。
The KMS generates and provisions key material for each device. It MUST supply an SSK along with a PVT to all devices that are to send signed messages. The mechanism by which these SSKs are provided MUST be secure, as the security of the authentication provided by ECCSI signatures is no stronger than the security of this supply channel.
KMSは、各デバイスのキーマテリアルを生成およびプロビジョニングします。署名付きメッセージを送信するすべてのデバイスに、PVTとともにSSKを提供する必要があります。 ECCSI署名によって提供される認証のセキュリティはこの供給チャネルのセキュリティよりも強力ではないため、これらのSSKが提供されるメカニズムは安全である必要があります。
Before using the supplied key material (SSK, KPAK) to form signatures, the Sender MUST verify the key material (SSK) against the root of trust (KPAK) and against its own ID and its PVT, using the algorithm defined in Section 5.1.2.
提供されたキーマテリアル（SSK、KPAK）を使用して署名を作成する前に、送信者はセクション5.1で定義されたアルゴリズムを使用して、キーマテリアル（SSK）を信頼のルート（KPAK）と自身のIDおよびそのPVTに対して検証する必要があります。 2。
During the signing process, once the Signer has formed its message, it signs the message using its SSK. It transmits the Signature (including the PVT), and MAY also transmit the message (in cases where the message is not known to the Verifier). The Verifier MUST then use the message, Signature, and Sender ID in verification against the KPAK.
署名プロセスでは、署名者がメッセージを形成すると、SSKを使用してメッセージに署名します。署名（PVTを含む）を送信し、メッセージも送信できます（メッセージがベリファイアに知られていない場合）。次に検証者は、KPAKに対する検証でメッセージ、署名、および送信者IDを使用する必要があります。
This document specifies
このドキュメントでは、
* an algorithm for creating a KPAK from a KSAK, for a given elliptic curve;
* 与えられた楕円曲線に対して、KSAKからKPAKを作成するアルゴリズム。
* a format for transporting a KPAK;
* KPAKを転送するためのフォーマット。
* an algorithm for creating an SSK and a PVT from a Signer's ID, using the KSAK;
* KSAKを使用して、署名者のIDからSSKおよびPVTを作成するアルゴリズム。
* an algorithm for verifying an SSK and a PVT against a Signer's ID and KPAK;
* 署名者のIDとKPAKに対してSSKとPVTを検証するアルゴリズム。
* an algorithm for creating a Signature from a message, using a Signer's ID with a matching SSK and PVT;
* SSKとPVTが一致する署名者のIDを使用して、メッセージから署名を作成するアルゴリズム。
* a format for transporting a Signature;
* 署名を転送するためのフォーマット。
* an algorithm for verifying a Signature for a message, using a Signer's ID with the matching KPAK.
* 一致するKPAKで署名者のIDを使用して、メッセージの署名を検証するアルゴリズム。
This document does not specify (but comments on)
このドキュメントでは指定していません（コメントについて）
* how to choose a valid and secure elliptic curve;
* 有効で安全な楕円曲線を選択する方法;
* which hash function to use;
* 使用するハッシュ関数。
* how to format a Signer's ID;
* 署名者のIDをフォーマットする方法。
* how to format a message for signing;
* 署名用にメッセージをフォーマットする方法。
* how to manage and install a KPAK;
* KPAKを管理およびインストールする方法。
* how to transport or install an SSK.
* SSKの輸送またはインストール方法。
As used in [RFC6509], the elliptic curve and hash function are specified in Section 2.1.1 of [RFC6509], the format of Identifiers is specified in Section 3.2 of [RFC6509], and messages for signing are formatted as specified in [RFC3830].
[RFC6509]で使用されているように、楕円曲線とハッシュ関数は[RFC6509]のセクション2.1.1で指定され、識別子の形式は[RFC6509]のセクション3.2で指定され、署名用のメッセージは[RFC3830 ]。
ECCSI relies on elliptic curve arithmetic. If P and Q are two elliptic curve points, their addition is denoted P + Q. Moreover, the addition of P with itself k times is denoted [k]P.
ECCSIは楕円曲線演算に依存しています。 PとQが2つの楕円曲線点である場合、それらの加算はP + Qで表されます。さらに、P自体のk回の加算は[k] Pで表されます。
F_p denotes the finite field of p elements, where p is prime. All elliptic curve points will be defined over F_p.
F_pはp要素の有限体を示し、pは素数です。すべての楕円曲線点はF_pで定義されます。
The curve is defined by the equation y^2 = x^3 - 3*x + B modulo p,
where B is an element of F_p. Elliptic curve points, other than the
group identity (0), are represented in the format P = (Px,Py), where
Px and Py are the affine coordinates in F_p satisfying the above
equation. In particular, a point P = (Px,Py) is said to lie on an
elliptic curve if Py^2 - Px^3 + 3*Px - B = 0 modulo p. The identity
point 0 will require no representation.
This section provides canonical representations of values that MUST be used to ensure interoperability of implementations. The following representations MUST be used for input into hash functions and for transmission. In this document, concatenation of octet strings s and t is denoted s || t. The logarithm base 2 of a real number a is denoted lg(a).
このセクションでは、実装の相互運用性を保証するために使用する必要がある値の正規表現を提供します。次の表現は、ハッシュ関数への入力および送信に使用する必要があります。このドキュメントでは、オクテット文字列sとtの連結をs ||と表記しています。 t。実数aの対数の底2はlg（a）で表されます。
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]. There will be no need to represent negative integers. When transmitted or hashed, such octet strings MUST have length N = Ceiling(lg(p)/8).
整数整数は、ビット長が8の倍数のオクテット文字列として表現する必要があります。これを実現するには、整数を最初に最上位ビットで表し、必要な長さのオクテット文字列が得られるまで左側にゼロビットを埋めます。これは、[RFC6090]のセクション6で説明されているオクテット文字列表現です。負の整数を表す必要はありません。送信またはハッシュされる場合、そのようなオクテット文字列の長さはN = Ceiling（lg（p）/ 8）でなければなりません。
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. For use in ECCSI, such octet strings MUST have length N = Ceiling(lg(p)/8).
F_p要素F_pの要素は、上記で定義したオクテット文字列表現を使用して、0からp-1の範囲の整数として表現する必要があります。 ECCSIで使用するには、そのようなオクテット文字列の長さはN = Ceiling（lg（p）/ 8）でなければなりません。
Points on E Elliptic curve points MUST be represented in uncompressed form ("affine coordinates") 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 N-octet string representing x and y' is the N-octet string representing y.
E楕円曲線上の点は、[RFC5480]のセクション2.2で定義されているように、非圧縮形式（「アフィン座標」）で表す必要があります。 F_pにxとyがある楕円曲線点（x、y）の場合、この表現は0x04 ||で与えられます。 x '|| y '。ここで、x'はxを表すNオクテット文字列であり、y 'はyを表すNオクテット文字列です。
This section describes the subfields of the different objects used within the protocol.
このセクションでは、プロトコル内で使用されるさまざまなオブジェクトのサブフィールドについて説明します。
Signature = r || s || PVT where r and s are octet strings of length N = Ceiling(lg(p)/8) representing integers, and PVT is an octet string of length 2N+1 representing an elliptic curve point, yielding a total signature length of 4N+1 octets. (Note that r and s represent integers rather than elements of F_p, and therefore it is possible that either or both of them could equal or exceed p.)
署名= r || s || PVT。ここで、rとsは整数を表す長さN = Ceiling（lg（p）/ 8）のオクテット文字列で、PVTは楕円曲線点を表す長さ2N + 1のオクテット文字列であり、合計署名長は4N + 1になります。オクテット。 （rとsはF_pの要素ではなく整数を表すことに注意してください。したがって、これらのいずれかまたは両方がpと等しいかそれを超える可能性があります。）
The following static parameters are fixed for each implementation. They are not intended to change frequently, and MUST be specified for each user community. Note that these parameters MAY be shared across multiple KMSs.
次の静的パラメータは、実装ごとに固定されています。それらは頻繁に変更することを意図しておらず、ユーザーコミュニティごとに指定する必要があります。これらのパラメータは複数のKMS間で共有できることに注意してください。
n A security parameter; the size in bits of the prime p over which elliptic curve cryptography is to be performed.
nセキュリティパラメータ。楕円曲線暗号化が実行される素数pのビットサイズ。
N = Ceiling(n/8) The number of octets used to represent fields r and s in a Signature. Also the number of octets output by the hash function (see below).
N = Ceiling（n / 8）署名のフィールドrおよびsを表すために使用されるオクテットの数。また、ハッシュ関数によって出力されるオクテットの数（以下を参照）。
p A prime number of size n bits. The finite field with p elements is denoted F_p.
pサイズnビットの素数。 p要素の有限体はF_pと表されます。
E An elliptic curve defined over F_p, having a subgroup of prime order q.
E F_p上で定義され、素数次数qのサブグループを持つ楕円曲線。
B An element of F_p, where E is defined by the formula y^2 = x^3 - 3*x + B modulo p.
B F_pの要素。Eは、式y ^ 2 = x ^ 3-3 * x + B modulo pで定義されます。
G A point on the elliptic curve E that generates the subgroup of order q.
G次数qのサブグループを生成する楕円曲線E上の点。
q The prime q is defined to be the order of G in E over F_p.
q素数qは、F_p上のEのGの次数になるように定義されます。
Hash A cryptographic hash function mapping arbitrary strings to strings of N octets. If a, b, c, ... are strings, then hash( a || b || c || ...) denotes the result obtained by hashing the concatenation of these strings.
Hash任意の文字列をNオクテットの文字列にマッピングする暗号化ハッシュ関数。 a、b、c、...が文字列の場合、hash（a || b || c || ...）は、これらの文字列の連結をハッシュして得られた結果を示します。
Identifiers The method for deriving user Identifiers. The format of Identifiers MUST be specified by each implementation. It MUST be possible for each device to derive the Identifier for every device with which it needs to communicate. In this document, ID will denote the correctly formatted Identifier string of the Signer. ECCSI makes use of the Signer Identifier only, though an implementation MAY make use of other Identifiers when constructing the message to be signed. Identifier formats MAY include a timestamp to allow for automatic expiration of key material.
識別子ユーザー識別子を導出する方法。識別子の形式は、各実装で指定する必要があります。各デバイスは、通信する必要のあるすべてのデバイスの識別子を導出できる必要があります。このドキュメントでは、IDは署名者の正しい形式の識別子文字列を示します。 ECCSIは署名者識別子のみを利用しますが、実装は、署名されるメッセージを構築するときに他の識別子を利用してもよい（MAY）。識別子の形式には、キーマテリアルの自動期限切れを可能にするタイムスタンプが含まれる場合があります。
It is RECOMMENDED that p, E, and G are chosen to be standardized values. In particular, it is RECOMMENDED that the curves and base points defined in [FIPS186-3] be used.
p、E、およびGを標準化された値として選択することをお勧めします。特に、[FIPS186-3]で定義されている曲線と基点を使用することをお勧めします。
The following community parameter MUST be supplied to devices each time the root of trust is changed.
信頼のルートが変更されるたびに、次のコミュニティパラメータをデバイスに提供する必要があります。
KPAK The KMS Public Authentication Key (KPAK) is the root of trust for authentication. It is derived from the KSAK in the KMS. This value MUST be provisioned in a trusted fashion, such that each device that receives it has assurance that it is the genuine KPAK belonging to its KMS. Before use, each device MUST check that the supplied KPAK lies on the elliptic curve E.
KPAK KMS公開認証キー（KPAK）は、認証の信頼のルートです。 KMSのKSAKから派生しています。この値は、それを受信する各デバイスが、そのKMSに属する本物のKPAKであることが保証されるように、信頼できる方法でプロビジョニングする必要があります。使用する前に、各デバイスは、提供されたKPAKが楕円曲線Eにあることを確認する必要があります。
The KMS MUST fix the KPAK to be KPAK = [KSAK]G, where the KSAK MUST
be chosen to be a random secret non-zero integer modulo q. The value
of the KSAK MUST be kept secret to the KMS.
To create signatures, each Signer requires a Secret Signing Key (SSK) and a Public Validation Token (PVT). The SSK is an integer, and the PVT is an elliptic curve point. The SSK MUST be kept secret (to the Signer and KMS), but the PVT need not be kept secret. A different (SSK,PVT) pair will be needed for each Signer ID.
署名を作成するには、各署名者に秘密署名鍵（SSK）と公開検証トークン（PVT）が必要です。 SSKは整数で、PVTは楕円曲線点です。 SSKは（署名者とKMSに対して）秘密にしておく必要がありますが、PVTを秘密にしておく必要はありません。署名者IDごとに異なる（SSK、PVT）ペアが必要になります。
The KMS constructs a (SSK,PVT) pair from the Signer's ID, the KMS secret (KSAK), and the root of trust (KPAK). To do this, the KMS MUST perform the following procedure:
KMSは、署名者のID、KMSシークレット（KSAK）、および信頼のルート（KPAK）から（SSK、PVT）ペアを構築します。これを行うには、KMSは次の手順を実行する必要があります。
1) Choose v, a random (ephemeral) non-zero element of F_q;
1）vを選択します。vはF_qのランダム（一時的な）非ゼロ要素です。
2) Compute PVT = [v]G (this MUST be represented canonically -- see
Section 3.2);
3) Compute a hash value HS = hash( G || KPAK || ID || PVT ), an N-octet integer;
3）ハッシュ値HS = H（G || KPAK || ID || PVT）、Nオクテット整数を計算します。
4) Compute SSK = ( KSAK + HS * v ) modulo q;
5) If either the SSK or HS is zero modulo q, the KMS MUST erase the SSK and abort or restart the procedure with a fresh value of v;
5）SSKまたはHSのいずれかがqを法とするゼロの場合、KMSはSSKを消去し、vの新しい値で手順を中止または再開する必要があります。
6) Output the (SSK,PVT) pair. The KMS MUST then erase the value v.
6）（SSK、PVT）ペアを出力します。次に、KMSは値vを消去する必要があります。
The method for transporting the SSK to the legitimate Signer device is out of scope for this document, but the SSK MUST be provisioned by the KMS using a method that protects its confidentiality.
SSKを正規の署名者デバイスに転送する方法はこのドキュメントの範囲外ですが、SSKは、その機密性を保護する方法を使用してKMSによってプロビジョニングされる必要があります。
If necessary, the KMS MAY create multiple (SSK,PVT) pairs for the same Identifier.
必要に応じて、KMSは同じ識別子に対して複数の（SSK、PVT）ペアを作成できます（MAY）。
Every SSK MUST be validated before being installed as a signing key. The Signer uses its ID and the KPAK to validate a received (SSK,PVT) pair. To do this validation, the Signer MUST perform the following procedure, passing all checks:
すべてのSSKは、署名鍵としてインストールする前に検証する必要があります。署名者は、IDとKPAKを使用して、受信した（SSK、PVT）ペアを検証します。この検証を行うには、署名者は次の手順を実行し、すべてのチェックに合格する必要があります。
1) Validate that the PVT lies on the elliptic curve E;
1）PVTが楕円曲線Eにあることを確認します。
2) Compute HS = hash( G || KPAK || ID || PVT ), an N-octet integer. The integer HS SHOULD be stored with the SSK for later use;
2）HS = hash（G || KPAK || ID || PVT）、Nオクテット整数を計算します。整数HSは、後で使用するためにSSKとともに保存する必要があります（SHOULD）。
3) Validate that KPAK = [SSK]G - [HS]PVT.
To sign a message (M), the Signer requires
メッセージに署名するには（M）、署名者は
* the KMS Public Authentication Key, KPAK;
* KMS公開認証キー、KPAK。
* the Signer's own Identifier, ID;
* 署名者自身の識別子、ID。
* its Secret Signing Key, SSK;
* その秘密署名鍵、SSK。
* its Public Validation Token, PVT = (PVTx,PVTy).
* その公開検証トークン、PVT =（PVTx、PVTy）。
These values, with the exception of ID, MUST have been provided by the KMS. The value of ID is derived by the Signer using the community-defined method for formatting Identifiers.
これらの値は、IDを除き、KMSから提供されている必要があります。 IDの値は、識別子をフォーマットするためにコミュニティが定義した方法を使用して署名者によって導出されます。
The following procedure MUST be used by the Signer to compute the signature:
署名を計算するには、署名者が次の手順を使用する必要があります。
1) Choose a random (ephemeral) non-zero value j in F_q;
1）F_qのランダムな（エフェメラル）非ゼロ値jを選択します。
2) Compute J = [j]G (this MUST be represented canonically).
Viewing J in affine coordinates J = (Jx,Jy), assign to r the
N-octet integer representing Jx;
3) Recall (or recompute) HS, and use it to compute a hash value HE = hash( HS || r || M );
3）HSを再呼び出し（または再計算）し、それを使用してハッシュ値を計算しますHE = hash（HS || r || M）;
4) Verify that HE + r * SSK is non-zero modulo q; if this check fails, the Signer MUST abort or restart this procedure with a fresh value of j;
4）HE + r * SSKがqを法とする非ゼロであることを確認します。このチェックが失敗した場合、署名者はjの新しい値でこの手順を中止または再開する必要があります。
5) Compute s' = ( (( HE + r * SSK )^-1) * j ) modulo q; the Signer
MUST then erase the value j;
6) If s' is too big to fit within an N-octet integer, then set the
N-octet integer s = q - s'; otherwise, set the N-octet integer
s = s' (note that since p is less than 2^n, by Hasse's theorem
on elliptic curves, q < 2^n + 2^(n/2 + 1) + 1. Therefore, if
s' > 2^n, we have q - s' < 2(n/2 + 1) + 1. Thus, s is
guaranteed to fit within an N-octet integer);
7) Output the signature as Signature = ( r || s || PVT ).
Note that step 6) is necessary because it is possible for q (and hence for elements of F_q) to be too big to fit within N octets. The Signer MAY instead elect to set s to be the least integer of s' and q - s', represented in N octets.
q（およびF_qの要素）が大きすぎてNオクテットに収まらない可能性があるため、手順6）が必要であることに注意してください。代わりに、署名者は、Nオクテットで表されるs 'とq-s'の最小の整数になるようにsを設定することを選択してもよい（MAY）。
The algorithm provided assumes that the Verifier computes points on elliptic curves using affine coordinates. However, the Verifier MAY perform elliptic curve operations using any appropriate representation of points that achieves the equivalent operations.
提供されるアルゴリズムは、Verifierがアフィン座標を使用して楕円曲線上の点を計算することを前提としています。ただし、ベリファイアは、同等の演算を実現するポイントの適切な表現を使用して楕円曲線演算を実行してもよい（MAY）。
To verify a Signature ( r || s || PVT ) against a Signer's Identifier (ID), a message (M), and a pre-installed root of trust (KPAK), the Verifier MUST perform a procedure equivalent to the following:
署名（r || s || PVT）を署名者の識別子（ID）、メッセージ（M）、および事前にインストールされた信頼のルート（KPAK）に対して検証するには、検証者は次と同等の手順を実行する必要があります。
1) The Verifier MUST check that the PVT lies on the elliptic curve E;
1）Verifierは、PVTが楕円曲線Eにあることを確認する必要があります。
2) Compute HS = hash( G || KPAK || ID || PVT );
3) Compute HE = hash( HS || r || M );
4) Y = [HS]PVT + KPAK;
5) Compute J = [s]( [HE]G + [r]Y );
6) Viewing J in affine coordinates (Jx,Jy), the Verifier MUST check that Jx = r modulo p, and that Jx modulo p is non-zero, before accepting the Signature as valid.
6）アフィン座標（Jx、Jy）でJを表示する場合、検証者は、署名を有効として受け入れる前に、Jx = r modulo pであること、およびJx modulo pがゼロ以外であることを確認する必要があります。
It is anticipated that the ID, message (M), and KPAK will be implicitly understood due to context, but any of these values MAY also be included in signaling.
ID、メッセージ（M）、およびKPAKは、コンテキストにより暗黙的に理解されることが予想されますが、これらの値のいずれもシグナリングに含めることができます（MAY）。
Note that the parameter q is not needed during verification.
検証中はパラメーターqは必要ありません。
The ECCSI cryptographic algorithm is based upon [ECDSA]. In fact, step 5) in the verification algorithm above is the same as the verification stage in ECDSA. The only difference between ECDSA and ECCSI is that in ECCSI the 'public key', Y, is derived from the Signer ID by the Verifier (whereas in ECDSA the public key is fixed). It is therefore assumed that the security of ECCSI depends entirely on the secrecy of the secret keys. In addition, to recover secret keys, one will need to perform computationally intensive cryptanalytic attacks.
ECCSI暗号アルゴリズムは[ECDSA]に基づいています。実際、上記の検証アルゴリズムのステップ5）は、ECDSAの検証ステージと同じです。 ECDSAとECCSIの唯一の違いは、ECCSIでは「公開鍵」Yが検証者によって署名者IDから導出されることです（ECDSAでは公開鍵は固定されています）。したがって、ECCSIのセキュリティは完全に秘密鍵の機密性に依存すると想定されています。さらに、秘密鍵を回復するには、計算集約型の暗号解読攻撃を実行する必要があります。
The KSAK provides the security for each device provisioned by the KMS. It MUST NOT be revealed to any entity other than the KMS that holds it. Each user's SSK authenticates the user as being associated with the ID to which the SSK is assigned by the KMS. This key MUST NOT be revealed to any entity other than the KMS and the authorized user.
KSAKは、KMSによってプロビジョニングされた各デバイスにセキュリティを提供します。それを保持するKMS以外のエンティティに公開してはなりません。各ユーザーのSSKは、KMSによってSSKが割り当てられたIDに関連付けられているとしてユーザーを認証します。このキーは、KMSと承認されたユーザー以外のエンティティに公開しないでください。
The order of the base point G used in ECCSI MUST be a large prime q. If k bits of symmetric security are needed, Ceiling(lg(q)) MUST be at least 2*k.
ECCSIで使用される基点Gの次数は、大きな素数qでなければなりません。対称セキュリティのkビットが必要な場合、Ceiling（lg（q））は少なくとも2 * kでなければなりません。
It is RECOMMENDED that the curves and base points defined in [FIPS186-3] be used, since these curves are suitable for cryptographic use. However, if other curves are used, the security of the curves MUST be assessed.
[FIPS186-3]で定義されている曲線とベースポイントを使用することをお勧めします。これらの曲線は暗号化の使用に適しているためです。ただし、他の曲線を使用する場合は、曲線の安全性を評価する必要があります。
In order to ensure that the SSK is only received by an authorized device, it MUST be provided through a secure channel. The strength of the authentication offered by this signature scheme is no greater than the security provided by this delivery channel.
SSKが承認されたデバイスによってのみ受信されることを保証するために、SSKは安全なチャネルを介して提供される必要があります。この署名方式によって提供される認証の強度は、この配信チャネルによって提供されるセキュリティと同じです。
Identifiers MUST be defined unambiguously by each application of ECCSI. Note that it is not necessary to use a hash function to compose an Identifier string. In this way, any weaknesses that might otherwise be caused by collisions in hash functions can be avoided without reliance on the structure of the Identifier format. Applications of ECCSI MAY include a time/date component in their Identifier format to ensure that Identifiers (and hence SSKs) are only valid for a fixed period of time.
識別子は、ECCSIのアプリケーションごとに明確に定義する必要があります。識別子文字列を作成するためにハッシュ関数を使用する必要がないことに注意してください。このようにして、識別子形式の構造に依存することなく、ハッシュ関数の衝突によって引き起こされる可能性のある弱点を回避できます。 ECCSIのアプリケーションは、識別子（したがってSSK）が一定期間のみ有効であることを保証するために、識別子形式に時間/日付コンポーネントを含めることができます（MAY）。
The use of the ephemeral value r in the hash HE significantly reduces the scope for offline attacks, improving the overall security, as compared to [ECDSA]. Furthermore, if Identifiers are specified to contain date-stamps, then all Identifiers, SSKs, signatures, and hash values will periodically become deprecated automatically, reducing the need for revocation and other additional management methods.
ハッシュHEで一時的な値rを使用すると、[ECDSA]と比較して、オフライン攻撃の範囲が大幅に縮小され、全体的なセキュリティが向上します。さらに、識別子に日付スタンプが含まれるように指定すると、すべての識別子、SSK、署名、ハッシュ値が定期的に自動的に非推奨になり、失効やその他の追加の管理方法の必要性が減少します。
The randomness of values stipulated to be selected at random, as described in this document, is essential to the security provided by ECCSI. If the value of the KSAK can be predicted, then any signatures can be forged. Similarly, if the value of v used by the KMS to create a user's SSK can be predicted, then the value of the KSAK could be recovered, which would allow signatures to be forged. If the value of j used by a user is predictable, then the value of his SSK could be recovered. This would allow that user's signatures to be forged. Guidance on the generation of random values for security can be found in [RFC4086].
このドキュメントで説明されているように、ランダムに選択するように規定されている値のランダム性は、ECCSIによって提供されるセキュリティにとって不可欠です。 KSAKの値を予測できる場合は、署名を偽造できます。同様に、KMSがユーザーのSSKを作成するために使用するvの値を予測できる場合、KSAKの値を回復できます。これにより、署名を偽造できます。ユーザーが使用したjの値が予測可能な場合、ユーザーのSSKの値を回復できます。これにより、そのユーザーの署名を偽造できるようになります。セキュリティのためのランダム値の生成に関するガイダンスは、[RFC4086]にあります。
Note that in most instances, the value s in the Signature can be replaced by q - s. Thus, the malleability of ECCSI signatures is similar to that in [ECDSA]; malleability is available but also very limited.
ほとんどの場合、署名の値sはq-sに置き換えることができます。したがって、ECCSI署名の可鍛性は[ECDSA]と同様です。順応性はありますが、非常に限られています。
[ECDSA] X9.62-2005, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", November 2005.
[ECDSA] X9.62-2005、「金融サービス業界の公開鍵暗号化：楕円曲線デジタル署名アルゴリズム（ECDSA）」、2005年11月。
[FIPS186-3] Federal Information Processing Standards Publication (FIPS PUB) 186-3, "Digital Signature Standard (DSS)", June 2009.
[FIPS186-3]連邦情報処理標準（FIPS PUB）186-3、「デジタル署名標準（DSS）」、2009年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号サブジェクト公開鍵情報」、RFC 5480、2009年3月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、2011年2月。
[BA] Arazi, Benjamin, "Certification of DL/EC Keys", paper submitted to P1363 meeting, August 1998, <http://grouper.ieee.org/groups/1363/StudyGroup/ contributions/arazi.doc>.
[BA]アラジ、ベンジャミン、「DL / ECキーの認証」、P1363会議、1998年8月に提出された論文、<http://grouper.ieee.org/groups/1363/StudyGroup/contributions/arazi.doc>。
[FIPS180-3] Federal Information Processing Standards Publication (FIPS PUB) 180-3, "Secure Hash Standard (SHS)", October 2008.
[FIPS180-3]連邦情報処理標準（FIPS PUB）180-3、「Secure Hash Standard（SHS）」、2008年10月。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M。、およびK. Norrman、「MIKEY：Multimedia Internet KEYing」、RFC 3830、2004年8月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] Eastlake 3rd、D.、Schiller、J。、およびS. Crocker、「Randomness Requirements for Security」、BCP 106、RFC 4086、2005年6月。
[RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", RFC 6508, February 2012.
「ＲＦＣ６５０８」 Ｇろゔぇｓ、 Ｍ。、 ”さかいーかさはら けｙ えんｃｒｙｐちおん （さっけ）”、 ＲＦＣ ６５０８、 ふぇｂるあｒｙ ２０１２。
[RFC6509] Groves, M., "MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY)", RFC 6509, February 2012.
[RFC6509] Groves、M。、「MIKEY-SAKKE：Sakai-Kasahara Key Encryption in Multimedia Internet KEYing（MIKEY）」、RFC 6509、2012年2月。
This appendix provides test data built from the NIST P-256 curve and base point. SHA-256 (as defined in [FIPS180-3]) is used as the hash function. The keys and ephemerals -- KSAK, v, and j -- are arbitrary and for illustration only.
この付録では、NIST P-256曲線と基点から作成されたテストデータを提供します。 SHA-256（[FIPS180-3]で定義）がハッシュ関数として使用されます。キーとエフェメラル（KSAK、v、j）は任意であり、説明のみを目的としています。
// --------------------------------------------------------
// Global parameters
n := 256;
N := 32;
p := 0x FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFF;
p：= 0x FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFF;
Hash := SHA-256;
// --------------------------------------------------------
// Community parameters
B := 0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BCE3C3E 27D2604B;
B：= 0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BCE3C3E 27D2604B;
q := 0x FFFFFFFF 00000000 FFFFFFFF FFFFFFFF BCE6FAAD A7179E84 F3B9CAC2 FC632551;
q：= 0x FFFFFFFF 00000000 FFFFFFFF FFFFFFFF BCE6FAAD A7179E84 F3B9CAC2 FC632551;
G := 0x 04 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5;
G：= 0x 04 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5;
KSAK := 0x 12345;
KPAK := 0x 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4;
CBC：= 0x 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4;
// --------------------------------------------------------
// Signer ID
ID := "2011-02\0tel:+447700900123\0",
= 0x 3230 31312D30 32007465 6C3A2B34
34373730 30393030 31323300;
// --------------------------------------------------------
// Creating SSK and PVT
v := 0x 23456;
PVT := 0x 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79;
PVT：= 0x 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79;
HS := hash( 0x 04 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4 32303131 2D303200 74656C3A 2B343437
HS：=ハッシュ（0X 04 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4 32303131 2D303200 74656C3A 2B343437
37303039 30303132 3300 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79 ),
37303039 30303132 3300 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018）BA0
= 0x 490F3FEB BC1C902F 6289723D 7F8CBF79 DB889308 49D19F38 F0295B5C 276C14D1;
= 0x 490F3FEB BC1C902F 6289723D 7F8CBF79 DB889308 49D19F38 F0295B5C 276C14D1;
SSK := 0x 23F374AE 1F4033F3 E9DBDDAA EF20F4CF 0B86BBD5 A138A5AE 9E7E006B 34489A0D;
SSK：= 0x 23F374AE 1F4033F3 E9DBDDAA EF20F4CF 0B86BBD5 A138A5AE 9E7E006B 34489A0D;
// --------------------------------------------------------
// Creating a Signature
M := "message\0",
= 0x 6D657373 61676500;
j := 0x 34567;
J := 0x 04 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 6DDA6A13 10F4B067 BD5DABDA D741B7CE F36457E1 96B1BFA9 7FD5F8FB B3926ADB;
J：= 0x 04 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 6DDA6A13 10F4B067 BD5DABDA D741B7CE F36457E1 96B1BFA9 7FD5F8FB B3926ADB;
r := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81;
r：= 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81;
HE := hash( 0x 490F3FEB BC1C902F 6289723D 7F8CBF79 DB889308 49D19F38 F0295B5C 276C14D1 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 6D657373 61676500 ),
HE：= hash（0x 490F3FEB BC1C902F 6289723D 7F8CBF79 DB889308 49D19F38 F0295B5C 276C14D1 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D500 6D6573657）
= 0x 111F90EA E8271C96 DF9B3D67 26768D9E E9B18145 D7EC152C FA9C23D1 C4F02285;
= 0x 111F90EA E8271C96 DF9B3D67 26768D9E E9B18145 D7EC152C FA9C23D1 C4F02285;
s' := 0x E09B528D 0EF8D6DF 1AA3ECBF 80110CFC EC9FC682 52CEBB67 9F413484 6940CCFD;
s '：= 0x E09B528D 0EF8D6DF 1AA3ECBF 80110CFC EC9FC682 52CEBB67 9F413484 6940CCFD;
s := 0x E09B528D 0EF8D6DF 1AA3ECBF 80110CFC EC9FC682 52CEBB67 9F413484 6940CCFD;
s：= 0x E09B528D 0EF8D6DF 1AA3ECBF 80110CFC EC9FC682 52CEBB67 9F413484 6940CCFD;
Sig := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 E09B528D 0EF8D6DF 1AA3ECBF 80110CFC EC9FC682 52CEBB67 9F413484 6940CCFD 04
Sig：= 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 E09B528D 0EF8D6DF 1AA3ECBF 80110CFC EC9FC682 52CEFB67 9F413484 6940C
758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79;
758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79;
// --------------------------------------------------------
// Verifying a Signature
Y := 0x 04 833898D9 39C0013B B0502728 6F95CCE0 37C11BD2 5799423C 76E48362 A4959978 95D0473A 1CD6186E E9F0C104 B472499E 1A24D6CE 3D85173F 02EBBD94 5C25F604;
Y：= 0x 04 833898D9 39C0013B B0502728 6F95CCE0 37C11BD2 5799423C 76E48362 A4959978 95D0473A 1CD6186E E9F0C104 B472499E 1A24D6CE 3D85173F 02EBBD94 5C25F604;
J := 0x 04 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 6DDA6A13 10F4B067 BD5DABDA D741B7CE F36457E1 96B1BFA9 7FD5F8FB B3926ADB;
J：= 0x 04 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 6DDA6A13 10F4B067 BD5DABDA D741B7CE F36457E1 96B1BFA9 7FD5F8FB B3926ADB;
Jx := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81;
Jx：= 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81;
Jx = r modulo p
// --------------------------------------------------------
Author's Address
著者のアドレス
Michael Groves CESG Hubble Road Cheltenham GL51 8HJ UK
マイケルグローブCESGハッブルロードチェルトナムGL51 8HJイギリス
EMail: Michael.Groves@cesg.gsi.gov.uk