This is an automated email from the git hooks/post-receive script.

nickm pushed a commit to branch main in repository torspec.

The following commit(s) were added to refs/heads/main by this push: new 9dee2f8 State that "base32" always means RFC4648, unpadded. new 71ed0ed Merge remote-tracking branch 'tor-gitlab/mr/119' 9dee2f8 is described below

commit 9dee2f8efac9a03b1b1f64345c0faa0740c5a48c Author: Ian Jackson ijackson@chiark.greenend.org.uk AuthorDate: Tue Mar 7 13:20:13 2023 +0000

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. --- tor-spec.txt | 2 ++ 1 file changed, 2 insertions(+)

diff --git a/tor-spec.txt b/tor-spec.txt index 69ed12e..34a3b44 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -109,6 +109,8 @@ see tor-design.pdf.

We use "byte" and "octet" interchangeably. Possibly we shouldn't.

+ Some specs mention "base32". This means RFC4648, without "=" padding. + 0.1.1. Encoding integers

Unless we explicitly say otherwise below, all numeric values in the