Network Working Group D. M'Raihi
Request for Comments: 4226 VeriSign
Category: Informational M. Bellare
UCSD
F. Hoornaert
Vasco
D. Naccache
Gemplus
O. Ranen
Aladdin
December 2005
Network Working Group D. M'Raihi
Request for Comments: 4226 VeriSign
Category: Informational M. Bellare
UCSD
F. Hoornaert
Vasco
D. Naccache
Gemplus
O. Ranen
Aladdin
December 2005
HOTP: An HMAC-Based One-Time Password Algorithm
HOTP：一种基于HMAC的一次性口令算法
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network (VPN) access, Wi-Fi network logon to transaction-oriented Web applications.
本文档描述了一种基于哈希消息身份验证码（HMAC）生成一次性密码值的算法。对该算法进行了安全性分析，讨论了与算法安全部署相关的重要参数。所提出的算法可用于各种网络应用，从远程虚拟专用网（VPN）访问、Wi-Fi网络登录到面向事务的Web应用。
This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations.
这项工作是由誓言（开放认证）成员共同努力，以指定一种可以自由分发给技术社区的算法。作者认为，一个通用和共享的算法将有助于通过跨商业和开源实现的互操作性在互联网上采用双因素认证。
Table of Contents
目录
1. Overview ........................................................3
2. Introduction ....................................................3
3. Requirements Terminology ........................................4
4. Algorithm Requirements ..........................................4
5. HOTP Algorithm ..................................................5
5.1. Notation and Symbols .......................................5
5.2. Description ................................................6
5.3. Generating an HOTP Value ...................................6
5.4. Example of HOTP Computation for Digit = 6 ..................7
6. Security Considerations .........................................8
7. Security Requirements ...........................................9
7.1. Authentication Protocol Requirements .......................9
7.2. Validation of HOTP Values .................................10
7.3. Throttling at the Server ..................................10
7.4. Resynchronization of the Counter ..........................11
7.5. Management of Shared Secrets ..............................11
8. Composite Shared Secrets .......................................14
9. Bi-Directional Authentication ..................................14
10. Conclusion ....................................................15
11. Acknowledgements ..............................................15
12. Contributors ..................................................15
13. References ....................................................15
13.1. Normative References .....................................15
13.2. Informative References ...................................16
Appendix A - HOTP Algorithm Security: Detailed Analysis ...........17
A.1. Definitions and Notations .................................17
A.2. The Idealized Algorithm: HOTP-IDEAL .......................17
A.3. Model of Security .........................................18
A.4. Security of the Ideal Authentication Algorithm ............19
A.4.1. From Bits to Digits ................................19
A.4.2. Brute Force Attacks ................................21
A.4.3. Brute force attacks are the best possible attacks ..22
A.5. Security Analysis of HOTP .................................23
Appendix B - SHA-1 Attacks ........................................25
B.1. SHA-1 Status ..............................................25
B.2. HMAC-SHA-1 Status .........................................26
B.3. HOTP Status ...............................................26
Appendix C - HOTP Algorithm: Reference Implementation .............27
Appendix D - HOTP Algorithm: Test Values ..........................32
Appendix E - Extensions ...........................................33
E.1. Number of Digits ..........................................33
E.2. Alphanumeric Values .......................................33
E.3. Sequence of HOTP values ...................................34
E.4. A Counter-Based Resynchronization Method ..................34
E.5. Data Field ................................................35
1. Overview ........................................................3
2. Introduction ....................................................3
3. Requirements Terminology ........................................4
4. Algorithm Requirements ..........................................4
5. HOTP Algorithm ..................................................5
5.1. Notation and Symbols .......................................5
5.2. Description ................................................6
5.3. Generating an HOTP Value ...................................6
5.4. Example of HOTP Computation for Digit = 6 ..................7
6. Security Considerations .........................................8
7. Security Requirements ...........................................9
7.1. Authentication Protocol Requirements .......................9
7.2. Validation of HOTP Values .................................10
7.3. Throttling at the Server ..................................10
7.4. Resynchronization of the Counter ..........................11
7.5. Management of Shared Secrets ..............................11
8. Composite Shared Secrets .......................................14
9. Bi-Directional Authentication ..................................14
10. Conclusion ....................................................15
11. Acknowledgements ..............................................15
12. Contributors ..................................................15
13. References ....................................................15
13.1. Normative References .....................................15
13.2. Informative References ...................................16
Appendix A - HOTP Algorithm Security: Detailed Analysis ...........17
A.1. Definitions and Notations .................................17
A.2. The Idealized Algorithm: HOTP-IDEAL .......................17
A.3. Model of Security .........................................18
A.4. Security of the Ideal Authentication Algorithm ............19
A.4.1. From Bits to Digits ................................19
A.4.2. Brute Force Attacks ................................21
A.4.3. Brute force attacks are the best possible attacks ..22
A.5. Security Analysis of HOTP .................................23
Appendix B - SHA-1 Attacks ........................................25
B.1. SHA-1 Status ..............................................25
B.2. HMAC-SHA-1 Status .........................................26
B.3. HOTP Status ...............................................26
Appendix C - HOTP Algorithm: Reference Implementation .............27
Appendix D - HOTP Algorithm: Test Values ..........................32
Appendix E - Extensions ...........................................33
E.1. Number of Digits ..........................................33
E.2. Alphanumeric Values .......................................33
E.3. Sequence of HOTP values ...................................34
E.4. A Counter-Based Resynchronization Method ..................34
E.5. Data Field ................................................35
The document introduces first the context around an algorithm that generates one-time password values based on HMAC [BCK1] and, thus, is named the HMAC-Based One-Time Password (HOTP) algorithm. In Section 4, the algorithm requirements are listed and in Section 5, the HOTP algorithm is described. Sections 6 and 7 focus on the algorithm security. Section 8 proposes some extensions and improvements, and Section 10 concludes this document. In Appendix A, the interested reader will find a detailed, full-fledged analysis of the algorithm security: an idealized version of the algorithm is evaluated, and then the HOTP algorithm security is analyzed.
本文档首先介绍了基于HMAC[BCK1]生成一次性密码值的算法的上下文，因此称为基于HMAC的一次性密码（HOTP）算法。第4节列出了算法要求，第5节描述了HOTP算法。第6节和第7节重点介绍了算法的安全性。第8节提出了一些扩展和改进，第10节总结了本文档。在附录A中，感兴趣的读者将发现算法安全性的详细、全面的分析：评估算法的理想版本，然后分析HOTP算法的安全性。
Today, deployment of two-factor authentication remains extremely limited in scope and scale. Despite increasingly higher levels of threats and attacks, most Internet applications still rely on weak authentication schemes for policing user access. The lack of interoperability among hardware and software technology vendors has been a limiting factor in the adoption of two-factor authentication technology. In particular, the absence of open specifications has led to solutions where hardware and software components are tightly coupled through proprietary technology, resulting in high-cost solutions, poor adoption, and limited innovation.
今天，双因素身份验证的部署在范围和规模上仍然非常有限。尽管威胁和攻击级别越来越高，但大多数互联网应用程序仍然依赖弱身份验证方案来监控用户访问。硬件和软件技术供应商之间缺乏互操作性一直是采用双因素认证技术的一个限制因素。特别是，开放规范的缺失导致了硬件和软件组件通过专有技术紧密耦合的解决方案，导致解决方案成本高、采用率低、创新有限。
In the last two years, the rapid rise of network threats has exposed the inadequacies of static passwords as the primary mean of authentication on the Internet. At the same time, the current approach that requires an end user to carry an expensive, single-function device that is only used to authenticate to the network is clearly not the right answer. For two-factor authentication to propagate on the Internet, it will have to be embedded in more flexible devices that can work across a wide range of applications.
在过去两年中，网络威胁的迅速增加暴露了静态密码作为互联网上身份验证主要手段的不足。与此同时，当前的方法要求最终用户携带昂贵的单功能设备，仅用于向网络进行身份验证，这显然不是正确的答案。为了在互联网上传播双因素身份验证，必须将其嵌入更灵活的设备中，这些设备可以跨广泛的应用程序工作。
The ability to embed this base technology while ensuring broad interoperability requires that it be made freely available to the broad technical community of hardware and software developers. Only an open-system approach will ensure that basic two-factor authentication primitives can be built into the next generation of consumer devices such as USB mass storage devices, IP phones, and personal digital assistants.
在确保广泛互操作性的同时嵌入这一基础技术的能力要求它能够免费提供给硬件和软件开发人员的广泛技术社区。只有开放系统方法才能确保基本的双因素身份验证原语可以内置到下一代消费设备中，如USB大容量存储设备、IP电话和个人数字助理。
One-Time Password is certainly one of the simplest and most popular forms of two-factor authentication for securing network access. For example, in large enterprises, Virtual Private Network access often requires the use of One-Time Password tokens for remote user authentication. One-Time Passwords are often preferred to stronger
一次性密码无疑是保护网络访问安全的最简单和最流行的双因素身份验证形式之一。例如，在大型企业中，虚拟专用网络访问通常需要使用一次性密码令牌进行远程用户身份验证。一次性密码通常比更强的密码更受欢迎
forms of authentication such as Public-Key Infrastructure (PKI) or biometrics because an air-gap device does not require the installation of any client desktop software on the user machine, therefore allowing them to roam across multiple machines including home computers, kiosks, and personal digital assistants.
身份验证形式，如公钥基础设施（PKI）或生物特征识别，因为气隙设备不需要在用户机器上安装任何客户端桌面软件，因此允许他们在多台机器上漫游，包括家庭计算机、信息亭和个人数字助理。
This document proposes a simple One-Time Password algorithm that can be implemented by any hardware manufacturer or software developer to create interoperable authentication devices and software agents. The algorithm is event-based so that it can be embedded in high-volume devices such as Java smart cards, USB dongles, and GSM SIM cards. The presented algorithm is made freely available to the developer community under the terms and conditions of the IETF Intellectual Property Rights [RFC3979].
本文档提出了一种简单的一次性密码算法，可由任何硬件制造商或软件开发人员实现，以创建可互操作的认证设备和软件代理。该算法基于事件，因此可以嵌入高容量设备，如Java智能卡、USB加密狗和GSM SIM卡。所提出的算法根据IETF知识产权[RFC3979]的条款和条件免费提供给开发人员社区。
The authors of this document are members of the Open AuTHentication initiative [OATH]. The initiative was created in 2004 to facilitate collaboration among strong authentication technology providers.
本文件的作者是开放身份验证倡议[誓言]的成员。该倡议创建于2004年，旨在促进强有力的认证技术提供商之间的合作。
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]中所述进行解释。
This section presents the main requirements that drove this algorithm design. A lot of emphasis was placed on end-consumer usability as well as the ability for the algorithm to be implemented by low-cost hardware that may provide minimal user interface capabilities. In particular, the ability to embed the algorithm into high-volume SIM and Java cards was a fundamental prerequisite.
本节介绍了驱动该算法设计的主要需求。大量的重点放在终端消费者的可用性以及算法通过低成本硬件实现的能力上，这些硬件可以提供最小的用户界面功能。特别是，将算法嵌入大容量SIM卡和Java卡的能力是一个基本的先决条件。
R1 - The algorithm MUST be sequence- or counter-based: one of the goals is to have the HOTP algorithm embedded in high-volume devices such as Java smart cards, USB dongles, and GSM SIM cards.
R1-算法必须基于顺序或计数器：目标之一是将HOTP算法嵌入到大容量设备中，如Java智能卡、USB加密狗和GSM SIM卡。
R2 - The algorithm SHOULD be economical to implement in hardware by minimizing requirements on battery, number of buttons, computational horsepower, and size of LCD display.
R2-通过最小化对电池、按钮数量、计算马力和LCD显示器尺寸的要求，该算法应能在硬件中经济地实现。
R3 - The algorithm MUST work with tokens that do not support any numeric input, but MAY also be used with more sophisticated devices such as secure PIN-pads.
R3-该算法必须与不支持任何数字输入的令牌一起使用，但也可以与更复杂的设备（如安全引脚垫）一起使用。
R4 - The value displayed on the token MUST be easily read and entered by the user: This requires the HOTP value to be of reasonable length.
R4-令牌上显示的值必须易于读取并由用户输入：这要求HOTP值具有合理的长度。
The HOTP value must be at least a 6-digit value. It is also desirable that the HOTP value be 'numeric only' so that it can be easily entered on restricted devices such as phones.
HOTP值必须至少为6位数字。还希望HOTP值为“仅数字”，以便在受限设备（如电话）上轻松输入。
R5 - There MUST be user-friendly mechanisms available to resynchronize the counter. Section 7.4 and Appendix E.4 details the resynchronization mechanism proposed in this document
R5-必须有用户友好的机制可用于重新同步计数器。第7.4节和附录E.4详述了本文件中提出的重新同步机制
R6 - The algorithm MUST use a strong shared secret. The length of the shared secret MUST be at least 128 bits. This document RECOMMENDs a shared secret length of 160 bits.
R6-算法必须使用强共享秘密。共享秘密的长度必须至少为128位。本文档建议共享密钥长度为160位。
In this section, we introduce the notation and describe the HOTP algorithm basic blocks -- the base function to compute an HMAC-SHA-1 value and the truncation method to extract an HOTP value.
在本节中，我们将介绍符号并描述HOTP算法的基本块——计算HMAC-SHA-1值的基函数和提取HOTP值的截断方法。
A string always means a binary string, meaning a sequence of zeros and ones.
字符串始终表示二进制字符串，表示零和一的序列。
If s is a string, then |s| denotes its length.
如果s是字符串，则| s |表示其长度。
If n is a number, then |n| denotes its absolute value.
如果n是一个数字，那么| n |表示其绝对值。
If s is a string, then s[i] denotes its i-th bit. We start numbering the bits at 0, so s = s[0]s[1]...s[n-1] where n = |s| is the length of s.
如果s是字符串，则s[i]表示其第i位。我们从0开始编号，因此s=s[0]s[1]…s[n-1]，其中n=| s |是s的长度。
Let StToNum (String to Number) denote the function that as input a string s returns the number whose binary representation is s. (For example, StToNum(110) = 6.)
让StToNum（字符串到数字）表示一个函数，作为输入，字符串s返回二进制表示为s的数字。（例如，StToNum（110）=6。）
Here is a list of symbols used in this document.
以下是本文档中使用的符号列表。
Symbol Represents
-------------------------------------------------------------------
C 8-byte counter value, the moving factor. This counter
MUST be synchronized between the HOTP generator (client)
and the HOTP validator (server).
Symbol Represents
-------------------------------------------------------------------
C 8-byte counter value, the moving factor. This counter
MUST be synchronized between the HOTP generator (client)
and the HOTP validator (server).
K shared secret between client and server; each HOTP generator has a different and unique secret K.
K客户端和服务器之间的共享秘密；每个HOTP生成器都有一个不同且唯一的秘密K。
T throttling parameter: the server will refuse connections from a user after T unsuccessful authentication attempts.
T throttling参数：在T次身份验证尝试失败后，服务器将拒绝来自用户的连接。
s resynchronization parameter: the server will attempt to verify a received authenticator across s consecutive counter values.
s Ressynchronization参数：服务器将尝试跨s个连续计数器值验证收到的验证器。
Digit number of digits in an HOTP value; system parameter.
HOTP值中的位数；系统参数。
The HOTP algorithm is based on an increasing counter value and a static symmetric key known only to the token and the validation service. In order to create the HOTP value, we will use the HMAC-SHA-1 algorithm, as defined in RFC 2104 [BCK2].
HOTP算法基于递增的计数器值和仅令牌和验证服务已知的静态对称密钥。为了创建HOTP值，我们将使用RFC2104[BCK2]中定义的HMAC-SHA-1算法。
As the output of the HMAC-SHA-1 calculation is 160 bits, we must truncate this value to something that can be easily entered by a user.
由于HMAC-SHA-1计算的输出为160位，我们必须将该值截断为用户可以轻松输入的值。
HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))
HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))
Where:
哪里：
- Truncate represents the function that converts an HMAC-SHA-1 value into an HOTP value as defined in Section 5.3.
- Truncate表示将HMAC-SHA-1值转换为第5.3节中定义的HOTP值的函数。
The Key (K), the Counter (C), and Data values are hashed high-order byte first.
首先对键（K）、计数器（C）和数据值进行高阶字节散列。
The HOTP values generated by the HOTP generator are treated as big endian.
由HOTP生成器生成的HOTP值被视为big-endian。
We can describe the operations in 3 distinct steps:
我们可以用3个不同的步骤来描述操作：
Step 1: Generate an HMAC-SHA-1 value Let HS = HMAC-SHA-1(K,C) // HS
is a 20-byte string
Step 1: Generate an HMAC-SHA-1 value Let HS = HMAC-SHA-1(K,C) // HS
is a 20-byte string
Step 2: Generate a 4-byte string (Dynamic Truncation)
Let Sbits = DT(HS) // DT, defined below,
// returns a 31-bit string
Step 2: Generate a 4-byte string (Dynamic Truncation)
Let Sbits = DT(HS) // DT, defined below,
// returns a 31-bit string
Step 3: Compute an HOTP value
Let Snum = StToNum(Sbits) // Convert S to a number in
0...2^{31}-1
Return D = Snum mod 10^Digit // D is a number in the range
0...10^{Digit}-1
Step 3: Compute an HOTP value
Let Snum = StToNum(Sbits) // Convert S to a number in
0...2^{31}-1
Return D = Snum mod 10^Digit // D is a number in the range
0...10^{Digit}-1
The Truncate function performs Step 2 and Step 3, i.e., the dynamic truncation and then the reduction modulo 10^Digit. The purpose of the dynamic offset truncation technique is to extract a 4-byte dynamic binary code from a 160-bit (20-byte) HMAC-SHA-1 result.
Truncate函数执行第2步和第3步，即动态截断，然后按10^位进行约化。动态偏移截断技术的目的是从160位（20字节）HMAC-SHA-1结果中提取4字节动态二进制代码。
DT(String) // String = String[0]...String[19]
Let OffsetBits be the low-order 4 bits of String[19]
Offset = StToNum(OffsetBits) // 0 <= OffSet <= 15
Let P = String[OffSet]...String[OffSet+3]
Return the Last 31 bits of P
DT(String) // String = String[0]...String[19]
Let OffsetBits be the low-order 4 bits of String[19]
Offset = StToNum(OffsetBits) // 0 <= OffSet <= 15
Let P = String[OffSet]...String[OffSet+3]
Return the Last 31 bits of P
The reason for masking the most significant bit of P is to avoid confusion about signed vs. unsigned modulo computations. Different processors perform these operations differently, and masking out the signed bit removes all ambiguity.
屏蔽P的最高有效位的原因是为了避免混淆有符号和无符号模计算。不同的处理器执行这些操作的方式不同，屏蔽有符号位可以消除所有歧义。
Implementations MUST extract a 6-digit code at a minimum and possibly 7 and 8-digit code. Depending on security requirements, Digit = 7 or more SHOULD be considered in order to extract a longer HOTP value.
实现必须至少提取6位代码，可能还要提取7位和8位代码。根据安全要求，应考虑数字=7或更大，以便提取更长的HOTP值。
The following paragraph is an example of using this technique for Digit = 6, i.e., that a 6-digit HOTP value is calculated from the HMAC value.
以下段落是将此技术用于数字=6的示例，即，根据HMAC值计算6位HOTP值。
The following code example describes the extraction of a dynamic binary code given that hmac_result is a byte array with the HMAC-SHA-1 result:
以下代码示例描述了动态二进制代码的提取，前提是hmac_结果是具有hmac-SHA-1结果的字节数组：
int offset = hmac_result[19] & 0xf ;
int bin_code = (hmac_result[offset] & 0x7f) << 24
| (hmac_result[offset+1] & 0xff) << 16
| (hmac_result[offset+2] & 0xff) << 8
| (hmac_result[offset+3] & 0xff) ;
int offset = hmac_result[19] & 0xf ;
int bin_code = (hmac_result[offset] & 0x7f) << 24
| (hmac_result[offset+1] & 0xff) << 16
| (hmac_result[offset+2] & 0xff) << 8
| (hmac_result[offset+3] & 0xff) ;
SHA-1 HMAC Bytes (Example)
SHA-1 HMAC字节（示例）
-------------------------------------------------------------
| Byte Number |
-------------------------------------------------------------
|00|01|02|03|04|05|06|07|08|09|10|11|12|13|14|15|16|17|18|19|
-------------------------------------------------------------
| Byte Value |
-------------------------------------------------------------
|1f|86|98|69|0e|02|ca|16|61|85|50|ef|7f|19|da|8e|94|5b|55|5a|
-------------------------------***********----------------++|
-------------------------------------------------------------
| Byte Number |
-------------------------------------------------------------
|00|01|02|03|04|05|06|07|08|09|10|11|12|13|14|15|16|17|18|19|
-------------------------------------------------------------
| Byte Value |
-------------------------------------------------------------
|1f|86|98|69|0e|02|ca|16|61|85|50|ef|7f|19|da|8e|94|5b|55|5a|
-------------------------------***********----------------++|
* The last byte (byte 19) has the hex value 0x5a. * The value of the lower 4 bits is 0xa (the offset value). * The offset value is byte 10 (0xa). * The value of the 4 bytes starting at byte 10 is 0x50ef7f19, which is the dynamic binary code DBC1. * The MSB of DBC1 is 0x50 so DBC2 = DBC1 = 0x50ef7f19 . * HOTP = DBC2 modulo 10^6 = 872921.
* 最后一个字节（字节19）具有十六进制值0x5a。*低4位的值为0xa（偏移值）。*偏移值为字节10（0xa）。*从字节10开始的4个字节的值为0x50ef7f19，这是动态二进制代码DBC1。*DBC1的MSB为0x50，因此DBC2=DBC1=0x50ef7f19.*HOTP=DBC2模10^6=872921。
We treat the dynamic binary code as a 31-bit, unsigned, big-endian integer; the first byte is masked with a 0x7f.
我们将动态二进制代码视为31位无符号大端整数；第一个字节用0x7f屏蔽。
We then take this number modulo 1,000,000 (10^6) to generate the 6- digit HOTP value 872921 decimal.
然后，我们将这个数字除以1000000（10^6），生成6位的HOTP值872921十进制。
The conclusion of the security analysis detailed in the Appendix is that, for all practical purposes, the outputs of the Dynamic Truncation (DT) on distinct counter inputs are uniformly and independently distributed 31-bit strings.
附录中详述的安全性分析的结论是，出于所有实际目的，不同计数器输入上的动态截断（DT）输出是均匀且独立分布的31位字符串。
The security analysis then details the impact of the conversion from a string to an integer and the final reduction modulo 10^Digit, where Digit is the number of digits in an HOTP value.
然后，安全性分析详细说明了从字符串转换为整数的影响，以及最终的10^Digit归约，其中Digit是HOTP值中的位数。
The analysis demonstrates that these final steps introduce a negligible bias, which does not impact the security of the HOTP algorithm, in the sense that the best possible attack against the HOTP function is the brute force attack.
分析表明，这些最后的步骤引入了可忽略不计的偏差，这不会影响HOTP算法的安全性，因为针对HOTP函数的最佳可能攻击是蛮力攻击。
Assuming an adversary is able to observe numerous protocol exchanges and collect sequences of successful authentication values. This adversary, trying to build a function F to generate HOTP values based on his observations, will not have a significant advantage over a random guess.
假设对手能够观察到大量协议交换并收集成功身份验证值序列。这个对手试图构建一个函数F，根据他的观察结果生成HOTP值，与随机猜测相比不会有显著优势。
The logical conclusion is simply that the best strategy will once again be to perform a brute force attack to enumerate and try all the possible values.
合乎逻辑的结论是，最好的策略将再次是执行蛮力攻击，以枚举并尝试所有可能的值。
Considering the security analysis in the Appendix of this document, without loss of generality, we can approximate closely the security of the HOTP algorithm by the following formula:
考虑到本文件附录中的安全性分析，在不丧失一般性的情况下，我们可以通过以下公式近似计算HOTP算法的安全性：
Sec = sv/10^Digit
Sec = sv/10^Digit
Where:
- Sec is the probability of success of the adversary;
- s is the look-ahead synchronization window size;
- v is the number of verification attempts;
- Digit is the number of digits in HOTP values.
Where:
- Sec is the probability of success of the adversary;
- s is the look-ahead synchronization window size;
- v is the number of verification attempts;
- Digit is the number of digits in HOTP values.
Obviously, we can play with s, T (the Throttling parameter that would limit the number of attempts by an attacker), and Digit until achieving a certain level of security, still preserving the system usability.
显然，我们可以使用s、T（限制攻击者尝试次数的节流参数）和Digit，直到达到一定的安全级别，仍然可以保持系统的可用性。
Any One-Time Password algorithm is only as secure as the application and the authentication protocols that implement it. Therefore, this section discusses the critical security requirements that our choice of algorithm imposes on the authentication protocol and validation software.
任何一次性密码算法的安全性都取决于应用程序和实现它的身份验证协议。因此，本节讨论了我们选择的算法对身份验证协议和验证软件提出的关键安全要求。
The parameters T and s discussed in this section have a significant impact on the security -- further details in Section 6 elaborate on the relations between these parameters and their impact on the system security.
本节中讨论的参数T和s对安全性有重大影响——第6节中的进一步详细说明了这些参数之间的关系及其对系统安全性的影响。
It is also important to remark that the HOTP algorithm is not a substitute for encryption and does not provide for the privacy of data transmission. Other mechanisms should be used to defeat attacks aimed at breaking confidentiality and privacy of transactions.
还有一点很重要，即HOTP算法不能替代加密，也不能提供数据传输的隐私。应使用其他机制挫败旨在破坏交易机密性和隐私的攻击。
We introduce in this section some requirements for a protocol P implementing HOTP as the authentication method between a prover and a verifier.
在本节中，我们将介绍对协议P的一些要求，该协议将HOTP实现为验证方和验证方之间的身份验证方法。
RP1 - P MUST support two-factor authentication, i.e., the communication and verification of something you know (secret code such as a Password, Pass phrase, PIN code, etc.) and something you have (token). The secret code is known only to the user and usually entered with the One-Time Password value for authentication purpose (two-factor authentication).
RP1-P必须支持双因素身份验证，即对您知道的东西（密码、密码短语、PIN码等）和您拥有的东西（令牌）进行通信和验证。密码仅为用户所知，通常输入时使用一次性密码值进行身份验证（双因素身份验证）。
RP2 - P SHOULD NOT be vulnerable to brute force attacks. This implies that a throttling/lockout scheme is RECOMMENDED on the validation server side.
RP2-P不应该容易受到暴力攻击。这意味着建议在验证服务器端使用节流/锁定方案。
RP3 - P SHOULD be implemented over a secure channel in order to protect users' privacy and avoid replay attacks.
RP3-P应该通过安全通道实现，以保护用户的隐私并避免重播攻击。
The HOTP client (hardware or software token) increments its counter and then calculates the next HOTP value HOTP client. If the value received by the authentication server matches the value calculated by the client, then the HOTP value is validated. In this case, the server increments the counter value by one.
HOTP客户端（硬件或软件令牌）递增其计数器，然后计算下一个HOTP值HOTP client。如果身份验证服务器接收的值与客户端计算的值匹配，则验证HOTP值。在这种情况下，服务器将计数器值增加1。
If the value received by the server does not match the value calculated by the client, the server initiate the resynch protocol (look-ahead window) before it requests another pass.
如果服务器接收到的值与客户端计算的值不匹配，服务器将在请求另一次传递之前启动重新同步协议（前瞻窗口）。
If the resynch fails, the server asks then for another authentication pass of the protocol to take place, until the maximum number of authorized attempts is reached.
如果重新同步失败，服务器会要求进行协议的另一次身份验证，直到达到授权尝试的最大次数。
If and when the maximum number of authorized attempts is reached, the server SHOULD lock out the account and initiate a procedure to inform the user.
如果达到最大授权尝试次数，服务器应锁定帐户并启动程序通知用户。
Truncating the HMAC-SHA-1 value to a shorter value makes a brute force attack possible. Therefore, the authentication server needs to detect and stop brute force attacks.
将HMAC-SHA-1值截断为较短的值可以进行暴力攻击。因此，身份验证服务器需要检测并停止暴力攻击。
We RECOMMEND setting a throttling parameter T, which defines the maximum number of possible attempts for One-Time Password validation. The validation server manages individual counters per HOTP device in order to take note of any failed attempt. We RECOMMEND T not to be too large, particularly if the resynchronization method used on the server is window-based, and the window size is large. T SHOULD be set as low as possible, while still ensuring that usability is not significantly impacted.
我们建议设置一个限制参数T，该参数定义一次密码验证的最大可能尝试次数。验证服务器管理每个HOTP设备的单个计数器，以便记录任何失败的尝试。我们建议T不要太大，特别是如果服务器上使用的重新同步方法是基于窗口的，并且窗口大小很大。T应该设置得尽可能低，同时仍然确保可用性不会受到显著影响。
Another option would be to implement a delay scheme to avoid a brute force attack. After each failed attempt A, the authentication server would wait for an increased T*A number of seconds, e.g., say T = 5, then after 1 attempt, the server waits for 5 seconds, at the second failed attempt, it waits for 5*2 = 10 seconds, etc.
另一种选择是实施延迟方案，以避免暴力攻击。在每次失败的尝试A之后，身份验证服务器将等待增加的T*秒数，例如，假设T=5，然后在1次尝试之后，服务器等待5秒，在第二次失败的尝试中，它等待5*2=10秒，以此类推。
The delay or lockout schemes MUST be across login sessions to prevent attacks based on multiple parallel guessing techniques.
延迟或锁定方案必须跨越登录会话，以防止基于多种并行猜测技术的攻击。
Although the server's counter value is only incremented after a successful HOTP authentication, the counter on the token is incremented every time a new HOTP is requested by the user. Because of this, the counter values on the server and on the token might be out of synchronization.
虽然服务器的计数器值仅在成功的HOTP身份验证后增加，但每次用户请求新的HOTP时，令牌上的计数器都会增加。因此，服务器和令牌上的计数器值可能不同步。
We RECOMMEND setting a look-ahead parameter s on the server, which defines the size of the look-ahead window. In a nutshell, the server can recalculate the next s HOTP-server values, and check them against the received HOTP client.
我们建议在服务器上设置一个前瞻参数s，该参数定义前瞻窗口的大小。简而言之，服务器可以重新计算下一个SHOTP服务器值，并根据收到的HOTP客户端检查它们。
Synchronization of counters in this scenario simply requires the server to calculate the next HOTP values and determine if there is a match. Optionally, the system MAY require the user to send a sequence of (say, 2, 3) HOTP values for resynchronization purpose, since forging a sequence of consecutive HOTP values is even more difficult than guessing a single HOTP value.
在这种情况下，计数器的同步只需要服务器计算下一个HOTP值并确定是否存在匹配项。可选地，系统可能要求用户发送（例如，2，3）个HOTP值序列以用于重新同步，因为伪造连续HOTP值序列甚至比猜测单个HOTP值更困难。
The upper bound set by the parameter s ensures the server does not go on checking HOTP values forever (causing a denial-of-service attack) and also restricts the space of possible solutions for an attacker trying to manufacture HOTP values. s SHOULD be set as low as possible, while still ensuring that usability is not impacted.
参数s设置的上限可确保服务器不会永远检查HOTP值（导致拒绝服务攻击），并限制攻击者试图制造HOTP值的可能解决方案空间。应将可用性设置为尽可能低，同时确保可用性不受影响。
The operations dealing with the shared secrets used to generate and verify OTP values must be performed securely, in order to mitigate risks of any leakage of sensitive information. We describe in this section different modes of operations and techniques to perform these different operations with respect to the state of the art in data security.
必须安全地执行处理用于生成和验证OTP值的共享机密的操作，以降低敏感信息泄露的风险。在本节中，我们将根据数据安全领域的最新技术，描述执行这些不同操作的不同操作模式和技术。
We can consider two different avenues for generating and storing (securely) shared secrets in the Validation system:
我们可以考虑在验证系统中生成和存储（安全地）共享秘密的两种不同途径：
* Deterministic Generation: secrets are derived from a master seed, both at provisioning and verification stages and generated on-the-fly whenever it is required. * Random Generation: secrets are generated randomly at provisioning stage and must be stored immediately and kept secure during their life cycle.
* 确定性生成：机密从主种子中派生，无论是在供应和验证阶段，还是在需要时动态生成。*随机生成：机密在资源调配阶段随机生成，必须立即存储并在其生命周期内保持安全。
Deterministic Generation
------------------------
Deterministic Generation
------------------------
A possible strategy is to derive the shared secrets from a master secret. The master secret will be stored at the server only. A tamper-resistant device MUST be used to store the master key and derive the shared secrets from the master key and some public information. The main benefit would be to avoid the exposure of the shared secrets at any time and also avoid specific requirements on storage, since the shared secrets could be generated on-demand when needed at provisioning and validation time.
一种可能的策略是从主秘密中导出共享秘密。主密钥将仅存储在服务器上。必须使用防篡改设备存储主密钥，并从主密钥和某些公共信息中获取共享机密。主要的好处是避免在任何时候暴露共享机密，也避免了对存储的特定要求，因为共享机密可以在资源调配和验证时按需生成。
We distinguish two different cases:
我们区分两种不同的情况：
- A single master key MK is used to derive the shared secrets; each HOTP device has a different secret, K_i = SHA-1 (MK,i) where i stands for a public piece of information that identifies uniquely the HOTP device such as a serial number, a token ID, etc. Obviously, this is in the context of an application or service -- different application or service providers will have different secrets and settings. - Several master keys MK_i are used and each HOTP device stores a set of different derived secrets, {K_i,j = SHA-1(MK_i,j)} where j stands for a public piece of information identifying the device. The idea would be to store ONLY the active master key at the validation server, in the Hardware Security Module (HSM), and keep in a safe place, using secret sharing methods such as [Shamir] for instance. In this case, if a master secret MK_i is compromised, then it is possible to switch to another secret without replacing all the devices.
- 使用单个主密钥MK导出共享秘密；每个HOTP设备都有一个不同的秘密，K_i=SHA-1（MK，i），其中i代表唯一标识HOTP设备的公共信息，如序列号、令牌ID等。显然，这是在应用程序或服务的上下文中-不同的应用程序或服务提供商将有不同的秘密和设置。-使用多个主密钥MK_i，每个HOTP设备存储一组不同的派生秘密，{K_i，j=SHA-1（MK_i，j）}，其中j表示标识该设备的公共信息。其想法是仅将活动主密钥存储在验证服务器的硬件安全模块（HSM）中，并保存在安全的地方，例如使用[Shamir]等秘密共享方法。在这种情况下，如果主密钥MK_i被泄露，则可以在不更换所有设备的情况下切换到另一个密钥。
The drawback in the deterministic case is that the exposure of the master secret would obviously enable an attacker to rebuild any shared secret based on correct public information. The revocation of all secrets would be required, or switching to a new set of secrets in the case of multiple master keys.
确定性情况下的缺点是，主秘密的暴露显然会使攻击者能够基于正确的公共信息重建任何共享秘密。需要撤销所有机密，或者在多个主密钥的情况下切换到一组新的机密。
On the other hand, the device used to store the master key(s) and generate the shared secrets MUST be tamper resistant. Furthermore, the HSM will not be exposed outside the security perimeter of the validation system, therefore reducing the risk of leakage.
另一方面，用于存储主密钥和生成共享机密的设备必须是防篡改的。此外，HSM不会暴露在验证系统的安全边界之外，因此降低了泄漏风险。
Random Generation
-----------------
Random Generation
-----------------
The shared secrets are randomly generated. We RECOMMEND following the recommendations in [RFC4086] and selecting a good and secure random source for generating these secrets. A (true) random generator requires a naturally occurring source of randomness. Practically, there are two possible avenues to consider for the generation of the shared secrets:
共享秘密是随机生成的。我们建议遵循[RFC4086]中的建议，选择一个良好且安全的随机源来生成这些秘密。一个（真实的）随机生成器需要一个自然发生的随机性源。实际上，共享秘密的产生有两种可能的途径：
* Hardware-based generators: they exploit the randomness that occurs in physical phenomena. A nice implementation can be based on oscillators and built in such ways that active attacks are more difficult to perform.
*基于硬件的生成器：它们利用物理现象中发生的随机性。一个很好的实现可以基于振荡器，并以主动攻击更难执行的方式构建。
* Software-based generators: designing a good software random generator is not an easy task. A simple, but efficient, implementation should be based on various sources and apply to the sampled sequence a one-way function such as SHA-1.
*基于软件的生成器：设计一个好的软件随机生成器并非易事。一个简单但高效的实现应该基于各种源，并将单向函数（如SHA-1）应用于采样序列。
We RECOMMEND selecting proven products, being hardware or software generators, for the computation of shared secrets.
我们建议选择经验证的产品，即硬件或软件生成器，用于计算共享机密。
We also RECOMMEND storing the shared secrets securely, and more specifically encrypting the shared secrets when stored using tamper-resistant hardware encryption and exposing them only when required: for example, the shared secret is decrypted when needed to verify an HOTP value, and re-encrypted immediately to limit exposure in the RAM for a short period of time. The data store holding the shared secrets MUST be in a secure area, to avoid as much as possible direct attack on the validation system and secrets database.
我们还建议安全地存储共享机密，更具体地说，在使用防篡改硬件加密存储时加密共享机密，并仅在需要时公开它们：例如，在需要验证HOTP值时解密共享机密，并立即重新加密，以限制在RAM中的短时间暴露。保存共享机密的数据存储必须位于安全区域，以尽可能避免对验证系统和机密数据库的直接攻击。
Particularly, access to the shared secrets should be limited to programs and processes required by the validation system only. We will not elaborate on the different security mechanisms to put in place, but obviously, the protection of shared secrets is of the uttermost importance.
特别是，对共享机密的访问应仅限于验证系统所需的程序和过程。我们不会详细说明要建立的不同安全机制，但显然，保护共享机密是最重要的。
It may be desirable to include additional authentication factors in the shared secret K. These additional factors can consist of any data known at the token but not easily obtained by others. Examples of such data include:
可能希望在共享秘密K中包括附加认证因子。这些附加因子可以包括令牌处已知但他人不容易获得的任何数据。此类数据的示例包括：
* PIN or Password obtained as user input at the token * Phone number * Any unique identifier programmatically available at the token
* 在令牌*电话号码*上作为用户输入获得的PIN或密码令牌上以编程方式可用的任何唯一标识符
In this scenario, the composite shared secret K is constructed during the provisioning process from a random seed value combined with one or more additional authentication factors. The server could either build on-demand or store composite secrets -- in any case, depending on implementation choice, the token only stores the seed value. When the token performs the HOTP calculation, it computes K from the seed value and the locally derived or input values of the other authentication factors.
在该场景中，复合共享秘密K在供应过程中由随机种子值与一个或多个附加认证因子组合而成。服务器可以按需构建或存储复合机密——在任何情况下，根据实现选择，令牌只存储种子值。当令牌执行HOTP计算时，它根据种子值和其他身份验证因子的本地派生值或输入值计算K。
The use of composite shared secrets can strengthen HOTP-based authentication systems through the inclusion of additional authentication factors at the token. To the extent that the token is a trusted device, this approach has the further benefit of not requiring exposure of the authentication factors (such as the user input PIN) to other devices.
复合共享机密的使用可以通过在令牌处包含额外的身份验证因素来加强基于HOTP的身份验证系统。就令牌是可信设备的程度而言，该方法具有不需要向其他设备公开认证因素（例如用户输入PIN）的进一步好处。
Interestingly enough, the HOTP client could also be used to authenticate the validation server, claiming that it is a genuine entity knowing the shared secret.
有趣的是，HOTP客户机还可以用来验证验证服务器，声称它是一个知道共享秘密的真实实体。
Since the HOTP client and the server are synchronized and share the
same secret (or a method to recompute it), a simple 3-pass protocol
could be put in place:
1- The end user enter the TokenID and a first OTP value OTP1;
2- The server checks OTP1 and if correct, sends back OTP2;
3- The end user checks OTP2 using his HOTP device and if correct,
uses the web site.
Since the HOTP client and the server are synchronized and share the
same secret (or a method to recompute it), a simple 3-pass protocol
could be put in place:
1- The end user enter the TokenID and a first OTP value OTP1;
2- The server checks OTP1 and if correct, sends back OTP2;
3- The end user checks OTP2 using his HOTP device and if correct,
uses the web site.
Obviously, as indicated previously, all the OTP communications have to take place over a secure channel, e.g., SSL/TLS, IPsec connections.
显然，如前所述，所有OTP通信必须通过安全通道进行，例如SSL/TLS、IPsec连接。
This document describes HOTP, a HMAC-based One-Time Password algorithm. It also recommends the preferred implementation and related modes of operations for deploying the algorithm.
本文档描述了HOTP，一种基于HMAC的一次性密码算法。它还建议部署算法的首选实现和相关操作模式。
The document also exhibits elements of security and demonstrates that the HOTP algorithm is practical and sound, the best possible attack being a brute force attack that can be prevented by careful implementation of countermeasures in the validation server.
该文档还展示了安全性要素，并证明了HOTP算法是实用且可靠的，最好的攻击是暴力攻击，可通过在验证服务器中仔细实施对策来防止。
Eventually, several enhancements have been proposed, in order to improve security if needed for specific applications.
最后，提出了一些增强功能，以便在特定应用程序需要时提高安全性。
The authors would like to thank Siddharth Bajaj, Alex Deacon, Loren Hart, and Nico Popp for their help during the conception and redaction of this document.
作者要感谢Siddharth Bajaj、Alex Deacon、Loren Hart和Nico Popp在构思和编辑本文件期间提供的帮助。
The authors of this document would like to emphasize the role of three persons who have made a key contribution to this document:
本文件的作者希望强调对本文件作出重要贡献的三个人的作用：
- Laszlo Elteto is system architect with SafeNet, Inc.
- Laszlo Elteto是SafeNet，Inc.的系统架构师。
- Ernesto Frutos is director of Engineering with Authenex, Inc.
- Ernesto Frutos是Authenex，Inc.的工程总监。
- Fred McClain is Founder and CTO with Boojum Mobile, Inc.
- Fred McClain是Boojum Mobile，Inc.的创始人和首席技术官。
Without their advice and valuable inputs, this document would not be the same.
如果没有他们的建议和宝贵的投入，这份文件就不一样了。
[BCK1] M. Bellare, R. Canetti and H. Krawczyk, "Keyed Hash Functions and Message Authentication", Proceedings of Crypto'96, LNCS Vol. 1109, pp. 1-15.
[BCK1]M.Bellare，R.Canetti和H.Krawczyk，“密钥散列函数和消息身份验证”，Crypto'96会议录，LNCS第1109卷，第1-15页。
[BCK2] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[BCK2]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[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月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC3979]Bradner，S.，“IETF技术中的知识产权”，BCP 79，RFC 3979，2005年3月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[OATH] Initiative for Open AuTHentication http://www.openauthentication.org
[誓言]开放身份验证倡议http://www.openauthentication.org
[PrOo] B. Preneel and P. van Oorschot, "MD-x MAC and building fast MACs from hash functions", Advances in Cryptology CRYPTO '95, Lecture Notes in Computer Science Vol. 963, D. Coppersmith ed., Springer-Verlag, 1995.
[PrOo]B.Preneel和P.van Oorschot，“MD-x MAC和利用散列函数构建快速MAC”，《密码学进展——加密》95年，计算机科学讲稿第963卷，D.铜匠出版社，斯普林格·维拉格，1995年。
[Crack] Crack in SHA-1 code 'stuns' security gurus
http://www.eetimes.com/showArticle.jhtml?
articleID=60402150
[Crack] Crack in SHA-1 code 'stuns' security gurus
http://www.eetimes.com/showArticle.jhtml?
articleID=60402150
[Sha1] Bruce Schneier. SHA-1 broken. February 15, 2005.
http://www.schneier.com/blog/archives/2005/02/
sha1_broken.html
[Sha1] Bruce Schneier. SHA-1 broken. February 15, 2005.
http://www.schneier.com/blog/archives/2005/02/
sha1_broken.html
[Res] Researchers: Digital encryption standard flawed
http://news.com.com/
Researchers+Digital+encryption+standard+flawed/
2100-1002-5579881.html?part=dht&tag=ntop&tag=nl.e703
[Res] Researchers: Digital encryption standard flawed
http://news.com.com/
Researchers+Digital+encryption+standard+flawed/
2100-1002-5579881.html?part=dht&tag=ntop&tag=nl.e703
[Shamir] How to Share a Secret, by Adi Shamir. In Communications of the ACM, Vol. 22, No. 11, pp. 612-613, November, 1979.
[Shamir]如何分享秘密，作者：Adi Shamir。《ACM通讯》，第22卷，第11期，第612-613页，1979年11月。
Appendix A - HOTP Algorithm Security: Detailed Analysis
附录A-HOTP算法安全性：详细分析
The security analysis of the HOTP algorithm is summarized in this section. We first detail the best attack strategies, and then elaborate on the security under various assumptions and the impact of the truncation and make some recommendations regarding the number of digits.
本节总结了HOTP算法的安全性分析。我们首先详细介绍了最佳攻击策略，然后详细阐述了各种假设下的安全性以及截断的影响，并就位数提出了一些建议。
We focus this analysis on the case where Digit = 6, i.e., an HOTP function that produces 6-digit values, which is the bare minimum recommended in this document.
我们将此分析重点放在Digit=6的情况下，即生成6位值的HOTP函数，这是本文档中建议的最小值。
We denote by {0,1}^l the set of all strings of length l.
我们用{0,1}^l表示长度为l的所有字符串的集合。
Let Z_{n} = {0,.., n - 1}.
Let Z_{n} = {0,.., n - 1}.
Let IntDiv(a,b) denote the integer division algorithm that takes
input integers a, b where a >= b >= 1 and returns integers (q,r)
Let IntDiv(a,b) denote the integer division algorithm that takes
input integers a, b where a >= b >= 1 and returns integers (q,r)
the quotient and remainder, respectively, of the division of a by b. (Thus, a = bq + r and 0 <= r < b.)
a除以b的商和余数。（因此，a=bq+r和0<=r<b。）
Let H: {0,1}^k x {0,1}^c --> {0,1}^n be the base function that takes a k-bit key K and c-bit counter C and returns an n-bit output H(K,C). (In the case of HOTP, H is HMAC-SHA-1; we use this formal definition for generalizing our proof of security.)
设H:{0,1}^k x{0,1}^c-->{0,1}^n为基函数，它接受k位键k和c位计数器c，并返回n位输出H（k，c）。（在HOTP的情况下，H是HMAC-SHA-1；我们使用此正式定义来概括我们的安全性证明。）
We now define an idealized counterpart of the HOTP algorithm. In this algorithm, the role of H is played by a random function that forms the key.
现在，我们定义了HOTP算法的理想对应物。在该算法中，H的作用由一个构成键的随机函数发挥。
To be more precise, let Maps(c,n) denote the set of all functions
mapping from {0,1}^c to {0,1}^n. The idealized algorithm has key
space Maps(c,n), so that a "key" for such an algorithm is a function
h from {0,1}^c to {0,1}^n. We imagine this key (function) to be
drawn at random. It is not feasible to implement this idealized
algorithm, since the key, being a function from {0,1}^c to {0,1}^n,
is way too large to even store. So why consider it?
To be more precise, let Maps(c,n) denote the set of all functions
mapping from {0,1}^c to {0,1}^n. The idealized algorithm has key
space Maps(c,n), so that a "key" for such an algorithm is a function
h from {0,1}^c to {0,1}^n. We imagine this key (function) to be
drawn at random. It is not feasible to implement this idealized
algorithm, since the key, being a function from {0,1}^c to {0,1}^n,
is way too large to even store. So why consider it?
Our security analysis will show that as long as H satisfies a certain well-accepted assumption, the security of the actual and idealized algorithms is for all practical purposes the same. The task that really faces us, then, is to assess the security of the idealized algorithm.
我们的安全性分析将表明，只要H满足某种公认的假设，实际算法和理想算法的安全性在所有实际用途上都是相同的。因此，我们真正面临的任务是评估理想化算法的安全性。
In analyzing the idealized algorithm, we are concentrating on assessing the quality of the design of the algorithm itself, independently of HMAC-SHA-1. This is in fact the important issue.
在分析理想化算法时，我们专注于评估算法本身的设计质量，独立于HMAC-SHA-1。这其实是一个重要的问题。
The model exhibits the type of threats or attacks that are being considered and enables one to assess the security of HOTP and HOTP-IDEAL. We denote ALG as either HOTP or HOTP-IDEAL for the purpose of this security analysis.
该模型展示了正在考虑的威胁或攻击的类型，使人们能够评估HOTP和HOTP-IDEAL的安全性。为了进行安全性分析，我们将ALG表示为HOTP或HOTP-IDEAL。
The scenario we are considering is that a user and server share a key K for ALG. Both maintain a counter C, initially zero, and the user authenticates itself by sending ALG(K,C) to the server. The latter accepts if this value is correct.
我们正在考虑的场景是，用户和服务器共享ALG的密钥K。两者都保持一个计数器C，初始值为零，用户通过向服务器发送ALG（K，C）来进行身份验证。如果此值正确，则后者接受。
In order to protect against accidental increment of the user counter, the server, upon receiving a value z, will accept as long as z equals ALG(K,i) for some i in the range C,...,C + s-1, where s is the resynchronization parameter and C is the server counter. If it accepts with some value of i, it then increments its counter to i+1. If it does not accept, it does not change its counter value.
为了防止用户计数器意外增加，服务器在接收到值z时，将接受只要z等于ALG（K，i），对于范围C，…，C+s-1中的一些i，其中s是重新同步参数，C是服务器计数器。如果它接受某个i值，则它将计数器增加到i+1。如果不接受，则不会更改其计数器值。
The model we specify captures what an adversary can do and what it needs to achieve in order to "win". First, the adversary is assumed to be able to eavesdrop, meaning, to see the authenticator transmitted by the user. Second, the adversary wins if it can get the server to accept an authenticator relative to a counter value for which the user has never transmitted an authenticator.
我们指定的模型捕获了对手可以做什么以及为了“获胜”需要实现什么。首先，假设对手能够窃听，也就是说，能够看到用户发送的验证器。第二，如果对手能够让服务器接受一个相对于计数器值的验证器，而该计数器值是用户从未发送过验证器的，则对手获胜。
The formal adversary, which we denote by B, starts out knowing which algorithm ALG is being used, knowing the system design, and knowing all system parameters. The one and only thing it is not given a priori is the key K shared between the user and the server.
形式对手，我们用B表示，首先知道使用哪种算法ALG，知道系统设计，知道所有系统参数。唯一没有被预先给定的是用户和服务器之间共享的密钥K。
The model gives B full control of the scheduling of events. It has access to an authenticator oracle representing the user. By calling this oracle, the adversary can ask the user to authenticate itself and get back the authenticator in return. It can call this oracle as often as it wants and when it wants, using the authenticators it accumulates to perhaps "learn" how to make authenticators itself. At any time, it may also call a verification oracle, supplying the latter with a candidate authenticator of its choice. It wins if the server accepts this accumulator.
该模型使B完全控制事件的调度。它可以访问代表用户的验证器oracle。通过调用此oracle，对手可以要求用户对自己进行身份验证，并返回身份验证器。它可以随时调用此oracle，并在需要时使用它积累的验证器来“学习”如何生成验证器本身。在任何时候，它也可以调用验证oracle，为后者提供其选择的候选验证器。如果服务器接受此累加器，则它将获胜。
Consider the following game involving an adversary B that is attempting to compromise the security of an authentication algorithm ALG: K x {0,1}^c --> R.
考虑下面的游戏，它涉及一个试图破坏认证算法ALG:K x{0,1}^ C--R.的安全性的对手B。
Initializations - A key K is selected at random from K, a counter C is initialized to 0, and the Boolean value win is set to false.
初始化-从K中随机选择一个键K，计数器C初始化为0，布尔值win设置为false。
Game execution - Adversary B is provided with the two following oracles:
游戏执行-对手B配备以下两个神谕：
Oracle AuthO()
--------------
A = ALG(K,C)
C = C + 1
Return O to B
Oracle AuthO()
--------------
A = ALG(K,C)
C = C + 1
Return O to B
Oracle VerO(A)
--------------
i = C
While (i <= C + s - 1 and Win == FALSE) do
If A == ALG(K,i) then Win = TRUE; C = i + 1
Else i = i + 1
Return Win to B
Oracle VerO(A)
--------------
i = C
While (i <= C + s - 1 and Win == FALSE) do
If A == ALG(K,i) then Win = TRUE; C = i + 1
Else i = i + 1
Return Win to B
AuthO() is the authenticator oracle and VerO(A) is the verification oracle.
AuthO（）是验证器oracle，VerO（A）是验证oracle。
Upon execution, B queries the two oracles at will. Let Adv(B) be the probability that win gets set to true in the above game. This is the probability that the adversary successfully impersonates the user.
执行时，B随意查询这两个预言。设Adv（B）为在上述游戏中获胜的概率。这是对手成功模拟用户的概率。
Our goal is to assess how large this value can be as a function of the number v of verification queries made by B, the number a of authenticator oracle queries made by B, and the running time t of B. This will tell us how to set the throttle, which effectively upper bounds v.
我们的目标是评估该值随B进行的验证查询的数量v、B进行的验证器oracle查询的数量a和B的运行时间t的变化而变化的程度。这将告诉我们如何设置节流阀，它有效地限制了v。
This section summarizes the security analysis of HOTP-IDEAL, starting with the impact of the conversion modulo 10^Digit and then focusing on the different possible attacks.
本节总结了HOTP-IDEAL的安全性分析，从10位模转换的影响开始，然后重点介绍了不同的可能攻击。
The dynamic offset truncation of a random n-bit string yields a random 31-bit string. What happens to the distribution when it is taken modulo m = 10^Digit, as done in HOTP?
随机n位字符串的动态偏移截断产生随机31位字符串。当取模m=10^位时，如在HOTP中所做的那样，分布会发生什么变化？
The following lemma estimates the biases in the outputs in this case.
下面的引理估计了这种情况下输出的偏差。
Lemma 1
-------
Let N >= m >= 1 be integers, and let (q,r) = IntDiv(N,m). For z in
Z_{m} let:
Lemma 1
-------
Let N >= m >= 1 be integers, and let (q,r) = IntDiv(N,m). For z in
Z_{m} let:
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]
P_{N,m}(z) = Pr [x mod m = z : x randomly pick in Z_{n}]
Then for any z in Z_{m}
那么对于z{m}中的任何z
P_{N,m}(z) = (q + 1) / N if 0 <= z < r
q / N if r <= z < m
P_{N,m}(z) = (q + 1) / N if 0 <= z < r
q / N if r <= z < m
Proof of Lemma 1
----------------
Let the random variable X be uniformly distributed over Z_{N}. Then:
Proof of Lemma 1
----------------
Let the random variable X be uniformly distributed over Z_{N}. Then:
P_{N,m}(z) = Pr [X mod m = z]
P_{N,m}(z) = Pr [X mod m = z]
= Pr [X < mq] * Pr [X mod m = z| X < mq]
+ Pr [mq <= X < N] * Pr [X mod m = z| mq <= X < N]
= Pr [X < mq] * Pr [X mod m = z| X < mq]
+ Pr [mq <= X < N] * Pr [X mod m = z| mq <= X < N]
= mq/N * 1/m +
(N - mq)/N * 1 / (N - mq) if 0 <= z < N - mq
0 if N - mq <= z <= m
= mq/N * 1/m +
(N - mq)/N * 1 / (N - mq) if 0 <= z < N - mq
0 if N - mq <= z <= m
= q/N +
r/N * 1 / r if 0 <= z < N - mq
0 if r <= z <= m
= q/N +
r/N * 1 / r if 0 <= z < N - mq
0 if r <= z <= m
Simplifying yields the claimed equation.
简化得到所声称的方程式。
Let N = 2^31, d = 6, and m = 10^d. If x is chosen at random from Z_{N} (meaning, is a random 31-bit string), then reducing it to a 6- digit number by taking x mod m does not yield a random 6-digit number.
设N=2^31，d=6，m=10^d。如果x是从Z_{N}中随机选择的（意思是，是一个随机的31位字符串），那么通过取x mod m将其减少为一个6位数字并不会产生一个随机的6位数字。
Rather, x mod m is distributed as shown in the following table:
相反，x mod m的分布如下表所示：
Values Probability that each appears as output
----------------------------------------------------------------
0,1,...,483647 2148/2^31 roughly equals to 1.00024045/10^6
483648,...,999999 2147/2^31 roughly equals to 0.99977478/10^6
Values Probability that each appears as output
----------------------------------------------------------------
0,1,...,483647 2148/2^31 roughly equals to 1.00024045/10^6
483648,...,999999 2147/2^31 roughly equals to 0.99977478/10^6
If X is uniformly distributed over Z_{2^31} (meaning, is a random 31-bit string), then the above shows the probabilities for different outputs of X mod 10^6. The first set of values appears with
如果X均匀分布在Z_{2^31}（意思是，是一个随机的31位字符串），那么上面显示了X mod 10^6的不同输出的概率。第一组值显示为
probability slightly greater than 10^-6, the rest with probability slightly less, meaning that the distribution is slightly non-uniform.
概率稍大于10^-6，其余概率稍小，表示分布稍不均匀。
However, as the table above indicates, the bias is small, and as we will see later, negligible: the probabilities are very close to 10^-6.
然而，如上表所示，偏差很小，正如我们稍后将看到的，可以忽略不计：概率非常接近10^-6。
If the authenticator consisted of d random digits, then a brute force attack using v verification attempts would succeed with probability sv/10^Digit.
如果验证器由d个随机数字组成，则使用v验证尝试的暴力攻击将以sv/10^数字的概率成功。
However, an adversary can exploit the bias in the outputs of HOTP-IDEAL, predicted by Lemma 1, to mount a slightly better attack.
然而，对手可以利用引理1预测的HOTP-IDEAL输出中的偏差，发起稍微好一点的攻击。
Namely, it makes authentication attempts with authenticators that are the most likely values, meaning the ones in the range 0,...,r - 1, where (q,r) = IntDiv(2^31,10^Digit).
也就是说，它使用最有可能的值进行身份验证尝试，即范围为0，…，r-1的值，其中（q，r）=IntDiv（2^31,10^Digit）。
The following specifies an adversary in our model of security that mounts the attack. It estimates the success probability as a function of the number of verification queries.
下面在我们的安全模型中指定了发起攻击的对手。它将成功概率估计为验证查询数的函数。
For simplicity, we assume that the number of verification queries is at most r. With N = 2^31 and m = 10^6, we have r = 483,648, and the throttle value is certainly less than this, so this assumption is not much of a restriction.
为简单起见，我们假设验证查询的数量最多为r。对于N=2^31和m=10^6，我们有r=483648，节流阀的值肯定小于这个值，所以这个假设没有太大的限制。
Proposition 1
-------------
Proposition 1
-------------
Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Assume
s <= m. The brute-force-attack adversary B-bf attacks HOTP using v
<= r verification oracle queries. This adversary makes no
authenticator oracle queries, and succeeds with probability
Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Assume
s <= m. The brute-force-attack adversary B-bf attacks HOTP using v
<= r verification oracle queries. This adversary makes no
authenticator oracle queries, and succeeds with probability
Adv(B-bf) = 1 - (1 - v(q+1)/2^31)^s
Adv(B-bf) = 1 - (1 - v(q+1)/2^31)^s
which is roughly equal to
大约等于
sv * (q+1)/2^31
sv * (q+1)/2^31
With m = 10^6 we get q = 2,147. In that case, the brute force attack using v verification attempts succeeds with probability
当m=10^6时，我们得到q=2147。在这种情况下，使用v验证尝试的暴力攻击有可能成功
Adv(B-bf) roughly = sv * 2148/2^31 = sv * 1.00024045/10^6
Adv(B-bf) roughly = sv * 2148/2^31 = sv * 1.00024045/10^6
As this equation shows, the resynchronization parameter s has a significant impact in that the adversary's success probability is proportional to s. This means that s cannot be made too large without compromising security.
如该等式所示，再同步参数s具有重大影响，因为对手的成功概率与s成正比。这意味着，在不影响安全性的情况下，s不能太大。
A.4.3. Brute force attacks are the best possible attacks.
A.4.3. 暴力攻击是最好的攻击。
A central question is whether there are attacks any better than the brute force one. In particular, the brute force attack did not attempt to collect authenticators sent by the user and try to cryptanalyze them in an attempt to learn how to better construct authenticators. Would doing this help? Is there some way to "learn" how to build authenticators that result in a higher success rate than given by the brute-force attack?
一个核心问题是是否有比暴力攻击更好的攻击。特别是，暴力攻击并没有试图收集用户发送的身份验证器，并尝试对其进行加密分析，以了解如何更好地构造身份验证器。这样做会有帮助吗？是否有某种方法可以“学习”如何构建验证器，从而获得比暴力攻击更高的成功率？
The following says the answer to these questions is no. No matter what strategy the adversary uses, and even if it sees, and tries to exploit, the authenticators from authentication attempts of the user, its success probability will not be above that of the brute force attack -- this is true as long as the number of authentications it observes is not incredibly large. This is valuable information regarding the security of the scheme.
下面说这些问题的答案是否定的。无论对手使用什么策略，即使它看到并试图利用用户身份验证尝试中的身份验证者，它的成功概率不会高于暴力攻击——只要它观察到的身份验证数量不是难以置信的大，这是正确的。这是有关方案安全性的宝贵信息。
Proposition 2 ------------- Suppose m = 10^Digit < 2^31, and let
(q,r) = IntDiv(2^31,m). Let B be any adversary attacking HOTP-IDEAL
using v verification oracle queries and a <= 2^c - s authenticator
oracle queries. Then
Proposition 2 ------------- Suppose m = 10^Digit < 2^31, and let
(q,r) = IntDiv(2^31,m). Let B be any adversary attacking HOTP-IDEAL
using v verification oracle queries and a <= 2^c - s authenticator
oracle queries. Then
Adv(B) < = sv * (q+1)/ 2^31
Adv(B) < = sv * (q+1)/ 2^31
Note: This result is conditional on the adversary not seeing more than 2^c - s authentications performed by the user, which is hardly restrictive as long as c is large enough.
注意：此结果取决于对手看到的用户执行的身份验证不超过2^c-s，只要c足够大，这几乎没有限制。
With m = 10^6, we get q = 2,147. In that case, Proposition 2 says that any adversary B attacking HOTP-IDEAL and making v verification attempts succeeds with probability at most
当m=10^6时，我们得到q=2147。在这种情况下，命题2说，任何攻击HOTP-IDEAL并进行v验证尝试的对手B都以最大概率成功
Equation 1
----------
sv * 2148/2^31 roughly = sv * 1.00024045/10^6
Equation 1
----------
sv * 2148/2^31 roughly = sv * 1.00024045/10^6
Meaning, B's success rate is not more than that achieved by the brute force attack.
也就是说，B的成功率不超过暴力攻击的成功率。
We have analyzed, in the previous sections, the security of the idealized counterparts HOTP-IDEAL of the actual authentication algorithm HOTP. We now show that, under appropriate and well-believed assumption on H, the security of the actual algorithms is essentially the same as that of its idealized counterpart.
在前面的章节中，我们已经分析了实际身份验证算法HOTP的理想对等HOTP-IDEAL的安全性。我们现在证明，在适当且可信的H假设下，实际算法的安全性与理想化算法的安全性基本相同。
The assumption in question is that H is a secure pseudorandom function, or PRF, meaning that its input-output values are indistinguishable from those of a random function in practice.
所讨论的假设是H是一个安全的伪随机函数，即PRF，这意味着它的输入输出值在实践中与随机函数的输入输出值无法区分。
Consider an adversary A that is given an oracle for a function f: {0,1}^c --> {0, 1}^n and eventually outputs a bit. We denote Adv(A) as the prf-advantage of A, which represents how well the adversary does at distinguishing the case where its oracle is H(K,.) from the case where its oracle is a random function of {0,1}^c to {0,1}^n.
考虑一个对手A，它为函数f:{0,1}^ C＞{ 0, 1 } n给出了一个Oracle，并最终输出一个位。我们将Adv（A）表示为A的prf优势，这表示对手在区分其甲骨文为H（K，）的情况和其甲骨文为{0,1}^c到{0,1}^n的随机函数的情况方面做得有多好。
One possible attack is based on exhaustive search for the key K. If A runs for t steps and T denotes the time to perform one computation of H, its prf-advantage from this attack turns out to be (t/T)2^-k. Another possible attack is a birthday one [PrOo], whereby A can attain advantage p^2/2^n in p oracle queries and running time about pT.
一种可能的攻击是基于对密钥K的穷举搜索。如果A运行t个步骤，t表示执行一次H计算的时间，则该攻击的prf优势为（t/t）2^-K。另一种可能的攻击是生日攻击[PrOo]，通过这种攻击，a可以在p oracle查询和关于pT的运行时间方面获得优势p^2/2^n。
Our assumption is that these are the best possible attacks. This translates into the following.
我们的假设是这些是最好的攻击。这可以转化为以下内容。
Assumption 1
------------
Assumption 1
------------
Let T denotes the time to perform one computation of H. Then if A is any adversary with running time at most t and making at most p oracle queries,
设T表示执行一次H计算的时间。如果A是运行时间最多为T且最多进行p次oracle查询的任何对手，
Adv(A) <= (t/T)/2^k + p^2/2^n
Adv(A) <= (t/T)/2^k + p^2/2^n
In practice, this assumption means that H is very secure as PRF. For example, given that k = n = 160, an attacker with running time 2^60 and making 2^40 oracle queries has advantage at most (about) 2^-80.
在实践中，这一假设意味着H作为PRF是非常安全的。例如，假设k=n=160，运行时间为2^60并进行2^40 oracle查询的攻击者最多（大约）2^-80的优势。
Theorem 1
---------
Theorem 1
---------
Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B be any adversary attacking HOTP using v verification oracle queries,
假设m=10^Digit<2^31，设（q，r）=IntDiv（2^31，m）。假设B是使用v验证oracle查询攻击HOTP的任何对手，
a <= 2^c - s authenticator oracle queries, and running time t. Let T denote the time to perform one computation of H. If Assumption 1 is true, then
a<=2^c-s验证器oracle查询，运行时间t。让T表示执行一次H计算的时间。如果假设1为真，则
Adv(B) <= sv * (q + 1)/2^31 + (t/T)/2^k + ((sv + a)^2)/2^n
Adv(B) <= sv * (q + 1)/2^31 + (t/T)/2^k + ((sv + a)^2)/2^n
In practice, the (t/T)2^-k + ((sv + a)^2)2^-n term is much smaller than the sv(q + 1)/2^n term, so that the above says that for all practical purposes the success rate of an adversary attacking HOTP is sv(q + 1)/2^n, just as for HOTP-IDEAL, meaning the HOTP algorithm is in practice essentially as good as its idealized counterpart.
在实践中，（t/t）2^-k+（（sv+a）^2）2^-n项比sv（q+1）/2^n项小得多，因此上述说明，在所有实际目的中，对手攻击HOTP的成功率是sv（q+1）/2^n，就像HOTP-IDEAL一样，这意味着HOTP算法在实践中基本上与其理想化的对应算法一样好。
In the case m = 10^6 of a 6-digit output, this means that an adversary making v authentication attempts will have a success rate that is at most that of Equation 1.
在6位数输出的m=10^6的情况下，这意味着进行v验证尝试的对手的成功率最多为等式1的成功率。
For example, consider an adversary with running time at most 2^60 that sees at most 2^40 authentication attempts of the user. Both these choices are very generous to the adversary, who will typically not have these resources, but we are saying that even such a powerful adversary will not have more success than indicated by Equation 1.
例如，考虑一个具有最多2 ^ 60的运行时间的对手，该用户最多可以看到用户的2 ^ 40认证尝试。这两种选择对对手来说都是非常慷慨的，他们通常不会拥有这些资源，但我们要说的是，即使是如此强大的对手也不会比方程式1所示的更成功。
We can safely assume sv <= 2^40 due to the throttling and bounds on s. So:
我们可以安全地假设sv<=2^40，因为s上的节流和边界。因此：
(t/T)/2^k + ((sv + a)^2)/2^n <= 2^60/2^160 + (2^41)^2/2^160
roughly <= 2^-78
(t/T)/2^k + ((sv + a)^2)/2^n <= 2^60/2^160 + (2^41)^2/2^160
roughly <= 2^-78
which is much smaller than the success probability of Equation 1 and negligible compared to it.
这比方程1的成功概率小得多，与之相比可以忽略不计。
Appendix B - SHA-1 Attacks
附录B-SHA-1攻击
This sections addresses the impact of the recent attacks on SHA-1 on the security of the HMAC-SHA-1-based HOTP. We begin with some discussion of the situation of SHA-1 and then discuss the relevance to HMAC-SHA-1 and HOTP. Cited references are in Section 13.
本节讨论最近对SHA-1的攻击对基于HMAC-SHA-1的HOTP安全性的影响。我们首先讨论SHA-1的情况，然后讨论与HMAC-SHA-1和HOTP的相关性。引用的参考文献见第13节。
A collision for a hash function h means a pair x,y of different inputs such that h(x)=h(y). Since SHA-1 outputs 160 bits, a birthday attack finds a collision in 2^{80} trials. (A trial means one computation of the function.) This was thought to be the best possible until Wang, Yin, and Yu announced on February 15, 2005, that they had an attack finding collisions in 2^{69} trials.
散列函数h的冲突意味着不同输入的一对x，y，使得h（x）=h（y）。由于SHA-1输出160位，生日攻击在2^{80}次试验中发现冲突。（一次试验意味着函数的一次计算。）这被认为是最好的，直到2005年2月15日Wang、Yin和Yu宣布他们在2 ^{69}次试验中发现了碰撞攻击。
Is SHA-1 broken? For most practical purposes, we would say probably not, since the resources needed to mount the attack are huge. Here is one way to get a sense of it: we can estimate it is about the same as the time we would need to factor a 760-bit RSA modulus, and this is currently considered out of reach.
SHA-1坏了吗？出于最实际的目的，我们认为可能不会，因为发动攻击所需的资源是巨大的。这里有一种方法可以理解它：我们可以估计它大约与我们需要将760位RSA模因子化的时间相同，而这目前被认为是遥不可及的。
Burr of NIST is quoted in [Crack] as saying "Large national intelligence agencies could do this in a reasonable amount of time with a few million dollars in computer time". However, the computation may be out of reach of all but such well-funded agencies.
《快报》援引NIST的伯尔的话说，“大型国家情报机构可以用几百万美元的计算机时间在合理的时间内完成这项工作”。然而，除了这些资金充裕的机构之外，所有机构都可能无法进行计算。
One should also ask what impact finding SHA-1 collisions actually has on security of real applications such as signatures. To exploit a collision x,y to forge signatures, you need to somehow obtain a signature of x and then you can forge a signature of y. How damaging this is depends on the content of y: the y created by the attack may not be meaningful in the application context. Also, one needs a chosen-message attack to get the signature of x. This seems possible in some contexts, but not others. Overall, it is not clear that the impact on the security of signatures is significant.
人们还应该问，查找SHA-1冲突对签名等实际应用程序的安全性实际上有什么影响。要利用碰撞x，y伪造签名，您需要以某种方式获得x的签名，然后才能伪造y的签名。其破坏程度取决于y的内容：攻击创建的y在应用程序上下文中可能没有意义。此外，需要选择消息攻击才能获得x的签名。在某些情况下，这似乎是可能的，但在其他情况下则不然。总体而言，尚不清楚对签名安全的影响是否重大。
Indeed, one can read in the press that SHA-1 is "broken" [Sha1] and that encryption and SSL are "broken" [Res]. The media have a tendency to magnify events: it would hardly be interesting to announce in the news that a team of cryptanalysts did very interesting theoretical work in attacking SHA-1.
事实上，人们可以在媒体上看到SHA-1“坏了”[Sha1]，加密和SSL“坏了”[Res]。媒体有放大事件的倾向：在新闻中宣布一组密码分析人员在攻击SHA-1时做了非常有趣的理论工作是很不有趣的。
Cryptographers are excited too. But mainly because this is an important theoretical breakthrough. Attacks can only get better with time: it is therefore important to monitor any progress in hash functions cryptanalysis and be prepared for any really practical break with a sound migration plan for the future.
密码学家们也很兴奋。但主要是因为这是一个重要的理论突破。攻击只会随着时间的推移而变得更好：因此，监控哈希函数密码分析的任何进展，并为未来的合理迁移计划做好任何实际的准备是很重要的。
The new attacks on SHA-1 have no impact on the security of HMAC-SHA-1. The best attack on the latter remains one needing a sender to authenticate 2^{80} messages before an adversary can create a forgery. Why?
对SHA-1的新攻击对HMAC-SHA-1的安全没有影响。对后者的最佳攻击仍然是需要发送方对2^{80}条消息进行身份验证，然后对手才能创建伪造。为什么？
HMAC is not a hash function. It is a message authentication code (MAC) that uses a hash function internally. A MAC depends on a secret key, while hash functions don't. What one needs to worry about with a MAC is forgery, not collisions. HMAC was designed so that collisions in the hash function (here SHA-1) do not yield forgeries for HMAC.
HMAC不是散列函数。它是一种在内部使用哈希函数的消息身份验证码（MAC）。MAC依赖于密钥，而哈希函数则不依赖。MAC电脑需要担心的是伪造，而不是碰撞。HMAC的设计使哈希函数（这里是SHA-1）中的冲突不会产生HMAC的伪造。
Recall that HMAC-SHA-1(K,x) = SHA-1(K_o,SHA-1(K_i,x)) where the keys K_o,K_i are derived from K. Suppose the attacker finds a pair x,y such that SHA-1(K_i,x) = SHA-1(K_i,y). (Call this a hidden-key collision.) Then if it can obtain the MAC of x (itself a tall order), it can forge the MAC of y. (These values are the same.) But finding hidden-key collisions is harder than finding collisions, because the attacker does not know the hidden key K_i. All it may have is some outputs of HMAC-SHA-1 with key K. To date, there are no claims or evidence that the recent attacks on SHA-1 extend to find hidden-key collisions.
回想一下HMAC-SHA-1（K，x）=SHA-1（K_o，SHA-1（K_i，x）），其中密钥K_o，K_i来自K。假设攻击者找到一对x，y，使得SHA-1（K_i，x）=SHA-1（K_i，y）。（称之为隐藏密钥冲突。）然后，如果它可以获得x的MAC（本身是一个高阶），它可以伪造y的MAC。（这些值相同。）但查找隐藏密钥冲突比查找冲突更困难，因为攻击者不知道隐藏密钥K_i。它可能拥有的只是HMAC-SHA-1的一些带有密钥K的输出。到目前为止，没有任何声称或证据表明最近对SHA-1的攻击扩展到寻找隐藏的密钥冲突。
Historically, the HMAC design has already proven itself in this regard. MD5 is considered broken in that collisions in this hash function can be found relatively easily. But there is still no attack on HMAC-MD5 better than the trivial 2^{64} time birthday one. (MD5 outputs 128 bits, not 160.) We are seeing this strength of HMAC coming into play again in the SHA-1 context.
历史上，HMAC设计已经在这方面证明了自己。MD5被认为是坏的，因为可以相对容易地找到此哈希函数中的冲突。但是对HMAC-MD5的攻击仍然没有比微不足道的2^{64}次生日攻击更好的了。（MD5输出128位，而不是160位。）我们看到HMAC的这种强度在SHA-1环境中再次发挥作用。
Since no new weakness has surfaced in HMAC-SHA-1, there is no impact on HOTP. The best attacks on HOTP remain those described in the document, namely, to try to guess output values.
由于HMAC-SHA-1中没有出现新的弱点，因此对HOTP没有影响。对HOTP的最佳攻击仍然是文档中描述的攻击，即尝试猜测输出值。
The security proof of HOTP requires that HMAC-SHA-1 behave like a pseudorandom function. The quality of HMAC-SHA-1 as a pseudorandom function is not impacted by the new attacks on SHA-1, and so neither is this proven guarantee.
HOTP的安全性证明要求HMAC-SHA-1的行为类似于伪随机函数。HMAC-SHA-1作为伪随机函数的质量不受对SHA-1的新攻击的影响，因此这也不是经过验证的保证。
Appendix C - HOTP Algorithm: Reference Implementation
附录C-HOTP算法：参考实现
/*
* OneTimePasswordAlgorithm.java
* OATH Initiative,
* HOTP one-time password algorithm
*
*/
/*
* OneTimePasswordAlgorithm.java
* OATH Initiative,
* HOTP one-time password algorithm
*
*/
/* Copyright (C) 2004, OATH. All rights reserved.
*
* License to copy and use this software is granted provided that it
* is identified as the "OATH HOTP Algorithm" in all material
* mentioning or referencing this software or this function.
*
* License is also granted to make and use derivative works provided
* that such works are identified as
* "derived from OATH HOTP algorithm"
* in all material mentioning or referencing the derived work.
*
* OATH (Open AuTHentication) and its members make no
* representations concerning either the merchantability of this
* software or the suitability of this software for any particular
* purpose.
*
* It is provided "as is" without express or implied warranty
* of any kind and OATH AND ITS MEMBERS EXPRESSaLY DISCLAIMS
* ANY WARRANTY OR LIABILITY OF ANY KIND relating to this software.
*
* These notices must be retained in any copies of any part of this
* documentation and/or software.
*/
/* Copyright (C) 2004, OATH. All rights reserved.
*
* License to copy and use this software is granted provided that it
* is identified as the "OATH HOTP Algorithm" in all material
* mentioning or referencing this software or this function.
*
* License is also granted to make and use derivative works provided
* that such works are identified as
* "derived from OATH HOTP algorithm"
* in all material mentioning or referencing the derived work.
*
* OATH (Open AuTHentication) and its members make no
* representations concerning either the merchantability of this
* software or the suitability of this software for any particular
* purpose.
*
* It is provided "as is" without express or implied warranty
* of any kind and OATH AND ITS MEMBERS EXPRESSaLY DISCLAIMS
* ANY WARRANTY OR LIABILITY OF ANY KIND relating to this software.
*
* These notices must be retained in any copies of any part of this
* documentation and/or software.
*/
package org.openauthentication.otp;
包org.openauthentication.otp；
import java.io.IOException;
import java.io.File;
import java.io.DataInputStream;
import java.io.FileInputStream ;
import java.lang.reflect.UndeclaredThrowableException;
import java.io.IOException;
import java.io.File;
import java.io.DataInputStream;
import java.io.FileInputStream ;
import java.lang.reflect.UndeclaredThrowableException;
import java.security.GeneralSecurityException;
import java.security.NoSuchAlgorithmException;
import java.security.InvalidKeyException;
import java.security.GeneralSecurityException;
import java.security.NoSuchAlgorithmException;
import java.security.InvalidKeyException;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
/**
* This class contains static methods that are used to calculate the
* One-Time Password (OTP) using
* JCE to provide the HMAC-SHA-1.
*
* @author Loren Hart
* @version 1.0
*/
public class OneTimePasswordAlgorithm {
private OneTimePasswordAlgorithm() {}
/**
* This class contains static methods that are used to calculate the
* One-Time Password (OTP) using
* JCE to provide the HMAC-SHA-1.
*
* @author Loren Hart
* @version 1.0
*/
public class OneTimePasswordAlgorithm {
private OneTimePasswordAlgorithm() {}
// These are used to calculate the check-sum digits.
// 0 1 2 3 4 5 6 7 8 9
private static final int[] doubleDigits =
{ 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };
// These are used to calculate the check-sum digits.
// 0 1 2 3 4 5 6 7 8 9
private static final int[] doubleDigits =
{ 0, 2, 4, 6, 8, 1, 3, 5, 7, 9 };
/**
* Calculates the checksum using the credit card algorithm.
* This algorithm has the advantage that it detects any single
* mistyped digit and any single transposition of
* adjacent digits.
*
* @param num the number to calculate the checksum for
* @param digits number of significant places in the number
*
* @return the checksum of num
*/
public static int calcChecksum(long num, int digits) {
boolean doubleDigit = true;
int total = 0;
while (0 < digits--) {
int digit = (int) (num % 10);
num /= 10;
if (doubleDigit) {
digit = doubleDigits[digit];
}
total += digit;
doubleDigit = !doubleDigit;
}
int result = total % 10;
if (result > 0) {
result = 10 - result;
}
return result;
}
/**
* Calculates the checksum using the credit card algorithm.
* This algorithm has the advantage that it detects any single
* mistyped digit and any single transposition of
* adjacent digits.
*
* @param num the number to calculate the checksum for
* @param digits number of significant places in the number
*
* @return the checksum of num
*/
public static int calcChecksum(long num, int digits) {
boolean doubleDigit = true;
int total = 0;
while (0 < digits--) {
int digit = (int) (num % 10);
num /= 10;
if (doubleDigit) {
digit = doubleDigits[digit];
}
total += digit;
doubleDigit = !doubleDigit;
}
int result = total % 10;
if (result > 0) {
result = 10 - result;
}
return result;
}
/**
* This method uses the JCE to provide the HMAC-SHA-1
/**
* This method uses the JCE to provide the HMAC-SHA-1
* algorithm. * HMAC computes a Hashed Message Authentication Code and * in this case SHA1 is the hash algorithm used. * * @param keyBytes the bytes to use for the HMAC-SHA-1 key * @param text the message or text to be authenticated. * * @throws NoSuchAlgorithmException if no provider makes * either HmacSHA1 or HMAC-SHA-1 * digest algorithms available. * @throws InvalidKeyException * The secret provided was not a valid HMAC-SHA-1 key. * */
* 算法。*HMAC计算散列消息身份验证码，*在本例中，SHA1是使用的散列算法。**@param keyBytes用于HMAC-SHA-1密钥的字节*@param text要验证的消息或文本。**@如果没有提供程序使*HmacSHA1或HMAC-SHA-1*摘要算法可用，则抛出NoSuchAlgorithmException。*@抛出InvalidKeyException*提供的密钥不是有效的HMAC-SHA-1密钥。**/
public static byte[] hmac_sha1(byte[] keyBytes, byte[] text)
throws NoSuchAlgorithmException, InvalidKeyException
{
// try {
Mac hmacSha1;
try {
hmacSha1 = Mac.getInstance("HmacSHA1");
} catch (NoSuchAlgorithmException nsae) {
hmacSha1 = Mac.getInstance("HMAC-SHA-1");
}
SecretKeySpec macKey =
new SecretKeySpec(keyBytes, "RAW");
hmacSha1.init(macKey);
return hmacSha1.doFinal(text);
// } catch (GeneralSecurityException gse) {
// throw new UndeclaredThrowableException(gse);
// }
}
public static byte[] hmac_sha1(byte[] keyBytes, byte[] text)
throws NoSuchAlgorithmException, InvalidKeyException
{
// try {
Mac hmacSha1;
try {
hmacSha1 = Mac.getInstance("HmacSHA1");
} catch (NoSuchAlgorithmException nsae) {
hmacSha1 = Mac.getInstance("HMAC-SHA-1");
}
SecretKeySpec macKey =
new SecretKeySpec(keyBytes, "RAW");
hmacSha1.init(macKey);
return hmacSha1.doFinal(text);
// } catch (GeneralSecurityException gse) {
// throw new UndeclaredThrowableException(gse);
// }
}
private static final int[] DIGITS_POWER
// 0 1 2 3 4 5 6 7 8
= {1,10,100,1000,10000,100000,1000000,10000000,100000000};
private static final int[] DIGITS_POWER
// 0 1 2 3 4 5 6 7 8
= {1,10,100,1000,10000,100000,1000000,10000000,100000000};
/**
* This method generates an OTP value for the given
* set of parameters.
*
* @param secret the shared secret
* @param movingFactor the counter, time, or other value that
* changes on a per use basis.
* @param codeDigits the number of digits in the OTP, not
* including the checksum, if any.
* @param addChecksum a flag that indicates if a checksum digit
/**
* This method generates an OTP value for the given
* set of parameters.
*
* @param secret the shared secret
* @param movingFactor the counter, time, or other value that
* changes on a per use basis.
* @param codeDigits the number of digits in the OTP, not
* including the checksum, if any.
* @param addChecksum a flag that indicates if a checksum digit
* should be appended to the OTP.
* @param truncationOffset the offset into the MAC result to
* begin truncation. If this value is out of
* the range of 0 ... 15, then dynamic
* truncation will be used.
* Dynamic truncation is when the last 4
* bits of the last byte of the MAC are
* used to determine the start offset.
* @throws NoSuchAlgorithmException if no provider makes
* either HmacSHA1 or HMAC-SHA-1
* digest algorithms available.
* @throws InvalidKeyException
* The secret provided was not
* a valid HMAC-SHA-1 key.
*
* @return A numeric String in base 10 that includes
* {@link codeDigits} digits plus the optional checksum
* digit if requested.
*/
static public String generateOTP(byte[] secret,
long movingFactor,
int codeDigits,
boolean addChecksum,
int truncationOffset)
throws NoSuchAlgorithmException, InvalidKeyException
{
// put movingFactor value into text byte array
String result = null;
int digits = addChecksum ? (codeDigits + 1) : codeDigits;
byte[] text = new byte[8];
for (int i = text.length - 1; i >= 0; i--) {
text[i] = (byte) (movingFactor & 0xff);
movingFactor >>= 8;
}
* should be appended to the OTP.
* @param truncationOffset the offset into the MAC result to
* begin truncation. If this value is out of
* the range of 0 ... 15, then dynamic
* truncation will be used.
* Dynamic truncation is when the last 4
* bits of the last byte of the MAC are
* used to determine the start offset.
* @throws NoSuchAlgorithmException if no provider makes
* either HmacSHA1 or HMAC-SHA-1
* digest algorithms available.
* @throws InvalidKeyException
* The secret provided was not
* a valid HMAC-SHA-1 key.
*
* @return A numeric String in base 10 that includes
* {@link codeDigits} digits plus the optional checksum
* digit if requested.
*/
static public String generateOTP(byte[] secret,
long movingFactor,
int codeDigits,
boolean addChecksum,
int truncationOffset)
throws NoSuchAlgorithmException, InvalidKeyException
{
// put movingFactor value into text byte array
String result = null;
int digits = addChecksum ? (codeDigits + 1) : codeDigits;
byte[] text = new byte[8];
for (int i = text.length - 1; i >= 0; i--) {
text[i] = (byte) (movingFactor & 0xff);
movingFactor >>= 8;
}
// compute hmac hash
byte[] hash = hmac_sha1(secret, text);
// compute hmac hash
byte[] hash = hmac_sha1(secret, text);
// put selected bytes into result int
int offset = hash[hash.length - 1] & 0xf;
if ( (0<=truncationOffset) &&
(truncationOffset<(hash.length-4)) ) {
offset = truncationOffset;
}
int binary =
((hash[offset] & 0x7f) << 24)
| ((hash[offset + 1] & 0xff) << 16)
| ((hash[offset + 2] & 0xff) << 8)
// put selected bytes into result int
int offset = hash[hash.length - 1] & 0xf;
if ( (0<=truncationOffset) &&
(truncationOffset<(hash.length-4)) ) {
offset = truncationOffset;
}
int binary =
((hash[offset] & 0x7f) << 24)
| ((hash[offset + 1] & 0xff) << 16)
| ((hash[offset + 2] & 0xff) << 8)
| (hash[offset + 3] & 0xff);
|（散列[offset+3]&0xff）；
int otp = binary % DIGITS_POWER[codeDigits];
if (addChecksum) {
otp = (otp * 10) + calcChecksum(otp, codeDigits);
}
result = Integer.toString(otp);
while (result.length() < digits) {
result = "0" + result;
}
return result;
}
}
int otp = binary % DIGITS_POWER[codeDigits];
if (addChecksum) {
otp = (otp * 10) + calcChecksum(otp, codeDigits);
}
result = Integer.toString(otp);
while (result.length() < digits) {
result = "0" + result;
}
return result;
}
}
Appendix D - HOTP Algorithm: Test Values
附录D-HOTP算法：测试值
The following test data uses the ASCII string "12345678901234567890" for the secret:
以下测试数据使用ASCII字符串“123456789001234567890”作为密码：
Secret = 0x3132333435363738393031323334353637383930
Secret = 0x3132333435363738393031323334353637383930
Table 1 details for each count, the intermediate HMAC value.
表1各计数的详细信息，中间HMAC值。
Count Hexadecimal HMAC-SHA-1(secret, count)
0 cc93cf18508d94934c64b65d8ba7667fb7cde4b0
1 75a48a19d4cbe100644e8ac1397eea747a2d33ab
2 0bacb7fa082fef30782211938bc1c5e70416ff44
3 66c28227d03a2d5529262ff016a1e6ef76557ece
4 a904c900a64b35909874b33e61c5938a8e15ed1c
5 a37e783d7b7233c083d4f62926c7a25f238d0316
6 bc9cd28561042c83f219324d3c607256c03272ae
7 a4fb960c0bc06e1eabb804e5b397cdc4b45596fa
8 1b3c89f65e6c9e883012052823443f048b4332db
9 1637409809a679dc698207310c8c7fc07290d9e5
Count Hexadecimal HMAC-SHA-1(secret, count)
0 cc93cf18508d94934c64b65d8ba7667fb7cde4b0
1 75a48a19d4cbe100644e8ac1397eea747a2d33ab
2 0bacb7fa082fef30782211938bc1c5e70416ff44
3 66c28227d03a2d5529262ff016a1e6ef76557ece
4 a904c900a64b35909874b33e61c5938a8e15ed1c
5 a37e783d7b7233c083d4f62926c7a25f238d0316
6 bc9cd28561042c83f219324d3c607256c03272ae
7 a4fb960c0bc06e1eabb804e5b397cdc4b45596fa
8 1b3c89f65e6c9e883012052823443f048b4332db
9 1637409809a679dc698207310c8c7fc07290d9e5
Table 2 details for each count the truncated values (both in hexadecimal and decimal) and then the HOTP value.
表2详细说明了每个计数的截断值（十六进制和十进制），然后是HOTP值。
Truncated Count Hexadecimal Decimal HOTP 0 4c93cf18 1284755224 755224 1 41397eea 1094287082 287082 2 82fef30 137359152 359152 3 66ef7655 1726969429 969429 4 61c5938a 1640338314 338314 5 33c083d4 868254676 254676 6 7256c032 1918287922 287922 7 4e5b397 82162583 162583 8 2823443f 673399871 399871 9 2679dc69 645520489 520489
截断计数十六进制HOTP 0 4c93cf18 1284755224 755224 1 41397eea 1094287082 287082 2 FEF30 137359152 359152 3 66ef7655 17269669429 969429 4 61c5938a 1640338314 338314 5 33c083d4 868254676 254676 7256c032 1918287922 287922 4 E5B397 82162583 162583 162588 2823443f 673399871 399871 9 2679dc69 645520489 520489
Appendix E - Extensions
附录E-扩展
We introduce in this section several enhancements to the HOTP algorithm. These are not recommended extensions or part of the standard algorithm, but merely variations that could be used for customized implementations.
在本节中，我们将介绍对HOTP算法的一些增强。这些不是推荐的扩展或标准算法的一部分，而只是可用于定制实现的变体。
A simple enhancement in terms of security would be to extract more digits from the HMAC-SHA-1 value.
安全性方面的一个简单增强是从HMAC-SHA-1值中提取更多的数字。
For instance, calculating the HOTP value modulo 10^8 to build an 8- digit HOTP value would reduce the probability of success of the adversary from sv/10^6 to sv/10^8.
例如，计算以10^8为模的HOTP值来构建一个8位数的HOTP值，将对手的成功概率从sv/10^6降低到sv/10^8。
This could give the opportunity to improve usability, e.g., by increasing T and/or s, while still achieving a better security overall. For instance, s = 10 and 10v/10^8 = v/10^7 < v/10^6 which is the theoretical optimum for 6-digit code when s = 1.
这可以提供机会来提高可用性，例如，通过增加T和/或s，同时仍然实现更好的总体安全性。例如，s=10和10v/10^8=v/10^7<v/10^6，这是s=1时6位代码的理论最佳值。
Another option is to use A-Z and 0-9 values; or rather a subset of 32 symbols taken from the alphanumerical alphabet in order to avoid any confusion between characters: 0, O, and Q as well as l, 1, and I are very similar, and can look the same on a small display.
另一个选项是使用A-Z和0-9值；或者更确切地说，是从字母数字字母表中提取的32个符号的子集，以避免字符之间的任何混淆：0、O、Q以及l、1和I非常相似，并且在小屏幕上看起来相同。
The immediate consequence is that the security is now in the order of sv/32^6 for a 6-digit HOTP value and sv/32^8 for an 8-digit HOTP value.
直接的结果是，对于6位HOTP值，安全性现在的顺序是sv/32^6，对于8位HOTP值，安全性现在的顺序是sv/32^8。
32^6 > 10^9 so the security of a 6-alphanumeric HOTP code is slightly better than a 9-digit HOTP value, which is the maximum length of an HOTP code supported by the proposed algorithm.
32^6>10^9，因此6个字母数字的HOTP代码的安全性略优于9个数字的HOTP值，这是建议算法支持的HOTP代码的最大长度。
32^8 > 10^12 so the security of an 8-alphanumeric HOTP code is significantly better than a 9-digit HOTP value.
32^8>10^12，因此8位字母数字的HOTP代码的安全性明显优于9位数字的HOTP值。
Depending on the application and token/interface used for displaying and entering the HOTP value, the choice of alphanumeric values could be a simple and efficient way to improve security at a reduced cost and impact on users.
根据用于显示和输入HOTP值的应用程序和令牌/接口，字母数字值的选择可能是一种简单而有效的方法，以降低成本和对用户的影响来提高安全性。
As we suggested for the resynchronization to enter a short sequence (say, 2 or 3) of HOTP values, we could generalize the concept to the protocol, and add a parameter L that would define the length of the HOTP sequence to enter.
正如我们建议重新同步输入一个短的HOTP值序列（例如，2或3），我们可以将这个概念推广到协议中，并添加一个参数L来定义要输入的HOTP序列的长度。
Per default, the value L SHOULD be set to 1, but if security needs to be increased, users might be asked (possibly for a short period of time, or a specific operation) to enter L HOTP values.
默认情况下，值L应设置为1，但如果需要提高安全性，则可能会要求用户（可能在短时间内或特定操作）输入L HOTP值。
This is another way, without increasing the HOTP length or using alphanumeric values to tighten security.
这是另一种方法，不增加HOTP长度或使用字母数字值来加强安全性。
Note: The system MAY also be programmed to request synchronization on a regular basis (e.g., every night, twice a week, etc.) and to achieve this purpose, ask for a sequence of L HOTP values.
注：系统也可编程为定期（例如，每晚、每周两次等）请求同步，并为实现此目的，请求L HOTP值序列。
In this case, we assume that the client can access and send not only the HOTP value but also other information, more specifically, the counter value.
在这种情况下，我们假设客户端不仅可以访问和发送HOTP值，还可以访问和发送其他信息，更具体地说，是计数器值。
A more efficient and secure method for resynchronization is possible in this case. The client application will not send the HOTP-client value only, but the HOTP-client and the related C-client counter value, the HOTP value acting as a message authentication code of the counter.
在这种情况下，一种更有效、更安全的重新同步方法是可能的。客户端应用程序不会只发送HOTP客户端值，而是发送HOTP客户端和相关的C客户端计数器值，HOTP值充当计数器的消息身份验证代码。
Resynchronization Counter-based Protocol (RCP)
----------------------------------------------
Resynchronization Counter-based Protocol (RCP)
----------------------------------------------
The server accepts if the following are all true, where C-server is its own current counter value:
如果以下各项均为真，则服务器接受，其中C-server是其自身的当前计数器值：
1) C-client >= C-server
2) C-client - C-server <= s
3) Check that HOTP client is valid HOTP(K,C-Client)
4) If true, the server sets C to C-client + 1 and client is
authenticated
1) C-client >= C-server
2) C-client - C-server <= s
3) Check that HOTP client is valid HOTP(K,C-Client)
4) If true, the server sets C to C-client + 1 and client is
authenticated
In this case, there is no need for managing a look-ahead window anymore. The probability of success of the adversary is only v/10^6 or roughly v in one million. A side benefit is obviously to be able to increase s "infinitely" and therefore improve the system usability without impacting the security.
在这种情况下，不再需要管理前瞻窗口。对手成功的概率只有百万分之五或大约百万分之五。一个明显的副作用是能够“无限”地增加s，从而在不影响安全性的情况下提高系统可用性。
This resynchronization protocol SHOULD be used whenever the related impact on the client and server applications is deemed acceptable.
只要对客户端和服务器应用程序的相关影响被认为是可接受的，就应该使用此重新同步协议。
Another interesting option is the introduction of a Data field, which would be used for generating the One-Time Password values: HOTP (K, C, [Data]) where Data is an optional field that can be the concatenation of various pieces of identity-related information, e.g., Data = Address | PIN.
另一个有趣的选项是引入一个数据字段，用于生成一次性密码值：HOTP（K，C，[Data]），其中数据是一个可选字段，可以是各种身份相关信息的串联，例如，Data=Address | PIN。
We could also use a Timer, either as the only moving factor or in combination with the Counter -- in this case, e.g., Data = Timer, where Timer could be the UNIX-time (GMT seconds since 1/1/1970) divided by some factor (8, 16, 32, etc.) in order to give a specific time step. The time window for the One-Time Password is then equal to the time step multiplied by the resynchronization parameter as defined before. For example, if we take 64 seconds as the time step and 7 for the resynchronization parameter, we obtain an acceptance window of +/- 3 minutes.
我们还可以使用计时器，作为唯一的移动因子，或者与计数器结合使用——在本例中，例如Data=Timer，其中Timer可以是UNIX时间（自1970年1月1日以来的GMT秒）除以某个因子（8、16、32等），以给出特定的时间步长。一次性密码的时间窗口等于时间步长乘以前面定义的重新同步参数。例如，如果我们将64秒作为时间步长，将7秒作为重新同步参数，我们将获得+/-3分钟的接受窗口。
Using a Data field opens for more flexibility in the algorithm implementation, provided that the Data field is clearly specified.
如果明确指定了数据字段，那么使用数据字段将使算法实现更加灵活。
Authors' Addresses
作者地址
David M'Raihi (primary contact for sending comments and questions) VeriSign, Inc. 685 E. Middlefield Road Mountain View, CA 94043 USA
David M'Raihi（发送评论和问题的主要联系人）VeriSign，Inc.美国加利福尼亚州米德尔菲尔德路山景大道东685号，邮编94043
Phone: 1-650-426-3832 EMail: dmraihi@verisign.com
电话：1-650-426-3832电子邮件：dmraihi@verisign.com
Mihir Bellare Dept of Computer Science and Engineering, Mail Code 0114 University of California at San Diego 9500 Gilman Drive La Jolla, CA 92093, USA
加州大学圣地亚哥分校计算机科学与工程系MiHr Belaye，邮编0114，加州大学圣地亚哥分校，美国吉尔曼，拉卡，92093，92093
EMail: mihir@cs.ucsd.edu
EMail: mihir@cs.ucsd.edu
Frank Hoornaert VASCO Data Security, Inc. Koningin Astridlaan 164 1780 Wemmel, Belgium
Frank Hoornaert VASCO Data Security，Inc.科宁阿斯特里兰164 1780比利时韦梅尔
EMail: frh@vasco.com
EMail: frh@vasco.com
David Naccache Gemplus Innovation 34 rue Guynemer, 92447, Issy les Moulineaux, France and Information Security Group, Royal Holloway, University of London, Egham, Surrey TW20 0EX, UK
David Naccache Gemplus创新34 Guyimer-Roue，92447，Issy les Moulineaux，法国和信息安全小组，Royal Holloway，伦敦大学，埃格姆，Surry TW200EX，英国
EMail: david.naccache@gemplus.com, david.naccache@rhul.ac.uk
EMail: david.naccache@gemplus.com, david.naccache@rhul.ac.uk
Ohad Ranen Aladdin Knowledge Systems Ltd. 15 Beit Oved Street Tel Aviv, Israel 61110
Ohad Ranen Aladdin知识系统有限公司，以色列特拉维夫贝特奥维德街15号，61110
EMail: Ohad.Ranen@ealaddin.com
EMail: Ohad.Ranen@ealaddin.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。