"Niels Callesøe" <pfy@nntp.dk> wrote in message news:Xns91F889F746F56k5j6h4jk3@193.88.15.213...
åhvad, jeg hedder også Kasper, så jeg kan vel tillade mig..
> > 1) Generer en tilfældig symetrisk nøgle.
> > 2) Krypter beskeden med den nye nøgle. Helst i CBC mode.
> > 3) Krypter den nye nøgle under en fast nøgle.
>
> Hvorfor? Hvad skulle fordelen være ved dette i forhold til 1, stærk,
> nøgle?
Hvis man vælger at kryptere i CBC mode med en fast nøgle,
og den første del at to beskeder er ens, så vil den også være
ens i de krypterede udgaver, dette anses for at lække information.
For at undgå dette skal der enten bruges en initialiseringsvektor,
der bruges til at xor'e første blok med, hvorved beskederne
bliver forskellige.
Eller som foreslået, sessionsnøglen skal ikke være fast.
> > Det har desuden den fordel, at den faste nøgle så ikke
> > behøves være særlig effektiv. Den faste nøgle kunne f.eks.
> > være den offentlige nøgle i et asymetrisk nøglepar.
>
> Hvorfor ikke? Det ville da være logisk at angribe den svageste af de 2
> nøgler. Det eneste du, så vidt jeg kan se, får ud af din fremgangsmåde
> er at give en angriber 2 angrebspunkter i stedet for et - i hvert fald
> så længe den krypterede nøgle skal sendes over samme usikre medie som
> de øvrige krypterede data.
For at rette et angreb mod en af de nøgler der bruges, skal vi have
et plaintext/ciphertext par. For den fælles nøgle er dette det tilfældige
tal der bliver genereret=plaintext, og det tal der sendes frit=ciphertext.
Kun det ene er tilgængeligt, det andet ikke. Så ikke noget par.
Den sessions-nøgle der bruges til krypteringen af selve meddelelsen kan
godt angribes, idet vi antager at angriberen skaffer/gætter plaintext på
anden vis.
Men angriberen har så kun een meddelelse at arbejde med for en given
ukendt nøgle, en fordel idet man ikke kan læse mere end een besked
selvom man knækker sessionsnøglen, og der ikke kan bygges ordbog
selv med lille blokstørrelse.
>
> [snip]
> > Ved valget af algoritme til den symetriske nøgle er der
> > nogle muligheder. Der findes DES og 3DES, som er ved at
> > være noget forælede. De er ikke særligt effektive, og de
> > lider under en meget lille cifferblok på kun 64 bits.
> > DES har desuden en alt for lille nøgle på kun 56 bits.
> > På grund af de små blokke bør ingen DES eller 3DES
> > nøgle bruges til mere end en halv MB før den udskiftes.
>
> Lad os se bort fra "plain" DES, da den kan brydes med brute force,
> forudsat rimeligt store ressourcer.
>
> Så vidt jeg husker, er 3DES reelt ikke belastet af DES's lille
> blokstørrelse (jeg har ledt efter kilden, men kan ikke umiddelbart
DES/3DES, og ALLE andre algoritmer med en blokstørrelse på
64 bit har et problem når datamængden bliver stor:
http://lasecwww.epfl.ch/birthday.shtml
Problemet er at man kan opbygge en 'ordbog' og bruge
denne til at lære noget om beskederne, uden at man
nogensinde har brug for at kende nøglen.
Bemærk at hvis man bruger en ny nøgle hver gang, så kan angriberen
aldrig bygge en stor nok ordbog (med mindre man sender meget
store meddelelser)
> finde den), og har en nøglestørrelse på hhv. 112 eller 168 bit alt
> efter implementation (2 eller 3 nøgler). Kan du komme med nærmere
> dokumentation for at 3DES skulle have brug for udskiftning af nøgle
> efter kun en halv MB?
Ovenstående link giver sandsynligheden for at der er brugbare par
i de opsnappede data.
3DES med 3 stk 56 bit nøgler har ikke 168 bit hårdhed, idet der er
sære måder at angribe systemet på. (det mest ekstreme og måske
urealistiske ville være at opbygge en tabel for det sidste trin, hvilket
ville kræve 2^56 memory, men også spare en faktor 2^56 work.
Der findes udgaver af angrebet der virker med realistisk ramforbrug)
Så 3key-3DES er i størrelsesordenen 112-128 bit i arbejde.
> AES er formodentlig både stærkere og hurtigere end 3DES. (Hurtigere er
> den i hvert fald) Men den har ikke modstået mange års angreb og
> kryptoanalyse, sådan som 3DES har. Og mig bekendt er det endnu ikke
> lykkedes nogen at bryde 3DES, selv ikke ved known plaintext/chosen
> ciphertext. Hvorfor ikke bare vælge den løsning der har den bedste
> track record?
Fordi den har nogle andre ulemper (nøglestørrelse 112bit, blokstørrelse
64 bit, sløv i software, inversions fænomener o. lign. der giver en dårlig
fornemmelse) der gør, at man har lyst til at finde på noget der
passer bedre til dagens 32bittere.
Hvis vi er konservative, og antager at nogen finder på et 2^128 angreb
(de små grønne mænd med kvantemaskinerne lander? Mindst.), så
er 256 bit AES stadig 2^8 bedre end 3DES.
Og det er jo ikke just sådan at de bare har stemplet den til brug -
den var ude som forslag et par år. I denne tid ER der blevet kigget
på den; De (kryptofolkene derude) har forsøgt samtlige?
angrebsmetoder der er offentliggjort de sidste 40? år, i jagten på
hæder og ære.
Og den viden er naturligvis også gået i designet af AES. AES har
_ikke_ de særheder og sårbarheder der kendes for DES.
--
Hvis jeg selv skal komme med et forslag, så genererer man
en tilfældig symmetrisk nøgle, bruger den til at kryptere
meddelelsen med, kryptere nøglen med 'en halv
diffie-hellman', og lægger den ved. Så kan angriberen ikke
læse de sendte meddeleser selvom han stjæler den maskine
der har lavet dem. Kun dig med den anden halvdel (den
private eksponent) kan regne nøglen ud og dekryptere.
been there, done that, og det er relativt simpelt.
Slagfast elektronisk sparegris.
/Kasper