]>

marc.vieuille@polytechnique.org

Individual Submission Internet-Draft This document specifies EPHEMSEC, an algorithm for generating one-time passwords (OTPs) and one-time keys (OTKs). Unlike traditional OTP algorithms that rely solely on static shared secrets, EPHEMSEC uses public key cryptography, which simplifies secure deployment on authentication servers. EPHEMSEC also supports binding the generated OTP/OTK to contextual data. When this context is obtained and injected by a trusted agent, the resulting codes can be made resistant to phishing and man-in-the-middle attacks. Finally, EPHEMSEC includes a built-in time synchronization mechanism that embeds a synchronization hint into the generated output. This allows both parties to deterministically derive the same OTP/OTK value without requiring trial-and-error validation, enabling compatibility with protocols such as Password Authenticated Key Exchange (PAKE) and TLS with Pre-Shared Key (TLS-PSK) that require exact secret agreement.

Introduction The concept of one-time passwords has existed for decades. Proprietary systems such as RSA SecurID have been available since the early days of the Internet and have demonstrated the viability of time-based and event-based one-time passwords. HOTP (specified in ) and TOTP (specified in ) are open algorithms that enable the implementation of one-time password generators operating similarly to earlier proprietary systems. These algorithms now form the foundation of various hardware tokens and numerous smartphone authenticator applications that provide a second authentication factor for high-profile web applications. While OTP authenticator applications are simple to use and widely available, they have had limited impact on web application security. Two factors contribute to this limited success: Deployment of corresponding authentication servers introduces additional risks, as stored credentials can be used to impersonate users if compromised. This problem is particularly serious in today's cloud environments. The design of traditional authenticator applications does not address specific security challenges of web applications. In particular, modern web browsers do not provide a trusted input interface for entering authentication data, making users vulnerable to phishing attacks that capture credentials. These problems are the main reasons explaining the lack of attractiveness of one-time passwords for securing web applications. In the current technological ecosystem, one-time password solutions are seen as obsolete, and the current trend is toward using authentication credentials such as , which address problems 1 and 2 by relying on digital signature key pairs. The KerPass EPHEMSEC algorithm also addresses problems 1 and 2 but takes a meaningfully different approach than digital signatures. The EPHEMSEC client credential contains a Diffie-Hellman key pair, and the server stores only the public part of this key pair. To obtain a new OTP from EPHEMSEC, a trusted agent obtains the server's ephemeral public key and acquires context information such as the login page URL. This information is passed to the EPHEMSEC client (also known as the Responder; see ) in a challenge message. The client first calculates a Diffie-Hellman secret using the received public key and local key pair, then uses this ephemeral secret key to generate an OTP using an algorithm based on principles similar to the HOTP algorithm described in . This simplified description excludes many important details but should be sufficient to provide an understanding of how public key cryptography is used in EPHEMSEC. Assuming that both EPHEMSEC OTP and digital signature solutions like can solve the server credential storage issue described in problem 1 and the phishing issue described in problem 2 (by having their output depend upon context input provided by a trusted agent), are there differences between the two that could help determine which option is better in a specific context? One advantage that an OTP authenticator application has over a digital signature authenticator application is simpler integration, resulting from the smaller size of OTPs compared to digital signatures. Integration of smartphone interfaces such as NFC and Bluetooth to computing devices may eventually lessen this advantage, and EPHEMSEC can also generate one-time keys (OTK) that would benefit from the ubiquity of such interfaces. The main difference between OTP/OTK and digital signature credentials is that OTP/OTK are ephemeral shared secrets known by both peers involved in an authentication session, whereas digital signatures can only be generated by the peer controlling the private key. There are contexts such as transaction validation in which the one-way nature of digital signatures is an advantage. However, shared secrets have the distinctive advantage that they can be used as the main credential with protocols like Password Authenticated Key Exchange (PAKE) or TLS-PSK that enable mutual authentication of the peers involved in an authentication session. The potential to use EPHEMSEC OTP/OTK for mutual authentication is the distinctive feature of this solution. OTPs generated by HOTP/TOTP algorithms are also ephemeral shared secrets, but synchronization problems make their integration with PAKE protocols complex (see ). EPHEMSEC has a built-in auto-synchronization feature (see ) that addresses this issue. This document specifies the KerPass EPHEMSEC algorithm, which addresses the fundamental limitations of HOTP/TOTP that have contributed to the low attractivity of OTP authenticator applications for securing web applications. EPHEMSEC solves the server credential storage security problem by using credentials based on public key cryptography, provides a context binding mechanism that enables the generation of OTPs and OTKs resistant to phishing and man-in-the-middle attacks, and produces shared secrets that can be used with mutual authentication protocols such as PAKE and TLS-PSK. Given the ease of implementing OTP/OTK authenticator applications on smartphones, an OTP/OTK generation algorithm with properties similar to EPHEMSEC may be valuable across a wide range of use cases.

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Functions and Notation This section defines notation and helper functions used throughout the specification. ||: Denotes byte string concatenation. byte(v): Converts an integer or single-character input v to a one-byte string. size(bs): Returns the length of byte string bs, as an integer. BE8(v): Returns the 8-byte big-endian encoding of unsigned integer v. U64(bs): Converts an 8-byte string bs into an unsigned 64-bit integer, using big-endian interpretation. TLV(tag, bs): Constructs a Tag-Length-Value encoding. Returns byte(tag) || byte(size(bs)) || bs where: tag: An integer identifier in the range 0–255 bs: A byte string with length ≤ 255 bytes

