View Issue Details

IDProjectCategoryView StatusLast Update
0009617Talerspecificationpublic2025-05-10 02:11
Reporterreynir Assigned ToChristian Grothoff Resolution deadline
ImplementerReviewer 
Release signed byDeployed by 
VerifierCommunicator 
Data protection authority notification requiredNo  
CSIRT notification requiredNo  
Estimated effort (hours)Actual effort (hours)0 
Fast-trackNo
Work packagenone
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version1.0Fixed in Version1.0 
Summary0009617: Deviations from Crockford's base-32
DescriptionIn the documentation it is mentioned that Crockford's base-32 is used with the deviation that 'U' is considered the same as 'V' with a link to Crockford's web page on base-32. Looking at the GNUnet 0.23.0 implementation in src/lib/util/strings.c it seems there are more differences:

- a minor nit pick, but 'u' is as well considered the same as 'V'
- Crockford's base-32 allows inserting dashes ('-') anywhere into the encoded string. They don't have any significance. They are not accepted by GNUnet
- Crockford's base-32 has an (in my opinion underspecified) optional checksum at the end which allows for extra symbols ('*', '~', '$', '=', 'U'/'u'). This is not implemented by GNUnet (and the 'U'/'u' conflicts with the 'V' alias).

Please excuse me if GNU Taler is using a different implementation of base-32 - it's a lot of code to search through :-)

https://docs.taler.net/core/api-common.html#binary-data
Additional InformationIt seems a lot of implementations of Crockford's base-32 deviate from the specification by not allowing dashes and/or not implementing checksums. However, the documentation links to Crockford's own specification.
TagsNo tags attached.

Required notifications

Address or linkRemarkAdded byNotifiedActions

Activities

Christian Grothoff

2025-03-13 13:29

manager   ~0024193

The text says 'u' == 'v' -- and Crockford/base32 is *always* case-insensitive. ;-).

You did find the correct implementation.

We should improve the spec to highlight the other differences you pointed out better.

Christian Grothoff

2025-03-13 13:37

manager   ~0024194

I clarified this in the documentation.

Issue History

Date ModifiedUsernameFieldChange
2025-03-13 09:40reynirNew Issue
2025-03-13 09:40reynirStatusnew => assigned
2025-03-13 09:40reynirAssigned To => Christian Grothoff
2025-03-13 13:29Christian GrothoffNote Added: 0024193
2025-03-13 13:37Christian GrothoffStatusassigned => informing
2025-03-13 13:37Christian GrothoffResolutionopen => fixed
2025-03-13 13:37Christian GrothoffFixed in Version => 1.0
2025-03-13 13:37Christian GrothoffNote Added: 0024194
2025-03-13 13:37Christian GrothoffProduct Version => git (master)
2025-03-13 13:37Christian GrothoffTarget Version => 1.0
2025-05-10 02:11Christian GrothoffStatusinforming => closed