aboutsummaryrefslogtreecommitdiff
path: root/bandwidth-file-spec.txt
diff options
context:
space:
mode:
authorIan Jackson <ijackson@chiark.greenend.org.uk>2023-03-07 13:20:13 +0000
committerIan Jackson <ijackson@chiark.greenend.org.uk>2023-03-07 13:25:15 +0000
commit9dee2f8efac9a03b1b1f64345c0faa0740c5a48c (patch)
tree9ea8771f99ff6bee838d117927612701a222646f /bandwidth-file-spec.txt
parent29fbf57f79658d036e940502c5ce975fcc388a36 (diff)
downloadtorspec-9dee2f8efac9a03b1b1f64345c0faa0740c5a48c.tar.gz
torspec-9dee2f8efac9a03b1b1f64345c0faa0740c5a48c.zip
State that "base32" always means RFC4648, unpadded.
I found src/lib/encoding/binascii.[ch] in the C Tor codebase. It has #define BASE32_CHARS "abcdefghijklmnopqrstuvwxyz234567" The function "base32_encode" says "Implements base32 encoding as in RFC 4648.". Now, that RFC says that it's supposed to be padded unless explicitly stated otherwise. However, the padding is pointless and neither our "base32_encode" nor our "base32_decode" seem to implemnet it. I hope that we are using the same base32 encoding everywhere, but have not checked.
Diffstat (limited to 'bandwidth-file-spec.txt')
0 files changed, 0 insertions, 0 deletions