W 9-tej wersji Acrobata firma Adobe wprowadziła rozszerzoną wersję algorytmu szyfrującego, wykorzystującą AES z kluczem o długości 256 bitów. Równocześnie jednak Elcomsoft - znany producent oprogramowania do łamania haseł w PDFach - pochwalił się, że szyfrowanie w wersji 9-tej jest stukrotnie łatwiejszy do złamania.
Szyfrowanie dokumentu hasłem jest obecne w specyfikacji PDF ("PDF Reference") od pierwszych wersji wypuszczanych na początku lat 90-tych. Za aktualny należy uznać algorytm dostępny z Acrobatem 7, który używa szyfrowania AES z kluczem 128 bitów ("algorytm 3.2", PDF Reference 1.7, str. 125) . Rozszerzona wersja została wprowadzona w Acrobacie 9 i jej specyfikacja znajduje sięw suplemencie ("algorytm 3.2a", Adobe Supplement to ISO 32000, str. 19).
Algorytm 3.2
Hasło użytkownika jest ograniczone do 32 znaków interpretowanych według bieżącej strony kodowej. Hasłą krótsze niż 32 bajty są uzupełniane stałym ciągiem, co ma dodatkowo tę konsekwencję że hasło puste przekłada się na stały klucz szyfrujący zbudowany na bazie tego stałego uzupełnienia . Uzupełnione hasło jest przepuszczane 50 razy przez funkcję MD5, której wynik daje klucz szyfrujący dla AES-128.
Algorytm 3.2a
Hasło jest konwertowane na UTF-8. Z tej reprezentacji do dalszego przetwarzania brane jest 127 znaków, taka jest więc maksymalna długość hasła w Acrobacie 9 (w przybliżeniu, bo znaki spoza ASCII w UTF-8 będą zajmować 2 bajty). Po dodaniu 64-bitowego losowego modyfikatora (Key Salt) hasło jest przepuszczane przez SHA-256. Wynik o długości 32 bajtów jest używany do rozszyfrowania dodatkowej wartości pośredniej używanej do implementacji uprawnień dokumentu i generowanej losowo ("algorytm 3.8").
Jak widać, algorytm używany w Acrobacie 9 pomija znany z PKCS#5 mechanizm wielokrotnego haszowania klucza wprowadzającego celowe opóźnienie przy konwersji hasła na klucz. Biorąc pod uwagę, że MD5 jest ok. 3,2x szybsze od SHA-256 ale powtarza się go 50x różnica w czasie wykonywania obu operacji może być mniej więcej piętnastokrotna. To znaczy w Acrobacie 9 liczenie klucza z hasła zajmie piętnastokrotnie mniej czasu niż w Acrobacie 7 i 8.
Jedyne uzasadnienie dla skrócenia tego czasu podane przez Adobe to przyspieszenie otwierania dokumentów zaszyfrowanych hasłem w Acrobacie 9 i cel ten niewątpliwie został osiągnięty. Równocześnie jednak przyspieszenie konwersji hasła na klucz jest przyczyną radości programistów Elcomsoftu, bo są w stanie w krótszym czasie przetestować wszystkie kombinacje hasła.
Wydaje mi się jednak, że przyspieszenie będzie widoczne tylko przy klasycznym łamaniu "brute force" polegającym na podawaniu wszystkich możliwych kombinacji hasła (lub słów ze słownika) na wejście algorytmu. Niewątpliwie przyspieszy to złamanie hasła trywialnego. Sprawdźmy - w wersji demo programu APDFPR 5.0 osiągnąłem następujące wyniki w łamaniu czteroznakowego hasła zawierającego małe i duże litery:
- Acrobat 7 - 128 bit security v.4 - 14'674 haseł na sekundę, czas łamania 3 minuty 20 sekund
- Acrobat 9 - 256 bit security v.5, 298'981 haseł na sekundę, czas łamania 10 sekund
Z drugiej strony nowy algorytm dzięki zastosowaniu salta powinien uniemożliwić stosowanie łamania hasła przez atakowanie skrótu hasła techniką "Rainbow Tables" (zwanych przez Elcomsoft "Thunder Tables"). Równocześnie znacząco zwiększone zostały zarówno długość hasła (do 127 znaków) oraz dopuszczalny zestaw znaków (praktycznie cały Unikod). O atakowaniu klucza kryptograficznego można właściwie zapomnieć już od Adobe Acrobat 6, który stosuje klucze o długości 128 bitów.
Można sobie zadać pytanie, dlaczego projektanci "algorytmu 3.2a" nie wprowadzili co najmniej pięciokrotnej pętli SHA-256? Dałoby to taki sam efekt opóźniający jak w "algorytmie 3.2". Równocześnie opóźnienie dla użytkownika jest raczej niezauważalne - na serwerze z procesorem 3 GHz w ciągu sekundy wykonuje się prawie 300 tys. operacji SHA-256 (i ok. 1 mln MD5), więc pięć w tę i we wtę nie robi dużej różnicy.
Warto dodać, że opisane algorytmy standardowe (czyli do Acrobata 8) są opisane w specyfikacji PDF dostępnej jako ISO 32000, ale nie polecam jej do porównywania z suplementem, bo pomimo niemal identycznej zawartości merytorycznej nie zgadzają się numery stron. W oryginalnej specyfikacji Adobe jest więcej praktycznych uwag i komentarzy, które w ISO wyczyszczone zapewne ze względu na przejrzystość dokumentu. Z drugiej strony w specyfikacji ISO jest znacznie więcej przykładów.