Konverter Base32 / Base58

Keduanya adalah dua jawaban untuk satu pertanyaan: saluran yang membawa teks diminta membawa byte. Base32 dan Base58 bukan enkripsi dan bukan hashing — keduanya tidak menyembunyikan apa pun dan tidak memperpendek apa pun. Mereka menulis ulang string byte menggunakan himpunan karakter yang tetap dan mudah dibaca, dan siapa pun yang tahu himpunan mana yang dipakai dapat langsung membalikkannya. Satu-satunya alasan memilih salah satu di atas yang lain adalah apa yang dilakukan pihak penerima terhadap karakter-karakternya.

Dua keluarga melakukan penulisan ulang itu dengan cara yang sama sekali berbeda, dan perbedaannya menjelaskan hampir setiap kejutan di halaman ini:

• Pengemasan bit — Base32, Base32 Hex, Crockford Base32, z-base-32. Byte dipotong menjadi grup tetap dan setiap lima bit menjadi satu karakter. Panjang output dapat diprediksi dari panjang input, dan grup terakhir yang terisi sebagian ditandai dengan karakter padding atau dibiarkan pendek.
• Konversi bilangan besar — setiap tabel Base58. Seluruh string byte dibaca sebagai satu bilangan yang sangat besar dalam basis 256 dan ditulis ulang dalam basis 58. Tidak ada grup dan tidak ada padding; panjangnya tidak terbagi menjadi apa pun, dan setiap byte nol di depan menjadi satu simbol nol di depan.

Setiap alfabet ditampilkan lengkap alih-alih dideskripsikan, karena dua alat yang mencetak karakter berbeda dengan nama yang sama tidak akan sepakat satu sama lain, apa pun labelnya. Baris RFC 4648 bersifat normatif; baris Crockford dan z-base-32 mengikuti yang dipublikasikan penulis format; ketiga baris Base58 adalah konvensi yang meluas dan bukan standar, itulah sebabnya dicantumkan secara terpisah.

Alfabet membuang I, L, O, dan U sehingga tidak ada simbol yang bisa terbaca sebagai simbol lain. Yang tersisa tidak peka huruf besar-kecil saat dibaca: i dan l dibaca sebagai digit 1, o dibaca sebagai digit 0, dan tanda hubung hanya ada agar string panjang lebih mudah dibaca. Selain itu format ini mendefinisikan simbol cek opsional, yaitu nilai string simbol dibaca sebagai bilangan basis 32 lalu diambil modulo 37, dan ditulis dengan lima simbol tambahan untuk nilai 32 sampai 36.

Simbol cek dihitung dari string simbol, bukan dari byte: karena encoder menambahkan nol di depan grup terakhir, mendekode karakter yang sama selalu kembali ke nilai yang sama. Itulah sebabnya nilai cek dalam tabel dapat direproduksi dengan tangan hanya dari kolom terkode. Lima simbol tambahan adalah *, ~, $, =, dan U untuk nilai 32, 33, 34, 35, dan 36, sehingga simbol cek tidak selalu berupa angka atau huruf.

z-base-32 mempertahankan pengemasan lima bit dari RFC 4648 Base32 dan hanya mengubah urutan ketiga puluh dua karakternya. Urutannya dipilih agar karakter yang paling mungkin perlu dituliskan seseorang adalah yang paling mudah ditulis dan paling sulit tertukar. Formatnya tidak memiliki padding, sehingga pembaca harus tahu berapa simbol yang diharapkan dalam sebuah nilai; itulah harga dari format yang dirancang untuk dibaca dengan tangan terlebih dahulu.

Base58 sendiri tidak punya cara membedakan string yang salah ketik dari yang benar, karena hampir setiap kombinasi dari lima puluh delapan karakternya adalah bilangan yang valid. Base58Check memperbaikinya dengan membungkus data di dalam pembungkus: satu byte versi, lalu payload, lalu empat byte pertama SHA-256 yang diterapkan dua kali berturut-turut pada dua bagian pertama. Program penerima menghitung ulang empat byte itu dan menolak string tersebut ketika berbeda. Byte versi itulah yang memberi tahu dompet apakah ia sedang melihat alamat pembayaran, alamat skrip, atau kunci privat.

