MantisBT - Issues

0011253: GET /private/orders fails with mixed currency

Mon, 16 Mar 2026 01:43:57 +0100

accumulate_total () doesn't support mixed currencies...

0011125: Multiple services are using the wrong peer identity key

Mon, 16 Mar 2026 01:07:39 +0100

Since the PILS service has been implemented, there are still multiple services and components in GNUnet which use the function `GNUNET_CRYPTO_eddsa_key_create_from_configuration()`. This function simply reads a private key for the peer from the a configuration instead of asking the PILS service about the current peer identity. This results in signature mismatches for example and other cryptographic issues.

I'd suggest that we fully remove this function, replacing it with PILS integration. So that services like CADET, DHT, NSE, EXIT, REGEX and multiple TRANSPORT communicators work as intended again and they could react to peer identity changes.

0011254: Read receipts do not ensure individual decryption

Sun, 15 Mar 2026 21:16:59 +0100

When user's send a message to other members of a chat room, they typically receive a read receipt which corresponds to any message sent by the other member following the original sent message from the user. However this does not account for encrypted messages (PRIVATE or SECRET messages).

In this case a user might assume their message has been received while only the encrypted message has been received, potentially without the recipient being able to decrypt and read it yet. So in this case the service/chat-library/application should ensure that the encrypted message and the associated key have been transmitted before confirming via a visual "read receipt".

0010202: add lattice-based PQC blind signature support

Sat, 14 Mar 2026 21:09:30 +0100

For now, I think we should base it on:

https://github.com/Chair-for-Security-Engineering/lattice-anonymous-credentials

Just as a 3rd case next to RSA and CS.

0008892: Design Considerations for future *KEY types

Sat, 14 Mar 2026 21:08:59 +0100

The Design of GNS thus far could be improved to allow easier cryptographic analysis. Each consideration here is of minor severity, i.e. there is no immediate consequence of not implementing the proposed changes, to the best of my knowledge. Nevertheless, these (in some cases breaking) changes might be worth considering for a cleaner design.
I am currently working off RFC 9498 rather than the actual implementation, so I apologize should my analysis not reflect changes made in the meantime.

# Making Full Use of HKDF

To derive a bunch of random looking bits from a zone key (zkey below) and a label, one could take a hash function H and output

H(zkey || label || 0) || H(zkey || label || 1) || H(zkey || label || 2) || ...

where || denotes concatenation.
This is well justified if one is willing to model H as an ideal random function, whose output may only be correlated with its input only by plugging in values and observing what comes out. (This is routinely called a Random Oracle.)
However, algorithms are not random oracles, and in particular cannot always be trusted to generate arbitrarily many independent output bits from highly correlated inputs. For this very reason, modern key derivation functions like HKDF derive only a single key from a keying distribution using a dedicated component called a strong randomness extractor ("Extract") and then use this one key to derive independent looking key streams using another dedicated component called pseudorandom function ("Expand"). In HKDF, these are both implemented using HMAC, which is secure almost independent of where you plug in parameters, IF you are willing to model HMAC or the underlying hash function as a random oracle (which is why the current implementation is "probably" fine). A modular analysis of schemes however requires using HKDF using its extract and expand functionality in the sense above.

For this reason, it may be good practice to first derive blinding key material bkm as follows:

salt := "gns-extract-" || zone_type
bkm := HKDF-Extract(salt, zkey || label)

zkey is assumed to have fixed length, a length encoding or some sort of final delimiter.
The salt here is merely used as a domain separation tag. It includes the zone type so that the encoding of zkey may differ between zone types without having to worry about collisions.
The initial keying material (zkey || label) is chosen such that both the combination of a sufficiently unknown zkey with a predictable label (as required by GNS for unlinkability in a web-surfing-like scenario) as well as the combination of a known zkey with a sufficiently random label (as required for censorship resistance and privacy with re:claim) result in input keying material distributions of sufficient entropy for the extractor to do its job and extract a bkm indistinguishable from random.

bkm may then be used to derive arbitrary random data using HKDF-Expand. For example, to derive a symmetric key for (say) AES-GCM and a blinding factor for (say) EdDSA key blinding one could use

