Internet-Draft | The GNU Taler Protocol | July 2024 |

Gütschow | Expires 9 January 2025 | [Page] |

- Workgroup:
- independent
- Internet-Draft:
- draft-guetschow-taler-protocol
- Published:
- Intended Status:
- Informational
- Expires:

[ TBW ]¶

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 9 January 2025.¶

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

[ TBW ]¶

Beware that this document is still work-in-progress and may contain errors. Use at your own risk!¶

SHA-256(msg) -> hash Input: msg input message of length L < 2^61 octets Output: hash message digest of fixed length HashLen = 32 octets¶

`hash`

is the output of SHA-256 as per Sections 4.1, 5.1, 6.1, and 6.2 of [RFC6234].¶

SHA-512(msg) -> hash Input: msg input message of length L < 2^125 octets Output: hash message digest of fixed length HashLen = 64 octets¶

`hash`

is the output of SHA-512 as per Sections 4.2, 5.2, 6.3, and 6.4 of [RFC6234].¶

SHA-512(msg) -> hash Input: msg input message of length L < 2^125 octets Output: hash message digest of fixed length HashLen = 32 octets¶

The output `hash`

corresponds to the first 32 octets of the output of SHA-512 defined in Section 3.1.2:¶

temp = SHA-512(msg) hash = temp[0:31]¶

Note that this operation differs from SHA-512/256 as defined in [SHS] in the initial hash value.¶

The Hashed Key Derivation Function (HKDF) used in Taler is an instantiation of [RFC5869]
with two different hash functions for the Extract and Expand step as suggested in [HKDF]:
`HKDF-Extract`

uses `HMAC-SHA512`

, while `HKDF-Expand`

uses `HMAC-SHA256`

(cf. Section 3.2.1).¶

HKDF(salt, IKM, info, L) -> OKM Inputs: salt optional salt value (a non-secret random value); if not provided, it is set to a string of 64 zeros. IKM input keying material info optional context and application specific information (can be a zero-length string) L length of output keying material in octets (<= 255*32 = 8160) Output: OKM output keying material (of L octets)¶

The output OKM is calculated as follows:¶

PRK = HKDF-Extract(salt, IKM) with Hash = SHA-512 (HashLen = 64) OKM = HKDF-Expand(PRK, info, L) with Hash = SHA-256 (HashLen = 32)¶

Based on the HKDF defined in Section 3.3.1, this function returns an OKM that is smaller than a given big number N.¶

HKDF-Mod(N, salt, IKM, info) -> OKM Inputs: N big number; Nbit denotes the length of N in bits salt optional salt value (a non-secret random value); if not provided, it is set to a string of 64 zeros. IKM input keying material info optional context and application specific information (can be a zero-length string) Output: OKM output keying material (smaller than N)¶

The final output `OKM`

is determined deterministically based on a counter initialized at zero,
where `c`

denotes the two least significant octets of the counter in network-byte order¶

counter = 0 do until OKM < N: x = HKDF(salt, IKM, info | c, ceil(Nbits/8)) OKM = Nbits least significant bits of x counter += 1¶

RSA-FDH(msg, pubkey) -> fdh Inputs: msg message pubkey RSA public key consisting of modulus N and public exponent e Output: fdh full-domain hash of msg over pubkey.N¶

`fdh`

is calculated based on HKDF-Mod from Section 3.3.2 as follows:¶

info = 0x5253412d46444120465470735721 ("RSA-FDA FTpsW!" encoded as UTF-8) salt = length(pubkey.N) | length(pubkey.e) | pubkey.N | pubkey.e fdh = HKDF-Mod(pubkey.N, salt, msg, info)¶

The resulting `fdh`

can be used to test against a malicious RSA pubkey
by verifying that the greatest common denominator (gcd) of `fdh`

and `pubkey.N`

is 1.¶

RSA-FDH-Derive(bks, pubkey) -> out Inputs: bks blinding key secret of length L = 8 octets pubkey RSA public key consisting of modulus N and public exponent e Output: out full-domain hash of bks over pubkey.N¶

`out`

is calculated based on HKDF-Mod from Section 3.3.2 as follows:¶

info = 0x426c696e64696e67204b4446 ("Blinding KDF" encoded as UTF-8) salt = 0x426c696e64696e67204b444620657874726163746f7220484d4143206b6579 ("Blinding KDF extractor HMAC key" encoded as UTF-8) fdh = HKDF-Mod(pubkey.N, salt, bks, info)¶

RSA-FDH-Blind(msg, bks, pubkey) -> out Inputs: msg message bks blinding key secret of length L = 8 octets pubkey RSA public key consisting of modulus N and public exponent e Output: out message blinded for pubkey¶

`out`

is calculated based on RSA-FDH from Section 3.5.1 as follows:¶

data = RSA-FDH(msg, pubkey) r = RSA-FDH-Derive(bks, pubkey) r_e = r ** pubkey.e (mod N) out = r_e * data (mod N)¶

RSA-FDH-Unblind(sig, bks, pubkey) -> out Inputs: sig blind signature bks blinding key secret of length L = 8 octets pubkey RSA public key consisting of modulus N and public exponent e Output: out unblinded signature¶

`out`

is calculated as follows:¶

r = RSA-FDH-Derive(bks, pubkey) r_inv = inverse of r (mod N) out = sig * r_inv (mod N)¶

RSA-FDH-Verify(msg, sig, pubkey) -> out Inputs: msg message sig signature of pubkey over msg pubkey RSA public key consisting of modulus N and public exponent e Output: out true, if sig is a valid signature¶

`out`

is calculated based on RSA-FDH from Section 3.5.1 as follows:¶

data = RSA-FDH(msg, pubkey) exp = sig ** pubkey.e (mod N) out = (data == exp)¶

[ TBD ]¶

None.¶

- [HKDF]
- Krawczyk, H., "Cryptographic Extraction and Key Derivation: The HKDF Scheme", Springer Berlin Heidelberg, Advances in Cryptology – CRYPTO 2010 pp. 631-648, DOI 10.1007/978-3-642-14623-7_34, ISBN ["9783642146220", "9783642146237"], , <https://doi.org/10.1007/978-3-642-14623-7_34>.
- [RFC2104]
- Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, , <https://www.rfc-editor.org/rfc/rfc2104>.
- [RFC5869]
- Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, , <https://www.rfc-editor.org/rfc/rfc5869>.
- [RFC6234]
- Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, , <https://www.rfc-editor.org/rfc/rfc6234>.
- [SHS]
- Dang, Q., "Secure Hash Standard", National Institute of Standards and Technology, DOI 10.6028/nist.fips.180-4, , <https://doi.org/10.6028/nist.fips.180-4>.

[ TBD ]¶

This work was supported in part by the German Federal Ministry of Education and Research (BMBF) within the project Concrete Contracts.¶