Aloha!
(Jag misstänker att den här postningen riskerar att fastna i div skräpfilter…)
Kollegan och polaren I tog för några dagar sedan en titt på kryptot Helix.
Helix är ett strömkrypto utvecklat av bland andra Bruce Schneier och Niels Ferguson. Några av de intressanta egenskaperna med Helix är att det är ett snabbt krypto med låga resurskrav och att den har ett inbyggt stöd för meddelandeautenticering (MAC). Tillsammans gör detta Helix itressant att titta på för inbyggda system.
Det I upptäckte när han började läsa igenom artikeln som specificerar Helix var att det bland annat skall finnas testvektorer och en referensimplementation. Schneier & Co skriver:
The authors will maintain a web site at http://www.macfergus.com/helix with news, example code, and test vectors.
Men det man får när man går till den webbplatsen är inte testvektorer, utan saker av det här slaget:
Någonting har uppenbarligen hänt med Niels Fergsons webbplats. Whois visar att macfergus.com ägs MacFergus BV och senaste uppdateringen skedde i mitten av januari. Men MacFergus verkar inte ha speciellt mycket att göra med ägarna till phentermine-google.com, vilket är där man landar.
Schneier har kontaktats. Förhoppningsvis blir det här fixat i närtid. Jag skulle dock gärna se att testvektorer och referensimplementationen flyttas till samma ställe som specifikationen för Helix.
Sedan kan man iofs fundera på om Helix i dag är ett bra val. Det har så vitt jag vet inte publicerats några analyser som visar på svagheter med Helix, men för dess syskon eSTREAM-kandidaten Phelix finns det problem.
Uppdatering 2008-01-31
Jag har fått ett svar från Niels Ferguson som säger att han skall ta tag i sin webbplats. Har dock inte hänt något uppenbart än.
No related posts.
Related posts brought to you by Yet Another Related Posts Plugin.
Håller med om att Helix/Phelix är intressanta då de ger en MAC i princip gratis. Det finns en attack på Helix, presenterad på FSE2004. Det krävs dock att man kan tvinga fram återanvändande av nonce om jag minns rätt.
Aloha!
Alf: Den artikeln hade jag missat, tack för infon. Problematiken påminner om den för Phelix där det var kravet på att ej återanvända nonse som fällde Phelix. Som eSTREAM-organisationen uttryckte det:
Thus many observers have asserted that [10] does not count as an attack.
However, the Phelix designers do claim that key recovery should not be
possible even if the nonce is re-used and [10] clearly invalidates this
claim.
Furthermore, we believe that the attack does constitute a genuine threat
against real life systems using Phelix. It does seem plausible that an
attacker would be able to mount an attack against such a system, re-
using nonces, and that recovering the key would be a serious outcome.
Attackers are not usually bound by usage rules. With some regret we
have decided not to advance Phelix. However we believe the algorithm
has good features and we encourage further research along these lines.
Jag tycker spceciellt om meningen: “Attackers are not usually bound by usage rules.” 😉
Har du någon koll på om man ser det som en nackdel att klartexten är involverad i uträkningen av nyckelström? Man kan ju ibland läsa att strömchiffer har fördelen (över blockchiffer) att man kan generera nyckelström innan man har tillgång till klartext. Därmed kan man snabba upp kryptering/dekryptering när klartexten väl finns eftersom endast xor återstår.
Hur fungerar det i inbyggda system/andra praktiska tillämpningar? Har det någon som helst betydelse?
Aloha!
Alf: Menar du att data passerar genom blockkryptot vs att man i strömkryptot kör XOR med nyckelströmmen? Och att det i blockkryptofallet skulle vara ett säkerhetsproblem?
Jag har iaf inte sett någon sådan frågeställning. Blockkrypton bedöms utifrån sina egenskaper att skramla indatat tillräckligt bra. Och som jag uppfattat det är den relativa nyckelstyrkan/bit samma.
Sedan kör man ju alltid ett blockkrypto med en kryptomod. Och tar du ex GCM kan du förberäkna nyckelström på samma sätt som för ett strömkrypto, så där är det ingen egentlig skillnad.
Men jag hängde nog inte helt med vad du avsåg…
Aloha!
En sak till. Tittar man ex på ZigBee använder man där AES-128 i en variant av CCM-mod kallad CCM*. Tittar du sedan på mobilsystem används A5/1 i GSM, vilket är ett strömkrypto, men KASUMU i 3G vilket är ett blockkrypto. Så i inbyggda system används både blockkrypton och strömkrypton.
Jag menar inte att det är en nackdel säkerhetsmässigt. Bara att man inte kan generera nyckelström innan klartexten finns tillgänglig, vilket är fallet i nästan alla andra strömchiffer. Det kan snabba upp systemet eftersom man bara har xor kvar att utföra när man väl har fått klartexten.
Dock så har jag bortsett från att man får “gratis” MAC och att man naturligtvis måste ha klartext för att räkna MAC. Så i jämförelse med valfri authenticated encryption mode så är det ingen skillnad. Det känns som om jag kanske jämför äpplen med päron.
Aloha!
Ok då begriper jag mer.
Det finns som sagt bra kryptomoder (CTR, GCM etc) för blockkrypton som gör att man kan bygga upp nyckelmaterial i förväg. Men att kunna göra detta är helt klart en bra egenskap. Speciellt för inbyggda system där man i vissa fall kan sänka klockfrekvensen om man inte har så bråttom och bygga upp sitt förråd med nyckelmaterial i bakgrunden.
En detalj att komma ihåg är dock att för trafik med okänd mängd data, eller tom “oändlig” mängd data fungerar detta mindre bra. För ex bulkkrypto får man räkna med att köra kryptoalgoritmen i takt med datat iaf.
Och om mängden data är okänd men begränsad, finns det risk att man får timout-problem när poolen med nyckelmaterial är slut? Ger detta upphov till ett säkerhetsproblem i sig?
Bra frågeställningar Alf!