KerPass EPHEMSEC One-Time Password Algorithm

4.1. Initiator Role

This role is normally assigned to relying web application.¶

4.2. Responder Role

This role is normally assigned to authenticator application.¶

5.1. 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 [RFC5869].¶

5.2. 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 [RFC7748], which yields a 32-byte shared secret.¶

5.3. 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.¶

5.4. Code Output

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

5.5. 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:¶

1. <Hash> corresponds to the hash function used (see Section 5.1), e.g., SHA512.¶

2. <ECDH> denotes the ECDH function used (see Section 5.2), e.g., X25519.¶

3. <Pattern> specifies the key exchange pattern (see Section 5.3), e.g., E1S1.¶

4. T<T>B<B>P<P> encodes the code output parameters (see Section 5.4), with <T>, <B>, and <P> replaced by their respective values.¶

6.1. 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.¶

6.2. 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.¶

6.3. 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.¶

8.1. INONCE – Initiator Nonce

The Initiator generates a nonce INONCE that contributes to the personalization of the derived intermediary secret (see Section 10). 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.¶

8.2. 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.¶

step = T / (B - 1) # floating point division
PTIME = round(time / step)
SYNCHINT = PTIME % B
return PTIME, SYNCHINT

mintime = time - (T / 2)
step = T / (B - 1) # floating point division
mpt = round(mintime / step)
mphint = mpt % B

Q = mpt // B # integer division
PTIME = Q * B + SYNCHINT

if SYNCHINT < mphint:
    PTIME += B

return PTIME

9.1. Initiator E1S1 Z Derivation

Inputs:¶

• ei Initiator ephemeral Keypair¶

• Sr Responder static PublicKey¶

Z = ECDH(ei, Sr)¶

9.2. Responder E1S1 Z Derivation

Inputs:¶

• sr Responder static Keypair¶

• Ei Initiator ephemeral PublicKey¶

Z = ECDH(sr, Ei)¶

9.3. Initiator E1S2 Z Derivation

Inputs:¶

• ei Initiator ephemeral Keypair¶

• si Initiator static Keypair¶

• Sr Responder static PublicKey¶

Z = ECDH(ei, Sr) || ECDH(si, Sr)¶

9.4. Responder E1S2 Z Derivation

Inputs:¶

• sr Responder static Keypair¶

• Ei Initiator ephemeral PublicKey¶

• Si Initiator static PublicKey¶

Z = ECDH(sr, Ei) || ECDH(sr, Si)¶

9.5. 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)¶

9.6. 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.1. 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 Section 5.5).¶

• B: Code encoding base (see Section 5.4.2).¶

• P: Code size (see Section 5.4.3).¶

• INONCE: An Initiator-generated nonce, a byte string between 16 and 64 bytes (see see Section 8.1).¶

• PTIME: Responder-contributed time nonce (see Section 8.2).¶

• PSK: A shared pre-established secret (≥ 32 bytes) (see Section 6.1).¶

• Z: Diffie-Hellman shared secret derived from the selected key exchange pattern (see see Section 9).¶

10.2. 10.2 ISK Derivation

The ISK is derived using the following steps:¶

# CONTEXT & SCHEME are used for domain separation
salt = TLV(byte('C'), CONTEXT) || TLV(byte('S'), SCHEME)

ikm = Z || PSK

# INONCE & PTIME are used for output personalization
info = TLV(byte('N'), INONCE) || TLV(byte('T'), BE8(PTIME))

# Output length
if B == 256:
  L = P - 1 # OTK case
else:
  L = 8 # OTP case

ISK = HKDF(salt, ikm, info, L)

return ISK

11.1. Inputs

• B: Code encoding base (see Section 5.4.2).¶

• P: Code size (see Section 5.4.3).¶

• PTIME: Responder-contributed time nonce (see Section 8.2).¶

• ISK: Intermediate secret key (see Section 10).¶

11.2. 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.¶

# Interpret ISK as a big-endian unsigned integer
maxcode = B ^ (P - 1)
isrc = U64(ISK) % maxcode

# Extract (P - 1) digits in base B
OTP = '' # empty byte string
for i in 0 .. (P - 2):
    digit = byte(isrc % B)
    OTP = digit || OTP
    isrc /= B

