Forum Debian Users Gang

1118

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:59:52)

uzytkownikubunt napisał(-a):

BTW Wiadomo już coś w sprawie włamania na kernel.org z 2011 roku? Obiecali, że opiszą co się stało...

Było, hasło kluczowe - backdoor w Proftpd, mieli jakąś dziurawą wersję.

W szyfrowanie pojedynczych plików też średnio wierzę, bo po prostu sam rozmiar szyfrowanego pliku i wiadomość, jakim sposobem szyfrowany, już decyduje o targecie ataku.

W przypadku TC albo Cryptsetup pliczek ma rozmiar partycji, co wymusza troszkę inny sposób postępowania, i znacząco utrudnia odszyfrowanie pojedynczych plików, a jeśli wzorem TC, w środku jednego kontenera szyfrowanego jest drugi ukryty, to już w ogóle niech ktoś powie, czy to puste miejsce, czy coś tam jeszcze jest. :D

Oczywiście na Dropboxa czy Google Drive wolałbym użyć GPG - o ile to możliwe, jest najlepszy do szyfrowania pojedynczych plików, i z racji znaczenia w Linuxie, jest pod największym nadzorem ekosystemu linuxowego. :D

Ostatnio edytowany przez Jacekalex (2014-12-31 23:07:16)

A gdzie te 300000 kluczy po jednym dla każdego pliku  trzymasz?

Pytam, bo w przypadku TC i Luksa  życzę radosnego łamania. :D
Pytam też dlatego, że klucz TC i Luksa może być np na pandraku - ten od dyzia, a na dyziu ten od pendraka.
I niech wtedy sobie łamią. :D

Jednak podobno już są sposoby, żeby ten klucz wyczesać z szyfrowanego kontenera, z drugiej jednak strony, dlaczego miałby się tam znajdować, kiedy ja dla TC wskazuję klucz na innym nośniku?

Chociaż i tak muszę Cię rozczarować, każdy program do szyfrowania kiedyś zostanie pokonany, dzięki temu "biznes się kręci".
Najpełniejszy i najbardziej hardcorowy sposób szyfrowania miał TC,
ale co się z nim stało, to widać "na załączonym obrazku". :P

Ostatnio edytowany przez Jacekalex (2014-10-12 21:12:58)

No tylko mogliby jakieś info postnąć, a nie jak kamień w wodę i nic..

A gdzie te 300000 kluczy po jednym dla każdego pliku  trzymasz?

No każdy plik ma klucz, którym został zaszyfrowany, zaszyty wewnątrz siebie. xD Wszystkie klucze szyfrujące pliki są zaszyfrowane innym kluczem — tym ciągiem 32bajtowym i on też jest zaszyfrowany, np. twoim hasłem do systemu. xD Dlatego bez uzyskania fizycznego dostępu do twojej maszyny, nie dasz rady wydobyć hasła rozkodowującego klucze szyfrujące poszczególnych plików. Niby używasz krótkiego pojedynczego hasła ale szyfrowanie odbywa się cholernie długim ciągiem i różnymi kluczami i nawet przechwycenie tego krótkiego hasła przez keylogger nie pomoże w odszyfrowaniu plików.

Poza tym, jest jeszcze jeden ciekawy ficzer związany z tym eCryptfs — możesz mieć szereg plików w jednym katalogu, który udostępnisz konkretnym użytkownikom, Każdy z nich ma innego 32bajtowego hasha i jeśli podmontuje u siebie ten katalog, zobaczy on tylko te pliki, które rozkoduje jego hash. Tego żaden LUKS nie potrafi. xD

Odradzam trzymania kluczy na pendrakach. To jest, podobnie jak biometria, fałszywe poczucie bezpieczeństwa, no chyba, że te klucze się umieści gdzieś między mbr i pierwszą partycją albo gdzieś w innym miejscu na dysku, grunt by wgrywać taki klucz w formie binarnej bezpośrednio na pena, a nie w postaci pliku na partycję.

To już są drobiazgi techniczne, do zrobienia.

Nie takie znowu drobiazgi — wszyscy trzymają pliki na penach i myślą, że są bezpieczni, bo przecie peny mają zawsze ze sobą i nikt im do kompa nie dostanie się. xD

Przy okazji, bawiłeś się Luksem, tam pendrak z kluczem tylko przy montowaniu musi być wsadzony, czy przez cały czas używania kontenera, czy tylko w momencie montowania?
Wczytuje go do pamięci RAM na czas sesji (chyba powinien).

No taka jest idea — odkodować klucz i załadować go do pamięci i wywalić hasło do kosza, choć z tym hasłem to różnie bywa.

