Hash Generator

[ DIGEST ]
d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592
256-bit digest of 43 bytes
Bits ng digest256
Bytes ng input43
Mga karakter43
[ LAHAT NG TATLO ]
SHA-256 · 256 bits
d7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592
SHA-384 · 384 bits
ca737f1014a48f4c0b6dd43cb177b0afd9e5169367544c494011e3317dbf9a509cb1e5dc1e85a941bbee3d7f2afbc9b1
SHA-512 · 512 bits
07e547d9586f6a73f73fbac0435ed76951218fb7d0c8d788a309d785436bbb642e93a252a954f23912547d1e8a3b5ed6e1bfd7097821233fa0538f3db854fee6
A plain hash is not a message authentication code. Anyone can compute one, so it proves a file has not changed, never who produced it. Use HMAC with a shared key for that.
[ ANO ITO ]

Ang hash ay function ng BYTES, hindi ng mga titik. Kaya walang kahulugan ang "SHA-256 ng isang string" hangga't hindi sinasabi kung anong encoding — at dito, palaging UTF-8. Isang karakter ang piso sign at tatlong byte, kaya ipinapakita ng pahina ang dalawang bilang.

Iyan din ang dahilan ng pinakamadalas na hindi pagtugma: ang newline sa dulo. Ang echo hello ay nagpapadala ng anim na byte, hindi lima, kaya ibang input na ang na-hash. Tingnan ang bilang ng byte kapag hindi tumugma ang isang halaga.

Ang hash at HMAC ay hindi magkapareho ang trabaho. Pinapatunayan ng hash na hindi nagbago ang datos. Kayang kuwentahin ninuman ang SHA-256, kaya kung kayang baguhin ng umaatake ang datos, kaya rin niyang kuwentahin ulit ang digest. Ang HMAC ay nangangailangan ng lihim na susi, kaya iyon ang nagpapatunay kung sino ang gumawa nito.

[ MGA TANONG ]

Bakit iba ang digest ko sa ibinibigay ng sha256sum?

Halos laging bagong linya sa dulo. Ang `echo hello` ay nagpapadala ng “hello\n” — anim na byte, hindi lima — kaya magkaibang input ang dalawang digest at hindi sila kailanman magtutugma. Gamitin ang `echo -n` o ang `printf`, o idikit ang teksto dito nang walang bagong linya. Iniuulat ng pahinang ito ang bilang ng byte sa tabi ng digest kaya nakikita ang pagkakaiba sa halip na maging misteryo.

Anong encoding ang ginagamit sa pag-hash ng teksto?

UTF-8. Ang hash ay function ng byte at hindi ng karakter, kaya walang kahulugan ang “ang SHA-256 ng isang string” hangga't walang pinapangalanang encoding. Mahalaga ito sa sandaling hindi payak na ASCII ang teksto: ang tandang piso ay isang karakter at tatlong byte. Iyon ang dahilan kung bakit ipinapakita ng pahina ang dalawang bilang.

Ano ang pagkakaiba ng hash at ng HMAC?

Pinapatunayan ng payak na hash na hindi nagbago ang datos. Pinapatunayan ng HMAC kung sino ang gumawa nito, dahil kailangan ng lihim na susi para makakuwenta ng isa. Kahit sino ay makakakuwenta ng SHA-256, kaya walang pinapatunayan ang hubad na digest — kung kayang baguhin ng umaatake ang datos, kaya rin niyang kuwentahin muli ang digest para tumugma.

Bakit hindi na lang pagsamahin sa hash ang susi at ang mensahe?

Dahil mahina ang SHA-256 sa length extension: ang pagkaalam sa hash ng lihim kasama ang mensahe ay nagpapahintulot sa umaatake na kuwentahin ang hash ng lihim na iyon kasama ang mas mahabang mensahe, nang hindi kailanman nalalaman ang lihim. Ang nakapugad na konstruksiyon ng HMAC ang nagsasara nito, at iyon ang buong dahilan ng pag-iral nito sa halip na maging basta kumbensiyon.

Bakit walang MD5 o SHA-1?

Sira silang dalawa para sa anumang umaasang mahirap ang banggaan, at pareho pa rin silang unang inaabot ng mga tao. Ang pag-aalok sa kanila katabi ng SHA-2 ay maghaharap sa kanila bilang usapin ng panlasa. Tunay na pangangailangan ang pagpapatunay ng lumang checksum na gawa ng iba at hindi iyon sapat na dahilan para maglabas ng sirang primitive dito.

Ano ang mangyayari sa tinitipa ko?

Walang umaalis sa browser mo. Ang mga hash function ay isinulat sa sariling calculation engine ng site na ito — hindi tinatawag sa network, at hindi kinuha sa third-party na library — kaya ang tekstong idinidikit mo ay hindi kailanman ipinapadala, itinatala o itinatago.

Tama ba ang mga implementasyong ito?

Sinusuri sila laban sa inilathalang test vector at hindi laban sa sarili nila. Ang SHA-256, SHA-384 at SHA-512 ay pinapatunayan laban sa FIPS 180-4, kasama ang kasong isang milyong byte, at ang konstruksiyon ng HMAC laban sa RFC 4231 — na ang kaso 6 ay sumasaklaw sa panuntunang madalas mapalampas ng kinamay na HMAC, na ang susing mas mahaba sa block ay hina-hash at hindi pinuputol.

[ ANG KOMPUTASYON ]
Ang tatlo, at ang laki ng digest
SHA-256256 bits · 64 hex
SHA-384384 bits · 96 hex
SHA-512512 bits · 128 hex

Ang SHA-384 ay hindi pinutol na SHA-512. Magkaiba ang panimulang halaga nila, kaya ang pagputol ng 48 byte sa SHA-512 ay nagbibigay ng iba at maling sagot.

[ ANG SUSING MAS MAHABA SA BLOCK ]

Sa HMAC, ang susing mas mahaba sa block ng algorithm ay hina-hash muna, hindi pinuputol. Ito ang linyang pinakamadalas na nakakalimutan sa sulat-kamay na HMAC — at kapag nakaligtaan, ang dalawang magkaibang mahabang susi ay puwedeng magbigay ng parehong MAC. Ang RFC 4231 case 6 ay umiiral para mahuli mismo ito, at sinusubok namin laban doon.

[ SUSUNOD ]
46Gumawa ng JWTWhere this HMAC does its real work
47Gumawa ng Secret KeyFor generating the key to sign with
44Base64 Encoder / DecoderThe other way a digest gets written down
61Lakas ng PasswordWhy hashing a password is not the same job
[ MAHALAGA ]

Computed in your browser and never transmitted. The implementations are verified against the FIPS 180-4 and RFC 4231 test vectors, but a digest is only as meaningful as the bytes you gave it — check the byte count if a value does not match one from elsewhere. Walang ipinapadala sa mga server namin ang tina-type mo rito — sa browser mo tumatakbo nang buo ang pagkuwenta.