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!

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.

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.

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…

Hur fungerar det i inbyggda system/andra praktiska tillämpningar? Har det någon som helst betydelse?

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:

Phelix is a stream cipher with built-in authentication function and en-
couraging performance. However, Wu and Preneel [10] have published
an attack allowing efficient recovery of the secret key, if the attacker can
re-use the same nonce value more than once. This paper has been the
sub ject of much debate. The usage rules for Phelix explicitly forbid nonce
re-use; and it is clear that, for any algorithm like this, security
properties
fail (specifically, MAC forgery is possible) if nonce re-use is permitted.

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.”