Kérdés:
Az SHA256 kimenetének csonkítása 128 bitre
H M
2013-04-25 01:24:49 UTC
view on stackexchange narkive permalink

Tegyük fel, hogy 128 bites hash kimenetre van szükségünk / előnyben részesítjük, például 128 bites titkosítási kulcs előállításához, vagy más alkalmazásokban (pl. a fájlok integritásának ellenőrzése) kevesebb tárhelyet kell fogyasztanunk.

Nem nem ismerek új / szabványos / töretlen 128 bites kivonatolási funkciót, ezért úgy tűnik, hogy az SHA256-ot kell használnunk.

Az SHA256 kimenet 128 bitesre történő csonkolása elfogadható? Egy ilyen csonka hash biztonsága megegyezik-e egy 128 bites hash-szal? Mármint egy 128 bites hash-ot, amelynek nincs ismert sebezhetősége; határozottan nem MD5!

Van ötletem ennek megvalósítására: 

  MD5 (Truncate128 (SHA256_hash))

I nem tudom, hogy ennek lesz-e előnye / hátránya a biztonságnak.

Ezen a szálon meg kell említeni az AUTH_HMAC_SHA2_256_128 és az AUTH_HMAC_SHA2_512_256 neveket is, amelyek azok a nevek, amelyek [rfc8221] alatt (https://tools.ietf.org/html/rfc8221) az SHE-256/128 és az SHA-512/256 használatát javasolja az IKE /IPSec.Ez a szál segített megérteni, miért akarják csonkítani a kivonatot.
Kettő válaszokat:
Tom Leek
2013-04-25 01:31:49 UTC
view on stackexchange narkive permalink

Bár az SHA-256 névlegesen 256 bites kimenetet kínál, a kimenet 128 bitesre csonkításával kapcsolatban nem ismert semmilyen gyengeség, kivéve természetesen a rövidebb kimeneti hosszúságban rejlő gyengeségeket; például. az ütközési ellenállás a megvalósíthatatlan 2 128 -ról a lehetséges (de kemény) 2 64 -ra csökken.

Ez nem a hash függvények általános tulajdonsága (* ), de némileg "nyilvánvaló" az SHA-256 meghatározásának módja alapján. Különösen, amikor a NIST definiálta az SHA-224-et, egy hash függvényt 224 bites kimenettel, akkor csupán az SHA-256-ot vették, külön inicializáló vektorral és csonka kimenettel.

(* ) Megmutatható, hogy egy adott biztonságos hash függvény csonkítva nem lehet borzasztóan rossz, de mégis kissé rosszabb lehet a vártnál. Az SHA-256 esetében a csonkolás biztonságosnak tűnik.

user25151
2013-04-25 01:45:11 UTC
view on stackexchange narkive permalink

Ahogy Tom most mondta, az integritás érdekében az SHA-256 kimenetet 128 bitesre csonkíthatja, mert az 128 ütem elegendő az ütközések ésszerű elkerülésére.

Azonban az olyan hash funkciók, mint az SHA-256, nem alkalmasak kulcsgenerálás vagy fájl hitelesség (csak integritás).

Ha kulcsot akar létrehozni, használjon valami hasonlót, mint a PKBDF2 vagy a scrypt. Ha fájlt szeretne hitelesíteni, használjon HMAC függvényeket (amelyek az SHA- 256.).

Forrás: Bevezetés a Coursera kriptográfiájába.

Ha kulcsot akar létrehozni * jelszóból *, akkor a PBKDF2-re vagy a scryptre van szüksége. Ha mesterkulcsból akarja generálni, akkor a sima SHA-256 rendben van, bár a jó stílus a HKDF lenne.
Az adatok hitelesítése összetett téma. Néha kivonatot szeretne (például megváltoztathatatlan fájlok esetén), néha MAC-ot (a HMAC-SHA-2 a kedvenc MAC-om), néha digitális aláírást, a kívánt szemantikától függően. A csonka SHA-2 (k || m) egy biztonságos MAC btw, feltéve, hogy elegendő bitet vág el. Különösen az SHA-512/256 (k || m) elég erős, és az SHA-256/128 (k || m) is megfelelő.
Igazad van, az adatok hitelesítésének nemcsak egy jó módja van. De az SHA-2 (k || m) kiszolgáltatott a [hossz-kiterjesztéses támadásoknak] (https://en.wikipedia.org/wiki/Length_extension_attack)
Tudom, de a csonkolás megakadályozza a hosszhosszabbítási támadást. Az SHA-256/128 (k || m) biztonsági szintjének körülbelül 128 bitnek kell lennie egy 128 bites kulccsal. Nem használnám további elemzések nélkül, de azt remélem, hogy biztonságos lesz.
Én sem értek egyet az első mondattal. Míg a 128 bit bőven elég az előképekkel szemben, csak 64 bit ütközési ellenállása van, ami a határon kivitelezhető. Természetesen nem bíznék az SHA-256/128 ütközésállóságában.


ⓘ
Ezt a kérdést és választ automatikusan lefordították angol nyelvről.Az eredeti tartalom elérhető a stackexchange oldalon, amelyet köszönünk az cc by-sa 3.0 licencért, amely alatt terjesztik.
Loading...