diff options
| author | Ian Jackson <ijackson@chiark.greenend.org.uk> | 2023-03-07 13:20:13 +0000 |
|---|---|---|
| committer | Ian Jackson <ijackson@chiark.greenend.org.uk> | 2023-03-07 13:25:15 +0000 |
| commit | 9dee2f8efac9a03b1b1f64345c0faa0740c5a48c (patch) | |
| tree | 9ea8771f99ff6bee838d117927612701a222646f | |
| parent | 29fbf57f79658d036e940502c5ce975fcc388a36 (diff) | |
| download | torspec-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.
| -rw-r--r-- | tor-spec.txt | 2 |
1 files changed, 2 insertions, 0 deletions
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 |