K := HKDF-Expand(bkm, "gns-encrypt-aes-gcm-key", 256/8)
h := HKDF-Expand(bkm, "gns-blind-eddsa", 512/8)

In terms of the RR data confidentiality, query privacy and censorship resistance, this should simplify the analysis a decent bit.

# Simplifying and Future-Proofing the Symmetric Encryption

Contrary to the terminology in RFC 9498, the actual nonce ("number used once") is not the NONCE derived using HKDF (which is always the same, since it is derived deterministically for each zkey-label pair), but rather the expiration time of the record. Encryption algorithms typically only provide any guarantees if this value is only used once.

There are two approaches to "guaranteeing" this. One could write a "MUST" into a specification detailing that expiration times shall be strictly increasing. This approach might however leave the not cryptographically inclined reader (or non-reader. How many people using DNS have read the specifications? :D) with the impression that violating this constraint heuristically to support distributed signing infrastructures, temporary setups and backup solutions might only lead to temporary interoperability problems, rather than a leak of confidential information. Even if all users and implementations were to understand this, it would complicate the above use cases and, as a result, make GNS less flexible.

Alternatively, one could take out the problem. That is, ideally generating a random (at least) 64-bit nonce each time and placing it next to the ciphertext. If one is worried about accidental nonce reuse, there are AEAD schemes like AES-GCM-SIV to handle this exact case. If one does not want to store ciphertexts locally and rather re-encrypt plaintexts on demand, one may either just store the nonce values alongside the expiration timestamp or derive them deterministically by applying an independently keyed pseudorandom function to the plaintext, expiration and blinded public key.

Speaking of AEAD schemes, with the internet moving away from giving users access to low-level cryptographic primitives, many libraries will primarily expose, review, and also optimize, AEAD schemes. It does little harm to use these for encryption, even though integrity is already protected by a digital signature. The AD may also be used to bind the ciphertext to a particular blinded key.

To illustrate the full RRBlock creation, assume a layout such as (bitlengths in brackets, "varies" depends on zone_type or data length):

size(32) || zone_type(32) || expiration(64) || blind_zone_key(varies) || nonce(64) || bdata(varies) || aead_tag(128) || signature(varies)

Here I have left size and zone_type unchanged for compatibility with existing *KEY types, expiration has moved slightly to the front to have fixed size key types in the header as much as possible. Doing so for the nonce would make AD-calculation and deterministic nonce-calculation more cumbersome.

Creation steps:
1. Fill in size, zone_type and expiration
2. Do the KDF extract step above
3. Use the KDF expand to derive randomness for blinding zkey, and fill in blind_zone_key
4. Fill in the nonce randomly, using a stored value, or by applying a PRF to the parts already filled in
5. Use the KDF expand to derive a symmetric encryption key
6. Fill in bdata and aead_tag by encrypting RDATA with everything from size to blind_zone_key as AD and the chosen nonce
7. Fill in a signature over everything before it

If you need every last bit of speed in creating the RRBlock, keep a hash of everything you have filled in so far. You can pass this hash to the nonce-PRF, use it as an effective AD and have it ready for the signature. I do not think that this makes much of a difference, but some to-be-defined *KEY types might make use of such optimizations.

0011252: Test "flickering" issue of KYC Auth in taler-merchant v1.5.8 (or earlier)

Sat, 14 Mar 2026 18:33:36 +0100

After a discussion with CG, apparently a flickering issue after entering a bank no. is still possible, which was, definitely given in earlier version of taler-merchant v.1.5.x.

Trying to exclude herewith.

0011195: Communicators require access to private key of peer identity

Fri, 13 Mar 2026 18:41:32 +0100

The TCP and UDP communicators perform multiple cryptographic operations using the private key from the peer identity besides signing messages. This contains GNUNET_CRYPTO_hpke_elligator_kem_decaps() using an HPKE key derived from the EDDSA key and GNUNET_CRYPTO_eddsa_kem_decaps() using the key itself.

