Base32

Bita dalam tiga puluh dua karakter, dan digit yang ditinggalkan

Base32 menulis bita sebagai teks, dengan tiga puluh dua karakter yang masing-masing mewakili lima bit, sehingga setiap lima bita — empat puluh bit — menjadi delapan karakter. Hello terdiri atas lima bita dan ditulis JBSWY3DP. Pilih “Dekode” lalu tempel Base32, dan halaman ini mengembalikan bita yang diwakilinya: sebagai teks, atau sebagai heksadesimal jika Anda menyetel “Bita sebagai” ke “Heksadesimal”.

RFC 4648, yang mendefinisikannya, memakai dua puluh enam huruf besar dan digit 2 sampai 7. RFC itu menyebutkan alasan 0 dan 1 tidak ada: siapa pun yang menangani teksnya bisa dengan mudah salah mengira 0 sebagai O, dan 1 sebagai l atau I, jadi alfabetnya mempertahankan huruf-huruf itu dan meninggalkan kedua digit tersebut. Selain huruf, alfabet itu memerlukan enam digit, dan enam yang diambilnya adalah 2 sampai 7, jadi 8 dan 9 juga tidak ada di dalamnya. Saat mendekode dalam alfabet ini, halaman ini menolak 0, 1, 8, atau 9 di tempatnya, alih-alih membaca 0 sebagai O atau 1 sebagai I: RFC itu mengizinkan pendekode membacanya begitu, dan mengatakan bahwa secara bawaan hal itu sebaiknya tidak dilakukan.

Besar-kecil huruf bukan bagian dari nilainya. RFC 4648 merancang Base32 untuk teks yang harus dibaca tanpa memandang besar-kecil huruf, jadi jbswy3dp adalah Hello, sama seperti JBSWY3DP. RFC itu menulis alfabetnya dengan huruf besar, begitu pula halaman ini kecuali Anda menyalakan sakelar “huruf kecil”. Pembacaan juga melewati karakter spasi di mana pun, termasuk pemutus baris, sehingga Base32 yang dipecah menjadi kelompok atau dipisah ke beberapa baris terbaca seolah ditulis bersambung.

Padding, dan panjang yang mungkin dimiliki Base32

Jumlah bita jarang merupakan kelipatan lima. Satu sampai empat bita yang tersisa di ujung memakan dua, empat, lima, atau tujuh karakter, dan RFC 4648 melengkapi kelompok terakhir itu hingga delapan dengan =: sebanyak enam, empat, tiga, atau satu. Jadi f adalah MY======, fo adalah MZXQ====, foo adalah MZXW6=== dan foob adalah MZXW6YQ=, sedangkan fooba, lima bita, tepat mengisi delapan karakternya sebagai MZXW6YTB.

Maka, jika dihitung per delapan, karakter sebelum = mana pun selalu bersisa 0, 2, 4, 5, atau 7 dan tidak pernah 1, 3, atau 6, karena tidak ada jumlah bita yang menyisakan sebanyak itu; halaman ini menolak teks seperti itu di karakter terakhirnya alih-alih membacanya sebagai sesuatu yang lebih pendek. Padding tidak mengatakan apa pun yang tidak dikatakan panjangnya, jadi halaman ini membaca Base32 yang ditulis tanpa padding — JBUQ adalah Hi, sama seperti JBUQ==== — dan menolak padding hanya di tempat padding itu ada dan salah: = di tengah, dengan bagian teks lain sesudahnya, atau jumlah = yang salah di ujung, tempat penolakannya menyebut berapa banyak yang semestinya ada di sana.