EPHEMSEC Roles EPHEMSEC distinguishes two roles: Initiator & Responder.

Initiator Role This role is normally assigned to relying web application.

Responder Role This role is normally assigned to authenticator application.

EPHEMSEC Parametrization Each EPHEMSEC protocol instance is characterized by its selection of cryptographic primitives and operational parameters. These include: A secure hash function, An elliptic-curve Diffie-Hellman (ECDH) function, A key exchange pattern defining key contributions from the parties, Code output parameters specifying how the OTP/OTK values are formatted.

Hash Function The hash function MUST be cryptographically secure (e.g., SHA-512) with digest length between 32 and 64 bytes. . This hash function is used to instantiate the HKDF key derivation function, as specified in .

HKDF(salt, ikm, info, L) → byte[L] Function This function follows the specification in . salt, ikm, and info are arbitrary-length byte strings. L is a positive integer indicating the desired output length in bytes. The function returns a byte string of length L.

ECDH(privKey, PubKey) → byte[DHLEN] Function This function performs an Elliptic-Curve Diffie-Hellman (ECDH) key agreement over a specified elliptic curve group, producing a shared secret of fixed length DHLEN. privKey: A private key from an elliptic curve key pair. PubKey: A public key from the same elliptic curve group. The function computes a shared secret using the standard ECDH primitive associated with the curve in use. The result is a byte string of length DHLEN. The specific behavior, including internal encoding and validation, is determined by the curve and cryptographic library in use. An example of a suitable ECDH function is X25519, as defined in , which yields a 32-byte shared secret.

Key Exchange Pattern The key exchange pattern determines which types of keys (ephemeral or static) are contributed by the Initiator and Responder during the ECDH exchanges. Note that in each of the pattern below, the Initiator always contribute an ephemeral key and the Responder always contribute a static key.

E1S1 Pattern Initiator contributes: 1 ephemeral key. Responder contributes: 1 static key.

E1S2 Pattern Initiator contributes: 1 ephemeral key and 1 static key. Responder contributes: 1 static key.

E2S2 Pattern Initiator contributes: 1 ephemeral key and 1 static key. Responder contributes: 1 ephemeral key and 1 static key.

Rationale for Selecting a Key Exchange Pattern The choice of key exchange pattern should align with the authentication guarantees provided by the method used to validate the generated OTP or OTK. If the selected authentication method provides only one-way authentication—verifying the Responder to the Initiator—then there is no benefit in selecting a pattern more complex than E1S1. Patterns such as E1S2 or E2S2 introduce additional computational and communication overhead without improving the resulting security. If the authentication method provides mutual authentication—for example, using PAKE or TLS-PSK—then the use of E1S2 or E2S2 becomes appropriate. These patterns ensure that both the Initiator and the Responder contribute static keys to the Diffie-Hellman exchange, reinforcing the mutual nature of the derived secret.

Code Output The format and characteristics of the OTP/OTK values produced by EPHEMSEC are determined by the parameters T, B, and P.

T – Time Window T defines the duration of a validity window for each generated code, expressed in seconds. T MUST be a positive integer greater than parameter B.

