W bardziej zaawansowanych metodach szyfrowania (np używanym obecnie AES) jest to właśnie tak rozwiązane, ze mając fragment jawny i zaszyfrowany nie jesteś w stanie wydobyć klucza.

Zauważ, że dany format pliku ma zawsze ten sam nagłówek, więc gdyby można było znaleźć klucz porównując dane zaszyfrowane z jawnymi to szyfrowanie popularnych formatów nigdy nie byłoby bezpieczne bo można byłoby uzyskać klucz analizując nagłówek zaszyfrowanych plików.

To o czym pisałem to szyfrowanie symetryczne, gdy musisz po prostu zabezpieczyć swoje dane na miejscu (AES, DES) występuje tu pojedynczy klucz zwykle nie dłuższy niż 256b.

Jest jeszcze szyfrowanie asymetryczne np RSA używane gdy chcesz wysłać dane przez niezaufane medium, lub zrobić coś w stylu jednokierunkowej zapadki szyfrującej.

Tu klucze są zwykle dłuższe: od 1024 do 4096 (para: publiczny i prywatny)

Brutalne złamanie RSA jak i AES przy standardowej dla danego szyfru długości klucza (podałem wcześniej) wymagałoby obliczeń trwających tak długo, że nikt rozsądnie tego nie rozważa.

Nie wiadomo czy istnieje sposób na znalezienie klucza matematycznie.

Najczęściej podejmowane próby łamania to jednak wykorzystanie nieudolności w implementacji np. ktoś wykorzystuje do generowania klucza ciąg liczb losowych, które w rzeczywistości aż tak losowe nie są jak mu się zdaje. Albo ktoś zaimplementuje algorytm w taki sposób, że zapisuje krytyczne dane w nieczyszczonych obszarach pamięci itp

>Zauważ, że dany format pliku ma zawsze ten sam nagłówek, więc gdyby można było znaleźć klucz porównując dane zaszyfrowane z jawnymi to szyfrowanie popularnych formatów nigdy nie byłoby bezpieczne bo można byłoby uzyskać klucz analizując nagłówek zaszyfrowanych plików.

Nic mi to nie mówi...

Pamiętam z filmu o bitwie o Midway chyba, że tam złamali szyfry
japońców na podstawie podstawianych depesz.

Amerykanie tak zrobili:
puścili depeszę o swoich planach, odnośnie rozmieszczenia okrętów,
którą japońcy odczytali, więc potem komunikowali o tym swoją flotę,
i używając oczywiście tych samych pozycji, nazw okrętów Amerykańskich,
jak i swoich, których dotyczyły rozkazy.

Co z kolei Ameryka przechwyciła, i tym sposobem poznali plany japońców!
Finalnie, pomimo zdecydowanej przewagi floty wroga, amerykanie i tak wygrali -
zniszczyli japońskie lotniskowce i niszczyciele,
zanim te zdołały dopłynąć do celu i zrealizować swoje plany.

Sprawa jest dosc skomplikowana a niestety sprzedawcy upraszczaja do bólu.

Zasadniczo to co dostajesz w momencie kupna komputera/programu to nie pojedynczy koncept szyfrowania ale cały system, składajacy sie co najmniej z
- systemu ochrony kluczy prywatnych
- algorytmu genercji liczb pseudolosowych
- algorytmu generacji klucza sesyjnego
- algorytmu bezpiecznej wymiany kluczy sesyjnych
- algorytmu uwierzytelniania stron transmisji (klient A - Klient B)

Do tego alorytmy te moga zostac zastosowane w różnych konfiguracjach
Tak jak to slusznie zauwazył Jan Bednarski - atakuje się najsłabsze elementy systemu.

Sprzedawca oczywiscie będzie zachwalał że jego system ma szyfrowanie "tyle-a-tyle" bitow co w praktyce oznacza, że klucz ma taką długość. W teorii im klucz dłuższy tym dane bezpieczniejsze ale koszt (z reguły tym kosztem jest czas) szyfrowania/odszyfrowania rośnie. Oczywiscie klucz idealny to klucz taki ktory ma taką samą długość jak dane do zaszyfrowania i jest unikalny. Istnieje matematyczny dowód, że systemu takiego złamać się nie da (pl.wikipedia.org/wiki/Szyfr_z_kluczem_jednorazowym) - każdy inny system - teoretycznie można złamać.
Praktycznie tak dobiera się długość klucza aby technologia w przewidywalnej przyszłości i w zakresie istotnosci danych (np dane po roku mogą nie miej już żadnej wartości) nie pozwalała na przetestowanie wszystkich możliwych kluczy.
w latach 70 powstał szyfr DES - który obecnie jest już uznany za "słaby". ale nie został on złamany - po prostu wzrost predkosci procesorow spowodował że w 1999 roku udało się odczytać wiadomość sprawdzając wszystkie możliwe klucze w 22 godziny. (en.wikipedia.org/wiki/Distributed.net). Długość klucza miała 56 bitów
Przy obecnym stanie technologii przetestowanie kluczy o dlugosci 128 bitów zajmie bardzo bardzo długo - ale kto wie - komputery kwantowe mogą zmienic regułu gry

Wracając do naszego sprzedawcy - dla niego te 128bit czy 512 to taki slogan majacy przekonać cię że jego jest lepsze. W praktyce jest tam dużo więcej do sprawdzenia. Ale jest nadzieja - z punktu widzenia uzytkownika końcowego programu/komputera - używaj tych najbardziej znanych z najlepszą reputacją. Nie jest to 100% gwarancja bezpieczeństwa ale w 98 przypadkach na 100 - zadziała. W przypadku gdy głównym powodem dla uzytkownika końcowego aby zapłącic kilka stówek wiecej jest "szyfrowanie 256 bitowe" vs "szyfrowanie 128 bitowe" - kup tansze - i tak 3 dni po gwarancji ci to urzadzenie padnie i kupisz nowe.

>Na czym polega to komputerowe szyfrowanie: 128 bitowe, 256, 1024 itp. ?
To jest po prostu długość klucza. Im dłuższy klucz, tym więcej możliwości i tym trudniej sprawdzić wszystkie żeby znaleźć właściwy, ale też tym kosztowniejsze obliczeniowo jest szyfrowanie i rozszyfrowywanie, jak napisał Abdullah.

Ogólnie dla n-bitowego klucza możliwych kluczy jest 2^n. Troszkę inaczej jednak wygląda sprawa z łamaniem szyfrów symetrycznych i asymetrycznych.

W przypadku szyfrów symetrycznych, klucz jest całkowicie tajny. Zakładając więc brak błędów w implementacji algorytmu, o których wspominał Jan Bednarski, żeby złamać szyfr w najgorszym wypadku trzeba sprawdzić wszystkie możliwości. 2^128 czy 2^256 to liczby tak ogromne, że już 128 czy 256-bitowe szyfry uznaje się w tym przypadku za bezpieczne.

W szyfrach asymetrycznych jednak część klucza jest publiczna. Generalnie szyfry te polegają na tym, że jest para kluczy: klucz publiczny, który można rozgłaszać na cały świat i który służy do szyfrowania, oraz klucz prywatny, który powinien być tajny i który służy do odszyfrowywania (można odwrócić ich zastosowanie i uzyskać w ten sposób podpisy cyfrowe, ale to kwestia na osobny temat). W przypadku np. szyfru RSA, klucz publiczny to dwie liczby (oznaczane N i e), a klucz prywatny - jedna liczba, oznaczana d. Problem polega na tym, że d jest zależne od N i e, więc teoretycznie znając N i e można obliczyć d. Dlaczego więc uważa się publikowanie N i e za bezpieczne?

Otóż żeby obliczyć d, trzeba znać czynniki pierwsze liczby N. W algorytmie RSA N jest zwykle iloczynem dwóch liczb pierwszych - N = p*q. Nie są znane sposoby na szybkie rozkładanie dużych liczb na czynniki pierwsze, dlatego gdy N jest odpowiednio duże, uznaje się, że potencjalny atakujący nie zdoła znaleźć p i q w rozsądnym czasie (i dlatego duże liczby pierwsze są takie cenne). Rozkładanie na czynniki pierwsze jest jednak o wiele szybsze, niż sprawdzanie wszystkich możliwości, dlatego N zwykle ma 1024, 2048, albo nawet 4096 bitów, aby uzyskać odpowiedni poziom bezpieczeństwa.

>A jak będzie z tym rozszyfrowywaniem, gdy mam obie wersje danych,
>np. tekst oryginalny - przed zaszyfrowaniem, jak i ten już po zaszyfrowany:
>czy z togo można już wyciągnąć te klucze używane w szyfrowaniu,
>i rozszyfrować inne dane, w których zastosowane ten sam schemat oraz klucze?
W przypadku dobrych algorytmów szyfrujących - nie, to nie wystarczy. Dlatego też stworzenie dobrego algorytmu nie jest takie proste. Musi on być na tyle skomplikowany, żeby nie dało się tak łatwo odtworzyć klucza, a jednocześnie na tyle prosty, żeby komputer był w stanie szybko go wykonywać.

>Ogólnie dla n-bitowego klucza możliwych kluczy jest 2^n.

I co z tego?
Jest mnóstwo problemów które mają n! rozwiązań, albo i n^n,
a pomimo tego są one rozwiązywane w czasie liniowym:
n, albo niewiele większym: n*log(n), ostatecznie n^2.

>I co z tego?
>Jest mnóstwo problemów które mają n! rozwiązań, albo i n^n,
>a pomimo tego są one rozwiązywane w czasie liniowym:
>n, albo niewiele większym: n*log(n), ostatecznie n^2.
Owszem, tylko że jeśli algorytm szyfrujący jest dobry, to takich rozwiązań nie ma i zostajesz z przeszukiwaniem całej przestrzeni kluczy.

Albo inaczej: zazwyczaj jeśli istnieje sposób szybszego znalezienia klucza, to szyfr uważa się za złamany.

