Szyfrowanie portfela - niekonwencjonalnie

[11111111]

Witam

Zarejestrowałem się, ponieważ coraz bardziej podoba mi się temat BTC, ale do rzeczy.
Korzystam z klienta Multibit, a on nie ma możliwości szyfrowania portfela.
Trochę interesuję się kryptografią, ale chciałbym się dowiedzieć jakbyście to widzieli.

Jeszcze przed poznaniem BTC stworzyłem aplikację do szyfrowania plików.
Plik jest szyfrowany innym plikiem. Przykład:

Mamy plik tekstowy z hasłami i ważnymi danymi, który zajmuje 8KB.
Szyfrujemy ten plik, plikiem, który waży 800MB.
Szyfrowany jest każdy bit, przy użyciu XOR'a.
Mały plik tekstowy jest przewijany do początku gdy się "skończy" i szyfrowany od nowa - tyle razy ile razy jest mniejszy od pliku szyfrującego. Można użyć dodatkowo hasła.

Plikiem szyfrującym może być film z chrzcin lub jakiś plik dostępny w internecie, lub wygenerowany losowy plik z /dev/urandom (wybór jest duży a nawet nieograniczony).
I teraz pytanie, czy to może być przynajmniej tak bezpieczne jak konwencjonalne sposoby typu - szyfrowanie symetryczne?
Według mnie jest to wygodniejsze i przynajmniej tak samo bezpieczne (oczywiście zachowując względy bezpieczeństwa i wybierając "dobry" plik szyfrujący).

Jak myślicie?

[pm7]

W praktyce jest to po prostu
http://pl.wikipedia.org/wiki/Szyfr_z_kl ... dnorazowym
Jeżeli weźmiesz losowy plik z /dev/random o długości co najmniej równej długości portfela jest nie do złamania, w przeciwieństwie do wszystkich innych szyfrów (oczywiście bez pliku-klucza).
Przewijanie jest niebezpieczne. Wallet ma ustandaryzowaną strukturę i teoretycznie możliwe byłoby odzyskanie klucza na podstawie zmian względem wzorca w zaszyfrowanym pliku. Ja bym nie ryzykował szyfrowania ogólnodostępnym plikiem - może ktoś wpadnie, może nie.
Osobiście używam szyfrowania keepass i CAST5.

[Przemo]

A jak Ci się uszkodzi ten film? Im większy plik tym większe ryzyko.

Nie rozumiem dlaczego trzeba szyfrować tak dużymi kluczami, przecież szyfrowanie hasłem o długości powiedzmy 15 znaków jest nie do złamania - w praktyce.
Przecież nikt nie będzie tego łamał na masową skalę, chyba, że masz tam miliony BTC??

Ja mam swój portfel zaszyfrowany hasłem co się składa z kilku słów z wiersza z drobną zmianą - nie do zapomnienia i nie do złamania tak mi sie wydaje.

[pm7]

Chyba, że zostanie złamany algorytm szyfrujący, a nie hasło.
Szyfr z kluczem jednorazowym to swego rodzaju ideał, ale jest problem właśnie z przechowaniem plików ( i ich losowością ).

[11111111]

W praktyce jest to po prostu
http://pl.wikipedia.org/wiki/Szyfr_z_kl ... dnorazowym
Jeżeli weźmiesz losowy plik z /dev/random o długości co najmniej równej długości portfela jest nie do złamania, w przeciwieństwie do wszystkich innych szyfrów (oczywiście bez pliku-klucza).
Przewijanie jest niebezpieczne. Wallet ma ustandaryzowaną strukturę i teoretycznie możliwe byłoby odzyskanie klucza na podstawie zmian względem wzorca w zaszyfrowanym pliku. Ja bym nie ryzykował szyfrowania ogólnodostępnym plikiem - może ktoś wpadnie, może nie.
Osobiście używam szyfrowania keepass i CAST5.

Nie wiem czy się dobrze zrozumieliśmy. Plik szyfrowany przewijany jest do początku, po to by go zaszyfrować kolejną częścią pliku szyfrującego. Na przykład mamy:

długość pliku do zaszyfrowania = 2
długość pliku szyfrującego = 10
I mamy:

