Kryptera med hashar?

Försöker hitta på ett bra sätt (för skoj) att kyptera mha. godtycklig kryptografiskt säker hash.

Det jag tänkte var följande "algoritm":


Tycker att det borde hålla rätt bra mot "known plaintext attack".
Säg att jag känner till data0. Då kan jag ta data0 xor block0 och få ut nyckel0, men det
ger mig ändå inte nyckel1 eller nyckel2 eftersom jag ändå inte kan få fram lösenordet på det viset.

Mönster i datat syns inte eftersom vi har en kedja av hashar där nyckeln hela tiden kommer att förändras. Kravet på en krypografisk hash är att en liten förändring i data (säg en bit) inte skall ge en snarlik hash, utan det skall ge en, till synes, slumpmässig hash.

Kärnan är altså i att vi har den här magiska hash fuktionen som vi antar är kyptografiskt säker.

Varför är det här en dålig ide?
Det är beräkningsmässigt dyrt att räkna ut alla hasharna, men folk minar ju bitcoins, så det är klart att det är görbart om man vill.

Är det osäkert?

Du gör alltså ett block cipher där den enda operation som görs på blocket är xor, och en keystretchingalgoritm där du rekursivt utökar nyckeln genom att kombinera resultatet av föregående iteration med nyckelordet, för att generera en nyckel som är lika lång som meddelandet.

Ja, det är sårbart för flera olika typer av angrepp.

Först och främst vill jag säga att du av misstag snuddat vid det enda koncept som gör det omöjligt att ens i teorin knäcka ett skiffer; en nyckel som är lika lång som klartexten. Då kan du varken angripa nyckeln eller skiffertexten.

Två saker krävs dock för att detta ska vara sant; nyckeln måste vara fullständigt slumpmässig, och du får inte använda samma nyckel till mer än ett meddelande. Bryter du mot någotdera kan du i teorin alltid få fram klartexten, och i praktiken rätt ofta.

Eftersom varje nyckel bara får användas en gång kallas detta system ofta för "one time pad", något du säkert känner igen. Du kanske också känner till att Japan under slutet av andra världskriget började använda detta system, och att de allierade knäckte ett dugligt antal av dessa meddelanden? Då var ändå nycklarna perfekt slumpmässiga.

Din genererade nyckel är inte ett dugg slumpmässig, och det gör dig sårbar för known ciphertext-attacker, och då är det ingen större mening att fundera på om den är sårbar för known plaintext. Vilket den också är, även partial, för övrigt.

Eftersom din algoritm utgår från ett lösenord kommer det med rätt stor sannolikhet skickas flera meddelanden med samma nyckel, vilket gör att man kan knäcka den relativt enkelt.

Och sist, men inte minst; man kan angripa lösenordet, eftersom man bara behöver testa första hashen mot det första blocket i meddelandet, och förkasta alla resultat som är uppenbart fel. Här skulle du vara hjälp av att padda ett antal block med äkta slumpdata, för att göra det mer tidskrävande att generera en tillräckligt lång nyckel.

Om du genererade en fullkomligt slumpmässig nyckel, och gjorde det för varje meddelande, skulle din algoritm vara säker, men eftersom du då måste lämna över nyckeln till mottagaren på ett säkert vis, och den då är lika lång som meddelandet, skulle du lika gärna kunna lämna över meddelandet direkt.

Jag är ingen kryptoexpert, men det måste gå att utnyttja att du återanvänder nycklarna. T ex, vad händer om någon gissar två följande meddelanden, t ex data2 och data3? Då kan dom få fram både nyckeln och saltet som användes för just den nyckeln, och då måste det väl gå att reverse-hasha fram lösenordet?

Jag tänker om man jämför med t.ex. AES. Den är ju inte i sig slumpmässig, men den bygger på ett state som hela tiden följer med.

Men, om man nu tänker sig en kommunikation med meddelanden, så finns det ju ingenting som hindrar att man då och då byter nyckel, eller "lösenord" i mitt fall. Typ var 10:e sekund eller så.

Säg att det man i stället för salt har ett psedurandom nummer.

Man kan ha en bankdosa som genererar de här numren utifrån en klocka. Mottagaren har en liknande dosa.

Då blir varje session unik.

Det känns lite misstänkt, men det borde inte gå att göra någon reverse-hash eller säga något om de andra hasharna utifrån en hash, förutsatt att hashen är kryptografiskt säker.

Det skulle ju inte heller i så fall, om det gick att göra en sådan attack, hjälpa att lägga in något unikt.

Det blir i så fall det som genererar det här unika som blir den svagaste punkten, och då kan man lika gärna ha den direkt som one-time pad.

Man kan också börja med att hasha 1000 gånger på nyckel0 innan man startar.

Om det tar 10 sekunder att generera nyckel0 så blir det inte lika roligt att bruteforcea.

Hasha en miljard gånger så har du ändå bara en hash.

Vidare - eftersom varje block bara råkar ut för 1 xor, så innebär det att 1 bit omslag i klartext slår om 1 bit i det krypterade resultatet. Det är förkastligt, om du inte använder engångsnyckel så du aldrig kan kryptera två lika eller nästan lika texter med samma nyckel.

Funderar på om det skulle gå att avhjälpa lgenom att baka in t.ex block0 i nyckeln för data1 osv. Men det hjälper egentligen inte.

Ett annat faktum ät att så fort man hashar något som är längre än antalet bitar i hashen så försvinner information (duvslagsprincipen).

Det betyder att för varje block så finns det n antal okända lösenord som avkrypterar dem, inte bara ett.

Det känns som en dålig egenskap.

Din konstruktion påminner om https://blog.cryptographyengineering...odel-and-why-2 där IV för blockN är utbytt mot nyckelN-1 i stället för att ökas med ett för varje block som krypteras.

EDIT:

Enligt Matthew Green så går det inte att härleda klartexten från chiffertexten om man antar att hashfunktionen är ett random oracle. Se länk ovan.


Hur menar du?

Lösenord+salt måste vara unikt för varje block, t ex genom att härleda en sessionsnyckel session_key = H(lösenord | timestamp) som du föreslår. Det är nog bättre att sätta salt till en räknare som man ökar med ett för varje block, vilket gör att det går att dekyptera flera block parallellt.


Det krävs fortfarande att du hittar två lösenord så att de hashar till samma nyckel, dvs hitta en kollision i hashfunktionen. Det är nog inget du behöver oroa dig för.

Den genererade nyckeln har egenskaper som gör det möjligt att både kraftigt reducera nyckelrymden, och att använda statisk analys för att angripa det krypterade meddelandet i sig.

En annan sak är att jag inte ser meningen med saltet, då det krävs för att kunna dechiffrera och alltså måste lämnas över tillsammans med nyckeln.

I en viss implementation av algoritmen så väljer man ett visst salt var tanken.
Då går det åt minstone inte att köra standard rainbowtables för t.ex. sha256 för att knäcka, utan man måste ta fram nya rainbow tables för denhär specifika implementationen.