>Owszem, tylko że jeśli algorytm szyfrujący jest dobry, to takich rozwiązań nie ma i zostajesz z przeszukiwaniem całej przestrzeni kluczy.

Tak? Zatem na czym ma polegać to szyfrowanie, że pomimo 1GB danych zaszyfrowanych, jak i nie zaszyfrowanych, nadal nie można znaleźć tego maluteńkiego kluczyka... bo raptem 256 bit = 32 bajty zaledwie!

>Albo inaczej: zazwyczaj jeśli istnieje sposób szybszego znalezienia klucza, to szyfr uważa się za złamany.

Nawet znalezienie klucza jednego spośród miliarda możliwych (30 bitów) jest w praktyce niemożliwe, bo musiałbyś dekodować to kolejno, miliard razy i sprawdzać, czy otrzymany wynik jest sensowny, czytelny - zawiera w ogóle cokolwiek sensownego, jak słowa angielskie, czy dowolne inne dane, jak fotografie, filmy, a może to dźwięk w mp3?

Ale sytuacja będzie drastycznie inna gdy wiesz co było zaszyfrowane:
masz zarówno oryginał jak i ten zaszyfrowany plik.

1. Zainteresowało mnie to:
Cytat:

Rozważmy problem rozmiaru n mający n^n rozwiązań (oczywiście że n^n .> n!)
Po pierwsze czy masz tu na myśli znalezienie wszystkich rozwiązań dla takiego problemu ?
Bo jeśli tak, to samo ich wypisanie miałoby złożoność n^n.
Jeśli natomiast masz na myśli znalezienie byle którego rozwiązania to najprawdopodobniej pierwszy lepszy kandydat będzie spełniał warunki zadania (przestrzeń rozwiązań jest tak wielka)
Podaj przykład takiego problemu.

2. Nie zgodzę się z tym:
Cytat:

Zazwyczaj istnieje szybszy sposób niż przeszukiwanie całej przestrzeni kluczy. Niekoniecznie musi to oznaczać, że złożoność jest mniejsza ale i tak można to robić wielokrotnie krócej niż sprawdzanie wszystkich kluczy.
Weźmy taki RSA, cała jego trudność sprowadza się do znalezienia p i q takich, że pq=N.

W praktycznych zastosowaniach istnieje stosunkowo duże prawdopodobieństwo, że p i q nawet nie są pierwsze. Stosowany powszechnie test Rabina-Millera ma charakter probabilistyczny, więc nie mamy gwarancji, że przepuszczane przez niego liczby (przy generowaniu klucza) rzeczywiście są pierwsze. Była kiedyś głośna sprawa, gdy okazało się, że w kluczu publicznym jakiejś instytucji N dzieliło się przez 3 .
Biorąc jeszcze pod uwagę kilka trywialny faktów (np że każda liczba pierwsza od 5 musi być postaci 6n+1 lub 6n-1) mamy do przeszukania wielokrotnie mniej kandydatów do dzielenia N niż samo N.

>Tak? Zatem na czym ma polegać to szyfrowanie, że pomimo 1GB danych zaszyfrowanych, jak i nie zaszyfrowanych, nadal nie można znaleźć tego maluteńkiego kluczyka... bo raptem 256 bit = 32 bajty zaledwie!

Zastanów się. Jeśli próbujesz odszyfrować tekst, ale podajesz złe hasło to skąd program deszyfrujący wie, że podałeś złe hasło ? Po prostu do pliku podczas szyfrowania dodawany jest fragment, którego spodziewana postać po odszyfrowaniu jest znana. Robi się tak ponieważ jedną z podstawowych zasad współczesnej kryptografii jest to aby możliwość porównania danych jawnych z zaszyfrowanymi nie ułatwiała uzyskania klucza deszyfrującego.

Rozważmy to na przykładzie RSA:
klucz publiczny (n,e) - szyfrujący
klucz prywatny (n,d) - deszyfrujący

Znajdujemy dwie duże liczby pierwsze p i q (test Rabina-Millera), obliczamy N=pq
obliczmy t=(p-1)(q-1)
Wybieramy wykładnik e
Znajdujemy d = odwrotność e modulo t (robi się to szybko np algorytmem Euklidesa)

Aby zaszyfrować tekst używa się klucza publicznego (n,e):
c = m^e mod n (1) (c to zaszyfrowana postać liczby m)
(tę operacje można wykonywać b. szybko np dzięki algorytmowi iteracyjnego podnoszenia do kwadratu)

Aby odszyfrować (n,d):
m = c^d mod n (2)
(tę operacje można wykonywać b. szybko np dzięki algorytmowi iteracyjnego podnoszenia do kwadratu)

Zobacz, aby uzyskać klucz prywatny z publicznego, musiałbyś umieć rozłożyć n.
Wtedy byś uzyskał p, q , a następnie t = (p-1)(q-1) i to pozwoliłoby Ci uzyskać d jako odwrotność e modulo t.

Nie ma innej możliwości.
Dodatkowa znajomość postaci jawnej i zaszyfrowanej (m i c) nic tu nie ułatwia.
Nie są znane metody analityczne rozwiązywania równań 1 i 2, nawet jeśli jedyną niewiadomą jest d.
Potęgowanie w ciele skończonym, które odbywa się podczas kodowania to prawdopodobnie funkcja jednokierunkowa.

Udowodniono matematycznie, że trudność odwrócenia tego rodzaju funkcji jest równa problemowi faktoryzacji całkowitej (n=pq). Oba te problemy zaliczają się do szerszej grupy problemów NP-zupełnych, czyli takich dla których nie jest znane rozwiązanie w czasie wielomianowym, ale są ze sobą ściśle związane.
Znaleziono mnóstwo problemów dla których udowodniono przynależność do klasy NP-zupełnej: problem cyklu hamiltona, problem kliki, problem SAT, kolorowanie grafu, pokrycie wierzchołkowe i wiele, wiele innych.

Rozwiązywanie tych problemów nie musi polegać na sprawdzaniu wszystkich możliwości. Można to robić dużo szybciej np poprzez backtracking (np. hamilton, klika, kolorowanie), chociaż złożoność nadal pozostaje ponad-wielomianowa.

Znalezienie rozwiązania w czasie wielomianowym dla któregokolwiek z nich byłoby wielką tragedią, gdyż pociągnęłoby to możliwość szybkiego rozwiązywania ich wszystkich (w tym szybkie łamanie RSA).

Na szczęście, mimo że udowodniono przynależność do NPC dla setek problemów, to nikomu nie udało się pokazać wielomianowego rozwiązania dla żadnego z takich problemu, ani nawet udowodnić jego istnienia.
Ostatnio widziałem ankietę, że ponad połowa ekspertów przewiduje rozwiązanie kwestii problemów NPC przed 2100 rokiem.

Czuję, że ostatecznie rozwój informatyki teoretycznej wykluczy wielomianową możliwość rozwiązywania problemów NPC. Być może prędzej tego rodzaju problemy będą rozwiązywane brutalnie z wykorzystaniem komputerów kwantowych. Ale to jeszcze nie za mojego życia, gdyż wbrew temu co się w popularnej prasie propaguje postęp techniczny zwalnia

.

>Zazwyczaj istnieje szybszy sposób niż przeszukiwanie całej przestrzeni kluczy. Niekoniecznie musi to oznaczać, że złożoność jest mniejsza ale i tak można to robić wielokrotnie krócej niż sprawdzanie wszystkich kluczy.
>Weźmy taki RSA, cała jego trudność sprowadza się do znalezienia p i q takich, że pq=N.
Owszem, wspomniałem o tym wyżej

BTW, tu jest ciekawe podejście do łamania RSA: phuctor.nosuchlabs.com/phuctored
Ta strona usiłuje rozkładać klucze publiczne na czynniki pierwsze przez szukanie wspólnych dzielników wielu różnych kluczy. Zdaje się, że już mają jakieś ciekawe wyniki (Rozłożonych kluczy mają dużo, ale wygląda na to, że zawierają one błędy.)

>Rozważmy problem rozmiaru n mający n^n rozwiązań (oczywiście że n^n .> n!)
>Po pierwsze czy masz tu na myśli znalezienie wszystkich rozwiązań dla takiego problemu ?

Zwykle szukamy optymalnego rozwiązania,
np. problem komiwojażera ma złożoność n!

Licząc to na piechotę byłoby niemożliwe, bowiem już nawet 100!
>10^300,
czego nawet tryliony komputerów do kupy naraz nie policzy w czasie miliarda lat!

A jednak rozwiązują to skutecznie nawet dla n = kilkadziesiąt tysięcy,
biorąc n = 1000 byłby to już kosmos: 1000!
>10^1000, co znaczy 1 i tysiąc zer!

>Bo jeśli tak, to samo ich wypisanie miałoby złożoność n^n.

n^n rozwiązań ma np. problem szukania drogi w sieci ważonej,
w której każdy węzeł ma n sąsiadów.
Problem optymalizacji produkcji, transportu, a chyba nawet obwody elektryczne.

Takie coś rozwiązujemy liniowo!
Za pomocą metod programowania dynamicznego, albo i algorytm Dijkstry.

Można także użyć metod stochastycznych, jak wyżarzanie albo i genetyczne.

>>Tak? Zatem na czym ma polegać to szyfrowanie, że pomimo 1GB danych zaszyfrowanych, jak i nie zaszyfrowanych, nadal nie można znaleźć tego maluteńkiego kluczyka... bo raptem 256 bit = 32 bajty zaledwie!

>Zastanów się. Jeśli próbujesz odszyfrować tekst, ale podajesz złe hasło to skąd program deszyfrujący wie, że podałeś złe hasło ? Po prostu do pliku podczas szyfrowania dodawany jest fragment, którego spodziewana postać po odszyfrowaniu jest znana. Robi się tak ponieważ jedną z podstawowych zasad współczesnej kryptografii jest to aby możliwość porównania danych jawnych z zaszyfrowanymi nie ułatwiała uzyskania klucza deszyfrującego.

