szyfrowane archiwum (AES vs ZIP 2.0)

W wielu źródłach można przeczytać (np tutaj: http://kb.winzip.com/kb/entry/80/), że jeżeli chodzi o bezpieczeństwo danych to standardowe szyfrowanie ZIP jest niezalecane. Stąd moje pytania:

1. Zastanawia mnie, jaka jest różnica w bezpieczeństwie danych przy zastosowaniu do łamania hasła metodu 'brute force'. Przy tej prymitywnej technice nie ma znaczenia jakim algorytmem zaszyfrowano dane? Przecież przy wpisywaniu wszystkich możliwych kombinacji znaków w końcu trafi się na właściwe hasło i algorytm szyfrowania nie ma znaczenia. Mam rację?
2. Skoro standardowy algorytm szyfrujący ZIP jest taki słaby to rozumiem ze istnieją inne techniki na uzyskanie hasła niż prymitywna, wspomniana juz metoda 'brute force'. Niestety nie udało mi się znaleźć nic na ten temat.

Google: "A Known-Plaintext Attack on the PKZIP Stream Cipher"

ZIP nie szyfruje nazw plików, więc możliwe staje się odgadnięcie zawartości któregoś pliku z archiwum w wielu przypadkach. Mając już plain-text można odgadnąć hasło do ZIPa sprytniej niż metodą brute-force.

W ZIPie jednak poszczególne pliki mogą być zaszyfrowane różnymi hasłami, przez co zmniejszając skuteczność ataku poprzez znajomość czystego tekstu (wtedy atak musiałby być oparty na znajomości początku atakowanego pliku), ale chyba mało kto to stosuje.

Przecież przy wpisywaniu wszystkich możliwych kombinacji znaków w końcu trafi się na właściwe hasło i algorytm szyfrowania nie ma znaczenia. Mam rację?
Ma znaczenie czy każda próba trwa jedną milionową sekundy, czy sekundę. Im algorytm bardziej obliczeniowo złożony, tym dłużej będzie trwało brute force.

(topic stary, ale dorzucę coś od siebie, jeśli by tu kiedyś ktoś trafił)

riker napisał(a):

1. Zastanawia mnie, jaka jest różnica w bezpieczeństwie danych przy zastosowaniu do łamania hasła metodu 'brute force'. Przy tej prymitywnej technice nie ma znaczenia jakim algorytmem zaszyfrowano dane? Przecież przy wpisywaniu wszystkich możliwych kombinacji znaków w końcu trafi się na właściwe hasło i algorytm szyfrowania nie ma znaczenia. Mam rację?

Musisz pod uwagę wziąć jeszcze długość klucza. W przypadku ZIP jest to 12 bajtów (konkretniej: 3 klucze po 4 bajty), czyli de facto 96 bitów.
Idąc dalej tym tropem, 96 bitów klucza daje maksymalnie 79228162514264337593543950336 kombinacji (7.9e28), czyli nawet zakładając, że brute forcer sprawdza 1mld (1e9) kluczy na sekundę, to, żeby wyczerpać wszystkie kombinacje potrzeba by 7.9e19 sekund, a więc 2512308552583 lat (tak, to trochę dużo) :)

Do tego trzeba wziąć pod uwagę fakt, że podstawowym kryterium przy brute force (mogą być inne oczywiście) jest sprawdzenie sumy kontrolnej z nagłówków (CRC32) z faktyczną sumą kontrolną danych, oraz dodatkowo w przypadku ZIP ostatni bajt lub dwa odszyfrownych danych mają być takie górne CRC32, to w najlepszym wypadku co 2.8e14 sprawdzonych kombinacji dostaniemy informacje, że znaleźliśmy klucz, pomimo, że rozszyfrowane dane będą niepoprawne (aka będą kolizje, które będą generować False Positives).
Kolizji w sumie w całej przestrzeni będzie 2.8e14, a więc i tak trzeba by wymyślić jakieś dodatkowe kryterium jak to przeglądać automatycznie. Na szczęście samo przeglądanie FP zajmie jedyne 3 dni (zakładając 1mld testów na sek), po tym jak spędzimy te 2512308552583 lat na ich znalezienie ofc :)
Ułatwieniem tu by była nieszyfrowana nazwa pliku, która mogłaby zasugerować jakie kryterium wybrać.

Ah - powyższe rozważania mają sens dla dobrego hasła oczywiście. Słabe hasło brute force połamie dużo szybciej :)
W przypadku dobrego hasła pozostaje plaintext attack (afair wymagana jest znajomość pierwszych 13 bajtów rozszyfrowanych danych).