Niebezpieczny świat.

Ostatnie wydarzenia coraz bardziej skłaniają mnie do – paranoicznego, przyznaję – wniosku, że żadne dane, niezależnie od tego jak zabezpieczane, nie są bezpieczne i prędzej czy później nastąpi ich ujawnienie. O ile tylko komuś będzie zależało.

Na początek – hasła. Niektóre portale, jak Allegro, trzymają hasła otwartym tekstem. Niezależnie od podjętych środków bezpieczeństwa, przy takim podejściu wyciek tych haseł jest IMHO kwestią czasu.

Wiele nie zmienia trzymanie skrótów (hashy) haseł. Ostatnio – poza małymi wyciekami polskimi typu JPwyciekły hashe haseł z Gawkera i niesolone hashe haseł z FSF. To drugie jest wielką porażką, bo mówimy o środowisku z – teoretycznie – wysoką świadomością dotyczącą bezpieczeństwa i spraw technicznych, a tymczasem korzystano z najsłabszej funkcji skrótu i w najgorszym wydaniu. Powinno być najlepiej, było najgorzej. Klasyczne szewc bez butów chodzi.

Zresztą, pomału można zacząć stawiać znak równości między wyciekiem hashy haseł (zwł. niesolonych), a wyciekiem samych haseł – crackery MD5 są coraz szybsze. Co prawda to tylko benchmark, ale najnowsza wersja crackera whitepixel, który podobno jest chyba obecnie najszybszy, sprawdza 33 miliardy (nie miliony, miliardy) kombinacji na sekundę (dla pojedynczego hasha). Na potężnym, co prawda (4 dwurdzeniowe GPU; 1,2 kW poboru prądu przy obciążeniu, 2700 USD w tej chwili), ale pojedynczym komputerze PC.

Inne funkcje skrótu też nie są wiele lepsze. SHA1 to wg tego benchmarku w tym momencie 390 milionów kombinacji na sekundę, oczywiście na pojedynczej maszynie. A przecież bez problemu można mieć tych maszyn więcej, i to za niewielkie pieniądze.

Ale nie tylko haseł się to tyczy. Dane, które nie powinny ujrzeć światła dziennego wyciekły z „wewnętrznego”, rządowego systemu. Oczywiście mowa o wikileaksowym Cablegate. Swoją drogą ciekawe, jak długo w tych okolicznościach w stanie nieujawnionym pozostanie polisa Wikileaks (dead link)?

Głośno też było o rzekomym backdoorze w OpenBSD, a konkretniej IPSEC, który miało zamieścić FBI 10 lat temu (celowo nie linkuję, AFAIK rozeszło się po kościach i backdoora nie było, ale nie śledziłem). Co nie jest takie niemożliwe, bo korzystając z różnych „dziwnych” właściwości matematyki, da się zmusić algorytm szyfrujący, by „wyciekał” klucze. W mało zauważalny sposób – na przykład 128 bajt zaszyfrowanej wiadomości, przexorowany przez arbitralny klucz, będzie ujawniał klucz, którym była szyfrowana cała wiadomość. Albo coś na podobnej zasadzie – sky – i wiedza matematyczna – is the limit.

I raczej nie wierzę w to, żeby programista – czy użytkownik, który zwykle nie ma wielkiej wiedzy matematycznej/kryptograficznej, był w stanie coś takiego zauważyć. Przykład tego widać było przy dziurze w OpenSSL w Debianie. Efekt był dość spektakularny – do każdego konta umożliwiającego logowanie SSH po kluczach można się było dostać przy – IIRC – maksimum 65 tys. prób (bo tylko tyle różnych kluczy było generowanych). Na dowolnym systemie. O ile tylko klucz publiczny użytkownika był generowany na podatnym Debianie.

Niedowiarkom przykład ciekawych właściwości matematycznych można łatwo i zrozumiale zaprezentować na przykładzie listy 18 ulubionych filmów. Oto test (przetłumaczyłem na polski, z wyjtkiem tytułów, polecam IMDB):

Zrób test i dowiedz się, jaki film jest twoim ulubionym. Ten prosty matematyczny quiz przewiduje, który z 18 filmów spodoba ci się najbardziej. Nie pytaj w jaki sposób, ale to działa!

  • Wybierz cyfrę z zakresu 1-9.
  • Pomnóż ją przez 3.
  • Do wyniku dodaj 3.
  • Otrzymany wynik ponownie pomnóż przez 3.
  • Zsumuj obie cyfry otrzymanej liczby. Wynik to numer twojego przewidzianego ulubionego film na poniższej liście:

Lista filmów:

  1. Gone With The Wind
  2. E.T.
  3. Blazing Saddles
  4. Star Wars
  5. Forrest Gump
  6. The Good, The Bad, and the Ugly
  7. Jaws
  8. Grease
  9. The Joy of Anal Sex With A sheep
  10. Casablanca
  11. Jurassic Park
  12. Shrek
  13. Pirates of the Caribbean
  14. Titanic
  15. Raiders Of The Lost Ark
  16. Home Alone
  17. Mrs. Doubtfire
  18. Toy Story

W zasadzie koniec mijającego roku widzę trochę na zasadzie do kogóż to włamano się dzisiaj? I to tylko patrząc na najgłośniejsze i ujawnione sprawy i dziury (taki wariant minimum dla administratora – trochę wypada się w security orientować)…

Korzystając z okazji – bo to ostatni wpis, życzę wszystkim użytkownikom komputerów (ze specjalnym uwzględnieniem adminów) w nadchodzącym Nowym Roku mniej dziur bezpieczeństwa i awarii.

UPDATE: Paranoje dotyczące postępującej szybkości łamania hashy studzi ten wpis o przechowywaniu haseł. Polecam.

Nie o takie CUDA chodziło…

Kupując laptopa wziąłem pod uwagę kartę graficzną (nie, żeby to było jakieś istotne kryterium, bo 99,9% spędza w 2D). W szczególności cieszyło mnie wsparcie dla CUDA – nawet mam plan zabawy w programowanie tego w chwili wolnej (czyli pewnie nigdy, ale…). Co prawda jest to niski model karty (Nvidia 8200M), na dodatek wersja mobilna i ze współdzielonym RAM, ale liczyłem, że w porównaniu do CPU to będzie ogień, czyli rząd wielkości szybsze.

Niedawno miałem okazję przetestować wydajność komputera, a zwłaszcza CUDA. Przy pomocy BarsWF (Windows only) zrobiłem szybki test. Wynik nierewelacyjny – ok. 45 M/sek, przy czym po 15 M/sek robi każdy rdzeń procesora i tylko 15 M/sek grafika. Nie wiem, czemu tak słabo (z tego, co rozmawiałem, sterownik nie powinien mieć wiele do powiedzenia – bardziej CUDA działa albo nie działa). W tej chwili jest standardowy z Windows Vista (system widzi ją jako 9200 IIRC).

Jakieś sugestie, jak zwiększyć wydajność CUDA na Nvidia 8200M? Wydajność na poziomie kolejnego rdzenia procesora to IMHO porażka. Sugerowane narzędzia do diagnostyki pod Windows (taktowanie karty, temperatura karty itp.)? Ograniczeń i problemów z przegrzewaniem się laptopowych Nvidii serii 8xxx jestem świadom, bardziej chciałem potestować, ile da się wycisnąć maksymalnie z tego sprzętu, niż liczyć coś produkcyjnie.

PS. Szczególnie wdzięczny byłbym, gdyby ktoś z podobną grafiką (Nvidia 8200M) pochwalił się swoimi wynikami z BarsWF.