Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
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.[/quote]
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.
Offline
1118
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:59:52)
Offline
Ostatnia aktualizacja o audycie TC była 5 miechów temu. Także wiesz, albo się czegoś doszukali i nie chcą opublikować (ewentualnie nie mogą), albo chcieli opublikować i teraz wszyscy siedzą. xD
Offline
[quote=uzytkownikubunt]BTW Wiadomo już coś w sprawie włamania na kernel.org z 2011 roku? Obiecali, że opiszą co się stało...[/quote]
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)
Offline
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.[/quote]
Tylko ten eCryptfs ma dość ciekawie rozwiązany mechanizm szyfrowania — każdy plik jest szyfrowany innym kluczem. W przypadku kontenera LUKS albo TC, wszystkie pliki mają ten sam klucz. Złamiesz klucz, i wszytskie pliki twoje. W przypadku eCryptfs, to najwyżej jeden plik zdekodujesz. Do tego, rzadko kto stosuje długie hasła w swoich kontenerach, no chyba, że jest mną i używa 128 znakowych haseł. xD A przecie przeciętniacy mają hasła 8-10 znakowe. W eCryptfs możesz zaszyfrować sobie dowolny ciąg znaków, powiedzmy jakiś hash 32bajtów i to jego użyć do szyfrowania kluczy w plikach podczas gdy twój system poprosi cię tylko o hasło lokalne. Także jeśli ktoś zdalnie chciałby łamać hasło do klucza, to mu życzę powodzenia, jeśli będzie ono miało formę typu:Kod:
$ od -x -N 32 --width=32 /dev/urandom | head -n 1 | sed "s/^0000000//" | sed "s/\s*//g" 0c62f064f7d06b0ebc19cacb5182a8a91793f92314a49a4401f56c088a8f193eJedyne co to ten eCryptfs trochę kuleje ale rozwiązanie ma ciekawe.
Ostatnio edytowany przez morfik (2014-10-12 20:15:00)
Offline
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)
Offline
1119
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:59:53)
Offline
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?[/quote]
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ę.
Offline
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ę.[/quote]
To już są drobiazgi techniczne, do zrobienia.
Ja odradzam stosowanie haseł, jak masz hasło, które umiesz sprawnie wpisać, to można je też sprawnie łamać.
Przy okazji, bawiłeś się Luksem, tam pendrak z kluczem tylko przy montowaniu musi być wsadzony, przez cały czas używania kontenera, czy tylko w momencie montowania?
Wczytuje go do pamięci RAM na czas sesji (chyba powinien).
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 właściciela, aczkolwiek ciekaw jestem, kiedy FW będzie miał zastosowanie do interfejsów hciX. :D
Szyfrowanie ma zabezpieczać w przypadku fizycznego dostępu przez osoby nieupoważnione, np kradzieży lub zgubienia lapka czy smartfona,
co akurat takie rzadkie ani nierealne nie jest.Ostatnio edytowany przez Jacekalex (2014-10-12 22:43:31)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
To już są drobiazgi techniczne, do zrobienia.[/quote]
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ę. xDPrzy 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).[/quote]
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.[/quote]
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. xDOffline
1123
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:59:58)
Offline
[quote=morfik]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.[/quote]
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.[/quote]
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.
Offline
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/[/quote]
Offline
[quote=uzytkownikubunt]Na razie to nic dziwnego, terminy czasem się przesuwają, nie da się dokładnie powiedzieć czasu ile zajmie coś takiego. Jakby opublikowali pół raportu, to byłaby to amatorszczyzna.... Imho źle będzie świadczyło o audycie, jak do końca 2014 roku nie skończą.[/quote]
Chyba można już sobie olać TC, bo raczej w 3,5h nie zdążą. xD
Offline
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).[/quote]
http://www.computerworld.pl/news/400429/Te.narzedzia.szyfrowania.danych.spedzaly.sen.z.powiek.informatykom.z.NSA.html
Offline
1382
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:05:45)
Offline
1383
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:05:46)
Offline
Time (s) | Query |
---|---|
0.00014 | SET CHARSET latin2 |
0.00007 | SET NAMES latin2 |
0.00137 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.145.93.227' WHERE u.id=1 |
0.00084 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.145.93.227', 1732400269) |
0.00076 | SELECT * FROM punbb_online WHERE logged<1732399969 |
0.00104 | SELECT topic_id FROM punbb_posts WHERE id=280681 |
0.00237 | SELECT id FROM punbb_posts WHERE topic_id=26518 ORDER BY posted |
0.00083 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=26518 AND t.moved_to IS NULL |
0.00020 | SELECT search_for, replace_with FROM punbb_censoring |
0.00116 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=26518 ORDER BY p.id LIMIT 0,25 |
0.00142 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=26518 |
Total query time: 0.0102 s |