The Register har publicerat en intervju med Erik Tews, Andrei Pychkine och Ralf-Philipp Weinmann – personerna bakom nya den nya attacken mot WEP. Klart intressant läsning om hur de gick till väga. Attacken bygger på den nya attack mot RC4 som Klein publicerade förra året – en attack som inte fick speciellt mycket uppmärksamhet.
Jag mailade till Ben Harris, personen bakom RFC 4345. Denna RFC som publicerades precis innan Kleins attack publicerades specificerar nya RC4-moder för RC4 till SSL - arcfour128 och arcfour128. I RFC:n anges att de första 1536 Bytes som genereras efter nyckelbyte skall kastas bort för att undvika läckage av nyckelinformation i de första 256 Bytes som genereras, något tidigare attacker visat på. Frågan jag hade var om de antaganden som görs i RFC 4345 fortfarande gäller? Jag bad Ben Harris att titta på Kleins attack. Hans slutsats är att:
I’ve only glanced through it quickly, but it looks to me like the attacks described there don’t affect RC4 as used in SSH (either RFC 4345 or RFC 4253). The attacks in sections 4 and 5 both seem to assume the existence of a large number (several thousand) of separate RC4 keystreams encrypted with keys that include a public IV.In SSH, RC4 is keyed with an entirely secret pseudo-random key generated by the exchange hash, and separate streams have entirely independent keys. This is precisely the countermeasure mentioned in the last paragraph of the paper.
Skönt att veta. Det jag funderar på ärFrågan är dock om den generella svaghet i arraybaserade krypton som använder modulär aritmetik för tillståndsuppdateringar ändå gör RFC 4345 ointressant. Borde vi kanske helt frankt se till att få bort RC4, ex till förmån för AES-CTR. Det verkar finnas ett starkt behov, intresse att fortsätta med RC4 - nästan oavsett vad som händer.
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.
Fördelen med RC4 är att den är extremt simpel att implementera och att den är snabb i mjukvara. Förutsatt att nyckel och IV hashas innan de används i KSA och att man kastar bort några bytes i inledningen så finns det inga svagheter i RC4 som kan utnyttjas i praktiken. Jag kan tänka mig att detta är en anledning till att man fortsätter använda den i t.ex. SSL.
En annan anledning kan vara att det är en gammal algoritm och det finns mycket kunskap redan om den. Detta gör att den går att lita på i större utsträckning än många andra algoritmer. Jämför t.ex med A5/1 och E0. Egenkonstruerade algoritmer som inte genomgick publik granskning innan de sattes i bruk. Detta misstag vill man helst inte göra om även om många envisas med att göra det. (Jag jämför inte med AES-CTR, den är klart bättre)
Att du behöver kasta bort 1536 Bytes är lite mer än “några bytes”. Och även på superskalära processorer med stora aliasfönster kommer du inte upp i en Byte/cykel i prestanda. Även med specialanpassad HW är det svårt att nå bättre än fyra cykler/Byte.
Dock har du helt rätt i att algoritmen är välbeprövad och dessutom väldigt enkel – både att komma ihåg och att implementera (jag har själv implementerat den ett flertal gånger, både i SW och HW).
Vi behöver helt klart algoritmer som blir snabba i SW och som är säkra. Det är därför eSTREAM är ett så intressant projekt.