Since the PILS service is intended to abstract/manage the peer identity and its private key portion, there are changes needed to utilize this service via its handle instead of requiring direct access to this private key. Additionally this would need new functions on the PILS service handle to perform the needed operations.

0011251: CADET encryption authentication smell

Fri, 13 Mar 2026 18:00:42 +0100

The header encyption HENCRYPT and the message encryption ENCRYPT according the spec should both be AEAD schemes

The CADET implementation takes a shortcut: It Encrypts the header and the plaintext separately with the respective keys using TWOFISH(AES(*)) and then appends a MAC using the HK that is calculated over both ciphertexts

Probably not breakable per se, but smells bad.

0011250: CADET header encryption nonce entroopy missing

Fri, 13 Mar 2026 17:59:17 +0100

I think there is a crypto bug in CADET: According to https://signal.org/docs/specifications/doubleratchet/#external-functions HENCRYPT(hk, plaintext): Returns the AEAD encryption of plaintext with header key hk. Because the same hk will be used repeatedly, the AEAD nonce must either be a stateful non-repeating value, or must be a random non-repeating value chosen with at least 128 bits of entropy.. In the code we can see

13 GNUNET_CRYPTO_hkdf_gnunet (result: &iv,
14 out_len: sizeof iv,
15 xts: NULL,
16 xts_len: 0,
17 skm: &ax->HKs,
18 skm_len: sizeof ax->HKs);

that the nonce (iv) is derived from said HK which will be used repeatedly, and no other entropy is input.

0011235: [qc] input amount on merchant doesnt respect currency spec

Fri, 13 Mar 2026 15:27:43 +0100

on order creation, using the arrows on the input type=number steps by 0.001 for CHF

0010946: wallet-core DB transactions should automatically re-try after handling certain errors [8h]

Fri, 13 Mar 2026 13:43:42 +0100

And in particular, we might want to catch certain errors (e.g. denominations not validated) and handle them before re-trying.

0011149: QR code scanner screen

Fri, 13 Mar 2026 13:26:58 +0100

Add a clear button for the user to exit the screen and add the possibility to use flash

0011239: exchange still treats section names case-sensitive in coin directories

Fri, 13 Mar 2026 13:15:03 +0100

This is bound to lead to (even more) issues in the future.

The secmods should start using section names case-insensitively and rename existing directories to a standardized case (say, lower-case).

fdold-work@sapota ~> ls ~/.local/share/taler-exchange/secmod-rsa/keys/
cOiN_CHF_n1/

0011210: Wallets must highlight / warn about use of untrusted exchanges [meta]

Fri, 13 Mar 2026 13:14:14 +0100

It just happened to me trying to send some TOPS/CHF (real money as of exchange.taler-ops.ch) that I managed to pick the CHF currency for use with exchange.stage.taler-ops.ch, which is not real, but test money.

I suggest there's a field which allows a Taler Wallet to mark money as test money in a visible way; this could be an attribute in /config of the exchange.

0011245: CHF filter broken

Fri, 13 Mar 2026 13:11:41 +0100

Given cases where the same currency is used, but for different scopes, like in my case (seen in Android)