To jest niemożliwe:
gdy znam dane oryginalne, wówczas nie będę na oślep generował trylionów wersji,
bo wystarczy mi sprawdzić = odkodować jeden bit, czy bajt, aby stwierdzić że klucz jest nieprawidłowy.

Zatem zmieniam klucz tak aby otrzymać konkretny wynik - bajt czy znak,
i tak po kolei.
Wtedy to się zredukuje do: log(2^n) = n - jak w przypadku tamtych problemów.

Po prostu idę teraz jeną ścieżką w jakimś grafie - od wierzchołka w dół,
zamiast skanować całe drzewo - 2^n.

Nie znam się za bardzo na tych szyfrach, ale coś mi tu śmierdzi.
być może celowo głosi się, że to jest tak strasznie mocne - nie do złamania,
aby zniechęcić, odstraszyć hakerów.
Dowodów w tej teorii zbyt dużo nie widzę, jedynie jakieś mgliste bajdurzenia.

> Aby zaszyfrować tekst używa się klucza publicznego (n,e):
> c = m^e mod n (1) (c to zaszyfrowana postać liczby m)

> Aby odszyfrować (n,d):
> m = c^d mod n (2)

A czym są tu te c i m?

Powiedzmy że mam plik o długości 10 bajtów, i dokładnie taki:
0123456789

co jest tym m i c w tym przypadku?

>Zatem zmieniam klucz tak aby otrzymać konkretny wynik - bajt czy znak,
>i tak po kolei.

Mam 1 Gb oryginału i 1 Gb szyfru.
Jest (128-32) znaków możliwych w kluczu symetrycznym
czyli mamy podstawę 96 ^ ilość znaków w kluczu.
Stosuje hasło 32 znaki (moje typowe, policzyłem).
Mam 10 miliardów komputerów sprawdzających czy jest ok czy nie 1000000 miliardów razy na sekundę (zupełnie nie realne dla 1 Gb).

masz:

(96^32/(10*10^9 * 10^6* 10^9)) /(365*24*3600)
8587620624093685185011207393956.81 lat

Moje psy na pewno nie dożyją

Puste gadanie.

Coś w stylu:
jest trylion gwiazd w okolicach, więc nie sposób przelecieć z jednej do drugiej obok, ponieważ jest... trylion innych, a możliwych dróg trylion do tryliona = ... hipertylion.

>Puste gadanie.
>Coś w stylu:
>jest trylion gwiazd w okolicach, więc nie sposób przelecieć z jednej do drugiej obok,

A co ma wspólnego podróż międzygwiezdna z kryptografią?
Chyba tylko masę nośnika danych tworzącą się przy łamaniu siłowym...

>ponieważ jest... trylion innych, a możliwych dróg trylion do tryliona = ... hipertylion.

Jeżeli chcesz łamać aes256 siłowo to najprościej podać klucz i porównać wynik z oryginałem. Tak będzie i nic tego nie zmieni.

Dodatkowo trzeba pamiętać jaka kombinacja nie dała poprawnego wyniku, to też nietrywialne (przy przetwarzaniu równoległym) jest.

>To jest niemożliwe:
>gdy znam dane oryginalne, wówczas nie będę na oślep generował trylionów wersji,
>bo wystarczy mi sprawdzić = odkodować jeden bit, czy bajt, aby stwierdzić że klucz jest nieprawidłowy.
Tyle tylko, że nie jesteś w stanie kontrolować konkretnych bitów odszyfrowywanej wiadomości. Każdy bit klucza ma wpływ na wszystkie bity szyfrowanego bloku. Jesteś więc skazany na testowanie każdej możliwości, bo nie jesteś w stanie przewidzieć, jak należy dobrać klucz, aby uzyskać poprawny blok.

>np. problem komiwojażera ma złożoność n!

Problem komiwojażera (przez to ustalmy: znalezienie cyklu Hamiltona o minimalnej sumie wag dla grafu pełnego nieskierowanego) ma dla ogólnego przypadku złożoność ponadwielomianową i jest problemem NPC. Nie są znane szybsze algorytmy.

>A jednak rozwiązują to skutecznie nawet dla n = kilkadziesiąt tysięcy

Nie napisałeś nic więcej, więc trudno mi przewidzieć jaką postać problemu masz dokładnie na myśli (pewnie jakąś nie należącą do NPC).
W praktyce stosuje się:
a) algorytmy dokładne o ponadwielomianowej złożoności (jeśli rozmiar zadania jest wystarczająco mały)

Nawet w tak fatalnej sytuacji złożoność n! to przypadek bardzo pesymistyczny.
Jeśli stosujesz backtracking to przeszukując przestrzeń rozwiązań bardzo często obcinasz "ślepe uliczki".
Często korzysta się też z metody podziału i ograniczeń opierającej się o heurystyke.

Dla tego typu metod mimo, że pesymistyczna złożoność to rzeczywiście n! to należy zakładać, że natrafienie na prawidłowe rozwiązanie nastąpi zdecydowanie szybciej niż po (n!)/2 sprawdzeniach.
To może być szczególnie skuteczne jeśli graf nie jest pełny.

b) algorytmy dokładne o wielomianowej złożoności (jeśli mamy do czynienie ze szczególną postacią problemu komiwojażera np. bitoniczny problem komiwojażera itp)

bitoniczny ma np n^2

c) algorytmy przybliżone o wielomianowej złożoności (jeśli rozmiar zadania jest duży a problem komiwojażera ogólny)

np. przeszukiwanie lokalne albo christofedes (dla grafów spełniających warunek trójkąta)

>A jednak rozwiązują to skutecznie nawet dla n = kilkadziesiąt tysięcy,

Masz albo na myśli, któryś z przypadków szczególnych (b) lub przybliżonych (c).
Ewentualnie (a) przy niskiej gęstości grafu (jeśli n oznacza liczbę wierzchołków to przecież nic nam nie mówi o ilości krawędzi)

>n^n rozwiązań ma np. problem szukania drogi w sieci ważonej,

Ale byle której drogi ?
Bo interesujące są chyba tylko drogi najkrótsze (Ford-Bellaman, Dijkstra itp)
A wtedy liczba rozwiązań nie jest n^n
Podam Ci prosty kontrprzykład. Wyobraź sobie graf pełny o 3 wierzchołkach.
No to co, liczba rozwiązań byłaby 27 ?
A są przecież tylko 3 krawędzie w takim grafie.

>Takie coś rozwiązujemy liniowo!
>Za pomocą metod programowania dynamicznego, albo i algorytm Dijkstry.

Programowanie dynamiczne dla dróg to masz chyba na myśli Floyda-Warshalla ?
Ale tu złożoność jest n^3 (zależy też co rozumiesz przez n, ja rozumiem liczbę wierzchołków)
Natomiast Dijkstra ma złożoność n^2 (ostatecznie ElogV przy dobrej implementacji reprezentacji grafu)

Który algorytm za złożoność linową dla szukania najkrótszych dróg ? (bo ja nie znam takiego, a bardzo chciałbym poznać)
Jeśli natomiast chodzi o szukanie byle której drogi: przecież to zwykłe przeszukiwanie w głąb lub wszerz - złożoność liniowa względem liczby krawędzi.

>bo wystarczy mi sprawdzić = odkodować jeden bit, czy bajt, aby stwierdzić że klucz jest nieprawidłowy.

W RSA n jest zwykle bardzo dużą liczbą. Nie możesz sobie odkodować jednego bitu czy jednego bajtu. Kodowanie odbywa się w partiach po kilkanaście bajtów.
Druga sprawa, że RSA jest tak wolny w stosunku do algorytmów symetrycznych, że najczęściej używa się go tylko do szyfrowania klucza symetrycznego (albo w ogóle nie używa się RSA tylko krzywych eliptycznych).

>Dowodów w tej teorii zbyt dużo nie widzę, jedynie jakieś mgliste bajdurzenia.

Mogę Ci przedstawić dowód teoretyczny poprawności RSA. Ale czy będzie to dla Ciebie interesujące ?
Jeśli chodzi o dowód "matematycznego bezpieczeństwa" RSA , to faktycznie, nie udowodniono tego (pisałem o tym).

>A czym są tu te c i m?

>Powiedzmy że mam plik o długości 10 bajtów, i dokładnie taki:
>0123456789

>co jest tym m i c w tym przypadku?

napisałem:
m - dane jawne
c - zakodowane

W zależności o wielkości klucza (dokładnie od wielkości n), dane dzieli się na partie po kilkanaście bajtów.
Np w Twoim przypadku prawdopodobnie wszystkie bajty zostałyby potraktowane jako jedna wielka liczba m.

.

>>A jednak rozwiązują to skutecznie nawet dla n = kilkadziesiąt tysięcy,
>Masz albo na myśli, któryś z przypadków szczególnych (b) lub przybliżonych (c).
>Ewentualnie (a) przy niskiej gęstości grafu (jeśli n oznacza liczbę wierzchołków to przecież nic nam nie mówi o ilości krawędzi)

To jest to samo: brak krawędzi oznaczamy d = oo.
Rozwiązują to dla grubych tysięcy, pomimo że marne n=100 jest już zdecydowanie nie do przetworzenia na piechotę: miliard lat nie wystarczyłoby na przeszukanie 10 do 160 możliwych pętli!

>>n^n rozwiązań ma np. problem szukania drogi w sieci ważonej,
>Ale byle której drogi ?

Mowa o drogach minimalnych w zadanym sensie.

W zwyczajnej sieci jest chyba: n^n możliwych dróg pomiędzy dwoma zadanymi punktami.
No i Dijkstra wylicza to momentalnie dla grubych tysięcy, a nawet i milionów.

>W RSA n jest zwykle bardzo dużą liczbą. Nie możesz sobie odkodować jednego bitu czy jednego bajtu. Kodowanie odbywa się w partiach po kilkanaście bajtów.

To jest tylko takie wrażenie, bowiem sama reprezentacja numeryczna to narzuca - te algorytmy.