Saat mengodekan, sakelar “Padding” menentukan apakah = ditulis. Sakelar itu menyala saat halaman dibuka, karena RFC 4648 meminta padding kecuali spesifikasi yang memakainya menyatakan lain, dan beberapa spesifikasi memang demikian: Key Uri Format, yang menjelaskan otpauth:// URI dalam kode QR 2FA, menyatakan bahwa padding pada rahasia sebaiknya dihilangkan, dan catatan NSEC3 serta IPFS tidak menulis padding sama sekali. Sakelar “huruf kecil” di sampingnya menulis huruf-hurufnya sebagai huruf kecil; digit dan = tidak punya besar-kecil huruf untuk diubah. Kedua sakelar itu hanya ada saat mengodekan, karena pembacaan menerima setiap kombinasinya.

Alat lain membaca lebih sedikit daripada halaman ini. GNU coreutils menulis Base32 dengan base32, dan base32hex, alfabet kedua, dengan basenc --base32hex; modul base64 milik Python punya fungsi untuk masing-masing. Semuanya menulis apa yang ditulis halaman ini saat dibuka, dengan padding dan dalam huruf besar. Namun base32 -d menolak Base32 tanpa padding atau berhuruf kecil, dan b32decode milik Python juga menolak keduanya, serta hanya membaca huruf kecil jika diberi casefold=True:

# Writing: the default Alphabet, then the other one
printf 'Hi' | base32                          # JBUQ====
printf 'Hi' | basenc --base32hex              # 91KG====

# Reading back: padded, then without padding, then in lowercase
printf 'JBUQ====' | base32 -d                 # Hi
printf 'JBUQ' | base32 -d                     # base32: invalid input
printf 'jbuq====' | base32 -d                 # base32: invalid input

# The same in a script
import base64
base64.b32encode(b'Hi')                       # b'JBUQ===='
base64.b32hexencode(b'Hi')                    # b'91KG===='
base64.b32decode('JBUQ')                      # binascii.Error: Incorrect padding
base64.b32decode('jbuq====', casefold=True)   # b'Hi'

Dua alfabet: base32 dan base32hex

RFC 4648 mendefinisikan alfabet kedua, base32hex: digit 0 sampai 9, lalu huruf A sampai V, sehingga karakternya berurutan menurut nilai yang diwakilinya, dari 0 untuk nol sampai V untuk tiga puluh satu. Itu memberinya satu sifat yang tidak dimiliki alfabet pertama, sebagaimana ditunjukkan RFC itu: dibandingkan karakter demi karakter, teksnya terurut menurut urutan bita yang diwakilinya. Bita 00 adalah AA====== dalam base32 dan 00====== dalam base32hex, dan bita FF adalah 74====== dan VS======; jika diurutkan sebagai teks, base32 menaruh FF lebih dulu, karena digit diurutkan sebelum huruf, sedangkan base32hex menjaga bitanya tetap berurutan.

Catatan NSEC3 milik DNSSEC memakainya. Nama catatan semacam itu diawali hash dari nama domain, dengan hash itu ditulis dalam base32hex tanpa padding, dan RFC 5155 mencatat bahwa, bila ditulis begitu, nama-nama yang di-hash terurut dalam urutan yang sama dengan urutan nilai hash-nya. Zona contoh milik RFC itu sendiri meng-hash example menjadi 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom. Dengan base32hex terpilih, halaman ini membaca 32 karakter itu sebagai 20 bita hash tersebut; dengan base32 terpilih, halaman ini menolak 0 tersebut — dan pemberitahuan mengatakan bahwa teks itu terbaca utuh dalam base32hex, dengan tombol untuk beralih di sampingnya.

Karena bita yang sama menjadi teks yang berbeda di masing-masing alfabet — Hi adalah JBUQ==== dalam base32 dan 91KG==== dalam base32hex — alfabet yang Anda pilih berlaku di kedua arah, dan halaman ini tidak pernah mengubahnya untuk Anda. Ketika teks yang Anda dekode memuat karakter yang tidak dimiliki alfabet terpilih, atau berakhir dengan bit sisa yang bukan nol, yang dijelaskan pertanyaan-pertanyaan di bawah, sementara alfabet yang satunya membaca seluruh teks itu seperti yang akan ditulis penyandi, pemberitahuan mengatakannya, dengan tombol untuk beralih di sampingnya; alfabet hanya berganti ketika Anda menekan tombol itu atau memilihnya sendiri. Teks yang terbaca mulus oleh keduanya, seperti ABCDEFGH, dibaca dalam alfabet yang terpilih, karena tidak ada apa pun di dalamnya yang menyatakan mana yang dimaksud.