B – Encoding Base B specifies the base used for code encoding. Valid values are: 10, 16, or 32: Encodes the output using a human-readable digit set, suitable for OTP. 256: Encodes the output in binary form, suitable for OTK.

P – Code Size P defines the number of digits in the generated code, where each digit is an integer in the range [0..B). The valid range of P depends on the encoding base B and the minimum required entropy. The table below summarizes the minimum and maximum allowed values of P for each supported base, along with the corresponding entropy range. Base min P max P min Entropy max Entropy 10 8 15 23 bits 46 bits 16 7 17 24 bits 64 bits 32 6 13 25 bits 60 bits 256 4 65 24 bits 512 bits

Naming Scheme EPHEMSEC uses a structured naming scheme to identify specific protocol instantiations. A valid EPHEMSEC name has the following format: Kerpass_<Hash>_<ECDH>_<Pattern>_T<T>B<B>P<P> For example: Kerpass_SHA512_X25519_E1S1_T600B32P9 Where: <Hash> corresponds to the hash function used (see ), e.g., SHA512. <ECDH> denotes the ECDH function used (see ), e.g., X25519. <Pattern> specifies the key exchange pattern (see ), e.g., E1S1. T<T>B<B>P<P> encodes the code output parameters (see ), with <T>, <B>, and <P> replaced by their respective values.

EPHEMSEC Credentials EPHEMSEC requires an enrollment phase during which the Responder (typically the authenticator app) registers an account with the Initiator (the relying web application). Implementations may support various enrollment scenarios depending on their operational context and security requirements. This specification does not define a particular enrollment protocol, but it assumes the following outcomes: The Responder registers a static ECDH public key with the Initiator, corresponding to a key pair it controls. Both parties derive and retain a shared secret (PSK) that will be used in subsequent EPHEMSEC operations.

Shared PSK The pre-shared key (PSK) is a byte string shared between the Responder and Initiator. It is established during the enrollment process and MUST be at least 32 bytes in length. The PSK is stored by both parties.

Responder Static Key During enrollment, the Responder generates a static ECDH key pair and transmits the corresponding public key to the Initiator. The Initiator stores this public key as part of the Responder’s account data.

Initiator Static Key The Initiator is required to maintain a static ECDH key pair only when using key exchange patterns that require an Initiator static key (e.g., E1S2 or E2S2). The mechanism by which the Responder obtains and establishes trust in the Initiator’s static public key is out of scope for this specification.

EPHEMSEC Protocol Overview This section outlines the overall flow of a complete EPHEMSEC OTP/OTK generation exchange between an Initiator and a Responder. It assumes the following preconditions: The two parties have agreed on an EPHEMSEC instantiation (see ). The Responder has registered an account with the Initiator, including a shared PSK and necessary public key material (see ). The protocol operates as a Challenge/Response exchange. The Initiator sends a message to the Responder containing: A CONTEXT byte string (e.g., relying party information), A freshly generated INONCE, Its Diffie-Hellman public key(s) as required by the selected key exchange pattern.

• Note: The structure and transport of this message are out of scope for this specification.

Upon receiving this challenge, the Responder performs the following steps to compute the OTP or OTK: Obtain nonces (see ): Read or receive INONCE from the Initiator, Generate PTIME and extract SYNCHINT. Compute the Diffie-Hellman shared secret Z (see ):
Based on the agreed key exchange pattern and available keys. Derive the intermediary secret ISK (see ):
Using HKDF with Z, PSK, CONTEXT, SCHEME, INONCE, and PTIME. Generate the OTP or OTK (see ): The format is determined by the encoding base B, The last digit or byte encodes SYNCHINT. The Responder returns the resulting code to the Initiator. The Initiator, upon receiving the response, uses the included SYNCHINT to reconstruct PTIME and repeat the same derivation steps to validate or use the resulting code.

Nonce Acquisition Each EPHEMSEC session uses two distinct nonces contributed independently by the two parties involved: The Initiator provides a nonce called INONCE, which ensures session uniqueness from the Initiator's side. The Responder provides a time-based nonce called PTIME, which captures the Responder’s local clock state. These nonces serve as independent inputs to the intermediary secret derivation process (see ).