W grafach też możesz przypisać numerek każdej możliwej ścieżce,
a wtedy otrzymasz bardzo wielkie numerki.

> W zależności o wielkości klucza (dokładnie od wielkości n), dane dzieli się na partie po kilkanaście bajtów.
> Np w Twoim przypadku prawdopodobnie wszystkie bajty zostałyby potraktowane jako jedna wielka liczba m.

To znaczy że każde dane są dzielone na bloki, liczby np. po 256 bitów = 32 bajty każdy, gdy klucz ma 256 bitów?

Dość prymitywne to jest, wystarczy chyba jeden blok odkodować, i już gotowe.

Na tym pewnie opiera się to nowoczesne szyfrowanie;
stąd też im dłuższy klucz tym trudniej to zrobić...
tylko że tak jest jedynie w ramach tej teorii liczb pierwszych.

Ale pewnie nie ma żadnego dowodu, że tego nie można jakoś rozłożyć na raty,
znaczy budować ten klucz sukcesywnie - liniowo, bit po bicie, zamiast próbować w ciemno odkryć cały naraz.

>>>A jednak rozwiązują to skutecznie nawet dla n = kilkadziesiąt tysięcy,
>>Masz albo na myśli, któryś z przypadków szczególnych (b) lub przybliżonych (c).
>>Ewentualnie (a) przy niskiej gęstości grafu (jeśli n oznacza liczbę wierzchołków to przecież nic nam nie mówi o ilości krawędzi)
>To jest to samo: brak krawędzi oznaczamy d = oo.

Jesteś w błędzie.
W backtrackingu przechodzisz do kolejnych wierzchołków tam gdzie masz możliwość, następnie cofasz się (z rekurencją) i przechodzisz po kolejnej krawędzi wychodzącej z danego wierzchołka.
Nie ma sensu w ogóle przechodzić po krawędziach o wadze oo, dlatego jeśli jest dużo takich krawędzi to algorytm zakończy się dużo szybciej.

W skrajnym wypadku jeśli ilość normalnych krawędzi (mniejszych od oo) jest równa liczności wierzchołków to rozwiązanie masz natychmiast.

Jednak w prawdziwym problemie komiwojażera (należącym do NPC) graf ma wszystkie wagi skończone. Wtedy masz graf pełny czyli dla n wierzchołków masz n(n-1)/2 krawędzi.
Pół biedy jeśli wagi tych krawędzi się dość mocno wahają - wtedy przechodząc backtrackingiem dość szybko znajdziesz stosunkowo krótkie cykle i nie będziesz musiał już wchodzić z rekurencją tam gdzie nie ma nadziei na znalezienie krótszych.

Natomiast jeśli wagi krawędzi są wyrównane i jest to graf pełny czas przeszukiwania może być duży.

>Rozwiązują to dla grubych tysięcy, pomimo że marne n=100 jest już zdecydowanie nie do przetworzenia na piechotę: miliard lat nie wystarczyłoby na przeszukanie 10 do 160 możliwych pętli!

Opisałem Ci wyżej w jaki sposób "nietypowość" komiwojażera może tu dużo ułatwić.
W ogólnych i złośliwych przypadkach nie ma tak pięknie.

>W zwyczajnej sieci jest chyba: n^n możliwych dróg pomiędzy dwoma zadanymi punktami.

A można dowód lub źródło tej informacji ?
Bo to nieprawda.
Kontrprzykład: graf pełny o dwóch wierzchołkach.
n = 2
n^n = 4
ilość możliwych dróg pomiędzy dwoma zadanymi pukami = 1

>No i Dijkstra wylicza to momentalnie dla grubych tysięcy, a nawet i milionów.

Problem najkrótszych ścieżek, który rozwiązuje Dijkstra to nie problem komiwojażera.
Problem najkrótszych ścieżek uważa się za łatwy.
A i tak dla szczególnych przypadków są lepsze algorytmy, zobacz np "A star".

>>W RSA n jest zwykle bardzo dużą liczbą. Nie możesz sobie odkodować jednego bitu czy jednego bajtu. Kodowanie odbywa się w partiach po kilkanaście bajtów.
>To jest tylko takie wrażenie, bowiem sama reprezentacja numeryczna to narzuca - te algorytmy.
>W grafach też możesz przypisać numerek każdej możliwej ścieżce,
>a wtedy otrzymasz bardzo wielkie numerki.

Nie za bardzo rozumiem związek. Napisz coś więcej na ten temat.

>To znaczy że każde dane są dzielone na bloki, liczby np. po 256 bitów = 32 bajty każdy, gdy klucz ma 256 bitów?

W AESie wielkość bloku to 128b.
W RSA wielkość liczbowa bloku powinna być mniejsza niż n.

>stąd też im dłuższy klucz tym trudniej to zrobić...

Długość klucza to nie jedyny czynnik wpływający na siłę szyfrowania.
Np AES z kluczem 256 jest zdecydowanie silniejszy niż RSA z kluczem 1024 (tylko akurat te standardy są do rożnych zastosowań więc ciężko porównywać)

>tylko że tak jest jedynie w ramach tej teorii liczb pierwszych.
>Ale pewnie nie ma żadnego dowodu, że tego nie można jakoś rozłożyć na raty,

Matematyka nie dojrzała jeszcze do takich problemów. W teorii liczb postęp dość wolno się posuwa, znacznie lepiej to wygląda w dziedzinie geometrii algebraicznej dlatego nie zaleca się używania ECC dla danych o długim okresie ważności.

>znaczy budować ten klucz sukcesywnie - liniowo, bit po bicie, zamiast próbować w ciemno odkryć >cały naraz.

Bezpieczeństwo otwartych standardów szyfrowania opiera się przede wszystkim na nieustannych próbach ich forsowania przez niezależnych ekspertów, więc i Twoje dociekania w tym zakresie na pewno kryptografii nie zaszkodzą.
Wszelkie "własne i tajne pomysły" zazwyczaj się nie sprawdzają. Po prostu przeprowadzenie inżynierii odwrotnej fizycznego urządzenia bądź programu nie jest niczym szczególnie trudnym.

.

>Jesteś w błędzie.
>W backtrackingu przechodzisz do kolejnych wierzchołków tam gdzie masz możliwość, następnie cofasz się (z rekurencją) i przechodzisz po kolejnej krawędzi wychodzącej z danego wierzchołka.

Racja. Dla grafu z ujemnymi wagami raczej nie pójdzie tak łatwo.

Obecnie chyba rozwiązują ten problem w wersji: d(i,j) >= 0,
np. sieć miast w Polsce, czy w Niemczech - z 20-50 tysięcy punktów...

chociaż z drugiej strony:
każdą sieć z ujemnymi wagami można łatwo przerobić na taką z dodatnimi,
no bo przecież wystarczy dodać do każdej wagi minimalną wagę: d(i,j) += -min + 1,
a wtedy wszystkie będą dodatnie.

>>W zwyczajnej sieci jest chyba: n^n możliwych dróg pomiędzy dwoma zadanymi punktami.
>A można dowód lub źródło tej informacji ?
>Bo to nieprawda.
>Kontrprzykład: graf pełny o dwóch wierzchołkach.
>n = 2
>n^n = 4
>ilość możliwych dróg pomiędzy dwoma zadanymi pukami = 1

masz rację: liczba dróg w sieci to też n!, albo nawet (n-1)!;
bowiem tu idziemy od pierwszego do n-1 innych, potem już pozostaje: n-2, itd.

>>No i Dijkstra wylicza to momentalnie dla grubych tysięcy, a nawet i milionów.
>Problem najkrótszych ścieżek, który rozwiązuje Dijkstra to nie problem komiwojażera.
>Problem najkrótszych ścieżek uważa się za łatwy.
>A i tak dla szczególnych przypadków są lepsze algorytmy, zobacz np "A star".

Kiedyś robiłem obliczanie tras w Polsce, było tam około 7 tysięcy miast,
i wyliczałem to w czasie góra 3n chyba, czyli jednak nie było to n^3.

No, a może ja za dobry jestem... i nie zrobiłem Dijkstry, lecz coś ala Dijkstra tylko.

>Tak? Zatem na czym ma polegać to szyfrowanie, że pomimo 1GB danych zaszyfrowanych, jak i nie zaszyfrowanych, nadal nie można znaleźć tego maluteńkiego kluczyka... bo raptem 256 bit = 32 bajty zaledwie!
Zapominasz o dwoch elementach algorytmu szyfrujacego -
Key Schedule - en.wikipedia.org/wiki/Key_schedule - ktory co krok przeksztalca klucz do nowej postaci (co jest istotne dla algorytmow strumieniowych)
Tryb pracy - en.wikiped(*)Block_cipher_mode_of_operation - (co jest istotne dla algorytmow blokowych)

Jezeli jeszcze kryptosystem ma wbudowane wykrywanie i odrzucanie kluczy dajacych krotki cykl - posiadanie 1GB danych czy nawet 100TB - nic nie zmieni. - Kazdy blok danych (np dla AES 128 bitow) bedzie praktycznie zaszyfrowany innym kluczem. Co prawda bedzie isniala zaleznosc pomiedzy kluczem uzytym do szyfrowania kolejnych blokow - ale bez zlamania pierwszego bloku o dlugosci 128 bitow - nie zlamiesz nastepnych - bo technicznie inny klucz juz zostal uzyty do przeksztalcenia tego bloku.

Poprawnie zaimplementowany AES staje sie wrazliwy na niektore ataki statystyczne po zaszyfrowaniu jednym kluczem 2^64 bajtow. Czyli musial bys posiadac danych w ilosci okolo Exbibajtow.

Przy obecnej technologii - jeszscze chwile to potrwa.

Co wiecej wiekszosc kryptosystemow zmienia klucz sesji raz na jakis czas - z zaleznosci co system szyfruje - jezeli ruch sieciowy - jest to przypiete albo do zegara albo do ilosci przeslanych danych (albo obu naraz),
W przypadku szyfrowania plikow - mozna smialo zalozyc ze kazdy plik na dysku ma wlasny klucz.

