Alat pembangun · SHA kalkulator cincang
Teks Sama, Berbeza SHA-256: Baris Baharu, Pengekodan dan Bait Tersembunyi
· Bagaimana ia berfungsi
sha-256 pengekodan pemprosesan teks penyahpepijatan
Baris arahan mengatakan satu perkara dan pelayar mengatakan yang lain untuk apa yang kelihatan seperti teks yang sama. Mengekori baris baharu, UTF-16 dan CRLF menerangkan hampir setiap kes; siaran ini menunjukkan cara mencari bait tersembunyi.
echo mengatakan satu cincangan, alat itu mengatakan yang lain - ketidakpadanan setiap hari dan mengapa kedua-duanya tidak salah
Terminal melaporkan satu ringkasan SHA-256 dan pelayar melaporkan satu lagi untuk perkara yang kelihatan seperti teks yang sama. Alat baris arahan tidak rosak, dan pelayar juga tidak. Bait yang dicincang tidak sama, walaupun aksara yang kelihatan kelihatan sama. Siaran ini mengesan sumber paling biasa bagi bait tersembunyi tersebut dan menunjukkan cara mencarinya dengan medan teks dan pemapar hex.
Masalahnya hampir tidak pernah algoritma SHA-256 itu sendiri. SHA-256 adalah deterministik: bait yang sama sentiasa menghasilkan ringkasan yang sama dan ringkasan adalah betul. Apabila output berbeza, bait berbeza. Kekeliruan timbul kerana "teks yang sama" adalah samar-samar: seseorang melihat aksara, tetapi fungsi cincang melihat bait, dan terjemahan di antara mereka adalah tempat perbezaan tersembunyi bersembunyi.
Baris baharu yang mengekori — cara gema menambahkan bait dan printf tidak, dan apa yang dilakukannya kepada penghadaman
Perintah gema dalam cangkerang menambahkan aksara baris baharu (U+000A, bait 0x0A) pada outputnya. Ini adalah dengan reka bentuk: konvensyen dalam Unix bahawa fail teks berakhir dengan baris baharu memberikan gema satu kerja mudah. Apabila anda menaip echo abc ke dalam terminal dan paipkannya ke sha256sum, bait yang dicerna adalah 61 62 63 0A (yang ASCII kod untuk a, b, c, dan bait untuk baris baharu), bukan 61 62 63. Alat itu ToolAcre digunakan untuk mengira cincangan cincang bait 61 62 63 dan menghasilkan hasil yang berbeza.
Perintah printf tidak menambah baris baru melainkan anda menulis satu ke dalam rentetan format. printf abc | sha256sum mengira ringkasan bait 61 62 63 sahaja, yang sepadan dengan alat pelayar. Inilah sebabnya mengapa membandingkan cincang sering bermaksud menjalankan printf dan bukannya gema, atau menyalurkan ke sha256sum dengan bendera -z, atau menentukan input mentah dalam apa jua bentuk yang disediakan oleh alat anda. Baris baharu tersembunyi ialah satu-satunya sebab paling biasa alat pelayar dan alat baris arahan tidak bersetuju.
UTF-8 berbanding UTF-16 — mengapa aksara yang sama adalah bait yang berbeza dalam sesetengah cengkerang dan editor
UTF-8 dan UTF-16 mengekodkan aksara yang sama dengan jujukan bait yang berbeza. Aksara é (U+00E9, e dengan aksen akut) dikodkan sebagai dua UTF-8 bait: 0xC3 0xA9. Dalam UTF-16, iaitu bagaimana JavaScript secara dalaman mewakili rentetan, aksara yang sama menduduki dua bait dalam susunan yang berbeza (bergantung pada endianness) atau bentuk yang berbeza sepenuhnya jika terdiri daripada aksara asas dan tanda gabungan. Apabila anda menyalin kafe daripada aplikasi Windows dan menampalnya ke dalam alat cincang pelayar, bait cincang alat itu mungkin tidak sepadan dengan cincang terminal Mac, kerana sistem lalai kepada pengekodan atau bentuk normalisasi yang berbeza.
Alat cincang ToolAcre secara eksplisit menukar teks kepada UTF-8 sebelum mencincang melalui TextEncoder. Ini adalah pengekodan yang sama yang digunakan baris perintah Unix secara lalai. Kod sumber dalam apps/dev/src/lib/base64.js menunjukkan fungsi textToBytes memanggil TextEncoder().encode() baharu, yang menjamin UTF-8. Jika sistem lain menggunakan UTF-16 atau Latin-1 atau sebarang pengekodan lain, bait yang dihasilkan akan berbeza. Alat ini memaparkan kiraan bait bersebelahan dengan ringkasan, itulah sebabnya menampal kafe dan membandingkan dengan cincang baris arahan akan menunjukkan kiraan bait yang berbeza jika pengekodan menyimpang.
CRLF, BOM dan normalisasi — penghujung baris, tanda tertib bait dan aksen tersusun berbanding terurai sebagai perbezaan input yang tidak kelihatan
CRLF (carriage return + line feed, bytes 0x0D 0x0A) ialah konvensyen penamat talian pada Windows; LF (suapan talian sahaja, bait 0x0A) ialah konvensyen Unix. Fail teks yang kelihatan sama apabila dibuka dalam editor teks boleh membawa pengakhiran baris yang berbeza, dan bait tersebut adalah sebahagian daripada input kepada cincang. Fail yang diedit pada Windows dan disemak terhadap SHA-256 yang dikira pada sistem Unix tidak akan sepadan jika satu sistem telah menukar penghujung baris dan yang lain tidak.
Tanda pesanan bait (BOM, bait 0xEF 0xBB 0xBF untuk UTF-8) ialah urutan pilihan pada permulaan fail yang menandakan pengekodan. Sesetengah editor menambahnya; beberapa alat menanggalkannya; ada yang mengabaikannya. Jika fail membawa BOM dan anda mencincangnya bait demi bait, BOM bait adalah sebahagian daripada ringkasan. Jika anda kemudian menyalin teks yang boleh dilihat (yang mana penonton menyembunyikan BOM daripada) ke dalam alat yang tidak menambah BOM, ringkasan tidak akan sepadan. Borang penormalan teks (NFD berbanding NFC untuk aksen tersusun dan terurai) tambahkan lapisan lain: huruf beraksen yang sama boleh diwakili sebagai aksara pragubah tunggal atau sebagai aksara asas diikuti oleh loghat gabungan, dan jujukan bait adalah berbeza.
Contoh yang berfungsi — satu rentetan dicincang dengan dan tanpa baris baharu, kemudian dalam dua pengekodan, dengan setiap perbezaan bait ditunjukkan
Kaedah diagnostik satu: gunakan alat pembuangan hex atau penukar dalam talian untuk melihat dengan tepat bait alat anda beroperasi. Tampal teks ke dalam pengekod base64, kodkannya dan anda mempunyai rekod teks bait. Kemudian nyahkod base64 pada baris arahan dengan base64 -d dan paipkannya ke od -A x -t x1z untuk melihat jujukan bait hex. Jika bait sepadan, algoritma adalah betul; jika tidak, perbezaannya akan kelihatan.
Kaedah diagnostik dua: gunakan kalkulator cincang ToolAcre SHA untuk mencincang input yang lebih panjang secara beransur-ansur, bermula dengan satu aksara. Tambah baris baharu (yang bermaksud menaip Enter di dalam kotak teks), tambah ruang, tambah teks yang sama dengan UTF-16 urutan pelepasan aksara jika input datang daripada sumber bukan ASCII. Tonton perubahan pencernaan dengan setiap penambahan. Kiraan bait yang dipaparkan bersama ringkasan memberitahu anda berapa banyak bait yang dicincang oleh alat, yang menyempitkan carian secara mendadak.
Sarung hex dan ruang kosong dalam output — perbezaan yang semata-mata kosmetik
Perwakilan heksadesimal bagi pencernaan adalah tidak peka huruf besar-kecil. Huruf besar dan huruf kecil kedua-duanya mewakili bait yang sama: A = 10, a = 10. Sesetengah alat mengeluarkan huruf besar, beberapa huruf kecil, ada yang membenarkan sama ada. Jika satu digest adalah huruf kecil dan satu lagi adalah huruf besar, mereka adalah digest yang sama. Ruang kosong dalam paparan ringkasan adalah kosmetik semata-mata. Ikhtisar yang dipaparkan sebagai ba78 16bf berbanding ba7816bf adalah sama; ruang hanyalah pilihan pemformatan. Ketidakpadanan yang disebabkan oleh kes atau ruang kosong bukanlah ketidakpadanan sebenar.
Perbezaan pemformatan lebar tetap juga tidak kelihatan pada tahap bait. Ikhtisar yang ditunjukkan dengan tanda sempang, ruang atau titik bertindih (seperti ba-78-16-bf) ialah konvensyen pemformatan yang memudahkan manusia membaca, bukan perubahan kepada bait sebenar. Alat ToolAcre sentiasa mengeluarkan huruf kecil tanpa pemisah, yang merupakan format yang kebanyakan alat baris arahan dicetak. Jika anda membandingkan dengan alat yang mengeluarkan secara berbeza, tukar kepada perwakilan yang sama dahulu.
Perkara ini tidak meliputi — pencincangan fail, di mana prinsip yang sama digunakan tetapi bait datang daripada cakera dan bukannya medan teks
Kalkulator cincang ToolAcre SHA melakukan penukaran UTF-8 sebelum pencincangan, memaparkan kiraan bait input dan menawarkan bentuk output asas64 dan heksadesimal. Fail sumber apps/dev/src/lib/hash.js menunjukkan fungsi hashText yang memanggil digestBytes, yang menghantar bytes.slice().buffer kepada crypto.subtle.digest. Komen dalam fail itu secara eksplisit mendokumenkan bahawa langkah UTF-8 adalah disengajakan dan perhatikan perbezaan antara pengekodan yang berbeza. Menguji input anda terhadap vektor yang diketahui (cincang abc kepada ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad dalam hex) membuktikan bahawa alat pelayar berfungsi dengan betul; sebarang sisihan menunjukkan perbezaan bait dalam input.
Pencincangan fail mengikut prinsip yang sama. Bait dalam fail adalah perkara yang penting: perbezaan pengakhiran baris apabila anda mengeksport dari satu sistem dan mengimport ke sistem yang lain boleh mengubah setiap ringkasan. Sesetengah alat menawarkan pilihan untuk mengendalikan penghujung baris semasa perbandingan; yang lain mencincang fail itu sebagaimana adanya. Mengetahui sama ada alat anda mencincang fail sebagai binari atau melakukan penormalan teks terlebih dahulu adalah penting untuk kebolehulangan.
Bawa pulang: bait cincang, bukan teks — kalkulator cincang ToolAcre SHA mencincang bait yang anda tampal, jadi semak perkara yang anda tampal dahulu
Perbandingan dan pengesahan sahaja berfungsi apabila anda mencincang bait yang sama. Mulakan dengan mengesahkan anda sedang mencincang input yang sama: jalankan echo -n (atau printf) dan bukannya gema untuk mengelakkan baris baharu, nyatakan pengekodan UTF-8 secara eksplisit jika alat anda membenarkannya, pastikan CRLF belum dimasukkan oleh editor atau utiliti sistem. Kemudian cincang dengan kalkulator ToolAcre dan alat baris arahan bersebelahan. Jika cernaan sepadan, baitnya adalah sama. Jika tidak, gunakan paparan kiraan bait dan kaedah pembuangan hex untuk mencari perbezaan tersembunyi.
Sebaik sahaja anda memahami di mana bait menyimpang, anda boleh memilih sama ada untuk menormalkannya sebagai perbandingan. Sesetengah checksum bertujuan untuk mengesahkan integriti fail sama seperti ia wujud pada cakera, dalam hal ini pencincangan bait-untuk-bait adalah matlamatnya. Yang lain bertujuan untuk mengesahkan bahawa kandungan yang boleh dilihat adalah sama, dalam hal ini menormalkan pengakhiran baris dan pengekodan adalah betul. Tidak salah; mereka menjawab soalan yang berbeza. Algoritma SHA-256 sentiasa betul; persoalannya hanyalah sama ada anda memintanya untuk mencincang input yang sama dalam kedua-dua kes.