INONCE – Initiator Nonce The Initiator generates a nonce INONCE that contributes to the personalization of the derived intermediary secret (see ). This value acts as an Initiator-specific input to ensure uniqueness of each EPHEMSEC execution. INONCE MUST be a byte string of length between 16 and 64 bytes. It MUST be unique for each run of the EPHEMSEC algorithm, and MUST NOT be reused across authentication sessions. The value of INONCE is transmitted from the Initiator to the Responder as part of the authentication request.

PTIME – Responder Time Nonce The EPHEMSEC Responder derives a pseudo-time value, PTIME, from current time reading. This PTIME acts as a Responder contributed nonce and is used in secret derivation along with an Initiator-contributed nonce. The challenge lies in enabling the Initiator to reconstruct the same PTIME value computed by the Responder, despite clock skew between the two parties. To address this, the Responder includes a synchronization hint, SYNCHINT, in the last digit of the generated OTP or OTK. Given SYNCHINT, the Initiator can recover the original PTIME as long as clock drift remains within acceptable bounds.

Inputs The following parameters are used throughout this section: time: Current Unix timestamp (seconds since 1970-01-01). T: Code validity window (see ). B: Encoding base (see ).

Responder Function – PTime(time) → (PTIME, SYNCHINT) This function is executed by the Responder to compute the PTIME nonce and the associated synchronization hint:

Initiator Function – SyncPTime(time, SYNCHINT) → PTIME This function is executed by the Initiator to reconstruct the Responder’s PTIME using its local time and the received SYNCHINT:

This algorithm works correctly if the clock difference between the Responder and Initiator is less than T / 2. Outside this range, synchronization will fail, resulting in mismatched secrets. KerPass uses a 600-second time window, allowing up to ±5 minutes clock drift in between Initiator and Responder.

Z - Diffie-Hellman Secret Derivation Each party derives a shared secret Z using the Diffie-Hellman key exchange, based on the agreed EPHEMSEC key exchange pattern (see ). Key material is retrieved from received protocol messages and account credential storage. The result of the Diffie-Hellman exchange is a byte string Z, which is used as part of the key derivation input (see later sections). Where ephemeral key pairs are used, they MUST be freshly generated for each execution of the EPHEMSEC protocol and MUST NOT be reused across sessions. EPHEMSEC execution MUST be aborted if any required key is missing or invalid.

Initiator E1S1 Z Derivation Inputs: ei Initiator ephemeral Keypair Sr Responder static PublicKey Z = ECDH(ei, Sr)

Responder E1S1 Z Derivation Inputs: - sr Responder static Keypair - Ei Initiator ephemeral PublicKey Z = ECDH(sr, Ei)

Initiator E1S2 Z Derivation Inputs: ei Initiator ephemeral Keypair si Initiator static Keypair Sr Responder static PublicKey Z = ECDH(ei, Sr) || ECDH(si, Sr)

Responder E1S2 Z Derivation Inputs: sr Responder static Keypair Ei Initiator ephemeral PublicKey Si Initiator static PublicKey Z = ECDH(sr, Ei) || ECDH(sr, Si)

Initiator E2S2 Z Derivation Inputs: ei Initiator ephemeral Keypair si Initiator static Keypair Er Responder ephemeral PublicKey Sr Responder static PublicKey Z = ECDH(ei, Er) || ECDH(si, Sr)

Responder E2S2 Z Derivation Inputs: er Responder ephemeral Keypair sr Responder static Keypair Ei Initiator ephemeral PublicKey Si Initiator static PublicKey Z = ECDH(er, Ei) || ECDH(sr, Si)

10. ISK – Intermediary Secret Derivation EPHEMSEC derives an intermediary secret key ISK using the HKDF function (see ).

10.1 Inputs The function uses the following inputs: CONTEXT: An implementation-specific byte string (≤ 64 bytes), used to encode contextual information (e.g., login page url). SCHEME: A byte string representing the EPHEMSEC instantiation (see ). B: Code encoding base (see ). P: Code size (see ). INONCE: An Initiator-generated nonce, a byte string between 16 and 64 bytes (see see ). PTIME: Responder-contributed time nonce (see ). PSK: A shared pre-established secret (≥ 32 bytes) (see ). Z: Diffie-Hellman shared secret derived from the selected key exchange pattern (see see ).

10.2 ISK Derivation The ISK is derived using the following steps:

OTP/OTK Derivation The intermediate secret key ISK computed in serves as the final source of entropy for generating the OTP (one-time password) or OTK (one-time key). The output format depends on the encoding base B (see ).