Tempat Base32 muncul: rahasia 2FA, alamat onion, dan IPFS

Dalam Key Uri Format, yang menjelaskan otpauth:// URI yang dapat dimuat kode QR penyiapan, rahasia di balik kode aplikasi autentikator ditulis dalam Base32: parameter secret pada URI itu berupa Base32, dan padding sebaiknya dihilangkan. Tempel rahasia seperti itu dalam huruf besar atau huruf kecil, dalam kelompok yang dipisah spasi atau ke beberapa baris, dengan atau tanpa = — tanda hubung di antara kelompok ditolak di tempatnya — atau tempel seluruh URI, dan halaman ini membaca rahasia dari URI itu dan mengatakannya. Apa arti parameter lain dalam URI itu, dan bagaimana rahasia menjadi kode yang ditampilkan aplikasi, adalah urusan Debugger kode TOTP / 2FA: panduannya menjelaskan URI itu dan parameternya, dan halamannya menghitung kodenya. Label dan penerbit di dalam URI itu persen-terkodekan, seperti yang diminta Key Uri Format, dan Pengode / pendekode URL membacanya.

Alamat onion Tor versi 3 juga merupakan Base32. Bagiannya sebelum .onion, sebanyak 56 karakter, adalah Base32 dari 35 bita: kunci publik layanannya yang berukuran 32 bita, checksum dua bita, dan bita versi, 03. Spesifikasi Tor menulis alamat-alamat contohnya dalam huruf kecil, dan 35 bita mengisi kelompok yang utuh, jadi tidak ada padding yang perlu dihilangkan. Tempel 56 karakter itu tanpa .onion, setel “Bita sebagai” ke “Heksadesimal”, dan bita terakhirnya terbaca 03.

IPFS menulis pengenal kontennya, CID, dalam Base32 secara bawaan mulai versi 1: dalam huruf kecil dan tanpa padding, sesudah satu huruf, b, yang bukan bagian dari Base32-nya melainkan menamainya — prefiks multibase, yang dilepas sebelum sisanya didekode. Jadi bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi, contoh dalam dokumentasi IPFS sendiri, ditolak utuh di sini, sebagai panjang yang tidak dihasilkan bita mana pun; tanpa huruf b itu, ia terbaca sebagai 36 bita, yaitu CID biner, yang diawali 01 untuk versinya.

Rahasia 2FA adalah bita, bukan teks

Contoh rahasia dalam Key Uri Format adalah JBSWY3DPEHPK3PXP, dan dokumen itu menguraikan nilainya sebagai sepuluh bita: karakter-karakter Hello!, lalu DE AD BE EF. Delapan karakter pertamanya, JBSWY3DP, secara tersendiri adalah Hello. Bila didekode di sini dengan “Bita sebagai” pada “Teks”, pilihan bawaan halaman ini, rahasia itu keluar sebagai Hello!, lalu U+07AD — DE AD kebetulan membentuk satu karakter, yaitu tanda aksara Thaana — lalu dua U+FFFD, masing-masing mewakili deretan yang bukan teks. Pemberitahuan di bawah hasilnya menghitung deretan yang diganti, menyebut bahwa yang pertama dimulai pada bita ke-9, yang bitnya berawal di karakter pada baris 1, kolom 13, yaitu 3, dan menyebut bahwa bitanya mungkin sama sekali bukan teks.