>Tak? Zatem na czym ma polegać to szyfrowanie, że pomimo 1GB danych zaszyfrowanych, jak i nie zaszyfrowanych, nadal nie można znaleźć tego maluteńkiego kluczyka... bo raptem 256 bit = 32 bajty zaledwie!
Nie mam wiele do dodania do tego, co napisał Abdullah.
W przypadku prostych szyfrów miałbyś rację - np. w przypadku szyfru Vigenere'a, mając tekst jawny i tekst zaszyfrowany, znalezienie klucza jest banalne, bo i algorytm szyfrowania jest banalny. Współczesne algorytmy są projektowane w taki sposób, żeby nie było to takie proste.

>Nawet znalezienie klucza jednego spośród miliarda możliwych (30 bitów) jest w praktyce niemożliwe, bo musiałbyś dekodować to kolejno, miliard razy i sprawdzać, czy otrzymany wynik jest sensowny, czytelny - zawiera w ogóle cokolwiek sensownego, jak słowa angielskie, czy dowolne inne dane, jak fotografie, filmy, a może to dźwięk w mp3?
Akurat miliard to niedużo dla dzisiejszych komputerów Dlatego też stosuje się dłuższe klucze.

Przy okazji, to o czym piszesz ma swoją nazwę:
en.wikipedia.org/wiki/Known-plaintext_attack
I cytat stamtąd:
>Modern ciphers such as Advanced Encryption Standard are not currently known to be susceptible to known-plaintext attacks.

>Akurat miliard to niedużo dla dzisiejszych komputerów Dlatego też stosuje się dłuższe klucze.

Dlatego że algorytmy są znane - standaryzowane.

Bez tego nawet szyfr z kluczyka długości 32 bity = integer do 4 miliardów, byłby nie do rozkodowania.

>>Modern ciphers such as Advanced Encryption Standard are not currently known to be susceptible to known-plaintext attacks.

Bardzo dziwne, bo słyszałem że są programy, które pozwalają odtworzyć zaszyfrowane pliki przez te cryptowirusy, i po podaniu jednego oryginału (który zwykle mamy gdzieś indziej zapisany, np. na kopii zapasowej, lub w innym katalogu na dysku).

>Dlatego że algorytmy są znane - standaryzowane.
>Bez tego nawet szyfr z kluczyka długości 32 bity = integer do 4 miliardów, byłby nie do rozkodowania.
Akurat nieprawda. Nie znam się na tym wystarczająco dobrze, żeby Ci powiedzieć, jak to się robi, ale daje się łamać również szyfry z nieznanym algorytmem (choć oczywiście znajomość algorytmu znacznie upraszcza sprawę). Opieranie bezpieczeństwa na nieznajomości algorytmu przez przeciwnika to tzw. "security by obscurity" i jest sprzeczne z naczelną zasadą kryptografii.

>Bardzo dziwne, bo słyszałem że są programy, które pozwalają odtworzyć zaszyfrowane pliki przez te cryptowirusy, i po podaniu jednego oryginału (który zwykle mamy gdzieś indziej zapisany, np. na kopii zapasowej, lub w innym katalogu na dysku).
Prawdopodobnie efekt słabego algorytmu szyfrującego lub słabej implementacji. W takich sprawach cholernie łatwo zrobić coś źle.

>>Dlatego że algorytmy są znane - standaryzowane.
>>Bez tego nawet szyfr z kluczyka długości 32 bity = integer do 4 miliardów, byłby nie do rozkodowania.
>Akurat nieprawda. Nie znam się na tym wystarczająco dobrze, żeby Ci powiedzieć, jak to się robi, ale daje się łamać również szyfry z nieznanym algorytmem (choć oczywiście znajomość algorytmu znacznie upraszcza sprawę). Opieranie bezpieczeństwa na nieznajomości algorytmu przez przeciwnika to tzw. "security by obscurity" i jest sprzeczne z naczelną zasadą kryptografii.

Zwie sie to Zasada Kerckhoffa (pl.wikipedia.org/wiki/Zasada_Kerckhoffsa) - w skrocie "wrog zna system")

>Akurat nieprawda. Nie znam się na tym wystarczająco dobrze, żeby Ci powiedzieć, jak to się robi, ale daje się łamać również szyfry z nieznanym algorytmem (choć oczywiście znajomość algorytmu znacznie upraszcza sprawę).

Nigdy w życiu nie rozszyfrowałbyś pliku, nie mając wiedzy o algorytmie, którym został zaszyfrowany..
ani też żadna policja, super agentura rządowa, czy wojskowa - rozszyfrować tego nie zdołają!

Funkcjonuje oczywiście w obiegu mitologia o wszechmocy tajnych szpiegów, np.: wielu wierzy że tajniacy mogą go 'obserwować' przez TV (zwłaszcza wyłączony), czy śledzić z orbity jak chodzi sobie po ulicy.

No i im głównie o to chodzi: ludzie obserwowani są przecież posłuszni... więc niegroźni dla władzy.

>Nigdy w życiu nie rozszyfrowałbyś pliku, nie mając wiedzy o algorytmie, którym został zaszyfrowany..
>ani też żadna policja, super agentura rządowa, czy wojskowa - rozszyfrować tego nie zdołają!
Ja pewnie nie, podejrzewam że i Ty nie, natomiast rozszerzanie tego na innych to czysta arogancja. Historia zna niejeden przypadek złamania szyfru bez wiedzy o algorytmie.

>Ja pewnie nie, podejrzewam że i Ty nie, natomiast rozszerzanie tego na innych to czysta arogancja. Historia zna niejeden przypadek złamania szyfru bez wiedzy o algorytmie.

Puste gadanie.

Popatrz na taki przykład szyfrowania,
który jest celowo bardzo prosty, szybki i prymitywny:

biorę dowolne dane, które dzielę na bloki, albo i nie,
np. mogę te dane traktować jako serię liczb:
1-bitowych, 5-cio bitowych, 37, itd.

No ale dla ułatwienia biorę 8 bitów, czyli zwyczajne bajty.

A samo szyfrowanie polega na wyprodukowaniu k-tej permutacji tej serii liczb.
Dla pliku o rozmiarze np. 1000 bajtów mamy 1000 silnia permutacji, więc możesz sobie próbować... miliony lat!
Numer permutacji może być kodowany w kluczu, jak i w samych danych.

Inny prymitywny sposób - też nie do złamania:

biorę biblię albo inne popularne źródło,
odpowiednio duże, np. może to być film, czy cokolwiek (nie wiemy co to jest).

Koduję dane, pobierając liczby z tej biblii, indeksując ją liczbami generowanymi z prywatnego generatora random, który jest inicjowany kluczem lub też samymi danymi, które kodujemy.

Potem robię np. zwyczajny xor pary liczb:

szyfr[i] = dana[i] xor biblia[random(i)];

>Popatrz na taki przykład szyfrowania,
>który jest celowo bardzo prosty, szybki i prymitywny:
>biorę dowolne dane, które dzielę na bloki, albo i nie,
>np. mogę te dane traktować jako serię liczb:
>1-bitowych, 5-cio bitowych, 37, itd.
>No ale dla ułatwienia biorę 8 bitów, czyli zwyczajne bajty.
>A samo szyfrowanie polega na wyprodukowaniu k-tej permutacji tej serii liczb.
>Dla pliku o rozmiarze np. 1000 bajtów mamy 1000 silnia permutacji, więc możesz sobie próbować... miliony lat!
>Numer permutacji może być kodowany w kluczu, jak i w samych danych.
>Inny prymitywny sposób - też nie do złamania:
>biorę biblię albo inne popularne źródło,
>odpowiednio duże, np. może to być film, czy cokolwiek (nie wiemy co to jest).
>Koduję dane, pobierając liczby z tej biblii, indeksując ją liczbami generowanymi z prywatnego generatora random, który jest inicjowany kluczem lub też samymi danymi, które kodujemy.
>Potem robię np. zwyczajny xor pary liczb:
>szyfr[i] = dana[i] xor biblia[random(i)];
Twoje przykłady zachowają pewne cechy statystyczne, które dobry kryptolog prawdopodobnie zdołałby wykorzystać do złamania Twoich szyfrów (przy odpowiednio dużej próbce szyfrogramów).

Co ciekawe, przykład z Biblią jest bardzo blisko tzw. one-time pad, który faktycznie jest nie do złamania, a jednocześnie wystarczająco daleko, żeby mieć potencjalnie tragiczną słabość Mianowicie, aby one-time pad był nie do złamania, klucz musi być idealnie losowy - tutaj nie jest, gdyż Twoim kluczem jest losowy ciąg znaków z Biblii, a one nie mają jednorodnego rozkładu. Jeszcze zabawniejsze jest to, że gdybyś olał Biblię i zrobił szyfr[i] = dana[i] xor random[i], to otrzymałbyś dokładnie one-time pad (zakładając dobry generator liczb losowych)

Morał - więcej pokory, kiedy na czymś się nie znasz.

>Twoje przykłady zachowają pewne cechy statystyczne, które dobry kryptolog prawdopodobnie zdołałby wykorzystać do złamania Twoich szyfrów (przy odpowiednio dużej próbce szyfrogramów).

Jedynie w przypadku tej permutacji statystka będzie zachowana,
bowiem tu przestawiam jedynie znaki.

>Morał - więcej pokory, kiedy na czymś się nie znasz.

Ty masz za dużo wiary w propagandę tych pajaców, kryptologów,
pseudoprogramistów od strugania świeczki.
Faktycznie oni są głupsi od ciebie, pomimo że ty nie siedzisz w tym śmiesznym biznesie.

.
>Bardzo dziwne, bo słyszałem że są programy, które pozwalają odtworzyć zaszyfrowane pliki przez te cryptowirusy, i po podaniu jednego oryginału (który zwykle mamy gdzieś indziej zapisany, np. na kopii zapasowej, lub w innym katalogu na dysku).
>

