Twoja ostatnia edycja wskazuje, że obrazy są generowane proceduralnie, dlatego rozmiar klucza będzie ograniczony stanem wymaganym do wygenerowania obrazu. Twój wydaje się być sparametryzowany przez cztery zmienne dla warunków początkowych (i stałego rozmiaru obrazu wyjściowego, lokalizacji kamery, położenia światła punktowego, warunków zbieżności itp.).

Te 128-bitowe of state zostanie następnie przekształcony w obraz przez algorytm, który zależy wyłącznie od dostarczonego stanu, więc „klucz” obrazu nie może zawierać więcej niż 128 bitów informacji. W rzeczywistości uważam, że całe klasy wartości początkowych dają identyczne wyniki (np. Gdy wszystkie cztery zmiennoprzecinkowe są bardzo małe), więc rozmiar "klucza" obrazu będzie ściśle mniejszy niż 128 bitów.

Jest naprawdę nie ma korzyści z dotykania 128 bitów stanu przez przekształcenie go w obraz (a następnie w jakiś sposób z powrotem), jeśli tylko zmniejszysz rozmiar klucza w ten sposób.

Obraz jest o wiele za duży, aby użyć go bezpośrednio jako klucza szyfrowania, najpierw należy go przepuścić przez KDF.

Zależy to również całkowicie od obrazu czy będzie miał wystarczającą entropię, aby była użyteczna. Możesz mieć obraz 1000 x 1000, który jest jednolicie biały, ale byłby bezużyteczny jako klucz, ponieważ nie zawiera entropii. Obrazy z kamer mają zwykle sporą liczbę entropii w dolnych bitach, więc może to być w porządku, ale użytkownicy powinni zrozumieć, że nie każdy obraz jest dobrym kluczem.

Obrazy jako klucze ogólnie nie jest to świetny pomysł. Zdjęcia są zwykle pobierane w celu udostępnienia, a klucze to coś, czego nie chcesz nikomu pokazywać. Używanie obrazu jako klucza również wydaje mi się, że może polegać na bezpieczeństwie poprzez zaciemnienie (tj. Po prostu używasz obrazu z tysięcy, które masz na swoim komputerze, ale to w rzeczywistości bardzo niska entropia, prawdopodobnie poniżej 20 bitów, chyba że masz szaloną liczbę zdjęć).

Możesz kontynuować rozwijanie tego w celu uczenia się, ale dopóki nie będziesz lepiej rozumieć kryptografii, lepiej zostaw takie rzeczy do ekspertów (zobacz Dlaczego nie powinniśmy tworzyć własnych?).

Każdy system kryptograficzny powinien mieć klucze o rozmiarach kluczy na poziomach bezpieczeństwa 128, 192 i 256 bitów entropii.

Wraca więc pytanie: gdzie są te obrazy, z których pochodzą i ile zawierają entropii? Jeśli są to całkowicie losowe strumienie bitów, które są interpretowane jako obraz, to (ignorując utratę entropii spowodowaną stratnymi kodekami kompresji), otrzymasz log_base2 (256x256x256) = 24 bity entropii na piksel , więc d potrzebuję odpowiednio 6/8/11 pikseli dla 128/192/256 bitowych zabezpieczeń.

Jeśli nie generujesz całkowicie losowych obrazów i zamiast tego pozwalasz ludziom używać, na przykład, zdjęć, to mam nie mam pojęcia, jak w ogóle zacząłbyś szacować wielkość entropii w jednym z nich.

Konkluzja: używanie obrazów jako materiału kluczowego wydaje się być naprawdę dziwną rzeczą rób i koliduje z powszechną praktyką, zgodnie z którą materiał klucza to całkowicie przypadkowe dane z RNG o sile kryptograficznej.

Ponadto z informacji w pytaniu nie jestem przekonany, że brutalna siła jest trzeba się martwić; Bardziej interesowałbym się atakiem „uzyskaj dostęp do ich laptopa i wypróbuj każdy obraz na ich dysku twardym”.

Na podstawie obrazów mogę stwierdzić, że rozmiar klucza jest znacznie mniejszy niż rozmiar obrazów (ponieważ w przeciwnym razie większość z nich wyglądałaby jak statyczne elementy w losowych kolorach).

Rozmiar klucza jest mniejszy niż lub równy logarytmowi o podstawie 2 z całkowitej liczby różnych obrazów, które twój chaotyczny program atraktora może wygenerować. *

To inny sposób na powiedzenie, że rozmiar klucza jest mniejszy lub równy (prawdopodobnie mniejszy) bitów potrzebnych do określenia wszystkich danych wejściowych do programu chaotycznego atraktora.

Jeśli haszujesz obraz i używasz hasha jako klucza kryptograficznego, rozmiar twojego klucza jest równy lub mniejszy niż rozmiar skrótu .

* To twój dokładny rozmiar klucza, jeśli twój algorytm szyfrowania to coś w rodzaju „XOR każdego bitu obrazu z odpowiednim bitem tekstu jawnego” (nie używaj tego algorytmu do ważnych tajemnic, przy okazji, ponieważ części wiadomości zakryte szarymi obszarami na obrazach mogą być bardzo łatwe do odszyfrowania).

tl; dr - Proponujesz algorytm rozciągania klucza, który zamienia 128 bitów danych wejściowych na znacznie większy klucz. Nie jest to tak dobre, jak po prostu użycie znacznie większego klucza o tym samym rozmiarze, chociaż nie jest koniecznie tak słaby, jak 128-bitowe dane wejściowe. To powiedziawszy, Twoja mapa bitowa wygląda na bardzo uporządkowaną, co zdecydowanie sugeruje, że jest znacznie słabsza niż losowo generowana mapa bitowa.

