< draft-mraihi-oath-hmac-otp-01.txt   draft-mraihi-oath-hmac-otp-02.txt >
Internet Draft D. M'Raihi Internet Draft D. M'Raihi
Category: Informational Verisign Category: Informational VeriSign
Document: draft-mraihi-oath-hmac-otp-01.txt M. Bellare Document: draft-mraihi-oath-hmac-otp-02.txt M. Bellare
Expires: April 2005 UCSD Expires: April 2005 UCSD
F. Hoornaert F. Hoornaert
Vasco Vasco
D. Naccache D. Naccache
Gemplus Gemplus
O. Ranen O. Ranen
Aladdin Aladdin
October 2004 October 2004
HOTP: An HMAC-based One Time Password Algorithm HOTP: An HMAC-based One Time Password Algorithm
skipping to change at page 1, line 32 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than a "work in as reference material or to cite them other than a "work in
progress." progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This document describes an algorithm to generate one-time password This document describes an algorithm to generate one-time password
values, based on HMAC [BCK1]. A security analysis of the algorithm values, based on HMAC [BCK1]. A security analysis of the algorithm
skipping to change at page 2, line 12 skipping to change at page 2, line 12
membership to specify an algorithm that can be freely distributed membership to specify an algorithm that can be freely distributed
to the technical community. The authors believe that a common and to the technical community. The authors believe that a common and
HOTP: An HMAC-based One Time Password Algorithm October 2004 HOTP: An HMAC-based One Time Password Algorithm October 2004
shared algorithm will facilitate adoption of two-factor shared algorithm will facilitate adoption of two-factor
authentication on the Internet by enabling interoperability across authentication on the Internet by enabling interoperability across
commercial and open-source implementations. commercial and open-source implementations.
Table of Contents Table of Contents
1. Overview...................................................2 1. Overview......................................................2
2. Introduction...............................................3 2. Introduction................................................3
3. Requirements Terminology...................................4 3. Requirements Terminology....................................4
4. Algorithm Requirements.....................................4 4. Algorithm Requirements......................................4
5. HOTP Algorithm.............................................5 5. HOTP Algorithm..............................................5
5.1 Notation and Symbols.....................................5 5.1 Notation and Symbols........................................5
5.2 Description..............................................6 5.2 Description.................................................6
5.3 Generating an HOTP value.................................6 5.3 Generating an HOTP value....................................6
5.4 Example of HOTP computation for Digit = 6................7 5.4 Example of HOTP computation for Digit = 6...................7
6. Security and Deployment Considerations.....................8 6. Security and Deployment Considerations......................8
6.1 Authentication Protocol Requirements.....................8 6.1 Authentication Protocol Requirements........................8
6.2 Validation of HOTP values................................8 6.2 Validation of HOTP values...................................8
6.3 Throttling at the server.................................9 6.3 Throttling at the server....................................9
6.4 Resynchronization of the counter.........................9 6.4 Resynchronization of the counter............................9
7. HOTP Algorithm Security: Overview.........................10 7. HOTP Algorithm Security: Overview..........................10
8. Protocol Extensions and Improvements......................10 8. Protocol Extensions and Improvements.........................11
8.1 Number of Digits........................................11 8.1 Number of Digits...........................................11
8.2 Alpha-numeric Values....................................11 8.2 Alpha-numeric Values.......................................11
8.3 Sequence of HOTP values.................................11 8.3 Sequence of HOTP values....................................11
8.4 A Counter-based Re-Synchronization Method...............12 8.4 A Counter-based Re-Synchronization Method..................12
9. Conclusion................................................12 9. Conclusion.................................................12
10. Acknowledgements..........................................13 10. Acknowledgements...........................................13
11. Contributors..............................................13 11. Contributors...............................................13
12. References................................................13 12. References.................................................13
12.1 Normative...............................................13 12.1 Normative................................................13
12.2 Informative.............................................13 12.2 Informative..............................................13
13. Authors' Addresses........................................13 13. Authors' Addresses.........................................14
Appendix - HOTP Algorithm Security: Detailed Analysis..........14 Appendix A - HOTP Algorithm Security: Detailed Analysis.........14
A.1 Definitions and Notations.................................15 A.1 Definitions and Notations...................................15
A.2 The idealized algorithm: HOTP-IDEAL.......................15 A.2 The idealized algorithm: HOTP-IDEAL.........................15
A.3 Model of Security.........................................15 A.3 Model of Security...........................................15
A.4 Security of the ideal authentication algorithm............17 A.4 Security of the ideal authentication algorithm..............17
A.4.1 From bits to digits.....................................17 A.4.1 From bits to digits.......................................17
A.4.2 Brute force attacks.....................................18 A.4.2 Brute force attacks.......................................18
A.4.3 Brute force attacks are the best possible attacks.......19 A.4.3 Brute force attacks are the best possible attacks.........19
A.5 Security Analysis of HOTP.................................20 A.5 Security Analysis of HOTP...................................20
Appendix B - HOTP Algorithm: Reference Implementation...........22
Appendix C - HOTP Algorithm: Test Values........................26
1. Overview 1. Overview
The document introduces first the context around the HOTP The document introduces first the context around the HOTP
algorithm. In section 4, the algorithm requirements are listed and 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
HOTP: An HMAC-based One Time Password Algorithm October 2004 HOTP: An HMAC-based One Time Password Algorithm October 2004
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 9 concludes this document. The and improvements, and Section 9 concludes this document. The
interested reader will find in the Appendix a detailed, full-fledge interested reader will find in the Appendix a detailed, full-fledge
analysis of the algorithm security: an idealized version of the analysis of the algorithm security: an idealized version of the
algorithm is evaluated, and then the HOTP algorithm security is algorithm is evaluated, and then the HOTP algorithm security is
analyzed. analyzed.
2. Introduction 2. Introduction
Today, deployment of two-factor authentication remains extremely Today, deployment of two-factor authentication remains extremely
limited in scope and scale. Despite increasingly higher levels of limited in scope and scale. Despite increasingly higher levels of
skipping to change at page 4, line 53 skipping to change at page 5, line 5
MUST work with tokens that do not supports any numeric input, but MUST work with tokens that do not supports any numeric input, but
MAY also be used with more sophisticated devices such as secure MAY also be used with more sophisticated devices such as secure
PIN-pads. PIN-pads.
R3 - The value displayed on the token MUST be easily read and R3 - The value displayed on the token MUST be easily read and
entered by the user: This requires the HOTP value to be of entered by the user: This requires the HOTP value to be of
reasonable length. The HOTP value must be at least a 6-digit value. reasonable length. 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 is also desirable that the HOTP value be 'numeric only' so that
it can be easily entered on restricted devices such as phones. it can be easily entered on restricted devices such as phones.
HOTP: An HMAC-based One Time Password Algorithm October 2004
R4 - There MUST be user-friendly mechanisms available to R4 - There MUST be user-friendly mechanisms available to
resynchronize the counter. The sections 6.4 and 8.4 detail the resynchronize the counter. The sections 6.4 and 8.4 detail the
resynchronization mechanism proposed in this draft. resynchronization mechanism proposed in this draft.
HOTP: An HMAC-based One Time Password Algorithm October 2004
R5 - The algorithm MUST use a strong shared secret. The length of R5 - The algorithm MUST use a strong shared secret. The length of
the shared secret MUST be at least 128 bits. This draft RECOMMENDs the shared secret MUST be at least 128 bits. This draft RECOMMENDs
a shared secret length of 160 bits. a shared secret length of 160 bits.
5. HOTP Algorithm 5. HOTP Algorithm
In this section, we introduce the notation and describe the HOTP In this section, we introduce the notation and describe the HOTP
algorithm basic blocks - the base function to compute an HMAC-SHA-1 algorithm basic blocks - the base function to compute an HMAC-SHA-1
value and the truncation method to extract an HOTP value. value and the truncation method to extract an HOTP value.
skipping to change at page 5, line 38 skipping to change at page 5, line 42
of s. of s.
Let StToNum (String to Number) denote the function which as input a Let StToNum (String to Number) denote the function which as input a
string s returns the number whose binary representation is s. string s returns the number whose binary representation is s.
(For example StToNum(110) = 6). (For example StToNum(110) = 6).
Here is a list of symbols used in this document. Here is a list of symbols used in this document.
Symbol Represents Symbol Represents
------------------------------------------------------------------- -------------------------------------------------------------------
C 8-byte (Little Endian) counter value, which is C 8-byte counter value, the moving factor. This counter
The moving factor. This counter MUST be synchronized MUST be synchronized between the HOTP generator (client)
between the HOTP generator (client) and the and the HOTP validator (server);
HOTP validator (server);
K shared secret between client and server; each HOTP K shared secret between client and server; each HOTP
generator has a different and unique secret K; generator has a different and unique secret K;
T throttling parameter: the server will refuse connections T throttling parameter: the server will refuse connections
from a user after T unsuccessful authentication attempts; from a user after T unsuccessful authentication attempts;
s resynchronization parameter: the server will attempt to s resynchronization parameter: the server will attempt to
verify a received authenticator across s consecutive verify a received authenticator across s consecutive
counter values; counter values;
HOTP: An HMAC-based One Time Password Algorithm October 2004
Digit number of digits in an HOTP value; system parameter. Digit number of digits in an HOTP value; system parameter.
HOTP: An HMAC-based One Time Password Algorithm October 2004
5.2 Description 5.2 Description
The HOTP algorithm is based on an increasing counter value and a The HOTP algorithm is based on an increasing counter value and a
static symmetric key known only to the token and the validation static symmetric key known only to the token and the validation
service. In order to create the HOTP value, we will use the service. In order to create the HOTP value, we will use the
HMAC-SHA-1 algorithm, as defined in RFC 2104 [BCK2]. HMAC-SHA-1 algorithm, as defined in RFC 2104 [BCK2].
As the output of the HMAC-SHA1 calculation is 160 bits, we must As the output of the HMAC-SHA1 calculation is 160 bits, we must
truncate this value to something that can be easily entered by a truncate this value to something that can be easily entered by a
user. user.
HOTP(K,C) = Truncate(HMAC-SHA-1(K,C)) HOTP(K,C) = Truncate(HMAC-SHA-1(K,C))
Where: Where:
- Truncate represents the function that converts an HMAC-SHA-1 - Truncate represents the function that converts an HMAC-SHA-1
value into an HOTP value as defined in Section 5.3. value into an HOTP value as defined in Section 5.3.
The Key (K) and the Counter (C) values are hashed high-order byte
first.
The HOTP values generated by the HOTP generator are treated as big The HOTP values generated by the HOTP generator are treated as big
endian. endian.
5.3 Generating an HOTP value 5.3 Generating an HOTP value
We can describe the operations in 3 distinct steps: We can describe the operations in 3 distinct steps:
Step 1: Generate an HMAC-SHA-1 value Step 1: Generate an HMAC-SHA-1 value
Let HS = HMAC-SHA-1(K,C) // HS is a 20 byte string Let HS = HMAC-SHA-1(K,C) // HS is a 20 byte string
skipping to change at page 6, line 50 skipping to change at page 7, line 4
0...2^{31}-1 0...2^{31}-1
Return D = Snum mod 10^Digit // D is a number in the range Return D = Snum mod 10^Digit // D is a number in the range
0...10^{Digit}-1 0...10^{Digit}-1
The Truncate function performs Step 2 and Step 3, i.e. the dynamic The Truncate function performs Step 2 and Step 3, i.e. the dynamic
truncation and then the reduction modulo 10^Digit. The purpose of truncation and then the reduction modulo 10^Digit. The purpose of
the dynamic offset truncation technique is to extract a 4-byte the dynamic offset truncation technique is to extract a 4-byte
dynamic binary code from a 160-bit (20-byte) HMAC-SHA1 result. dynamic binary code from a 160-bit (20-byte) HMAC-SHA1 result.
DT(String) // String = String[0]...String[19] DT(String) // String = String[0]...String[19]
HOTP: An HMAC-based One Time Password Algorithm October 2004
Let OffsetBits be the low order four bits of String[19] Let OffsetBits be the low order four bits of String[19]
Offset = StToNum(OffSetBits) // 0 <= OffSet <= 15 Offset = StToNum(OffSetBits) // 0 <= OffSet <= 15
Let P = String[OffSet]...String[OffSet+3] Let P = String[OffSet]...String[OffSet+3]
Return the Last 31 bits of P Return the Last 31 bits of P
HOTP: An HMAC-based One Time Password Algorithm October 2004
The reason for masking the most significant bit of P is to avoid The reason for masking the most significant bit of P is to avoid
confusion about signed vs. unsigned modulo computations. Different confusion about signed vs. unsigned modulo computations. Different
processors perform these operations differently, and masking out processors perform these operations differently, and masking out
the signed bit removes all ambiguity. the signed bit removes all ambiguity.
Implementations MUST extract a 6-digit code at a minimum and Implementations MUST extract a 6-digit code at a minimum and
possibly 7 and 8-digit code. Depending on security requirements, possibly 7 and 8-digit code. Depending on security requirements,
Digit = 7 or more SHOULD be considered in order to extract a longer Digit = 7 or more SHOULD be considered in order to extract a longer
HOTP value. HOTP value.
skipping to change at page 7, line 49 skipping to change at page 8, line 4
| Byte Value | | Byte Value |
------------------------------------------------------------- -------------------------------------------------------------
|1f|86|98|69|0e|02|ca|16|61|85|50|ef|7f|19|da|8e|94|5b|55|5a| |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 last byte (byte 19) has the hex value 0x5a.
* The value of the lower four bits is 0xa (the offset value). * The value of the lower four bits is 0xa (the offset value).
* The offset value is byte 10 (0xa). * The offset value is byte 10 (0xa).
* The value of the 4 bytes starting at byte 10 is 0x50ef7f19, * The value of the 4 bytes starting at byte 10 is 0x50ef7f19,
which is the dynamic binary code DBC1 which is the dynamic binary code DBC1
HOTP: An HMAC-based One Time Password Algorithm October 2004
* The MSB of DBC1 is 0x50 so DBC2 = DBC1 = 0x50ef7f19 * The MSB of DBC1 is 0x50 so DBC2 = DBC1 = 0x50ef7f19
* HOTP = DBC2 modulo 10^6 = 872921. * HOTP = DBC2 modulo 10^6 = 872921.
We treat the dynamic binary code as a 31-bit, unsigned, big-endian We treat the dynamic binary code as a 31-bit, unsigned, big-endian
integer; the first byte is masked with a 0x7f. integer; the first byte is masked with a 0x7f.
HOTP: An HMAC-based One Time Password Algorithm October 2004
We then take this number modulo 1,000,000 (10^6) to generate the We then take this number modulo 1,000,000 (10^6) to generate the
6-digit HOTP value 872921 decimal. 6-digit HOTP value 872921 decimal.
6. Security and Deployment Considerations 6. Security and Deployment Considerations
Any One-Time Password algorithm is only as secure as the Any One-Time Password algorithm is only as secure as the
application and the authentication protocols that implement it. application and the authentication protocols that implement it.
Therefore, this section discusses the critical security Therefore, this section discusses the critical security
requirements that our choice of algorithm imposes on the requirements that our choice of algorithm imposes on the
authentication protocol and validation software. The parameters T authentication protocol and validation software. The parameters T
skipping to change at page 8, line 50 skipping to change at page 9, line 5
network (privacy, replay attacks, etc.) network (privacy, replay attacks, etc.)
6.2 Validation of HOTP values 6.2 Validation of HOTP values
The HOTP client (hardware or software token) increments its counter The HOTP client (hardware or software token) increments its counter
and then calculates the next HOTP value HOTP-client. If the value and then calculates the next HOTP value HOTP-client. If the value
received by the authentication server matches the value calculated received by the authentication server matches the value calculated
by the client, then the HOTP value is validated. In this case, the by the client, then the HOTP value is validated. In this case, the
server increments the counter value by one. server increments the counter value by one.
HOTP: An HMAC-based One Time Password Algorithm October 2004
If the value received by the server does not match the value If the value received by the server does not match the value
calculated by the client, the server initiate the resynch protocol calculated by the client, the server initiate the resynch protocol
(look-ahead window) before it requests another pass. (look-ahead window) before it requests another pass.
HOTP: An HMAC-based One Time Password Algorithm October 2004
If the resynch fails, the server asks then for another If the resynch fails, the server asks then for another
authentication pass of the protocol to take place, until the authentication pass of the protocol to take place, until the
maximum number of authorized attempts is reached. maximum number of authorized attempts is reached.
If and when 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 the server SHOULD lock out the account and initiate a procedure to
inform the user. inform the user.
6.3 Throttling at the server 6.3 Throttling at the server
skipping to change at page 9, line 50 skipping to change at page 10, line 5
server can recalculate the next s HOTP-server values, and check server can recalculate the next s HOTP-server values, and check
them against the received HOTP-client. them against the received HOTP-client.
Synchronization of counters in this scenario simply requires the Synchronization of counters in this scenario simply requires the
server to calculate the next HOTP values and determine if there is server to calculate the next HOTP values and determine if there is
a match. Optionally, the system MAY require the user to send a a match. Optionally, the system MAY require the user to send a
sequence of (say 2, 3) HOTP values for resynchronization purpose, sequence of (say 2, 3) HOTP values for resynchronization purpose,
since forging a sequence of consecutive HOTP values is even more since forging a sequence of consecutive HOTP values is even more
difficult than guessing a single HOTP value. difficult than guessing a single HOTP value.
HOTP: An HMAC-based One Time Password Algorithm October 2004
The upper bound set by the parameter s ensures the server does not The upper bound set by the parameter s ensures the server does not
go on checking HOTP values forever (causing a DoS attack) and also go on checking HOTP values forever (causing a DoS attack) and also
restricts the space of possible solutions for an attacker trying to restricts the space of possible solutions for an attacker trying to
manufacture HOTP values. s SHOULD be set as low as possible, while manufacture HOTP values. s SHOULD be set as low as possible, while
still ensuring usability is not impacted. still ensuring usability is not impacted.
HOTP: An HMAC-based One Time Password Algorithm October 2004
7. HOTP Algorithm Security: Overview 7. HOTP Algorithm Security: Overview
The conclusion of the security analysis detailed in the Appendix The conclusion of the security analysis detailed in the Appendix
section is that, for all practical purposes, the outputs of the section is that, for all practical purposes, the outputs of the
dynamic truncation (DT) on distinct counter inputs are uniformly dynamic truncation (DT) on distinct counter inputs are uniformly
and independently distributed 31-bit strings. and independently distributed 31-bit strings.
The security analysis then details the impact of the conversion The security analysis then details the impact of the conversion
from a string to an integer and the final reduction modulo 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, where Digit is the number of digits in an HOTP value.
skipping to change at page 10, line 50 skipping to change at page 11, line 5
- Sec is the probability of success of the adversary - Sec is the probability of success of the adversary
- s stands for the look-ahead synchronization window size; - s stands for the look-ahead synchronization window size;
- v stands for the number of verification attempts; - v stands for the number of verification attempts;
- Digit stands for the number of digits in HOTP values. - Digit stands for the number of digits in HOTP values.
Obviously, we can play with s, T (the Throttling parameter that Obviously, we can play with s, T (the Throttling parameter that
would limit the number of attempts by an attacker) and Digit until would limit the number of attempts by an attacker) and Digit until
achieving a certain level of security, still preserving the system achieving a certain level of security, still preserving the system
usability. usability.
HOTP: An HMAC-based One Time Password Algorithm October 2004
8. Protocol Extensions and Improvements 8. Protocol Extensions and Improvements
We introduce in this section several enhancements and suggestions We introduce in this section several enhancements and suggestions
to further improve the security of the algorithm HOTP to further improve the security of the algorithm HOTP
HOTP: An HMAC-based One Time Password Algorithm October 2004
8.1 Number of Digits 8.1 Number of Digits
A simple enhancement in terms of security would be to extract more A simple enhancement in terms of security would be to extract more
digits from the HMAC-SHA1 value. digits from the HMAC-SHA1 value.
For instance, calculating the HOTP value modulo 10^8 to build an For instance, calculating the HOTP value modulo 10^8 to build an
8-digit HOTP value would reduce the probability of success of the 8-digit HOTP value would reduce the probability of success of the
adversary from sv/10^6 to sv/10^8. adversary from sv/10^6 to sv/10^8.
skipping to change at page 11, line 50 skipping to change at page 12, line 5
values could be a simple and efficient way to improve security at a values could be a simple and efficient way to improve security at a
reduced cost and impact on users. reduced cost and impact on users.
8.3 Sequence of HOTP values 8.3 Sequence of HOTP values
As we suggested for the resynchronization to enter a short sequence 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 (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 protocol, and add a parameter L that would define the length of the
HOTP sequence to enter. HOTP sequence to enter.
HOTP: An HMAC-based One Time Password Algorithm October 2004
Per default, the value L SHOULD be set to 1, but if security needs 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 to be increased, users might be asked (possibly for a short period
of time, or a specific operation) to enter L HOTP values. of time, or a specific operation) to enter L HOTP values.
HOTP: An HMAC-based One Time Password Algorithm October 2004
This is another way, without increasing the HOTP length or using This is another way, without increasing the HOTP length or using
alphanumeric values to tighten security. alphanumeric values to tighten security.
Note: The system MAY also be programmed to request synchronization Note: The system MAY also be programmed to request synchronization
on a regular basis (e.g. every night, or twice a week, etc.) and to on a regular basis (e.g. every night, or twice a week, etc.) and to
achieve this purpose, ask for a sequence of L HOTP values. achieve this purpose, ask for a sequence of L HOTP values.
8.4 A Counter-based Re-Synchronization Method 8.4 A Counter-based Re-Synchronization Method
In this case, we assume that the client can access and send not In this case, we assume that the client can access and send not
skipping to change at page 12, line 53 skipping to change at page 13, line 5
This resynchronization protocol SHOULD be use whenever the related This resynchronization protocol SHOULD be use whenever the related
impact on the client and server applications is deemed acceptable. impact on the client and server applications is deemed acceptable.
9. Conclusion 9. Conclusion
This draft describes HOTP, a HMAC-based One-Time Password This draft describes HOTP, a HMAC-based One-Time Password
algorithm. It also recommends the preferred implementation and algorithm. It also recommends the preferred implementation and
related modes of operations for deploying the algorithm. related modes of operations for deploying the algorithm.
The draft also exhibits elements of security and demonstrates that
the HOTP algorithm is practical and sound, the best possible attack
HOTP: An HMAC-based One Time Password Algorithm October 2004 HOTP: An HMAC-based One Time Password Algorithm October 2004
The draft 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 being a brute force attack that can be prevented by careful
implementation of countermeasures in the validation server. implementation of countermeasures in the validation server.
Eventually, several enhancements have been proposed, in order to Eventually, several enhancements have been proposed, in order to
improve security if needed for specific applications. improve security if needed for specific applications.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Siddharth Bajaj, Alex Deacon and The authors would like to thank Siddharth Bajaj, Alex Deacon, Loren
Nico Popp for their help during the conception and redaction of Hart and Nico Popp for their help during the conception and
this document. redaction of this document.
11. Contributors 11. Contributors
The authors of this draft would like to emphasize the role of two The authors of this draft would like to emphasize the role of two
persons who have made a key contribution to this document: persons who have made a key contribution to this document:
- Laszlo Elteto is system architect with SafeNet, Inc. - Laszlo Elteto is system architect with SafeNet, Inc.
- Ernesto Frutos is director of Engineering with Authenex, Inc. - Ernesto Frutos is director of Engineering with Authenex, Inc.
skipping to change at page 13, line 52 skipping to change at page 14, line 4
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3668] Bradner, S., "Intellectual Propery Rights in IETF [RFC3668] Bradner, S., "Intellectual Propery Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
12.2 Informative 12.2 Informative
[OATH] www.openauthentication.org, Initiative for Open [OATH] www.openauthentication.org, Initiative for Open
AuTHentication AuTHentication
HOTP: An HMAC-based One Time Password Algorithm October 2004
13. Authors' Addresses 13. Authors' Addresses
HOTP: An HMAC-based One Time Password Algorithm October 2004
Primary point of contact (for sending comments and question): Primary point of contact (for sending comments and question):
David M'Raihi David M'Raihi
VeriSign, Inc. VeriSign, Inc.
685 E. Middlefield Road Phone: 1-650-426-3832 685 E. Middlefield Road Phone: 1-650-426-3832
Mountain View, CA 94043 USA Email: dmraihi@verisign.com Mountain View, CA 94043 USA Email: dmraihi@verisign.com
Other Authors' contact information: Other Authors' contact information:
skipping to change at page 14, line 41 skipping to change at page 14, line 43
Information Security Group, Information Security Group,
Royal Holloway, Royal Holloway,
University of London, Egham, University of London, Egham,
Surrey TW20 0EX, UK Email: david.naccache@rhul.ac.uk Surrey TW20 0EX, UK Email: david.naccache@rhul.ac.uk
Ohad Ranen Ohad Ranen
Aladdin Knowledge Systems Ltd. Aladdin Knowledge Systems Ltd.
15 Beit Oved Street 15 Beit Oved Street
Tel Aviv, Israel 61110 Email: Ohad.Ranen@ealaddin.com Tel Aviv, Israel 61110 Email: Ohad.Ranen@ealaddin.com
Appendix - HOTP Algorithm Security: Detailed Analysis Appendix A - HOTP Algorithm Security: Detailed Analysis
The security analysis of the HOTP algorithm is summarized in this The security analysis of the HOTP algorithm is summarized in this
section. We first detail the best attack strategies, and then section. We first detail the best attack strategies, and then
elaborate on the security under various assumptions, the impact of elaborate on the security under various assumptions, the impact of
the truncation and some recommendations regarding the number of the truncation and some recommendations regarding the number of
digits. digits.
HOTP: An HMAC-based One Time Password Algorithm October 2004
We focus this analysis on the case where Digit = 6, i.e. an 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 function that produces 6-digit values, which is the bare minimum
recommended in this draft. recommended in this draft.
HOTP: An HMAC-based One Time Password Algorithm October 2004
A.1 Definitions and Notations A.1 Definitions and Notations
We denote by {0,1}^l the set of all strings of length l. We denote by {0,1}^l the set of all strings of length l.
Let Z_{n} = {0,.., n - 1}. Let Z_{n} = {0,.., n - 1}.
Let IntDiv(a,b) denote the integer division algorithm that takes Let IntDiv(a,b) denote the integer division algorithm that takes
input integers a, b where a >= b >= 1 and returns integers (q,r) input integers a, b where a >= b >= 1 and returns integers (q,r)
the quotient and remainder, respectively, of the division of a by the quotient and remainder, respectively, of the division of a by
b. (Thus a = bq + r and 0 <= r < b.) b. (Thus a = bq + r and 0 <= r < b.)
skipping to change at page 15, line 51 skipping to change at page 16, line 4
idealized algorithm. idealized algorithm.
In analyzing the idealized algorithm, we are concentrating on In analyzing the idealized algorithm, we are concentrating on
assessing the quality of the design of the algorithm itself, assessing the quality of the design of the algorithm itself,
independently of HMAC-SHA-1. This is in fact the important issue. independently of HMAC-SHA-1. This is in fact the important issue.
A.3 Model of Security A.3 Model of Security
The model exhibits the type of threats or attacks that are being The model exhibits the type of threats or attacks that are being
considered and enables to asses the security of HOTP and considered and enables to asses the security of HOTP and
HOTP: An HMAC-based One Time Password Algorithm October 2004
HOTP-IDEAL. We denote ALG as either HOTP or HOTP-IDEAL for the HOTP-IDEAL. We denote ALG as either HOTP or HOTP-IDEAL for the
purpose of this security analysis. purpose of this security analysis.
The scenario we are considering is that a user and server share a 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 key K for ALG. Both maintain a counter C, initially zero, and the
HOTP: An HMAC-based One Time Password Algorithm October 2004
user authenticates itself by sending ALG(K,C) to the server. The user authenticates itself by sending ALG(K,C) to the server. The
latter accepts if this value is correct. latter accepts if this value is correct.
In order to protect against accidental increment of the user In order to protect against accidental increment of the user
counter, the server, upon receiving a value z, will accept as long 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 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 is the resynchronization parameter and C is the server counter. If
it accepts with some value of i, it then increments its counter to 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. i+ 1. If it does not accept, it does not change its counter value.
skipping to change at page 16, line 50 skipping to change at page 17, line 4
algorithm ALG: K x {0,1}^c --> R. algorithm ALG: K x {0,1}^c --> R.
Initializations - A key K is selected at random from K, a counter C 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. is initialized to 0, and the Boolean value win is set to false.
Game execution - Adversary B is provided with the two following Game execution - Adversary B is provided with the two following
oracles: oracles:
Oracle AuthO() Oracle AuthO()
O = ALG(K,C) O = ALG(K,C)
HOTP: An HMAC-based One Time Password Algorithm October 2004
C = C + 1 C = C + 1
Return O to B Return O to B
Oracle VerO() Oracle VerO()
i = C i = C
HOTP: An HMAC-based One Time Password Algorithm October 2004
While (i <= C + s - 1 and Win = FALSE) do While (i <= C + s - 1 and Win = FALSE) do
If O = ALG(K,i) then Win = TRUE; C = i + 1 If O = ALG(K,i) then Win = TRUE; C = i + 1
Else i = i + 1 Else i = i + 1
Return Win to B Return Win to B
AuthO() is the authenticator oracle and VerO() is the verification AuthO() is the authenticator oracle and VerO() is the verification
oracle. oracle.
Upon execution, B queries the two oracles at will. Let Adv(B) be 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 the probability that win gets set to true in the above game. This
skipping to change at page 17, line 49 skipping to change at page 18, line 4
Lemma 1 Lemma 1
Let N >= m >= 1 be integers, and let (q,r) = IntDiv(N,m). For z in Let N >= m >= 1 be integers, and let (q,r) = IntDiv(N,m). For z in
Z_{m} let: 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} Then for any z in Z_{m}
P_{N,m}(z) = (q + 1) / N if 0 <= z < r P_{N,m}(z) = (q + 1) / N if 0 <= z < r
HOTP: An HMAC-based One Time Password Algorithm October 2004
q / N if r <= z < m q / N if r <= z < m
Proof of Lemma 1 Proof of Lemma 1
Let the random variable X be uniformly distributed over Z_{N}. Let the random variable X be uniformly distributed over Z_{N}.
Then: Then:
HOTP: An HMAC-based One Time Password Algorithm October 2004
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 [X < mq] * Pr [X mod m = z| X < mq]
+ Pr [mq <= X < N] * Pr [X mod m = z| mq <= X < N] + Pr [mq <= X < N] * Pr [X mod m = z| mq <= X < N]
= mq/N * 1/m + = mq/N * 1/m +
(N - mq)/N * 1 / (N - mq) if 0 <= z < N - mq (N - mq)/N * 1 / (N - mq) if 0 <= z < N - mq
0 if N - mq <= z <= m 0 if N - mq <= z <= m
= q/N + = q/N +
skipping to change at page 18, line 49 skipping to change at page 19, line 5
However, as the Figure indicates, the bias is small and as we will However, as the Figure indicates, the bias is small and as we will
see later, negligible: the probabilities are very close to 10^-6. see later, negligible: the probabilities are very close to 10^-6.
A.4.2 Brute force attacks A.4.2 Brute force attacks
If the authenticator consisted of d random digits, then a brute If the authenticator consisted of d random digits, then a brute
force attack using v verification attempts would succeed with force attack using v verification attempts would succeed with
probability sv/10^Digit. probability sv/10^Digit.
HOTP: An HMAC-based One Time Password Algorithm October 2004
However, an adversary can exploit the bias in the outputs of HOTP- However, an adversary can exploit the bias in the outputs of HOTP-
IDEAL, predicted by Lemma 1, to mount a slightly better attack. IDEAL, predicted by Lemma 1, to mount a slightly better attack.
Namely, it makes authentication attempts with authenticators which Namely, it makes authentication attempts with authenticators which
are the most likely values, meaning the ones in the range 0,...,r - are the most likely values, meaning the ones in the range 0,...,r -
1, where (q,r) = IntDiv(2^31,10^Digit). 1, where (q,r) = IntDiv(2^31,10^Digit).
HOTP: An HMAC-based One Time Password Algorithm October 2004
The following specifies an adversary in our model of security that The following specifies an adversary in our model of security that
mounts the attack. It estimates the success probability as a mounts the attack. It estimates the success probability as a
function of the number of verification queries. function of the number of verification queries.
For simplicity, we assume the number of verification queries is at For simplicity, we assume the number of verification queries is at
most r. With N = 2^31 and m = 10^6 we have r = 483,648, and the 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 throttle value is certainly less than this, so this assumption is
not much of a restriction. not much of a restriction.
Proposition 1 Proposition 1
skipping to change at page 19, line 47 skipping to change at page 20, line 4
A.4.3 Brute force attacks are the best possible attacks A.4.3 Brute force attacks are the best possible attacks
A central question is whether there are attacks any better than the A central question is whether there are attacks any better than the
brute force one. In particular, the brute force attack did not brute force one. In particular, the brute force attack did not
attempt to collect authenticators sent by the user and try to attempt to collect authenticators sent by the user and try to
cryptanalyze them in an attempt to learn how to better construct cryptanalyze them in an attempt to learn how to better construct
authenticators. Would doing this help? Is there some way to "learn" authenticators. Would doing this help? Is there some way to "learn"
how to build authenticators that result in a higher success rate how to build authenticators that result in a higher success rate
than given by the brute-force attack? than given by the brute-force attack?
HOTP: An HMAC-based One Time Password Algorithm October 2004
The following says the answer to these questions is no. No matter 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 what strategy the adversary uses, and even if it sees, and tries to
exploit, the authenticators from authentication attempts of the exploit, the authenticators from authentication attempts of the
user, its success probability will not be above that of the brute user, its success probability will not be above that of the brute
force attack - this is true as long as the number of force attack - this is true as long as the number of
authentications it observes is not incredibly large. This is authentications it observes is not incredibly large. This is
valuable information regarding the security of the scheme. valuable information regarding the security of the scheme.
HOTP: An HMAC-based One Time Password Algorithm October 2004
Proposition 2 Proposition 2
Suppose m = 10^Digit < 2^31, and let (q,r) = IntDiv(2^31,m). Let B 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 be any adversary attacking HOTP-IDEAL using v verification oracle
queries and a <= 2^c - s authenticator oracle queries. Then 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 Note: This result is conditional on the adversary not seeing more
than 2^c - s authentications performed by the user, which is hardly than 2^c - s authentications performed by the user, which is hardly
restrictive as long as c is large enough. restrictive as long as c is large enough.
skipping to change at page 20, line 47 skipping to change at page 21, line 5
The assumption in question is that H is a secure pseudorandom The assumption in question is that H is a secure pseudorandom
function, or PRF, meaning that its input-output values are function, or PRF, meaning that its input-output values are
indistinguishable from those of a random function in practice. indistinguishable from those of a random function in practice.
Consider an adversary A that is given an oracle for a function f: 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) {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 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 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. case where its oracle is a random function of {0,1}^c to {0,1}^n.
HOTP: An HMAC-based One Time Password Algorithm October 2004
One possible attack is based on exhaustive search for the key K. If 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 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 computation of H, its prf-advantage from this attack turns out to
be (t/T)2^-k . Another possible attack is a birthday one [3], be (t/T)2^-k . Another possible attack is a birthday one [3],
whereby A can attain advantage p^2/2^n in p oracle queries and whereby A can attain advantage p^2/2^n in p oracle queries and
running time about pT. running time about pT.
HOTP: An HMAC-based One Time Password Algorithm October 2004
Our assumption is that these are the best possible attacks. This Our assumption is that these are the best possible attacks. This
translates into the following. translates into the following.
Assumption 1 Assumption 1
Let T denotes the time to perform one computation of H. Then if A 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 is any adversary with running time at most t and making at most p
oracle queries, oracle queries,
Adv(A) <= (t/T)/2^k + p^2/2^n Adv(A) <= (t/T)/2^k + p^2/2^n
skipping to change at page 21, line 48 skipping to change at page 22, line 5
adversary making v authentication attempts will have a success rate adversary making v authentication attempts will have a success rate
that is at most that of Equation 1. that is at most that of Equation 1.
For example, consider an adversary with running time at most 2^60 For example, consider an adversary with running time at most 2^60
that sees at most 2^40 authentication attempts of the user. Both that sees at most 2^40 authentication attempts of the user. Both
these choices are very generous to the adversary, who will these choices are very generous to the adversary, who will
typically not have these resources, but we are saying that even typically not have these resources, but we are saying that even
such a powerful adversary will not have more success than indicated such a powerful adversary will not have more success than indicated
by Equation 1. by Equation 1.
HOTP: An HMAC-based One Time Password Algorithm October 2004
We can safely assume sv <= 2^40 due to the throttling and bounds on We can safely assume sv <= 2^40 due to the throttling and bounds on
s. So: s. So:
(t/T)/2^k + ((sv + a)^2)/2^n <= 2^60/2^160 + (2^41)^2/2^160 (t/T)/2^k + ((sv + a)^2)/2^n <= 2^60/2^160 + (2^41)^2/2^160
roughly <= 2^-78 roughly <= 2^-78
which is much smaller than the success probability of Equation 1 which is much smaller than the success probability of Equation 1
and negligible compared to it. and negligible compared to it.
Appendix B - HOTP Algorithm: Reference Implementation
/*
* 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 EXPRESSELY 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;
import java.io.IOException;
import java.io.File;
import java.io.DataInputStream;
import java.io.FileInputStream ;
import java.lang.reflect.UndeclaredThrowableException;
HOTP: An HMAC-based One Time Password Algorithm October 2004
import java.security.GeneralSecurityException;
import java.security.NoSuchAlgorithmException;
import java.security.InvalidKeyException;
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-SHA1.
*
* @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 };
/**
* 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;
HOTP: An HMAC-based One Time Password Algorithm October 2004
}
return result;
}
/**
* This method uses the JCE to provide the HMAC-SHA1
* 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-SHA1 key
* @param text the message or text to be authenticated.
*
* @throws NoSuchAlgorithmException if no provider makes
* either HmacSHA1 or HMAC-SHA1
* digest algorithms available.
* @throws InvalidKeyException
* The secret provided was not a valid HMAC-SHA1 key.
*
*/
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-SHA1");
}
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};
/**
* This method generates an OTP value for the given
* set of parameters.
*
* @param secret the shared secret
HOTP: An HMAC-based One Time Password Algorithm October 2004
* @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-SHA1
* digest algorithms available.
* @throws InvalidKeyException
* The secret provided was not
* a valid HMAC-SHA1 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);
// put selected bytes into result int
int offset = hash[hash.length - 1] & 0xf;
if ( (0<=truncationOffset) &&
(truncationOffset<(hash.length-4)) ) {
offset = truncationOffset;
}
HOTP: An HMAC-based One Time Password Algorithm October 2004 HOTP: An HMAC-based One Time Password Algorithm October 2004
int binary =
((hash[offset] & 0x7f) << 24)
| ((hash[offset + 1] & 0xff) << 16)
| ((hash[offset + 2] & 0xff) << 8)
| (hash[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;
}
}
Appendix C - HOTP Algorithm: Test Values
The following test data uses the ASCII string
"123456787901234567890" for the secret:
Secret = 0x3132333435363738393031323334353637383930
Table 1 details for each count, the intermediate hmac value.
Count Hexadecimal HMAC-SHA1(secret, count)
0 cc93cf18508d94934c64b65d8ba7667fb7cde4b0
1 75a48a19d4cbe100644e8ac1397eea747a2d33ab
2 0bacb7fa082fef30782211938bc1c5e70416ff44
3 66c28227d03a2d5529262ff016a1e6ef76557ece
4 a904c900a64b35909874b33e61c5938a8e15ed1c
5 a37e783d7b7233c083d4f62926c7a25f238d0316
6 bc9cd28561042c83f219324d3c607256c03272ae
7 a4fb960c0bc06e1eabb804e5b397cdc4b45596fa
8 1b3c89f65e6c9e883012052823443f048b4332db
9 1637409809a679dc698207310c8c7fc07290d9e5
Table details for each count the truncated values (both in
hexadecimal and decimal) and then the HOTP value.
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
HOTP: An HMAC-based One Time Password Algorithm October 2004
5 33c083d4 868254676 254676
6 7256c032 1918287922 287922
7 4e5b397 82162583 162583
8 2823443f 673399871 399871
9 2679dc69 645520489 520489
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society 2004. This document is subject Copyright (C) The Internet Society 2004. This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
 End of changes. 49 change blocks. 
86 lines changed or deleted 343 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/