Inputs B: Code encoding base (see ). P: Code size (see ). PTIME: Responder-contributed time nonce (see ). ISK: Intermediate secret key (see ).

OTP Derivation (B ∈ {10, 16, 32}) When B is 10, 16, or 32, the code is formatted as an OTP composed of P digits. The first P - 1 digits are derived from ISK, and the last digit is a synchronization hint (SYNCHINT) derived from PTIME. ISK MUST be exactly 8 bytes long and is interpreted as an unsigned 64-bit integer.

Note: The result is returned as a sequence of P integer digits in base B. Conversion to a human-readable representation (e.g., alphanumeric alphabet) is outside the scope of this specification.

OTK Derivation (B = 256) When B is 256, the output is an opaque binary key. The first P - 1 bytes are taken directly from ISK, and the last byte encodes the synchronization hint.

Key Exchange Protocol Integration EPHEMSEC OTPs/OTKs are ephemeral shared secrets that can serve as primary credentials in mutually authenticated key exchange protocols, such as: Password-Authenticated Key Exchange (PAKE) TLS with Pre-Shared Key authentication (TLS-PSK) Traditional one-time password algorithms like HOTP, as defined in , are unsuitable for these protocols due to their reliance on loose synchronization. Validation servers must compare a received OTP against a range of possible values, which precludes direct use as cryptographic key material. EPHEMSEC addresses this limitation by appending a synchronization digit to each OTP/OTK. This digit enables reconstruction of the time-based nonce PTIME (see ), ensuring that both parties derive identical secrets without relying on trial-and-error validation. To use EPHEMSEC outputs as inputs to a key exchange protocol: Client Preparation: Append the synchronization digit to the account identifier. Use this composite identifier to initiate the key exchange protocol. Server Operation: Extract the synchronization digit from the received identifier. Remove the synchronization digit to recover the base account identifier. Load the corresponding client credentials using the base identifier. Execute the EPHEMSEC algorithm with the received session parameters, credentials, and synchronization hint to derive the shared secret. Proceed with the key exchange protocol using the derived secret.

Security considerations This section outlines the security properties of the EPHEMSEC algorithm. The analysis presented here is intended to demonstrate why the protocol is expected to meet its security goals, based on widely accepted cryptographic assumptions. This document has not yet undergone comprehensive peer review by the cryptographic and security communities. The security analysis presented should be considered preliminary, and implementers should exercise appropriate caution in security-critical deployments pending further review.

Adversary Profiles Two adversary profiles are considered in this analysis: Network Observer
This adversary has access to all publicly visible data, including the Initiator’s and Responder’s static ECDH public keys, session inputs (nonces, ephemeral public keys), and outputs (OTPs/OTKs) from previous EPHEMSEC sessions. It does not have access to any party’s private credentials. Credential Leak Attacker
This adversary has all the capabilities of a Network Observer, and additionally has read access to the Initiator’s credential store — specifically the Responder’s shared PSKs and static public keys. It does not have access to the Initiator’s private keys or control over protocol behavior.

Output Unpredictability of EPHEMSEC The primary security goal of an OTP/OTK algorithm is to ensure that outputs are unpredictable — even to attackers with significant passive or partial access. EPHEMSEC achieves this by combining Diffie-Hellman key exchange and HKDF with session-specific nonces. Specifically: Unpredictability of the Shared Secret (Z)
The ECDH-derived shared secret Z is indistinguishable from random to any adversary lacking private keys, due to the hardness of the Decisional Diffie-Hellman (DDH) problem on the chosen curve. Unpredictability of the HKDF Input (ikm)
The HKDF input key material (ikm = Z || PSK) inherits the unpredictability of Z. Even if the attacker knows the pre-shared key (PSK), the presence of the fresh and secret Z value ensures ikm remains secure. Security of the Derived Secret (ISK)
HKDF acts as a cryptographically strong pseudorandom function (PRF), meaning its outputs — including the intermediary secret ISK — are indistinguishable from random, provided the HKDF ikm secret input is unpredictable. Because each execution of EPHEMSEC uses unique nonces and ephemeral keys, the ISK value changes with every session. Output Derivation (OTP/OTK) For OTKs (B = 256): ISK is directly used, preserving its pseudorandomness. For OTPs (B ∈ {10, 16, 32}): ISK is converted to digits via modular arithmetic. This process introduces bias when B = 10, but the bias is mitigated by restricting code sizes (P) to the ranges specified in (see for analysis). Prevention of Replay and Forward Prediction
The use of unique nonces (INONCE, PTIME) and ephemeral keys ensures that no two executions produce the same output — even for the same account and context. This prevents replay attacks and ensures that attackers cannot predict future codes based on prior sessions. As a result, even an attacker who observes multiple sessions (and even possesses some server-side credentials) cannot derive or guess new OTPs or OTKs, nor can they reuse prior ones.

