Nawiązując do pytania z komentarzy odpowiadam: (prawie) każde szyfrowanie można złamać, TrueCrypt też. Wystarczy "tylko" znaleźć odpowiedni klucz, a jest to "tylko" kwestia czasu, w przypadku dobrego rozwiązania - bardzo długiego czasu. Trzeba przy tym uwzględnić fakt, że czas ten może zostać zredukowany nie tylko przez postęp techniczny, ale również przez kolejne osiągnięcia w kryptoanalizie (np. Nowy atak na AES-256 ).
Przykład szyfrowania, którego się "nie da" złamać to poprawnie użyty one-time pad, ale z dość oczywistych względów do szyfrowania dysków się nadaje umiarkowanie...
Więc nie opieraj bezpieczeństwa danych na utajnieniu algorytmu.
A nawet jesli uzywasz uznanych algorytmow - musisz robic to dobrze: http://labs.neohapsis.com/2010/01/19/even-if-you-dont-invent-your-own-crypto-its-still-hard/
Zastanawiam sie tylko nad tematem - skoro w kodzie aplikacji nie ma sensu obfuskacja samego algorytmu, nalezy jakos ukryc klucz (czy pare kluczy, czy IV, zwal jak chcial - chodzi o parametry algorytmu). Bo jesli ktos jest w stanie wydobyc klucz, wtedy moze juz wszystko. Jak dobrze ukryc klucz - czy sa na to jakies calkowicie pewne metody? Podejrzewam, ze nie, wiec caly ciezar przesunal sie na pisanie wymyslnych algorytmow ukrycia klucza do znanego algorytmu krypto. Czyli w sumie i tak wszystko jest do zlamania, bo liczy sie "najslabsze ogniwo".
Chyba, ze ktos zna jakas dobra metode na ukrycie klucza (w dowolnej technologii / architekturze) - robilem dorbny research w tym temacie, ale nic nie znalazlem.
Warto zwrócić uwagę choćby na Firefox lub Thunderbird, dostępna jest tam opcja "master password", wówczas hasła są szyfrowane unikalnym kluczem co jest bezpieczne, ale umiarkowanie wygodne. Gdyby KAŻDA aplikacja, która w jakiś sposób korzysta z haseł pytała mnie przy starcie o "master password", to chyba bym się lekko zirytował.
Można też szukać rozwiązań systemowych (wspominane kilka razy przeze mnie DPAPI), choć ono też ma swoje problemy zwłaszcza w kontekście ewentualnego "wrogiego kodu" działającego w systemie.
Myślałem (przypadek z życia wzięty) o aplikacji (WIN), która przesyła szyfrowane dane nt. własnej licencji w taki sposób, żeby użytkownik nie mógł tego podrobić (użytkownik nie może mieć dostępu do odszyfrowanych danych) - W związku z tym odpada deszyfrowanie podanymi przez użytkownika danymi, parametr musi być "gdzie indziej". Jeśli w aplikacji, to można go odkryć, jeśli jest przesyłany z zewnątrz, użytkownik może złamać samą transmisję.
Problem wygląda na nierozwiązywalny - DPAPI, o ile dobrze go zrozumiałem i tak opiera się na haśle uzytkownika. TPM - pewnie, ale to już hardware'owe ograniczenie. Czy znacie jakieś sprawdzone (czyli kosztowne do złamania) metody ukrycia tego klucza, czy też każdy wymyśla coś na własną rękę (np. producenci gier, które są łamane w godziny po premierze)?
Inaczej pewnie by tego nie ugryźli, bo odtworzenie algorytmu na podstawie surowego strumienia danych to strzelanie na ślepo - trzeba stawiać hipotezy dotyczące budowy algorytmu równocześnie z hipotezami dotyczącymi klucza.
W pełni zgadzam się Pawłem co do użycia haseł w aplikacjach - niestety, albo jest jakiś pochodzący z zewnątrz tajny parametr albo go nie ma. Tertium non datur DPAPI to spójny i sensowny mechanizm stanowiący kompromis pomiędzy wygodą użytkownika a bezpieczeństwem pod określonymi założeniami.
Co do ukrywania hasła w lokalnym systemie to w sensie jakościowym zawsze da się go wyciągnąć, jest to tylko kwestia włożonego w to wysiłku, czasu i pieniędzy. A to z kolei wynika z tego, jak wartościowa jest ukryta informacja. Metodami na maksymalizację tego kosztu jest np. TPM albo biblioteka obcode.
W roku 1933 i latach późniejszych walką było "już tylko" odtwarzanie kluczy dziennych, co na pewno nie było łatwe gdyż Niemcy pozbyli się luki w "protokole przekazania klucza" wiadomości.
EDIT: Cały oddzielny wpis w zasadzie zawierałby to, co jest zawarte w dokumentacji TrueCrypt w tym fragmencie: http://www.truecrypt.org/docs/?s=encryption-scheme
Oczywiście, szyfrant może być przebiegły i:
1) użyje trybu hidden
2) użyje zmodyfikowanego algorytmu
3) oprogramowanie będzie miał na USB, więc nie będzie go można zdeasemblować
I tak np. wystarczy użyć szyfru 3DES ze zmodyfikowanymi nieznacznie permutacjami wejściowymi (IP) i wyjściowymi, żeby uczynić wszelki próby łamania sprzętowego - nie mówiąc o zgadywaniu algorytmu - bezużytecznymi.
Dlatego HUMINT nadal jest tak ważne
I jeszcze jedna ciekawa opcja: mamy program deszyfrujący, ale użycie niewłaściwego hasła powoduje po prostu błędne „odszyfrowanie”, dostajemy bełkot. Jak odróżnić, czy dane odszyfrowaliśmy, czy nie? Zwłaszcza, jeśli zostały zaszyfrowane dwukrotnie: czy podajemy właściwe hasło, czy nie, dostajemy bełkot, z którym nie wiemy co (i w ogóle czy) zrobić.
Drugi temat - to zachowanie jest zupełnie normalne. Podasz nieprawidłowe hasło, wygenerowany zostanie nieprawidłowy klucz, dane zostaną odszyfrowane "prawidłowo", ale rezultat odszyfrowania będzie bzdurny. Nawet ostatnio spotkałem się z takim podejściem, co prawda nie przy szyfrowaniu, ale przy generowaniu haseł jednorazowych. Zastosowanie takiego podejścia przykładowo w TrueCrypt jest jednak niemożliwe.
A jak odzyskać / złamać hasło do zaszyfrowanej kontenera TrueCrypt? Zachciało mi się do jednego kontenera użyć nowego hasła Jednak nie zapisałem go..., a że nie używałem go później to teraz mam problem. Z tego co pamiętam hasło składa się raczej z pewnego mixu znanych mi ciągów znaków +może coś dodałem od siebie ponieważ podstawowe kombinacje moich wymyślonych i zapamiętanych ciągów nie działają.
Czy jest jakiś sposób na odzyskani tych danych (program/usługa/wróżka ) ?