# Append 1-digit time synchronization hint
SYNCHINT = byte(PTIME % B)
OTP = OTP || SYNCHINT

return OTP  # byte string of P digits in [0 .. B)

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.¶

11.3. 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.¶

SYNCHINT = byte(PTIME % 256)
OTK = ISK || SYNCHINT

return OTK  # byte string of length P

13.1. 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.¶

13.2. 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:¶

1. 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.¶

2. 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.¶

3. 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.¶

4. 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 Table 1 (see Appendix A for analysis).¶

5. 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.¶

13.3. 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 Section 10.1). This mechanism enables:¶

1. 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.¶

2. 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.¶

13.4. Mutual Authentication

Because the EPHEMSEC Initiator and Responder share a PSK (see Section 6.1), 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.¶

13.5. 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 Section 8.2).¶

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.¶

15.1. Normative References

[RFC7748]

Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/rfc/rfc7748>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

15.2. Informative References

[RFC4226]

M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, <https://www.rfc-editor.org/rfc/rfc4226>.

[RFC5869]

Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/rfc/rfc5869>.

[RFC6238]

M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, May 2011, <https://www.rfc-editor.org/rfc/rfc6238>.

[KerPass]

"KerPass open source project", n.d., <https://github.com/amvtek/KerPass>.

[PASSKEY]

"passkeys-Specifications", n.d., <https://passkeys.dev/docs/reference/specs/>.

A.1. 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.¶

p1 = p2 × (1 + 1/floor(M/m)) = p2 × (1 + bias)

where:
bias = 1/floor(M/m)

A.2. 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:¶

1. When M is divisible by m (M % m = 0):¶

   • Exactly M/m values for every r in [0, m)¶

2. 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)¶

For r in [0, m) let count(r) be the count of v satisfying v % m = r for v in [0, M)

Any v, such that v % m = r can be written as v = q·m + r where q ≥ 0
To keep v in [0, M), we must have q ≤ (M - 1 - r)/m, hence
count(r) = floor((M -1 - r)/m) + 1

When M = k·m (divisible case):

- count(r) = floor((k·m - 1 - r)/m) + 1 = k = M/m

When M = k·m + s (non-divisible case):

- For r < s: count(r) = k + 1
- For r ≥ s: count(r) = k

B.1. Use of HKDF

HKDF was chosen over the [RFC4226] HMAC approach for two reasons:¶

1. The HKDF domain separation feature enabled by the HKDF salt parameter (see Section 10.2) provides the necessary context binding used for phishing protection.¶

2. HKDF allows adjusting output size, which reduces the complexity of supporting the range of OTP/OTK sizes supported by EPHEMSEC (see Table 1).¶

B.2. 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 Section 5.3.1) alone cannot guarantee.¶

The incremental cost of mixing the PSK (see Section 6.1) into the HKDF ikm input (see Section 10.2) 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 Section 5.3.2) already provides the desired mutual secrecy.¶

B.3. 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.¶

C.1. Kerpass_SHA512_X25519_E1S1_T600B10P8 vector

{
  "scheme": "Kerpass_SHA512_X25519_E1S1_T600B10P8",
  "context": "a33698e33f8ac3aae8c3b1527cc019e5b3e34e5569883283b1a75fbfbe8f3d7d1d5c17d10d90533d33305a90560bfe",
  "psk": "55a439e62aefd92eebb7f4bc7e5f1626ef4545fa499252dd8658b61547f9df0e",
  "shared_secret": "0803020700020800",
  "otp": "83270280",
  "init_nonce": "d8421a5a86f2caf8d45e6ef5c62d3b5421ba7a",
  "init_time": 4134179892,
  "init_static_key": "",
  "init_ephemeral_key": "50d2af0ee110bd06604eb03e57a37763c9194400015290f3ef612be18ecd0583",
  "init_remote_static_key": "f1e1116982475e7fd252a2ca69c1459b3a4439029fa3f33059d7e657b3318912",
  "init_remote_ephemeral_key": "",
  "resp_time": 4134179984,
  "resp_synchro_hint": 0,
  "resp_static_key": "fad1034e60389317dd0e405c84fff2d17248fa1112d66a1979515ddf65a44a06",
  "resp_ephemeral_key": "",
  "resp_remote_static_key": "",
  "resp_remote_ephemeral_key": "0fc4c28b9d85a476a1b664050901c78c9b4ff69bde707829bd1e05e5602a3d55",
  "hkdf_salt": "432fa33698e33f8ac3aae8c3b1527cc019e5b3e34e5569883283b1a75fbfbe8f3d7d1d5c17d10d90533d33305a90560bfe53244b6572706173735f5348413531325f5832353531395f453153315f543630304231305038",
  "hkdf_info": "4e13d8421a5a86f2caf8d45e6ef5c62d3b5421ba7a54080000000003b23d1c",
  "hkdf_secret": "31215fcaafce8df63bd3a21371d15233501da05b5c52248fb6d4cafbdad20d3655a439e62aefd92eebb7f4bc7e5f1626ef4545fa499252dd8658b61547f9df0e"
}