0 1 0 1 0 1 0 1 0 1 (długość = 2)
XOR
0 1 2 3 4 5 6 7 8 9 (długość = 10)

Tym oto sposobem plik mniejszy zaszyfrowany jest całym plikiem większym.
Więc według mnie w tym wypadku mamy tylko zwiększenie bezpieczeństwa, a nie zmniejszenie.
Ale jeśli dalej się mylę to popraw mnie

Oczywiście najlepiej jest zaszyfrować całkowicie losowym plikiem z urandoma na przykład. Pliki filmowe mają nagłówki i "obszary zer", ale myślę, że przy kilkudziesięciu tysiącach szyfrowań pliku nie ma to kompletnego znaczenia bo 99% danych w filmie to dane losowe. Wystarczy sfimlować coś telefonem, drugi raz nie sfilmujemy identycznego pliku

A jak Ci się uszkodzi ten film? Im większy plik tym większe ryzyko.

Dowolność jak pisałem jest duża. Można zaszyfrować plik 8KB plikiem 80KB.

[pm7]

Czyli wielokrotnie w zaszyfrowanym pliku występuje oryginał?
To znacznie ułatwia łamanie.

[11111111]

Jeszcze się nie rozumiemy, chyba słabo tłumaczę o co mi chodzi
Ale w sumie sam musiałem zajrzeć do źródeł, żeby sobie przypomnieć

Przyjmijmy, że pliki to tablica N-elementów.
Bardzo ogólnie wygląda to tak:
P - plik do zaszyfrowania (N = 2)
X - plik szyfrujący (N = 10)
W - plik zaszyfrowany (długość równa długości pliku do zaszyfrowania: N = 2)

W[0] = P[0] XOR X[0]
W[1] = P[1] XOR X[1]
W[0] = W[0] XOR X[2]
W[1] = W[1] XOR X[3]
W[0] = W[0] XOR X[4]
W[1] = W[1] XOR X[5]
W[0] = W[0] XOR X[6]
W[1] = W[1] XOR X[7]
W[0] = W[0] XOR X[8]
W[1] = W[1] XOR X[9]

Innymi słowy plik jest wielokrotnie szyfrowany i nadpisywany nowymi danymi.
Teraz jaśniej?

[powered]

Ale w takim przypadku plik szyfrujący trzeba mieć w kilku kopiach. To tak jakby hasło zapisac na kilku kartkach.
Mniejsza szansa że stracimy plik szyfrujący lub hasło. Większa szansa że ktoś przejmie ten plik lub hasło.

[Hanczar]

I teraz pytanie, czy to może być przynajmniej tak bezpieczne jak konwencjonalne sposoby typu - szyfrowanie symetryczne?
Według mnie jest to wygodniejsze i przynajmniej tak samo bezpieczne (oczywiście zachowując względy bezpieczeństwa i wybierając "dobry" plik szyfrujący).