Te programy działają rożnie -
- albo baza danych kluczy została przejęta przez policję / firmy antywirusowe (np tutaj inicjatywa europolu i firm AV - www.nomoreransom.org/)
- albo implementacja szyfrowania ma błędy
- albo inny błąd był popełniony - np panowie "koolio hakerzy" zapomnieli jak działa usuwanie plików i algorytmy rezerwacji przestrzeni dyskowej - co pozwala na "odkasowanie" oryginalnych plików a przyjajmniej większości z nich.

>- albo baza danych kluczy została przejęta przez policję / firmy antywirusowe (np tutaj inicjatywa europolu i firm AV - www.nomoreransom.org/)

A po co komu baza kluczy?
Powinni generować te klucze... in fly.

Gdybym chciał takie wirusy produkować, no to żaden czarodziej nie rozkodowałby tego, nawet i tym mitycznym komputerkiem kwantowym.

.
>Gdybym chciał takie wirusy produkować, no to żaden czarodziej nie rozkodowałby tego, nawet i tym mitycznym komputerkiem kwantowym.

Widzę że mamy następnego trola na forum.

No zawsze możesz mi "pokazać" i wyprodukować - wyślij produkt na tą grupę - dostanę przeanalizuje odszczekam.
digital-fo(*)thal-forensicator/coin-holders

I nie zapomnij o warunkach które sam postawiłeś - stworzysz takiego wirusa ze nawet po przejęciu bazy kluczy nie będzie sie dało odczutać plików nim Zaszyfrowanych

>I nie zapomnij o warunkach które sam postawiłeś - stworzysz takiego wirusa ze nawet po przejęciu bazy kluczy nie będzie sie dało odczutać plików nim Zaszyfrowanych

Znam przypadek w którym zaszyfrowały się dane na serwerze plików i poradzić sobie z tym administratorzy nie mogli. Nie musi to być trywialne.

>>I nie zapomnij o warunkach które sam postawiłeś - stworzysz takiego wirusa ze nawet po przejęciu bazy kluczy nie będzie sie dało odczutać plików nim Zaszyfrowanych
>Znam przypadek w którym zaszyfrowały się dane na serwerze plików i poradzić sobie z tym administratorzy nie mogli. Nie musi to być trywialne.

Cala dyskusja jest o nie trywialnosci tego problemu. Ale nasz trol-uczen sie zagalopowal i glupio chlapnal - wiec postanowilem sprawdzic karty.

Nie zapominaj tez ze administrator to nie kryptoanalityk/informatyk śledczy. To dwie zupełnie inne dyscypliny z zupełnie inna wymaganą wiedzą.
Administrator - ma za zadanie utrzymać ruch w interesie - jego celem jest aby w wykrywać warunki gdy system może przestać działać i je usuwać.
Informatyk śledczy rozwiązuje zagadki - pojawiające się gdy system przestanie działać i administratorzy są pewni, że odpowiedzialna jest trzecia strona niezbyt przyjaźnie nastawiona do organizacji. I tak jak informatyk śledczy najprawdopodobniej nie utrzyma ruchu w interesie (no może z wyjątkiem bardzo małych środowisk - ale takie miejsca z prawie nigdy nie mają nadwornego informatyka śledczego) - tak administrator nie musi sobie poradzić z dogłębną analizą złośliwego oprogramowania czy łamaniem zabezpieczeń/szyfrów.

Nie pajacuj.
Gdzie się zagalopowałem, śmieszny trollu od kryptografii szkolnej?

Gadaj tylko tyle co wiesz, nie więcej.

>Nie zapominaj tez ze administrator to nie kryptoanalityk/informatyk śledczy. To dwie zupełnie inne dyscypliny z zupełnie inna wymaganą wiedzą.

Znam to ze szkolenia, ja tego nie widziałem. Podobno się starali ...
Mieli archiwizacje na taśmach, w kółko po chyba 10 dniach powtórka z nocy.
Końcówka MS$ podpięta na sieciowy wolumen się zaraziła i pliki MW$ zaszyfrowały się w locie. Ponoć więcej niż miała dostęp.
Nie było testu na niezależnym OS i serwerze czy chociażby wyrywkowe dane są ok (na Libre Office czy Open Office nie otworzysz zarażonego docx czy innego) i archiwizacji stałej co tydzień. Po kilku tygodniach wirus skasował się z OS i był zonk. Uważam to za możliwe. To było chyba rok temu, jeszcze się nie chwalili ci od firm security że rozszyfrowują ramsonware czy jak mu tam.

A Windows 10 to wspaniały przykład przerostu formy nad treścią
Ja wysiadam na wstępie

>No zawsze możesz mi "pokazać" i wyprodukować - wyślij produkt na tą grupę - dostanę przeanalizuje odszczekam.
>digital-fo(*)thal-forensicator/coin-holders
>I nie zapomnij o warunkach które sam postawiłeś - stworzysz takiego wirusa ze nawet po przejęciu bazy kluczy nie będzie sie dało odczutać plików nim Zaszyfrowanych

Nie rozśmieszaj mnie.

Chcesz to mogę ci wysłać:
jedno malutkie zdanie - z 80 znaków zaszyfrowanego tekstu, no i zobaczymy czy to odczytasz.

Mogę też wysłać 1 bajt zaszyfrowany w 1kB - pasuje... haha!
Oj, dzieciaki.

>Bez tego nawet szyfr z kluczyka długości 32 bity = integer do 4 miliardów, byłby nie do rozkodowania.
A to ciekawe - tajny szyfr CSS (content scramble system) z kluczem 40 bitowym - został złamany w 1999r - w 3 lata po publikacji
en.wikipedia.org/wiki/Content_Scramble_System
Po prostu byl kiepski.

Idea że algorytmy szyfrowania są publiczne ma bardzo istotne znaczenie - każdy student i doktorant chciałby móc napisać w CV złamalem taki algorytm szyfrowania - i wielu naprawde dobrych ludzi podejmie taka próbe.
Najlepsze algorytmy (AES, TwoFish, Ron's Code 6) oparły się takim próbom przez lata.

Jeżeli chcesz poczytać jak podchodzi się do szyfrów gdzie algorytmy są nieznane - polecam ksiazkę Rejewskiego o złamaniu Enigmy - ja wiem stary to już szyfr ale matematyka w tej książce pokazana podpowiada jak się do tego typu problemów podchodzi.

>Jeżeli chcesz poczytać jak podchodzi się do szyfrów gdzie algorytmy są nieznane - polecam ksiazkę Rejewskiego o złamaniu Enigmy - ja wiem stary to już szyfr ale matematyka w tej książce pokazana podpowiada jak się do tego typu problemów podchodzi.

Pewnie podpuścili i przechwycili klika depesz - jak w Midway.
Innych sposobów na to nie ma.

Przede wszystkim ustalmy, że mówimy o szyfrowaniu symetrycznym, tj. takim w którym hasło szyfrujące i deszyfrujące jest jedno, identyczne w przypadku wiadomości znane zarówno nadawcy jak i odbiorcy (w przypadku szyfrowania asymetrycznego jest nieco inaczej i inaczej oblicza się rzeczywistą moc klucza).

Sprawa druga jest taka, że hasło a klucz to dwie różne rzeczy. Dany klucz jest niejako wynikiem użycia danego hasła. Długość klucza jest zaszyta w sam określony mechanizm szyfrowania, natomiast hasło wybiera użytkownik. W praktyce złamanie hasła jest zwykle dużo prostsze niż klucza. Cóż bowiem z tego, że klucz ma długość 256bit (szyfrowanie symetryczne) albo 4048bit (asymetryczne) skoro użytkownik użył hasła: admin1 ?

>Na czym polega to komputerowe szyfrowanie: 128 bitowe, 256, 1024 itp. ?
>Jest to podobno nie do rozwalenia, ponieważ wymagałoby milionów lat obliczeń!

>A jak będzie z tym rozszyfrowywaniem, gdy mam obie wersje danych,
>np. tekst oryginalny - przed zaszyfrowaniem, jak i ten już po zaszyfrowany:
>czy z togo można już wyciągnąć te klucze używane w szyfrowaniu,
>i rozszyfrować inne dane, w których zastosowane ten sam schemat oraz klucze?
>

Liczba bitów to długość klucza szyfrującego, inaczej to liczba kombinacji do złamania szyfru "na piechotę", tzn. badając po kolei wszystkie możliwości. Metoda ta (ang. brute force) opiera się na "brutalnej sile" obliczeniowej współczesnych komputerów a nie na jakichkolwiek matematyczno-lingwistycznych dociekaniach, inżynierii odwrotnej sprzętowych układów szyfrujących czy metodach socjotechnicznych. Jest to metoda 100% pewna dla każdego szyfru o ile tylko ma się do dyspozycji wieczność albo/i nieskończenie szybki komputer Niestety jest to też metoda najwolniejsza.

Przykład Jeśli klucz jest 40bitowy, tzn. żeby mieć 100% pewność jego złamania trzeba wykonać 2^40 prób / sprawdzeń klucza. Zakładając, że przeciętny komputer wykonuje 2^20 prób w ciągu sekundy daje to nieco ponad 12 dni pracy bez przerwy. Ponieważ jednak łamanie szyfrów metodą brute force jest problemem łatwym do zrównoleglenia, to milion takich komputerów poradziłoby sobie z tym kluczem w ciągu około 1 sekundy.
Łatwo policzyć więc, że teoretyczne prawdopodobieństwo złamania klucza 256bitowego metodą bruteforce nawet przy pracy całej mocy obliczeniowej wszystkich komputerów na świecie choćby przez miliony lat jest wciąż bliska zeru.

Ok, wiemy już jak się objawia szyfrowanie i jest ale dlaczego nie można jakoś mądrze rozsupłać szyfrogramu? Ano dlatego, że u podstaw użytych algorytmów szyfrowania są zawarte same podstawy matematyki a mianowicie liczby pierwsze i to co się z nimi wiąże, czyli m.in. jeden z dużych problemów dotyczących złożoności obliczeniowej.
Przypomnienie ze szkoły liczby pierwsze to te które dzielą się tylko przez 1 i przez samą siebie, kolejno to: 1, 2, 3, 5, 7, 11, 13, 17, ... jeśli pomnożymy przez siebie otrzymamy liczbę która... tak podzielić można (pomijając sam iloczyn i 1) tylko na właśnie te dwie liczby pierwsze. I tu dochodzimy do sedna: matematycy nie znają jakiejkolwiek zależności występowania liczb pierwszych w ciągu liczb. Co więcej, prawdopodobnie, w ogóle ich występowanie nie układa się w jakikolwiek wzorzec. Dlatego też choć 77 łatwo nam rozbić na dwie składowe 7 i 11 to zgadnięcie 200cyforwych liczb pierwszych składających się na 400cyfrowy iloczyn jest niemal niemożliwe. Jednak przemnożenie 200cyfrowych liczb pierwszych jest wykonywane błyskawicznie przez przeciętny komputer. Dlatego też znając hasło a co za tym idzie mają wygenerowane obie liczby pierwsze możemy bez trudu odszyfrować dane a nie znając hasła a co za tym idzie obu liczb pierwszych możemy tylko zgadywać.

Zadanie domowe

1) Jak algorytm faktoryzacji Petera Shora użyty na komputerach kwantowych może zagrozić współczesnym algorytmom szyfrowania opartym o iloczyny liczb pierwszych?
2) Co to są tablice tęczowe oraz na czym polega i do czego służy "solenie" danych (ang. salt)

