Base32- / Base58-muunnin

Ne ovat kaksi vastausta yhteen kysymykseen: kanava, joka kuljettaa tekstiä, pyydetään kuljettamaan tavuja. Base32 ja Base58 eivät ole salausta eivätkä tiivistämistä — ne eivät piilota mitään eivätkä lyhennä mitään. Ne kirjoittavat tavujonon uudelleen kiinteällä joukolla luettavia merkkejä, ja kuka tahansa, joka tietää, mitä joukkoa käytettiin, voi kääntää sen suoraan takaisin. Ainoa syy suosia toista on se, mitä vastaanottava pää merkeillä tekee.

Kaksi perhettä tekee tuon uudelleenkirjoituksen täysin eri tavoin, ja ero selittää lähes jokaisen yllätyksen tällä sivulla:

• Bittipakkaus — Base32, Base32 Hex, Crockford Base32, z-base-32. Tavut leikataan kiinteisiin ryhmiin, ja jokainen viisi bittiä muuttuu yhdeksi merkiksi. Tulosteen pituus on ennustettavissa syötteen pituudesta, ja viimeinen, osittain täytetty ryhmä merkitään täytemerkeillä tai jätetään lyhyeksi.
• Suuren luvun muunnos — kaikki Base58-taulukot. Koko tavujono luetaan yhtenä valtavana lukuna kantaluvussa 256 ja kirjoitetaan uudelleen kantaluvussa 58. Ryhmiä tai täytettä ei ole; pituus ei jakaudu mihinkään, ja jokainen johtava nollatavu muuttuu yhdeksi johtavaksi nollamerkiksi.

Jokainen aakkosto on tulostettu kokonaan kuvaamisen sijaan, koska kaksi työkalua, jotka tulostavat eri merkit saman nimen alla, eivät ole samaa mieltä keskenään nimestä riippumatta. RFC 4648 -rivit ovat normatiivisia; Crockford- ja z-base-32-rivit seuraavat formaatin tekijän julkaisemaa; kolme Base58-riviä ovat laajalle levinneitä konventioita eikä standardeja, minkä vuoksi ne on lueteltu erikseen.

Aakkosto jättää pois I, L, O ja U, jotta mikään merkki ei voi lukeutua toiseksi. Jäljelle jäävä ei välitä kirjainkoosta sisään tullessa: i ja l luetaan numeroksi 1, o numeroksi 0, ja tavuviivat ovat olemassa vain merkkijonon lukemisen helpottamiseksi. Lisäksi formaatti määrittelee valinnaisen tarkistusmerkin, joka on merkkijonon arvo luettuna kantaluvun 32 lukuna, otettuna modulo 37, ja kirjoitettuna viidellä ylimääräisellä symbolilla arvoille 32-36.

Tarkistusmerkki lasketaan merkkijonosta, ei tavuista: koska enkooderi täydentää viimeisen ryhmän nollilla, samojen merkkien dekoodaus palaa aina samaan arvoon. Siksi taulukon tarkistusarvon voi laskea käsin pelkästä koodatusta sarakkeesta. Viisi ylimääräistä symbolia ovat *, ~, $, = ja U arvoille 32, 33, 34, 35 ja 36, joten tarkistusmerkki ei ole aina numero tai kirjain.

z-base-32 säilyttää RFC 4648 Base32:n viiden bitin pakkauksen ja muuttaa vain kolmenkymmenenkahden merkin järjestystä. Järjestys on valittu niin, että merkit, jotka ihminen todennäköisimmin joutuu kirjoittamaan muistiin, ovat helpoimmin kirjoitettavia ja vaikeimmin sekoitettavia. Siinä ei ole täytettä, joten lukijan on tiedettävä, kuinka monta symbolia arvon odotetaan sisältävän; se on hinta muodosta, joka on suunniteltu luettavaksi ensin käsin.

Pelkkä Base58 ei pysty erottamaan väärin kirjoitettua merkkijonoa oikeasta, koska lähes mikä tahansa yhdistelmä sen viidestäkymmenestäkahdeksasta merkistä on kelvollinen luku. Base58Check korjaa tämän kääräisemällä datan: yksi versiotavu, sitten hyötykuorma, sitten SHA-256:n ensimmäiset neljä tavua, sovellettuna kahdesti kahteen ensimmäiseen osaan. Vastaanottava ohjelma laskee nuo neljä tavua uudelleen ja hylkää merkkijonon, jos ne eroavat. Versiotavu kertoo lompakolle, katsotaanko maksuosoitetta, skriptiosoitetta vai yksityistä avainta.