Phishing and MITM Prevention via Context Binding EPHEMSEC can mitigate web browser phishing and man-in-the-middle (MITM) attacks by binding cryptographic outputs to authentication context through the CONTEXT input (see ). This mechanism enables: Phishing Resistance: By embedding the login page URL in CONTEXT, the derived OTP/OTK becomes domain-specific. An attacker hosting a fake page cannot reuse intercepted codes, as their context will differ. MITM Resistance: Including the server's TLS certificate hash in CONTEXT ensures the OTP/OTK is tied to the authenticated connection. A MITM with an invalid certificate cannot generate valid codes.

The need for a trusted Agent Context binding alone is insufficient to provide Phishing or MITM resistance. For Context binding to be efficient, it must be used jointly with a trusted Agent (e.g., a browser extension) that: Reliably acquire authentication context (e.g., page URL, certificate) Securely inject it into EPHEMSEC's CONTEXT parameter Resist spoofing or coercion by attackers

Mutual Authentication Because the EPHEMSEC Initiator and Responder share a PSK (see ), all OTP/OTK outputs are derived from a secret known to both parties. As a result, these values can serve as credentials in protocols that support mutual authentication, such as PAKE or TLS-PSK. However, when the E1S1 key exchange pattern is used, the only contribution from the Initiator is an ephemeral key. In this configuration, the mutuality of the shared secret relies solely on the PSK. If the PSK is compromised — for example, by a Credential Leak Attacker — the attacker can impersonate the Initiator to the Responder. To mitigate this risk, it is RECOMMENDED that mutual authentication deployments use the E1S2 or E2S2 key exchange patterns. These patterns require the Initiator to contribute a static ECDH key, ensuring that mutual authentication depends on key material not accessible to a Credential Leak Attacker. This prevents such an attacker from successfully impersonating the Initiator.

Time Synchronization Attacks EPHEMSEC's time-synchronized nature creates a potential attack vector against the protocol's availability. The algorithm requires that clock drift between Initiator and Responder remain within T/2 seconds for successful PTIME recovery (see ). An attacker who can manipulate the time sources or time synchronization mechanisms of either party may cause authentication failures by forcing clock drift to exceed this threshold. Such attacks could result in denial of service against the authentication system. Future revisions will extend PTIME derivation to support event-based counters alongside time-based synchronization. Setting T = 0 will enable event-synchronized OTP/OTK generation using shared counters, while T > 0 will maintain time-based operation, allowing applications to choose the synchronization method best suited to their threat model.

IANA Considerations No IANA action is required.

This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. 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. 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. This memo provides information for the Internet community. This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. The HOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security. The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access and Wi-Fi network logon to transaction-oriented Web applications. 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. This document is not an Internet Standards Track specification; it is published for informational purposes.

OTP Sampling Bias EPHEMSEC generates P (see ) digits OTPs from 64-bit pseudo-random integers as described in . This final operation may introduce a non-uniform distribution in the generated OTP when the code base B (see ) does not evenly divide 2^64, which occurs for all bases except B = 10. We apply the Bias Formula below to evaluate the bias for code base 10. The bias reaches its maximum when the code size P is at its maximum value. While EPHEMSEC supports a maximum P of 15, only 14 digits are used to encode the pseudo-random value. Therefore: bias = 1 / floor(2^64 / 10^14) ≈ 5.4e-6 This value is negligibly close to zero, making the code base 10 bias insignificant. For comparison, generates 6-digit base-10 OTPs from 31-bit pseudo-random integers, resulting in: bias = 1 / floor(2^31 / 10^6) ≈ 0.5e-3 While this value is also close to zero, it is approximately 100 times larger than EPHEMSEC's code base 10 bias.