dla chętnych zadania z gwiazdką:

3) szyfrowanie asymetryczne RSA/PGP/GPG - mechanizm działania, porównać z szyfrowaniem symetrycznym
4) jak działa algorytm szyfrowania Off-The-Record - porównanie z szyfrowaniem asymetrycznym RSA - wady i zalety, odpowiednie i nieodpowiednie zastosowania
5) czym się różnią statystycznie dane z redundancja 0% (idealna kompresja) od generatora liczb losowych (idealny "szum") i od idealnego szyfrogramu - jak je odróżnić?
6) dlaczego szyfrowanie SSL/TLS (w modelu PKI) używane na serwerach webowych i e-mailowych nie zapewnia prywatności rozmówcom.
7) generatory liczb losowych (prawdziwe) a generatory liczb pseudolosowych - czyli wynik funkcji chaosu a chaos naturalny - jak odróżnić?

>1) Jak algorytm faktoryzacji Petera Shora użyty na komputerach kwantowych może zagrozić współczesnym algorytmom szyfrowania opartym o iloczyny liczb pierwszych?

Nijak, bowiem mitologia nie ma żadnego znaczenia w technice.

>5) czym się różnią statystycznie dane z redundancja 0% (idealna kompresja) od generatora liczb losowych (idealny "szum") i od idealnego szyfrogramu - jak je odróżnić?

Nie ma różnic.

>6) dlaczego szyfrowanie SSL/TLS (w modelu PKI) używane na serwerach webowych i e-mailowych nie zapewnia prywatności rozmówcom.

A zapewnia?

>7) generatory liczb losowych (prawdziwe) a generatory liczb pseudolosowych - czyli wynik funkcji chaosu a chaos naturalny - jak odróżnić?
>

Nie da rady tego odróżnić.
Dobry random, o dużym cyklu, np. 64 bity, spełnia wszelkie testy tzw. prawdziwej losowości.
Twierdzenie Weyla chyba..
en.wikipedia.org/wiki/Equidistributed_sequence

>>1) Jak algorytm faktoryzacji Petera Shora użyty na komputerach kwantowych może zagrozić współczesnym algorytmom szyfrowania opartym o iloczyny liczb pierwszych?
>Nijak, bowiem mitologia nie ma żadnego znaczenia w technice.

Wydaje mi się, że mylisz niejawność z bezpieczeństwem.

1. Niejawność:

Jeśli masz jakieś ważne, swoje dane to możesz je powiedzmy zxorować z kolejnymi liczbami modulo 8 początkowo od 1103 miejsca po przecinku rozwinięcia dziesiętnego pierwiastka kwadratowego liczny Eulera.
Następnie powinieneś usunąć program, który napisałeś do zmiany struktury swoich dokumentów.
Inaczej siła Twojego szyfrowania jest najwyżej taka jak trudność w fizycznym dostępie do tego programu.
Jest to bardzo niepraktyczne bo za każdym razem kiedy chciałbyś uzyskać dostęp do tych danych musiałbyś pisać program/ skrypt deszyfrujący od podstaw (zapisanie go na dysku razem z danymi mija się przecież z celem).

Jest to jeszcze bardziej zawodne przy transmisji. Nawet jeśli udałoby Ci się w bezpieczny sposób dostarczyć swój program szyfrujący/deszyfrujący do współpracowników, to musisz się liczyć z tym, że w każdej chwili, ktoś może ten program wykraść. Z enigmą ostatecznie rozprawiono się właśnie dlatego, że przejęto jedną z maszyn. Przy RSA mógłbyś bez żadnego problemu używać nowego klucza na każdą transmisje.

2. Bezpieczeństwo:

W normalnych zastosowaniach (karty płatnicze i biletowe, DRM itp) należy liczyć się z tym, że urządzenie/ program wpadnie w ręce kogoś kto dokładnie przeanalizuje jego działanie i odtworzy wykorzystywany algorytm. W związku z tym użycie własnej kryptografii niczego tu nie utrudni. Byłoby to ryzykowne nawet gdybyś był kryptologiem, ponieważ siła standardów szyfrowania jak dotąd nie opiera się na dowodach analitycznych, ale raczej na tym, że nie poddały się one atakom ze strony milionów ludzi od wielu lat.
Philips wielokrotnie próbował stosować własny system kryptograficzny Mifare w swoich bezstykowych kartach kryptograficznych. Za każdym razem kończyło się to upublicznieniem narzędzia pozwalającego na obejście zabezpieczeń tych kart. Pojawiły się nawet spekulacje, że Philips celowo uparcie stosuje własną kryptografie, ponieważ chce aby karty były łamane, gdyż to wymusza na kliencie konieczność zakupu nowych kart

Dzięki kryptografii asymetrycznej mogę przez niezaufany kanał (tak jak tutaj) ogłosić swój klucz publiczny i każdy kto wyrazi taką chęć będzie mógł w bezpieczny sposób mi odpowiedzieć.

Jeśli uważasz, że RSA to ściema to proszę:
Na stronie pgpkeygen.com/ wygenerowałem klucz publiczny RSA-1024:

Cytat:

Odeślij za jakiś czas odpowiadający mu klucz prywatny w formacie akceptowanym przez PGP.
Przy okazji masz do dyspozycji nieskończoną ilość danych jawnych i odpowiadających im zaszyfrowanych (klucz publiczny pozwala na szyfrowanie do woli).
Nie musisz zdradzać jak to złamiesz.
Odesłanie klucza prywatnego będzie dla nas dostatecznym dowodem, że potrafisz to zrobić.

.

>Jeśli uważasz, że RSA to ściema to proszę:
>Na stronie pgpkeygen.com/ wygenerowałem klucz publiczny RSA-1024:

A pewnie że to banały.

>Odeślij za jakiś czas odpowiadający mu klucz prywatny w formacie akceptowanym przez PGP.
>Przy okazji masz do dyspozycji nieskończoną ilość danych jawnych i odpowiadających im zaszyfrowanych (klucz publiczny pozwala na szyfrowanie do woli).
>Nie musisz zdradzać jak to złamiesz.
>Odesłanie klucza prywatnego będzie dla nas dostatecznym dowodem, że potrafisz to zrobić.

Nie mam czasu na dziecinadę,
poza tym dowolny szyfr jest nie do ruszenia,
przykładzik:

'rura bomba koń trąba popiół siano rozstrzelano'

rozszyfruj mi to mistrzu, hehe!

Przy okazji przypominał mi się film, w którym ruski agent pracował w pentagonie,
i tam był taki popis tych durniów od szyfrowania:
oni dekodowali fotografię na której był ten szpieg...
mieszali, liczyli, kombinowali, no i ostatecznie rozkodowali to...
za pomocą transformacji Fouriera chyba, kupa śmiechu.

A tak przy okazji: facet od urodzenia żyje tam gdzie się urodził,
chodzi do szkoły, potem tam też pracuje, zna wszystkich dookoła,
a wszyscy jego... nie zna nawet obcych języków... bo niby po co?
Raptem okazuje się że to szpieg obcy... z innej planety!
Ludziom totalnie odbija...

>'rura bomba koń trąba popiół siano rozstrzelano'
>rozszyfruj mi to mistrzu, hehe!

Oczywiście, że czegoś takiego nie rozszyfruje.
Ale to jest niejawność.

Niejawność nie ma zbyt dużego praktycznego zastosowania ponieważ:
1. generuje trudności związane z uzgodnieniem i utajnieniem algorytmu szyfrowania (przy transmisji)
2. problem z przechowywaniem algorytmu. W zasadzie algorytm sam w sobie jest hasłem. Takiego algorytmu raczej nie schowasz w głowie, więc będziesz musiał go przechowywać fizycznie np. na pendrive. (przy zabezpieczaniu danych na miejscu)

Tymczasem kiedy tworzymy krypto-systemy potrzebujemy bezpieczeństwa, bowiem zarówno programy jak i urządzenia fizyczne poddają się inżynierii wstecznej.

Osobiście nie podejrzewam tu jakiegoś wielkiego spisku ponieważ na otwarte narzędzia szyfrujące patrzy i rozwija je cała rzesza zwolenników ruchu wolnego oprogramowania
(przecież z drugiej strony nikt nikomu nie zabrania używać własnych metod szyfrowania)

.