Muuntimen alla oleva generaattori ottaa versiotavun ja hyötykuorman heksadesimaalina ja kirjoittaa Base58Check-merkkijonon; tarkistin lukee sen takaisin, erottaa neljä tarkistustavua, laskee ne uudelleen ja ilmoittaa sekä löydetyn että odotetun. Väärä tarkistussumma tarkoittaa, että merkkijono on kirjoitettu väärin tai muutettu — se ei koskaan tarkoita, että hyötykuorma itsessään on väärin, koska hyötykuormaa ei koskaan tulkita.

• "Base64 on salausta." Ei ole. Avainta tai salaisuutta ei ole; kuka tahansa voi kääntää tuloksen. Base32 ja Base58 ovat samassa asemassa, eikä arvon vieminen kaikkien kolmen läpi lisää suojaa.
• "Base58-merkkijono on Bitcoin-osoite." Vain silloin, kun se läpäisee myös Base58Check-tarkistussumman ja kantaa vastaanottavan ohjelmiston tunnistaman versiotavun. Base58-merkkijonoja esiintyy monissa muissa paikoissa, myös yksinkertaisissa tunnisteissa ilman mitään tarkistussummaa.
• "Kolme Base58-aakkostoa ovat keskenään vaihdettavissa." Ne käyttävät samoja viittäkymmentäkahdeksaa merkkiä kolmessa eri järjestyksessä, joten samat tavut tuottavat kolme eri merkkijonoa. Työkalulle on kerrottava, mitä käyttää, ja tämä sivu kertoo aina, mitä se käytti.
• "Täyte kuuluu arvoon." =-merkit merkitsevät vain viimeistä ryhmää. Kaksi Base32-merkkijonoa, jotka eroavat vain täytteessään, kuvaavat samat tavut, minkä vuoksi dekooderi hyväksyy merkkijonon, josta täyte on leikattu pois.
• "Mitkä tahansa merkit käyvät." Jokainen aakkosto on kiinteä joukko. Sen ulkopuolisella merkillä ei ole arvoa, joten dekooderi pysähtyy ja nimeää merkin ja sen paikan arvaamisen sijaan.

Miksi Base32 käyttää merkkejä 2-7 eikä 0-9? Koska RFC 4648 valitsi aakkoston pysyäkseen verkkotunnuksessa sallituissa merkeissä ja jotta sen ääneen lukeminen on helppoa. Base32 Hex käyttää 0-9 A-V silloin, kun luonnollinen järjestäminen on tärkeämpää.

Miksi Base58-merkkijono alkaa usein merkillä 1? Jokainen syötteen johtava nollatavu muuttuu yhdeksi johtavaksi 1:ksi (Bitcoin- ja Flickr-aakkoston ensimmäinen merkki). Versiotavu 0x00 on yksi nollatavu, joten useimmat Bitcoinin pääverkon osoitteet alkavat tasan yhdellä 1:llä.

Mitä Esimerkki-painike lataa? Järjestelmän ja tällä hetkellä näkyvän suunnan kuuluvan esimerkin, ei koskaan kiinteää tekstiä. Enkooderille annetaan järjestelmän oman esimerkin teksti — RFC 4648:n osion 10 vektorit Base32:lle ja Base32 Hexille, Crockfordin 12345 ja yllä tulostetut z-base-32-rivit — ja dekooderille annetaan valitun aakkoston koodattu merkkijono, mikä tekee esimerkistä käyttökelpoisen molempiin suuntiin. Kolme Base58-riviä kantavat tarkoituksella saman tekstin, joten vaihdettaessa järjestelmää ja painettaessa Esimerkkiä uudelleen näkyy kolme järjestystä samoista viidestäkymmenestäkahdeksasta merkistä vierekkäin. Kun Crockford-tarkistusmerkki on valittu, dekooderille annetaan arvo symboli lopussa, mikä on ainoa tapa nähdä tarkistimen hyväksyvän sellaisen.

Lähetetäänkö tietojani minnekään? Ei. Jokainen muunnos tapahtuu tässä selainvälilehdessä, eikä sivulla ole minkäänlaisia verkkoyhteyksiä. Siksi se toimii myös, kun tiedosto avataan suoraan levyltä.

Mitä salaisuudelle kannattaa käyttää? TOTP- ja HOTP-todennussovellusten salaisuudet ovat yleensä Base32 RFC 4648 -aakkostossa, koska salaisuus on kirjoitettava käsin. Käytä sitä, mitä vastaanottava ohjelmisto pyytää, äläkä koskaan luota koodaukseen itseensä salassapidossa.