Nie moze być tak bezpieczne, bo:
- caly algorytm sprowadza sie do tego ze jest to D XOR K, gdzie klucz(K) i dane do szyfrowania(D) sa tej samej dlugosci (http://en.wikipedia.org/wiki/XOR_cipher), tylko klucz nie jest trzymany w postaci jawnej w pliku na dysku, tylko z danego pliku generowany. W opisanym algorytmie klucz powstaje przez XOR'owanie danych pliku - im dluzszy plik tym wiecej operacji xor, ale po wykonaniu pierwszej kazda kolejna nie zwieksza juz sily algorytmu skoro dane pochodza z tego samego pliku.
EDIT: Tutaj chodzi o to ze jak jest plik z portfelem do zaszyfrowania o długości 80B, i plik szyfrujacy o długości 4GB z chrzcin, to z tego 4GB pliku mozna poźniej wygenerowac klucz o długości 80B i go zapisać, a 4 GB film z chrzcin nie bedzie już potrzebny do odszyfrowywania.

- trzeba zagwarantowac ze plik szyfrujacy ma wystarczajaco dobra entropie bez powtarzajacych sie fragmentow ( np: wspomniany /dev/random - pomijajac ze na jakies dystrybucji systemu moze sie okazac ze byl bug czy backdoor umozliwiajacy odtworzenie generowanego ciagu )
- nie mozna uzywac tego samego pliku szyfrujacego do kilku plikow jakie chcemy szyfrowac - poniewaz znajomosc zawartosci jednego zaszyfrowanego tak pliku i posiadanie jego zakodowanej wersji, zdradza klucz i pozwala odkodowac wszystkie zabezpieczone tym szyfrem pliki - standardowe obecnie algorytmy symetryczne zabezpieczaja ujawnienie klucza w takim przypadku (http://en.wikipedia.org/wiki/Known-plaintext_attack).
- z takim plikiem szyfrujacym trzeba sie p...ć i przegrywac go z "bezpiecznego miejsca" po czym kasowac - tez "bezpiecznie", bo trzymanie go gdzies obok wersji szyfrowanej mija sie z celem szyfrowania.

Zysk z takiego szyfrowania to tylko:
- zaciemnienie, czyli teoretycznie atakujacy nie znajacy algorytmu zniecheci sie szybko do proby odszyfrowywania danych, czy tez nie przegra sobie wszystkich potrzebnych danych do odszyfrowania podczas ataku.
Ale wszelkie zabezpieczenia w postaci zaciemnienia chronia tylko do stopnia wartosci danych ktore chronia - odpowiednia wartosc materialna, prestiz, satysfakcja i zostaną zlamane.

[pm7]

długość pliku do zaszyfrowania = 2
długość pliku szyfrującego = 10
I mamy:

0 1 0 1 0 1 0 1 0 1 (długość = 2)
XOR
0 1 2 3 4 5 6 7 8 9 (długość = 10)

Tym zasugerowałeś, że kopiujesz wielokrotnie niezaszyfrowany plik, by go jednokrotnie xor'ować plikiem-hasłem.

Według nowszego opisu zabezpieczasz się przed niską entropią pliku-hasła kosztem konieczności przechowywanie tego dużego pliku.

Hanczar: Wielokronie szyfrując następnymi fragmentami uzyskuje to co można uzyskać używając jednego pliku z odpowiednią entropią. Więc nie jest tak, że jedyne co zyskuje to zaciemnienie.

[Hanczar]

Hanczar: Wielokronie szyfrując następnymi fragmentami uzyskuje to co można uzyskać używając jednego pliku z odpowiednią entropią. Więc nie jest tak, że jedyne co zyskuje to zaciemnienie.

Racja że nie tylko zaciemnienie, kalam się - wnosi ze plik jest szyfrowany kluczem o długości danych.

Zaciemnieniem jest trzymanie klucza w postaci dużego pliku (np: 800MB) podczas gdy klucz ma tylko 80B (tyle co plik do zaszyfrowania).

Opisany algorytm można by wykonać tak:
a) wygeneruj klucz z dużego pliku xorujac jego fragmenty
b) użyj klucza z pkt a) do szyfracji/deszyfracji danych.

Jeżeli zapisze ten klucz z pkt a) jako plik o długości 80B, ten plik zadziała dokladnie tak samo z tym samym programem szyfrujaco/deszyfrujacym jak ten 800MB filmik z chrzcin , /dev/randoma.

Odnośnie zwiększania entropi przez xorowanie ze sobą fragmentów pliku - uważam to za złudne bo pesymistycznie nic nie zwiekszy, wiec trzeba zagwarantowac plik wejsciowy z odpowiednią entropia,
a jak już taką ma to dodatkowy xor nic nie zmieni.
Co więcej tego samego pliku klucza nie może mieć nikt inny na świecie komu nie został on udostępniony jako klucz. (np: filmik z chrzcin którego kopie ma cała dalsza rodzina odpada)


W skrócie:
Duży plik jako klucz jest niewygodny, nic nie wnosi do bezpieczeństwa.

[11111111]

Dzięki za odpowiedzi

pm7,
Tak, faktycznie źle to przedstawiłem na początku.

Hanczar,
Dałeś mi trochę do myślenia, dzięki.

ale po wykonaniu pierwszej kazda kolejna nie zwieksza juz sily algorytmu skoro dane pochodza z tego samego pliku.