Rahasia sungguhan adalah bita acak, yang jarang membentuk teks, jadi bila didekode sebagai teks hasilnya adalah taburan karakter lepas dan U+FFFD yang tidak memberi tahu Anda apa pun tentang benar tidaknya rahasia itu. Untuk itulah “Heksadesimal” pada “Bita sebagai” ada. Pilih opsi itu, atau tekan tombol di samping pemberitahuan, dan rahasia yang sama ditampilkan utuh sebagai 48 65 6C 6C 6F 21 DE AD BE EF: bita itu sendiri, yang disimpan server dan menjadi bahan perhitungan setiap kode. Halaman ini tidak pernah beralih ke heksadesimal dengan sendirinya, jadi yang tampil di layar selalu yang Anda pilih.

Arah sebaliknya adalah pilihan yang sama, yang dibuat saat mengodekan. Kunci yang disimpan server sebagai heksadesimal adalah bita: pilih “Kodekan” dan setel “Bita sebagai” ke “Heksadesimal”, lalu tempel kunci itu — berspasi atau bersambung, dengan 0x di depan bita, sebagai larik bilangan atau sebagai dump heksadesimal dalam tata letak hexdump -C atau xxd — dan halaman ini menulis Base32 yang diterima aplikasi autentikator. Dari 48656C6C6F21DEADBEEF keluar JBSWY3DPEHPK3PXP, rahasia di atas; sepuluh bita mengisi kelompok yang utuh, dan kunci yang tidak demikian, misalnya kunci enam belas bita, keluar dengan = di belakangnya kecuali Anda mematikan padding, seperti yang diminta Key Uri Format. Heksadesimal yang keliru ditempel saat mendekode — digit heksadesimal berjumlah genap dan tidak ada yang lain selain karakter spasi, dalam bentuk yang dapat dibaca sebagai bita saat mengodekan — memunculkan pemberitahuan bahwa teks itu tampak seperti heksadesimal, dengan tombol di sampingnya yang beralih ke pengodean teks itu. Dan saat mendekode, “Unduh” menyimpan bita itu sendiri sebagai berkas bernama bytes.bin.

Base32 atau Base64, dan mengapa bukan alfabet Crockford

Base64 mengerjakan tugas yang sama dengan enam puluh empat karakter, empat untuk setiap tiga bita, sehingga teksnya sepertiga lebih panjang daripada bitanya, sedangkan teks Base32 tiga perlima lebih panjang. Yang dikorbankan Base64 demi itu adalah ketidakpekaan terhadap besar-kecil huruf: alfabetnya memuat huruf besar dan huruf kecil sebagai nilai yang berbeda, ditambah + dan /, jadi SGk= adalah Hi dan sgk= adalah dua bita lain. Base32 cocok untuk teks yang melewati sesuatu yang mengabaikan besar-kecil huruf, atau teks yang dibaca seseorang dari satu layar lalu diketik ke layar lain. Ketika Base64 yang ditempel di sini memuat + atau /, yang tidak ditulis Base32 mana pun, dan seluruhnya berbentuk Base64, ia ditolak dengan pemberitahuan bahwa teks itu tampak seperti Base64 dan tautan ke alat Base64, yang membaca Base64 sebagai teks.

Ada alfabet lain berisi tiga puluh dua karakter, dan halaman ini menawarkan kedua alfabet RFC 4648 dan tidak ada yang lain. Salah satunya adalah alfabet Douglas Crockford, yang mempertahankan kesepuluh digit dan meninggalkan I, L, O, dan U, dan yang dipakai format ULID. Crockford mendefinisikannya untuk menulis bilangan, dan bila dipakai untuk menulis bita ia punya dua jawaban: enam belas bita 00 sampai 0F, dikemas lima bit sekaligus seperti RFC 4648 mengemas bita, adalah 000G40R40M30E209185GR38E1W, dan bila dibaca sebagai satu bilangan 128-bit, seperti kedua puluh enam karakter ULID dibaca, bita-bita itu adalah 00041061050R3GG28A1C60T3GF. Halaman yang menulis bita dalam alfabet itu akan memilih salah satu dari keduanya atas nama Anda, tanpa Anda melihatnya.