>Niejawność nie ma zbyt dużego praktycznego zastosowania ponieważ:
>1. generuje trudności związane z uzgodnieniem i utajnieniem algorytmu szyfrowania (przy transmisji)
>2. problem z przechowywaniem algorytmu. W zasadzie algorytm sam w sobie jest hasłem. Takiego algorytmu raczej nie schowasz w głowie, więc będziesz musiał go przechowywać fizycznie np. na pendrive. (przy zabezpieczaniu danych na miejscu)

A cóż to za problem wykonać pogram w c, czy nawet basicu, składający się z trzech linii.

Przykładowo: bierzesz słownik portugalskiego, w którym jest zapewne coś rzędu miliona pozycji, no każdy naturalny tyle ma, no i robisz tylko podmianki wg jakiegoś tam schematu, np.:

i-te słowo zastępujemy:
k-tym = (i^77+555553) modulo 7771 xor (random()^2 * phi_binarny) and not rnd512 + exp...

przecież to jest dziecinnie łatwe.

>Tymczasem kiedy tworzymy krypto-systemy potrzebujemy bezpieczeństwa, bowiem zarówno programy jak i urządzenia fizyczne poddają się inżynierii wstecznej.

A kiedyś przyleci to UFO, no i co będzie?
Przecież oni używają kluczy algorytmicznych... znaczy klucz tam jest algorytmem... hehe!

>Osobiście nie podejrzewam tu jakiegoś wielkiego spisku ponieważ na otwarte narzędzia szyfrujące patrzy i rozwija je cała rzesza zwolenników ruchu wolnego oprogramowania
>(przecież z drugiej strony nikt nikomu nie zabrania używać własnych metod szyfrowania)

Jasne... głupota samoistnie się propaguje i utrwala,
a wy, znaczy kryptolodzy, jesteście jedynie jej nosicielami.
.

Tak przy okazji.
Słyszałem że w Chinach szyfrują już komunikaty w obrazkach.
Robią to jakoś tak:
każdy obraz, niezależnie od typu: gif, jpg, ... zawiera kilka mega,
więc cóż to za problem zakodować w tym kilka zdań tekstu?

W praktyce robimy to tak:
używamy jedynie ostatnich bitów, tych najmniej znaczących,
z obrazu, co daje możliwość zakodowania tekstu o długości aż 1/8 rozmiaru obrazu,
czyli potężnie dużo!

Wtedy sam obraz nie ulega praktycznie żadnej zmianie, bowiem składowa koloru: R, G lub B, albo H, L lub S, itp.; 255 zamieniona na 254, czy też: 54 na 55, itp. nie ma żadnego istotnego wpływu na wygląd obrazka, no ale moja informacja tam siedzi!

>Dzięki kryptografii asymetrycznej mogę przez niezaufany kanał (tak jak tutaj) ogłosić swój klucz publiczny i każdy kto wyrazi taką chęć będzie mógł w bezpieczny sposób mi odpowiedzieć.
>Jeśli uważasz, że RSA to ściema to proszę:
>Na stronie pgpkeygen.com/ wygenerowałem klucz publiczny RSA-1024:

1. Generuje się na swojej maszynie, niezaufana strona trzecia ma parę kluczy i hasło do nich Konto pocztowe masz podane niepoprawnie w swoim kluczu, nie ma domeny .p
pub 1024R/A8A5DC9D 2016-08-10
uid Wiktor (Kom) <wiktor@wiki.p>

2. Główny problem gnupg to bazy kluczy publicznych, nie wiadomo które są ważne a które nie (jak ktoś nie ustawił trwałości odpowiednio).
Przekazanie odcisku klucza też nie jest trywialne (najlepiej w opisie do przelewu bankowego chyba, posyłasz korespondentowi 1 grosz i już).

>Odesłanie klucza prywatnego będzie dla nas dostatecznym dowodem, że potrafisz to zrobić.

Mieliśmy nie karmić, zaraz przyjdzie AB i się nam oberwie.

ps
Z zadaań domowych padam na 1, o co chodzi tak łopatologicznie z tymi komputerami kwantowymi? Jest coś takiego chociaż w zarysie ?

>1. Generuje się na swojej maszynie, niezaufana strona trzecia ma parę kluczy i hasło do nich

Przecież wiem
Ale nie podejrzewam, że pantaray kolaboruje z tym serwisem.

>Konto pocztowe masz podane niepoprawnie w swoim kluczu, nie ma domeny .p

Tam było wszystko przykładowe. Nie jest to mój prawdziwy klucz.

Swoją drogą jeśli chciałby pisać swoje metody szyfrowania to i musiałby swój system operacyjny napisać.
Skąd wie, że Linus Torvalds nie współpracuje z NSA ?

youtube.com/watch?v=7gRsgkdfYJ8
.

>Swoją drogą jeśli chciałby pisać swoje metody szyfrowania to i musiałby swój system operacyjny napisać.

Nie widzę problem z napisaniem systemu operacyjnego... przynajmniej tego jądra, bo reszta to już robota dla... zwyczajnych programistów.

A dlaczego ja zakładałem w ogóle ten temat o szyfrowaniu?
Ano dlatego że jakiś głupi wirus zaszyfrował mi klika dysków,
no więc tak z lekka mnie to zainteresowało:
co ci idioci tworzą, a tak i w ogóle na czym stoi ten śmieszny biznes.

>>Konto pocztowe masz podane niepoprawnie w swoim kluczu, nie ma domeny .p
>Tam było wszystko przykładowe. Nie jest to mój prawdziwy klucz.

Swego czasu przynajmniej jeden z serwisów kluczy chodził przez email, można było brać klucze masowo , idealne dla spamerów ...

>Swoją drogą jeśli chciałby pisać swoje metody szyfrowania to i musiałby swój system operacyjny napisać.

Nie musisz mieć systemu, jednoukładowy procek podpięty pod RS232 (najprościej chyba sterowanie zrobić po RS) starczy. Tworzysz na jakimś openbsd, linuxie, openDOS itp tekst na typowym kompie, wysyłasz na szyfrator i odbierasz wynik. Są procki specjalizowane do tego ale normalny też może być. Typowe karty kryptograficznie tak działają przecież (oczywiście pomijam że to zazwyczaj wymaga M$ i Java). Atmel ma narzędzia pod C na 8 i 32 bitowe procesory jednoukładowe (8 bitów łatwo się lutuje na pająka, 32 to raczej moduł bo są wymagania częstotliwościowe co do płytki), nie widzę problemu dostosować jakieś źródła. Te procki nie mają bootloadera ani nic jak nie chcesz itp, można wstawić wszystko na piechotę, idealne do cypherpunku.

Naturalnie pojawia się pytanie czy np. kompilator jest ok. Ale przy kompilacji skrośnej i utworzeniu gcc ze źrodeł pod Atmela to już raczej paranoja a nie racjonalizm podejrzewać że coś jest nie tak.

Można zbudować cały sterownik, klawiaturę itp do szyfrowania na takich kościach, coś ala mikrokomputer, to nie jest trudne (sterownik na LED to sam napisałem do swojego hardware w dwa popołudnia bo się coś biblioteka nie chciała zgadzać, LCD są trudniejsze ale to tez nie temat Jak to mawiał mój kumpel (zanim pojechał do Irlandii i coś nie mam kontaktu) ważne dane są zazwyczaj małej objętości Pendrive do tego i masz zabawkę jak nic.

>Skąd wie, że Linus Torvalds nie współpracuje z NSA ?

Kernel czy linux jest źrodłowy, ktoś coś znajdzie jakby co.
gnupg jest z Niemczech a nie z USA przecież.

Bardziej obawiałbym się dziur w algorytmach niż w OS (takich normalnych OS naturalnie, nie M$). Wywiad brytyjski używa ponoć audytowanego Linuxa, VMWare , Xen też linuxopodobne (te dwa ostatnie to może nie do kryptografii ale chodzi mi o tręd

Mnie się win10 podoba, czy ogólnie MS$

ps
Trzeba zrobić rewolucję na portalu i wymóc zmianę regulaminu jaskini trolli. Nie tydzień czasu na wątek tylko dożywotnio, nie wolno zmieniać ani kasować żadnych wypowiedzi nikomu tak jak to było na news (za wyjątkiem wypowiedzi pod paragraf taki konkretny - groźby karalne, bezpieczeństwo państwa itp) i moderator ma prawo tylko wywalić wątek do jaskini a nie coś kasować. Założymy sobie tam hierarchie z tytułami i skończą się jęki że coś jest nie na temat, spam, kogoś wywalić bo agituje i się robi głosowanie (to dopiero porażka jest), żale za moderacją starą i dobra itp.

>Trzeba zrobić rewolucję na portalu i wymóc zmianę regulaminu jaskini trolli. Nie tydzień czasu na wątek tylko dożywotnio, nie wolno zmieniać ani kasować żadnych wypowiedzi nikomu tak jak to było na news (za wyjątkiem wypowiedzi pod paragraf taki konkretny - groźby karalne, bezpieczeństwo państwa itp) i moderator ma prawo tylko wywalić wątek do jaskini a nie coś kasować. Założymy sobie tam hierarchie z tytułami i skończą się jęki że coś jest nie na temat, spam, kogoś wywalić bo agituje i się robi głosowanie (to dopiero porażka jest), żale za moderacją starą i dobra itp.

A co to ma być - opinie trolla malkontenta?
Ostatnie ostrzeżenie! Następnym razom będę takie.. wymioty usuwał... bez żadnego komentarza.

>A co to ma być - opinie trolla malkontenta?
>Ostatnie ostrzeżenie! Następnym razom będę takie.. wymioty usuwał... bez żadnego komentarza.
>
A usuwaj a nawet wywal z portalu, na zdrowie. Jak Tobie to przyjemność sprawi (jest zresztą jakiś temat o przyjemności) - zawsze do usług.
Nikt się nie skompromituje bardziej niż on sam.

ps
Strasznie tu Towarzystwem Wzajemnej Adoracji zalatuje, takim ęą, jaśniepanie itp.
I jednocześnie czuć dyskretny zapach zgnilizny, jak z otwartego grobu