Zgodnie z odpowiedzią @ Blender, po prostu używasz 128 bitów do wygenerowania obrazu. Domyślam się, że chcesz, aby sam obraz liczył się jako klucz większy niż 128 bitów, które wstawiłeś do algorytmu, który go wygenerował. I może.

Konkretnie rzecz biorąc, próbujesz stworzyć algorytm rozciągania klucza, który próbuje rozciągnąć 128 bitów danych wejściowych do znacznie większy klucz. Niekoniecznie jest to bezowocne, ale jest kilka rzeczy, o których należy pamiętać:

1. Algorytm rozciągania klucza może być podatny na brutalną siłę wejścia. Na przykład, nawet jeśli ktoś nie mógł wykonać inżynierii wstecznej algorytmu generowania obrazu, mógłby wypróbować wszystkie 2 $ ^ {128} $ możliwe dane wejściowe, aby wygenerować wszystkie możliwe 2 $ ^ {128} $ możliwe obrazy, a następnie spróbować każdego. Aby temu zapobiec, musisz upewnić się, że algorytm generowania obrazu jest zbyt drogi, aby taki atak był możliwy.

2. Twoje zdjęcie nie wygląda na przypadkowe w lokalnym waga. Oznacza to, że każdy, kto patrzy na kilka pikseli, prawdopodobnie odgadnie sąsiednie piksele z lepszymi niż przypadkowe szansami powodzenia. Oznacza to, że algorytm nie jest pseudolosowy, nawet przeciwko napastnikowi, który nie może wykonać inżynierii wstecznej algorytmu generowania obrazu.

3. Twój obraz nie wygląda na przypadkowy skalę globalną. Oznacza to, że wyświetlane kształty mają globalną geometrię, a obrazy marnują piksele na dobrze zachowanym tle. To ponownie znacznie osłabia pseudolosowość, co może sugerować, że może być łatwo całkowicie złamać.

4. Algorytm rozciągania klucza generujący obraz nie ma żadnej realnej korzyści w porównaniu z jakąkolwiek inną reprezentacją tych samych danych. Owszem, rozciągnięty klawisz wygląda ładnie jak obrazek, ale ta uroda odzwierciedla jedynie jego słabość w porównaniu z losowo generowaną bitmapą.

Ta witryna wydaje się generować losowe czarno-białe mapy bitowe o określonych wymiarach. Na przykład, oto mapa bitowa piksela 250 $ \ razy 250 $:
.
Ta mapa bitowa jest (powinna być) losowa, ponieważ atakujący patrzy na dowolną kombinację jego pikseli nie powinno mieć większych niż równe szans na odgadnięcie, jaki może być inny piksel.

Ile entropii?

Niestety ta strona nie ma MathJax włączone, więc trudno jest bezpośrednio odpowiedzieć na pytanie, aby nie wyglądało dziwnie. Tutaj napiszę odpowiedź tak, jakby MathJax był dostępny.

Zestaw losowo wygenerowanych obrazów RGB o danej długości i szerokości zawiera $$ {\ left (n_ \ text {Red} \ , n_ \ text {Green} \, n_ \ text {Blue} \ right)} ^ {n_ \ text {szerokość} \, n_ \ text {wysokość}} \, \ text {Members} \ ,, $$ gdzie:

• $ n_ \ text {Red} $ to liczba możliwych wartości wymiaru „ czerwony ” piksela;

• $ n_ \ text {Zielony} $ to liczba możliwych wartości wymiaru „ zielonego ” piksela;

• $ n_ \ text {Blue} $ to liczba możliwych wartości wymiaru „ niebieski ” piksela;

• $ n_ \ text {width} $ jest liczbą pikseli na szerokości; a

• $ n_ \ text {length} $ to liczba pikseli długości.

Wtedy od entropii to $ \ log_2 {\ left (n_ \ text {Members} \ right)}, $ to byłoby $$ \ begin {align} \ left [\ text {entropy} \ right] & ~ = ~ \ log_2 { \ left ({\ left (n_ \ text {czerwony} \, n_ \ text {zielony} \, n_ \ text {niebieski} \ prawo)} ^ {n_ \ text {szerokość} \, n_ \ text {wysokość}} \ right)} \ [5px] & ~ = ~ {n_ \ text {szerokość} \, n_ \ text {wysokość}} \, \ log_2 {\ left (n_ \ text {czerwony} \, n_ \ text {zielony} \, n_ \ text {Blue} \ right)} \,. \ end {align} $$

W przypadku obrazu czarno-białego:

• $ n_ \ text {Red} = 2, $ ponieważ są dwa możliwe wartości dla kanału czerwonego;

• $ n_ \ text {Green} = n_ \ text {Blue} = 1, $ ponieważ zdefiniowane są wartości kanałów zielonego i niebieskiego aby wyrównać kanał czerwony (tak, że wszystkie piksele są czarne lub białe;

więc entropia byłaby $$ \ left [\ text {entropy} \ right] ~ = ~ {n_ \ text {szerokość} \, n_ \ text {wysokość}} \, \ log_2 {\ left (2 \ times 1 \ times 1 \ right)} ~ = ~ {n_ \ text {szerokość} \, n_ \ text {wysokość}} \,. $$

Tak więc, jeśli uda ci się ominąć początkowe problemy związane ze zbyt małym rozmiarem klucza i zbyt dużą utratą, a następnie użyjesz KDF, w końcu użycie tych kluczy do autoryzacji jest korzystne.

Generowanie tych rzeczy musi trwać wiecznie w porównaniu z tradycyjnym hashem, więc jeśli początkowe parametry są traktowane jak hasło, czas ataku na hasło będzie długi.

Ale są na to łatwiejsze sposoby. bcrypt () i znajomi dobrze się skalują.