C.2. Kerpass_SHA512_X25519_E1S2_T600B16P8 vector

{
  "scheme": "Kerpass_SHA512_X25519_E1S2_T600B16P8",
  "context": "037f9aae0e39c770b7c216572382e1b78ccff597a27aeb004cd14c881fe1944eb630e8af0f9840b1ef3ffaf2cf697fb0a08d9cacd5e8c5ff4a1be583b4",
  "psk": "a2096639c4a3b6de9bb4d76bfe5b047545eaa3ccb8b67839c55e580ba54feb0d",
  "shared_secret": "0e0f0b02070e020e",
  "otp": "EFB27E2E",
  "init_nonce": "a5ddd81c502e054357c58ac483b8d39ce1e7",
  "init_time": 568923577,
  "init_static_key": "77166d9d14b2cc221a3829f600aad1f2f18872e8a7e7cb7aae2def72b69bff58",
  "init_ephemeral_key": "90533d33305a90560bfef99d07c496ca92ef5001b62441860509af3d226d8ba4",
  "init_remote_static_key": "dc94881a2063e4d30a0e7fe377838202e542b46d8836e57187e9abef99216078",
  "init_remote_ephemeral_key": "",
  "resp_time": 568923459,
  "resp_synchro_hint": 14,
  "resp_static_key": "dcad0c9e9aafe811761199f7e2286fda5036e5f5fc6f98c5f4b97fce71532ef8",
  "resp_ephemeral_key": "",
  "resp_remote_static_key": "176198d01d29325b022a5efff4d315bbf9fb4a07755d19581f857754797f6b54",
  "resp_remote_ephemeral_key": "ecb63fa01c06b8d2c4de23d1abc4a5d57647481fbed22fb5866fda4c7989103c",
  "hkdf_salt": "433d037f9aae0e39c770b7c216572382e1b78ccff597a27aeb004cd14c881fe1944eb630e8af0f9840b1ef3ffaf2cf697fb0a08d9cacd5e8c5ff4a1be583b453244b6572706173735f5348413531325f5832353531395f453153325f543630304231365038",
  "hkdf_info": "4e12a5ddd81c502e054357c58ac483b8d39ce1e754080000000000d906ee",
  "hkdf_secret": "ca2a1d1f71d686ad52f6ef62571d38a5d579f96a86150861e736ea3e71aeba59c85cae9ec5404221a87423eaf952c151bc74b0213fa8a41fba0786ccf315fd5ba2096639c4a3b6de9bb4d76bfe5b047545eaa3ccb8b67839c55e580ba54feb0d"
}

C.3. Kerpass_SHA512_X25519_E2S2_T600B32P9 vector