Generator di bawah konverter menerima byte versi dan payload dalam heksadesimal dan menulis string Base58Check; verifikator membacanya kembali, memisahkan empat byte checksum, menghitungnya ulang, dan melaporkan checksum yang ditemukan serta yang diharapkan. Checksum yang tidak cocok berarti string salah ketik atau berubah — itu tidak pernah berarti payload-nya yang salah, karena payload tidak pernah diinterpretasikan.

• "Base64 adalah enkripsi." Tidak. Tidak ada kunci dan tidak ada rahasia; output dapat dibalik oleh siapa pun. Base32 dan Base58 berada dalam posisi yang sama, dan memindahkan nilai melalui ketiganya juga tidak menambah perlindungan.
• "String Base58 adalah alamat Bitcoin." Hanya jika juga lolos checksum Base58Check dan membawa byte versi yang dikenali perangkat lunak penerima. String Base58 muncul di banyak tempat lain, termasuk pengenal biasa tanpa checksum sama sekali.
• "Ketiga alfabet Base58 dapat saling menggantikan." Mereka memakai lima puluh delapan karakter yang sama dalam tiga urutan berbeda, sehingga byte yang sama menghasilkan tiga string yang berbeda. Sebuah alat harus diberi tahu mana yang digunakan, dan halaman ini selalu menyebutkan alfabet yang dipakainya.
• "Padding adalah bagian dari nilai." Karakter = hanya menandai grup terakhir. Dua string Base32 yang hanya berbeda pada padding-nya menggambarkan byte yang sama, itulah sebabnya dekoder menerima string yang padding-nya dipotong.
• "Karakter apa pun bisa dipakai." Setiap alfabet adalah himpunan tetap. Karakter dari luar himpunan tidak memiliki nilai, sehingga dekoder berhenti dan menyebut karakter beserta posisinya alih-alih menebak.

Mengapa Base32 memakai 2-7 dan bukan 0-9? Karena RFC 4648 memilih alfabet agar tetap berada dalam karakter yang boleh dipakai nama domain, dan agar mudah dibacakan keras-keras. Base32 Hex memakai 0-9 A-V sebagai gantinya bila pengurutan alami lebih penting.

Mengapa string Base58 sering diawali 1? Setiap byte nol di depan input menjadi satu 1 di depan (karakter pertama alfabet Bitcoin dan Flickr). Byte versi 0x00 adalah satu byte nol, sehingga sebagian besar alamat mainnet Bitcoin diawali tepat satu 1.

Apa yang dimuat tombol Contoh? Contoh yang sesuai dengan skema dan arah yang sedang ditampilkan, bukan teks tetap. Encoder diberi teks contoh milik skema itu — vektor RFC 4648 bagian 10 untuk Base32 dan Base32 Hex, 12345 milik Crockford, baris z-base-32 yang dicetak di atas — dan dekoder diberi string terkode untuk alfabet yang dipilih, dan itulah yang membuat contoh berguna di kedua arah. Tiga baris Base58 membawa teks yang sama dengan sengaja, sehingga mengganti skema dan menekan Contoh lagi menampilkan ketiga urutan dari lima puluh delapan karakter yang sama berdampingan. Dengan simbol cek Crockford dicentang, dekoder diberi nilai dengan simbol di ujungnya, dan itulah satu-satunya cara untuk melihat verifikator menerima satu simbol.

Apakah halaman ini mengirim data ke mana pun? Tidak. Setiap konversi berlangsung di tab browser ini, dan halaman tidak berisi panggilan jaringan apa pun. Itulah sebabnya halaman ini juga bekerja ketika file dibuka langsung dari disk.

Mana yang sebaiknya dipakai untuk rahasia? Rahasia authenticator TOTP dan HOTP biasanya berupa Base32 dalam alfabet RFC 4648, karena rahasia itu harus diketik dengan tangan. Gunakan yang diminta perangkat lunak penerima, dan jangan pernah mengandalkan pengodean itu sendiri untuk kerahasiaan.