Co do zdalnego łamania Luksa czy TC, to w ogóle paranoja, Linux aż tak spartolony nie jest, żeby zdalnie dało się przez neta po cudzym dysku szperać bez wyraźnego pozwolenia.

Tu chodzi o kontener na dropboxie, a ten jest udostępniony via NET i ludzie nie muszą ci na kompa włazić by dobrać się do kontenera, potem zostaje już tylko do złamania hasło, a to zwykle ludzie ustawiają sobie na <10 znaków i myślą, że skoro mają zaszyfrowane pliki AESem256 to nikt im się do plików na dropboxie nie dobierze, podczas gdy dostarczasz NSA kompletnego zbioru danych i wystarczy atakować pod kątem łamania hasła. To można wyeliminować przy stosowanie długich haseł, albo zwyczajnie przez keyfile trzymany lokalnie. Niemniej jednak z tym jest trochę roboty ale można zrobić z setup całkowicie transparentny dla użytkownika. Podczas gdy w ecryptfs masz "jedno" krótkie hasełko i poziom bezpieczeństwa jest porównywalny i nawet przekracza dobrze skonfigurowanego LUKSa. I o to tu chodzi o prostotę wykonania i implementacji. Poza tym,  Załóżmy, że jesteś gdzieś w terenie i potrzebujesz uzyskać dostęp do pojedynczego pliku z kontenera LUKSa, który masz na dropboxie. Ten kontener waży 10GiB — pytanie, jak odczytasz ten plik? xD No trzeba pobrać całę 10GiB i podmontować kontener, a w przypadku eCryptfs możesz pobrać jeden zaszyfrowany plik z dropboxa i go odszyfrować. I dlatego mi na tym cholernie zależy. xD

morfik napisał(-a):

Lepiej późno niż wcale dowiedzieć się, że:

In conclusion, while EncFS is a useful tool, it ignores many standard
  best-practices in cryptography. This is most likely due to it's old
  age (originally developed before 2005), however, it is still being
  used today, and needs to be updated.

  The EncFS author says that a 2.0 version is being developed [3]. This
  would be a good time to fix the old problems.

  EncFS is probably safe as long as the adversary only gets one copy of
  the ciphertext and nothing more. EncFS is not safe if the adversary
  has the opportunity to see two or more snapshots of the ciphertext at
  different times. EncFS attempts to protect files from malicious
  modification, but there are serious problems with this feature.

Tutaj jest wynik audytu tego narzędzia: https://defuse.ca/audits/encfs.htm — ma ponad pół roku. xD Zgodnie z tym co pisze tam w tym linku, jeśli nie poprawią tych błędów, to to narzędzie się nadaje do kosza, zwłaszcza jeśli używacie tego na dropboxie, mega czy innych tego typu serwisach.

Na ten rodzaj ataku większość metod szyfrowania jest podatna. Tylko że wyciąłeś fragmenty z kontekstu. Jest kilka warunków aby to nastąpiło.

3.2. Chosen Ciphertext Attacks

  Since the same key is used to encrypt all files, it may be possible
  for an attacker with read/write access to the ciphertext and partial
  read access to the plaintext (e.g. to one directory when --public is
  used) to perform a chosen ciphertext attack and decrypt ciphertexts
  for which they have no plaintext access.

  EncFS should consider using XTS mode.

  Correction 12/05/2014: XTS mode is probably not the ideal option, see
  Thomas Ptacek's blog post for good reasons why:

      http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Z najnowszych ujawnionych przez Snowdena, a opublikowanych przez Der Spiegel dokumentów wynika, że w styczniu 2012 roku agencja NSA wytypowała trzy projekty i narzędzia używane do szyfrowania i generalnie ochrony danych, które utrudniają jej najbardziej pracę (czytaj nie pozwalają jej skutecznie śledzić internautów). Są to: sieć Tor (The Onion Router), linuksowa dystrybucja aplikacji Tails (The Amnesic Incognito Live System) i TrueCrypt (narzędzie do szyfrowania dysków).

Od tego czasu w dwóch wymienionych powyżej narzędziach wykryto różne podatności. Pierwszą zidentyfikowano w sieci Tor (dzięki niej FBI mogło namierzyć użytkowników korzystających z usług tej sieci), a drugą w aplikacji Tail (co pozwoliło hakerom przechwytywać adresy IP przypisane użytkownikom korzystającym z jej usług). Jak dotąd jedynie w aplikacji TrueCrypt nie udało się znaleźć żadnej podatności, która pozwalałaby ją rozgryźć (przynajmniej nic o tym nie wiadomo, gdyż niektórzy twierdzą, że jest inaczej).

http://www.computerworld.pl/news/400429/Te.narzedzi … om.z.NSA.html

Tu jest trochę o tym torze: http://blog.cryptographyengineering.com/2014/12/on- … ocuments.html