- BFH/CHF, restricted to snack machines at BFH, and
- TOPS/CHF (stage), used for testing purposes (cf. https://docs.taler.net/deployments/tops-stage-devtesting.html), not backed by real CHF money,
- TOPS/CHF (production), used for real CHF transfers under the Swiss sandbox license, backed by real money,

it happens that the sums displayed at various areas in the app (most visibly when paying something) are just wrong, because the various CHF currencies are mixed (as in: somehow summed) together, but sometimes also with sums which are not simply the sum of all individual CHF sums.

0011241: clean up typst path issues

Fri, 13 Mar 2026 13:10:46 +0100

The typst packages are currently installed in a very odd location:

typstpackagedir = $(prefix)/.local/share/typst/packages/taler-exchange/vqf_902_1/0.0.0/

Instead, the typst packages should be installed under $(prefix)/share/taler-exchange/typst. When typst is invoked, XDG_DATA_HOME must then be set to $(prefix)/share/taler-exchange/.

0011208: call typst with XDG_DATA_HOME set

Fri, 13 Mar 2026 13:10:46 +0100

This way, we can move the packages to a nicer location.
This will require changes to libgnuneutil.

0011205: p2p transaction stuck on "KYC required" even though KYC is done at exchange

Fri, 13 Mar 2026 13:10:03 +0100

Student(s) had a fresh wallet (happened both with iOS and Android!), never used. P2P send them 3 CHF. Student did the KYC (SMS registration), but transaction still shows as KYC required in the wallet. Money did not arrive. On sending wallet, money is shown as paid out.

0011042: copy buttons for wire transfer details provide too little visual feedback

Fri, 13 Mar 2026 12:18:56 +0100

We had a user trying out the app, they were confused by the copy buttons, as they provide barely any feedback whether they were pressed or not.

I've seen it as a common pattern (often on Websites) that the copy button changes (e.g. to include a checkmark) after it has been pressed.

0011246: peer-push-credit transaction does not handle conflict response for merge operation when in KYC state

Fri, 13 Mar 2026 11:18:47 +0100

When a peer-push-credit transaction is in a KYC state, tries to merge the purse, but the merge has already been done into another reserve (presumably by another wallet), wallet-core does not handle this situation properly. It simply retries, which is futile.

0011231: Merchant: Some beta-test cases need to be replayed to (maybe) reproduce money losses in relation to bank transfers

Thu, 12 Mar 2026 22:23:13 +0100

A beta tester could replay (after some successful transfers) the following unsuccessful transactions:
1. Bank transfer with minimal amounts for verification of the bank account before a deposit could be effectuated (Taler Wallet -> bank account). The transfer of CHF 0.01 from the bank account takes the same amount of time as a transfer bank account -> Taler Wallet (which is to be expected). But the CHF 0.01 from the bank account did not arrive anywhere, neither in the Taler Wallet nor back in the user's bank account. This was tested with Alpian Bank and PostFinance.

2. The KYC process needed to be performed over and over again for every deposit Taler Wallet -> bank
"I would expect to have to make exactly one transfer from a bank account to a wallet and then always be able to send money back. However, depending on the bank, it seems that KYC is required again when sending money back. It also seems that KYC expires after a few days and has to be done again."

3. Bank -> Taler Wallet with transfer amount too small, money arrives but flagged as "fee"
"If you create a transfer in the Taler Wallet for, say, CHF 10.00, but the transfer from the bank is only for CHF 5.00, CHF 5.00 will arrive in the wallet and CHF 5.00 will be listed as a “fee.” Basically, this works OK, but the naming is a bit strange."

4. Bank -> Taler Wallet with transfer amount too high --> money gets lost??
"If you create a transfer in the Taler Wallet for CHF 10.00, for example, but the bank transfers CHF 15.00, CHF 10.00 will arrive in the wallet. The extra CHF 5.00 will remain missing and will not be transferred back."

0011242: when multiple bank accounts are configured, the order is non-deterministic and causes extra notifications

Thu, 12 Mar 2026 22:20:22 +0100

See additional information for two e-mails that contain exactly the same info but in different order. We send these out every few hours, despite nothing changing except the order of bank accounts.

0011236: [qc] kyc status table problems

Thu, 12 Mar 2026 21:44:29 +0100

rows should not be clickable

there should be a button at the end for call to action

0011099: coin selection should minimize small coins [3h]

Thu, 12 Mar 2026 19:43:04 +0100

According to experiments by one of Mikolai's student's, the current coin selection results in a large number of small coins that aren't spent. We should try to spend small coins earlier.

0010899: Android wallet passes wrong currency to getExchangeWithdrawalInfo on currency conversion withdrawal

Thu, 12 Mar 2026 19:04:29 +0100

This seems to only happen when (1) there is CHF in the wallet and (2) we do a second NETZBON currency conversion withdrawal.

The getExchangeWithdrawalInfo *always* needs the exchange's native currency as the instructed amount. But it seems in *some* situations, the Android UI passes the conversion input currency instead.

Note that from an empty wallet, this *doesn't* happen.