Mógłbyś rozwinąć tą myśl? Pochodzą z tego samego pliku ale w całości losowego (w przypadku np. filmu 99% losowego).
Zakładamy taką sytuację, że zaszyfrowaliśmy plik np. portfel - dużo większym plikiem.
Dowolność jest ogromna. Mógł to być plik z urandoma, mógł to być film. W wyniku wielokrotnego szyfrowania powstał ostateczny wynik. Przypuśćmy, że szyfrowaliśmy dodatkowo jeszcze z hasłem czyli W = P ^ X ^ PASSWORD
Dane totalnie się przemieszały w te i wewte tysiące razy. Żeby zdekodować te dane, trzeba powtórzyć dokładnie tak samo proces szyfrowania.
Zakładamy, że plik szyfrujący mamy w kilku kopiach w sejfie na pendrive'ach.

Według mnie mamy lepszą sytuację niż przy pojedynczym szyfrowaniu.
Oczywiście problemem jest przechowywanie pliku.
Ja po prostu zakładam, że ewentualny atakujący ma do dyspozycji tylko plik zaszyfrowany, że dochowaliśmy starań przy szyfrowaniu i plik szyfrujący jest bezpieczny.

[Hanczar]

(...) Żeby zdekodować te dane, trzeba powtórzyć dokładnie tak samo proces szyfrowania.

Nie, wystarczy plik o takiej samej długości jak porftel, i dość łatwo go wygenerować**.

(...)Mógłbyś rozwinąć tą myśl?(...)

Dlaczego to nie zmienia siły algorytmu? Bo przedstawiony algorytm używa najsilniejszego szyfrowania jakie istnieje - klucz o takiej samej długości jak dane które chroni*, i już sie go po prostu nie da wzmocnić.
Przy takiej długości klucza zamiast sprawdzac wszystkie możliwe klucze można równie dobrze sprawdzać po kolei wszystkie możliwe dane.
Atakując siłowo zaszyfrowany plik o długości 80B (anglokalecząc bruteforcem) znajde użyty klucz generujac wszystkie możliwe zawartości plików o długości 80 B,
nie bede musial generowac kluczy mających długość większą ( jak ten 800MB plik).

Odszyfrowanie zajmie atakującemu tyle samo prób(czasu) niezaleznie od tego czy do szyfrowania pliku o długości 80 B w podanym algorytmie zostanie użyty jako plik szyfrujący o długości 80 B z /dev/random,
czy o długości 80 GB z /dev/random.

W = P ^ X ^ PASSWORD

to ciagle jest:

Kod: Zaznacz cały

    W = X ^ K

gdzie X -dane o dlugości l, K - klucz o długości l, W - wynik o długości l.

tylko

Kod: Zaznacz cały

K = P ^ PASSWORD

gdzie P - wiele megabajtow danych xorowanych ze soba, PASSWORD - jakies tam dlugosci.

Ale ponieważ wcześniej uda mi sie znależć K niż P ( bo te jest dłuższe ), nie będę szukał P.
Kluczem jest rodzaj funkcji skrótu z tego duzego pliku, i gdy mam skrót nie potrzebuje pliku.

Dodanie PASSWORD - utrudnia pozyskanie klucza, ale to chroni przed innym typem ataku na szyfrowane dane - nie wystarczy wynajac zlodzieja aby zerwal z szyji pendrive'a z kluczem, trzeba jeszcze wynająć kilku szerokich kolesi żeby drugą część klucza w postaci hasła wyciągneli obcęgami. Ale gdy atakujacy pozyska klucz, siła użytego algorytmu czy długośc klucza jest już nieistotna.

* - przy zalozeniu ze klucz jest opdowiednio zabezpieczony, zawiera odpowiednią entropie itd.
** - operacja xor miedzy plikiem zaszyfrowanym a zdeszyfrowanym - da plik klucz o dlugosci pliku portfela bez koniecznosci uzywania nieporecznego 800MB pliku.

[11111111]

Teraz w końcu wszystko jasne. Że też wcześniej na to nie wpadłem - shame on me
Dzięki bardzo Hanczar.

Czyli podsumowując - największy nacisk trzeba kłaść na entropię pliku, bezpieczne przechowywanie i bezpieczne usuwanie.

[virus]

nie prosciej uzyc truecrypt ?

[11111111]

Pewnie prościej, ale powiem Ci, że lubię sobie utrudniać życie