Bias Formula For integers m and M where m ≤ M and m > 0, when sampling uniformly from [0, M) and taking remainder modulo m, remainder distribution may not be uniform. To quantify this non uniformity we can calculate a bias coefficient using: bias = 0 when M % m = 0 bias = 1/floor(M/m) when M % m ≠ 0 The bias value varies in [0,1] and indicates the relative overrepresentation of certain remainders. When bias = 0, distribution is uniform.

Derivation Let X be a uniformly distributed random variable that generates integers in the range [0,M). Let R = X % m, where R is a random variable that maps X to the remainder of the division by m. We want to determine the probability distribution of R and quantify any bias that arises. Since X is uniformly distributed, the probability of X taking any specific value v in [0, M) is 1/M. Using the results from Lemma 1 below, we can determine the probability distribution of R.

Case 1: When M is divisible by m (M % m = 0) From Lemma 1, each remainder r in [0, m) occurs exactly M/m times among the values [0, M).
Therefore, R is uniformly distributed with: p(r) = (M/m) × (1/M) = 1/m for all r in [0, m) In this case, there is no bias since all remainders are equally likely.

Case 2: When M is not divisible by m (M % m = s where 0 < s < m) From Lemma 1, the remainders have different frequencies: Remainders r in [0, s) occur floor(M/m) + 1 times each Remainders r in [s, m) occur floor(M/m) times each This leads to a non-uniform distribution: p(r) = p1 = (floor(M/m) + 1)/M for r in [0, s) p(r) = p2 = floor(M/m)/M for r in [s, m)

Bias Quantification The bias arises because p1 > p2. We can express this relationship as:

This bias factor measures the non-uniformity of the distribution: bias = 0 when M is divisible by m (uniform case) bias ∈ (0, 1] when M is not divisible by m, with larger values indicating greater non-uniformity The bias is maximized when floor(M/m) = 1, giving bias = 1

Lemma 1: Distribution of Remainders in [0, M) Let m and M be integers where m ≤ M and m > 0. For any integer r in [0, m), the number of integers v in [0, M) that satisfy v % m = r is: When M is divisible by m (M % m = 0): Exactly M/m values for every r in [0, m) When M is not divisible by m (M % m = s where 0 < s < m): floor(M/m) + 1 values for r in [0, s) floor(M/m) values for r in [s, m)

Proof:

Design Rationale The EPHEMSEC algorithm has undergone several implementation iterations, initially starting by modifying the HOTP algorithm described in to achieve the desired security properties. The following sections explain the rationale behind key design choices.

Use of HKDF HKDF was chosen over the HMAC approach for two reasons: The HKDF domain separation feature enabled by the HKDF salt parameter (see ) provides the necessary context binding used for phishing protection. HKDF allows adjusting output size, which reduces the complexity of supporting the range of OTP/OTK sizes supported by EPHEMSEC (see ).

Usage of PSK The inclusion of a pre-shared key (PSK) ensures that generated OTP/OTKs are always a mutual secret, which the E1S1 pattern (see ) alone cannot guarantee. The incremental cost of mixing the PSK (see ) into the HKDF ikm input (see ) is expected to be low, and the PSK improves the secrecy of ikm. Therefore, it is always used even when the pattern (e.g., E1S2; see ) already provides the desired mutual secrecy.

Usage of Nonces The design requires that both the Initiator and Responder contribute a nonce and are responsible for ensuring that their respective nonces are not reused. During development, it was considered whether the Initiator nonce could serve dual purposes with the ephemeral public key contributed by the Initiator. However, after recognizing that all practical authentication server designs supporting EPHEMSEC require maintaining unique session identifiers, no attempt was made to evaluate whether removing the Initiator nonce could provide benefits.

Transmission of the Responder Nonce When using OTP output, bandwidth between the Responder and the Initiator is severely constrained. Therefore, a synchronization digit SYNCHINT is used to "compress" the Responder nonce PTIME (see ). When using OTK output, it is assumed that the application has addressed the bandwidth limitations that necessitate OTP output, and therefore PTIME could potentially be transmitted in uncompressed form. However, explicit support for uncompressed transmission was not included for two reasons: The computational cost of running the synchronization algorithm to recover PTIME from SYNCHINT is very low. Having the server rely on SYNCHINT to reconstruct PTIME limits the Responder's ability to reuse its own nonces, which provides additional security benefits.