{
  "scheme": "Kerpass_SHA512_X25519_E2S2_T600B32P9",
  "context": "9e2d582a0afac79709941506151e9e6ce20cef6da6c3aa457b",
  "psk": "3ec69559723db8a20cdace8bee0bf6534a1de8902786fc3b3626e4897f261dee",
  "shared_secret": "13010a191603100111",
  "otp": "K1ASP3G1H",
  "init_nonce": "716fbb9b9872e0b49dce2723a52ade9d5fdc59",
  "init_time": 2246779725,
  "init_static_key": "6a846ddc06f426e60dd4ae3fbd5b9b06286abc3862e473855e89a138c56ea0b2",
  "init_ephemeral_key": "aa2b0e1b2e4704f08a377ba26e4475aaf1aab010fb8c6ad4bf63890816d3d3f2",
  "init_remote_static_key": "acc4416cd58c4a1a43272253c75a8f27708174f24548466757e13374e161c74b",
  "init_remote_ephemeral_key": "d32119b92d8a61d0c204a4355c86e19c7027376c2e42be84ffa907a1aaec9e6a",
  "resp_time": 2246779996,
  "resp_synchro_hint": 17,
  "resp_static_key": "6716e0cf047f6721662c501ad15f9884cada29210c019c7df566a0e71b67b1dd",
  "resp_ephemeral_key": "d45cf4b5736ef3f3fb0d2a98459a304e595276243d4af91aa5ef2366d44ade2e",
  "resp_remote_static_key": "f7c192278ea1c2323e92cc13da9ac5f0a8d53ac879eadbd774413c66659d865e",
  "resp_remote_ephemeral_key": "86e53308c5bcefe25707f0ffee26cbdc260fc98d22fc9f9e53f4c1994347c27c",
  "hkdf_salt": "43199e2d582a0afac79709941506151e9e6ce20cef6da6c3aa457b53244b6572706173735f5348413531325f5832353531395f453253325f543630304233325039",
  "hkdf_info": "4e13716fbb9b9872e0b49dce2723a52ade9d5fdc5954080000000006eb4bb1",
  "hkdf_secret": "36d0bdc70509bb9cff6f2d899e4b9dd261c91da06604f43e408e96da1253827fc37f09bdd64436333faab1150a0bd26d9c8ef3d5935e175b9db3c5ebacdbe7633ec69559723db8a20cdace8bee0bf6534a1de8902786fc3b3626e4897f261dee"
}

C.4. Kerpass_SHA512_X25519_E1S2_T1024B256P33 vector

{
  "scheme": "Kerpass_SHA512_X25519_E1S2_T1024B256P33",
  "context": "c58ac483b8d39ce1e7037f9aae0e39c770b7c216572382e1",
  "psk": "aad1f2f18872e8a7e7cb7aae2def72b69bff58a2096639c4a3b6de9bb4d76bfe",
  "shared_secret": "8479fca69f6d1dbc9164f20eaa4d799ba3b8dae83f915864766fa66d4cae17422c",
  "otp": "",
  "init_nonce": "5b047545eaa3ccb8b67839c55e580ba54feb0da5ddd81c502e054357",
  "init_time": 3762980154,
  "init_static_key": "6fda5036e5f5fc6f98c5f4b97fce71532ef8d077166d9d14b2cc221a3829f600",
  "init_ephemeral_key": "4e5569883283b1a75fbfbe8f3d7d1d5c17d10d90533d33305a90560bfef99d07",
  "init_remote_static_key": "2f92f4b84f1b107ca934e641f34bfae2b2251e9b70876cd1a256301f8f3ccc0e",
  "init_remote_ephemeral_key": "",
  "resp_time": 3762980663,
  "resp_synchro_hint": 44,
  "resp_static_key": "c496ca92ef5001b62441860509af3d226d8ba4dcad0c9e9aafe811761199f7e2",
  "resp_ephemeral_key": "",
  "resp_remote_static_key": "c52b20d6825127ecb33dfff5c1d9a0ed7f57b41eda1dd6855d7ad6268372fc70",
  "resp_remote_ephemeral_key": "6a5a0dd77082720ebd55bcab514a68be8db117af5a17fbb06a7e035e44959307",
  "hkdf_salt": "4318c58ac483b8d39ce1e7037f9aae0e39c770b7c216572382e153274b6572706173735f5348413531325f5832353531395f453153325f543130323442323536503333",
  "hkdf_info": "4e1c5b047545eaa3ccb8b67839c55e580ba54feb0da5ddd81c502e05435754080000000037da8f2c",
  "hkdf_secret": "04b954ad9d6d42e39217b6a32ae83bc52ba662a39e2bcf18240e6b07034a8c4c86e7a23622ce6b4cd46665d4309b624dd16fa39e57c86c7daf115ddd17f24039aad1f2f18872e8a7e7cb7aae2def72b69bff58a2096639c4a3b6de9bb4d76bfe"
}