Internet Engineering Task Force (IETF) M. Groves
Request for Comments: 6507 CESG
Category: Informational February 2012
ISSN: 2070-1721
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.
目前使用的许多签名方案都依赖证书进行身份验证。在基于身份的加密中，这会增加不必要的开销和管理。本文描述的基于身份加密（ECCSI）的基于椭圆曲线的无证书签名方案是无证书的。该方案具有低带宽和低计算要求的额外优点。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。互联网工程指导小组（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.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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.
数字签名在广泛的应用中提供身份验证服务。此类签名的信任链通常由证书提供。但是，在低带宽或其他资源受限的环境中，可能不希望使用证书。本文档描述了一种用于基于椭圆曲线的无证书签名的高效方案ECCSI，主要用于[RFC6508]中描述的基于身份的加密（IBE）方案。由于不需要证书，因此无需传输或存储证书来验证每个通信。该算法是根据Arazi[BA]提出的思想开发的，最初基于最常用的签名算法之一椭圆曲线数字签名算法[ECDSA]。
The algorithm is for use in the following context:
该算法用于以下上下文：
* where there are two parties, a Signer and a Verifier;
* 有签字人和验证人两方的；
* 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);
* 其中消息将被签名并随后被验证（例如，用于在基于身份的密钥建立期间认证发起方）；
* 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.
签名者没有证书，而是有一个标识符，其秘密签名密钥（SSK）（参见第2节）将通过KMS的公共验证令牌（PVT）（参见第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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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、一个用户社区，因此有一个KPAK。应用程序可能支持多个KPAK，在某些情况下，某些KPAK实际上可能是某些社区的“私有”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为每个设备生成和提供关键材料。它必须向所有要发送签名消息的设备提供SSK和PVT。提供这些SSK的机制必须是安全的，因为ECCSI签名提供的身份验证的安全性不强于此供应通道的安全性。
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.2节中定义的算法，根据信任根（KPAK）及其自己的ID和PVT验证密钥材料（SSK）。
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），也可以传输消息（在验证者不知道消息的情况下）。然后，验证者必须使用消息、签名和发送者ID对KPAK进行验证。
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;
* 使用签名者ID和匹配的SSK和PVT从消息创建签名的算法；
* a format for transporting a Signature;
* 用于传输签名的格式；
* an algorithm for verifying a Signature for a message, using a Signer's ID with the matching KPAK.
* 使用签名者ID和匹配的KPAK验证消息签名的算法。
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是两个椭圆曲线点，则它们的加法表示为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.
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=上限（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=上限（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.
椭圆曲线点上的点必须以[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
Signature=r | | s | | PVT，其中r和s是表示整数的长度为N=上限（lg（p）/8）的八位组字符串，PVT是表示椭圆曲线点的长度为2N+1的八位组字符串，产生4N+1个八位组的总签名长度。（请注意，r和
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.)
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=上限（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模p定义。
G A point on the elliptic curve E that generates the subgroup of order q.
椭圆曲线E上生成q阶子群的点。
q The prime q is defined to be the order of G in E over F_p.
素数q被定义为G在E上F_p的阶。
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.
哈希将任意字符串映射到N个八位字节的字符串的加密哈希函数。如果a、b、c。。。是字符串，则散列（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仅使用签名者标识符，尽管实现在构造要签名的消息时可以使用其他标识符。标识符格式可包括允许关键材料自动过期的时间戳。
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.
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.
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，F_q的随机（短暂）非零元素；
2) Compute PVT = [v]G (this MUST be represented canonically -- see
Section 3.2);
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=hash（G | | KPAK | | ID | | PVT），一个N个八位整数；
4) Compute SSK = ( KSAK + HS * v ) modulo q;
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传输到合法签名者设备的方法不在本文档的范围内，但必须由KMS使用保护其机密性的方法提供SSK。
If necessary, the KMS MAY create multiple (SSK,PVT) pairs for the same Identifier.
如有必要，KMS可为同一标识符创建多个（SSK、PVT）对。
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) Compute HS=hash（G | | KPAK | | ID | | PVT），一个N个八位整数。整数HS应与SSK一起存储，以备将来使用；
3) Validate that KPAK = [SSK]G - [HS]PVT.
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;
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;
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);
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 ).
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.
请注意，步骤6）是必要的，因为q（以及F_q的元素）可能太大，无法容纳在N个八位组中。签名者可以选择将s设置为以N个八位字节表示的s'和q-s'的最小整数。
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.
提供的算法假设验证器使用仿射坐标计算椭圆曲线上的点。然而，验证器可以使用实现等效操作的点的任何适当表示来执行椭圆曲线操作。
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:
要根据签名者的标识符（ID）、消息（M）和预安装的信任根（KPAK）验证签名（r | | s | | PVT），验证者必须执行与以下等效的过程：
1) The Verifier MUST check that the PVT lies on the elliptic curve E;
1) 验证者必须检查PVT是否位于椭圆曲线E上；
2) Compute HS = hash( G || KPAK || ID || PVT );
2) Compute HS = hash( G || KPAK || ID || PVT );
3) Compute HE = hash( HS || r || M );
3) Compute HE = hash( HS || r || M );
4) Y = [HS]PVT + KPAK;
4) Y = [HS]PVT + KPAK;
5) Compute J = [s]( [HE]G + [r]Y );
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模p，并且Jx模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将由于上下文而被隐式理解，但是这些值中的任何一个也可以包括在信令中。
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位对称安全性，则上限（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仅由授权设备接收，必须通过安全通道提供。此签名方案提供的身份验证强度不大于此传递通道提供的安全性。
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）仅在固定时间段内有效。
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.
与[ECDSA]相比，在散列HE中使用短暂值r大大减少了离线攻击的范围，提高了整体安全性。此外，如果将标识符指定为包含日期戳，则所有标识符、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]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 54802009年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，“基本椭圆曲线密码算法”，RFC 60902011年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]Arazi，Benjamin，“DL/EC密钥认证”，提交给P1363会议的文件，1998年8月<http://grouper.ieee.org/groups/1363/StudyGroup/ 贡献/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，“安全哈希标准（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，“米奇：多媒体互联网键控”，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，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC6508] Groves, M., "Sakai-Kasahara Key Encryption (SAKKE)", RFC 6508, February 2012.
[RFC6508]Groves，M.，“Sakai Kasahara密钥加密（SAKKE）”，RFC 65082012年2月。
[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多媒体互联网密钥加密（MIKEY）”，RFC 65092012年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
// --------------------------------------------------------
// Global parameters
n := 256;
n := 256;
N := 32;
N := 32;
p := 0x FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFF;
p:=0x-ffffffff00000001-00000000-00000000-ffffffffffffffffff；
Hash := SHA-256;
Hash := SHA-256;
// --------------------------------------------------------
// Community parameters
// --------------------------------------------------------
// Community parameters
B := 0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BCE3C3E 27D2604B;
B:=0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BE3C3E 27D2604B；
q := 0x FFFFFFFF 00000000 FFFFFFFF FFFFFFFF BCE6FAAD A7179E84 F3B9CAC2 FC632551;
q:=0x FFFFFFFF00000000 FFFFFFFFFFFFFFBCE6FAAD 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;
KSAK := 0x 12345;
KPAK := 0x 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4;
KPAK:=0x 04 50D4670B DE75244F 28D2838A 0D25558A 7A72686D 4522D4C8 273FB644 2AEBFA93 DBDD3755 1AFD263B 5DFD617F 3960C65A 8C298850 FF99F203 66DCE7D4 367217F4；
// --------------------------------------------------------
// Signer ID
// --------------------------------------------------------
// Signer ID
ID := "2011-02\0tel:+447700900123\0",
= 0x 3230 31312D30 32007465 6C3A2B34
34373730 30393030 31323300;
ID := "2011-02\0tel:+447700900123\0",
= 0x 3230 31312D30 32007465 6C3A2B34
34373730 30393030 31323300;
// --------------------------------------------------------
// Creating SSK and PVT
// --------------------------------------------------------
// Creating SSK and PVT
v := 0x 23456;
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 6B315 ECE CBB64068 37BF51F5 04 50D4670B DE75244F 28D2838A 0D25558A 7A722686D 4522D4C8 273FB644 2EBFA93 DBDD3755 1AFD263B 5DFD617F 3960C6808C29899F2667D437D437F4336727A
37303039 30303132 3300 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79 ),
370303039 30303132 3300 04 758A1427 79BE89E8 29E71984 CB40EF75 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 A464AE49 34663C52 65BA7018 BA091F79），
= 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
// --------------------------------------------------------
// Creating a Signature
M := "message\0",
= 0x 6D657373 61676500;
M := "message\0",
= 0x 6D657373 61676500;
j := 0x 34567;
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:=散列（0x 490F3FEB BC1C902F 6289723D 7F8CBF79 DB889308 49D19F38 F0295B5C 276C14D1 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 6d65733 61676500），
= 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
信号：=0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D DFE6029C 2AFFC493 6008CD2C C1045D81 E09B528D 0EF8D6DF 1AA3ECBF 80110CFC EC9FC682 52CEBB67 9F413484 6940CCFD 04
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
// --------------------------------------------------------
// 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 B4724499E 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
Jx = r modulo p
// --------------------------------------------------------
// --------------------------------------------------------
Author's Address
作者地址
Michael Groves CESG Hubble Road Cheltenham GL51 8HJ UK
迈克尔·格罗夫斯英国切尔滕纳姆塞斯克哈勃路GL51 8HJ
EMail: Michael.Groves@cesg.gsi.gov.uk
EMail: Michael.Groves@cesg.gsi.gov.uk