Problem z szyfrowaniem komunikacji między mcu

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Polish to

Threaded View
Mam jakieś zaćmienie,  problem może nie do końca z tematki grupy ale  
w końcu dotyczy obszaru mikrokontrolerów więc zaryzukuję. Dwa mcu  
komunikują się ze soba (UART), jeden wysyła polecenie (komunikat)  
drugiemu, ten drugi wykonuje robotę w zależności od polecenia,  
komunikacja jest w jedną stronę (mcu1->mcu2) i wg schematu: polecenie  
-> wykonanie. Chciałbym zaszyfrować komunikację między tymi dwoma  
mcu, aby nie można było podsłuchać komunikatu i go później  
"podrzucić" do mcu2 wpinając się w uart. Założenie jest takie, że oba  
mcu maja "w sobie" klucz, wybieram jakis dowolny cipher. I tu pojawia  
się problem, bo generalnie szyfrownaie nic nie daje, bo: mcu 1  
szyfruje polecenie X, dajac zaszyfrowany strumień, powiedzmy  
"Gk16w123clh3RZdYbGZc8g", 2 mcu mając ten sam klucz deszyfruje  
"Gk16w123clh3RZdYbGZc8g" dostając polecenie X i je wykonuje. Teraz  
wystarczy "udawać" mcu1 i wysłać do mcu2 po prostu  
"Gk16w123clh3RZdYbGZc8g", które zostanie odszyfrowane i spowoduje  
wykonanie polecenia X. Jak w miarę prosty sposób uniemożliwić taki  
atak? Wyobrażam sobie, że mcu2 może pierwszy nawiązywać komunikację i  
stowrzyć "dialog", który (jeśli będzie prawidłowy) oznaczać będzie,  
że druga strona ma prawidłowy klucz, czyli jest zaufana. Ale można  
wyobrazić sobie, że będzie można całą sekwencje odpowiedzi mcu1  
podrzucic na podstawie analizy statytycznej (np. wcześniej snifująć  
komunkację), liczba możliwych kombinacji jesty wielka ale skończona,  
więc nadal problem istnieje...

--  
Marek

Re: Problem z szyfrowaniem komunikacji między mcu
W dniu 22.07.2013 23:07, Marek pisze:
Quoted text here. Click to load it

Poczytaj o funkcjach haszujących.

--  
Pozdrawiam
Jakub Rakus

Re: Problem z szyfrowaniem komunikacji między mcu
On 22.07.2013 23:07, Marek wrote:
Quoted text here. Click to load it

google: replay attack

Quoted text here. Click to load it

Rozwiązań jest wiele - możesz umieszczać timestamp o ile jest wspólny,  
możesz przesyłać numer sekwencyjny i zapisywać go po obu stronach.  
Możesz zignorować problem bo może go tak naprawdę nie ma...

--  
Pozdrawiam
Michoo

Re: Problem z szyfrowaniem komunikacji między mcu
Quoted text here. Click to load it

O właśnie tego szukałem, dziękuję.


Quoted text here. Click to load it
wspólny,  
Quoted text here. Click to load it

Czyli nie da się przeprowadzić bezpiecznej komunikacji TYLKO w jedną  
stronę (polecenie -> wykonanie) bez stosowania wzajemnej  
synchronizacji (nr sekwencyjne/jednorazowe kody/timestampy itp),

--  
Marek

Re: Problem z szyfrowaniem komunikacji między mcu
może coś w tę stronę
http://en.wikipedia.org/wiki/KeeLoq


Re: Problem z szyfrowaniem komunikacji między mcu
On 23.07.2013 00:43, Marek wrote:
Quoted text here. Click to load it

Niestety nie. (Można wprawdzie robić "sec-by-obscurity" np doklejając  
przed szyfrowaniem trochę losowego śmiecia tak aby zaszyfrowany ciąg był  
za każdym razem inny istnieje ryzyko, że atakujący spróbuje wysłać ciąg  
bez odkodowania i ze zdziwieniem stwierdzi, że to działa.)

Zauważ tylko, że numer sekwencyjny jest rozwiązaniem prostym a  
jednocześnie wymaga synchronizacji jedynie na początku(a wtedy  
umieszczasz choćby klucze w obu procesorach). W czasie pracy odbiornik  
musi tylko sprawdzać, czy aktualny serial jest większy od ostatniego i  
jeżeli tak to go sobie zapisywać - komunikacja w jedną stronę wystarcza.  
Musisz oczywiście mieć jakieś sumy kontrolne, żeby odkodowanie śmieci  
(np z powodu zakłóceń) nie spowodowało padu komunikacji.

--  
Pozdrawiam
Michoo

Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it
Moją wiedzę o kryptografii opieram wyłącznie na moim zdaniem genialnej  
książce Ferguson, Schneier "Kryptografia w praktyce".
Treść zgodna z tytułem = "w praktyce".
Według nich złożoność każdego systemu to wróg bezpieczeństwa i nie należy  
tej złożoności podnosić wprowadzając zależność między podpisywaniem  
wiadomości, a jej szyfrowaniem.
Złamanie szyfrowania nie powinno oznaczać jednoczesnego złamania  
podpisywania i odwrotnie.
W tym co proponujesz CRC ma być podpisem (rozumiem, że ciąg  
jest szyfrowany, lub crc po szyfrowaniu). Złamanie  
szyfrowania natychmiast daje dostęp do podpisywania. Jeśli treść rozkazu nie  
musi być ukrywana to można zakładać, że takie działanie to tylko  
podpisywanie. Nie znam się na tyle aby być pewnym, ale coś podejrzewam, że  
kryptolodzy z jakiegoś powodu uzupełnienia wiadomości crc i zaszyfrowania  
tego nie uznają za dobrej jakości podpisywanie bo gdyby tak uznawali to nie  
kombinowali by z jakimiś CMAC czy HMAC.
Też na podstawie tej książki - nie ma jednomyślności wśród kryptologów czy  
wiadomość najpierw podpisywać, czy najpierw kodować.
Numer może być przesyłany jawnie - można zaoszczędzić kodowania.
Na przykład numer 8 bajtów, rozkaz 8 bajtów, podpis 8 bajtów. Podpis  
obejmuje numer i rozkaz = jeden blok 16 bajtowy. Wysyłany jest numer i 16  
bajtowy wynik zakodowania rozkazu i podpisu.
P.G.  


Re: Problem z szyfrowaniem komunikacji między mcu
W dniu 23.07.2013 11:13, Piotr Gałka pisze:

Quoted text here. Click to load it

A nie chodzi w tym przypadku o to, że obecność crc w zaszyfrowanej  
wiadomości ułatwia sprawdzenie czy dobrze odszyfrowaliśmy wiadomość  
podczas ataku?


Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it
Raczej nie.
Algorytmy szyfrujące z definicji mają być odporne również w przypadku ataku  
z tekstem jawnym.
Większość udanych ataków w historii było atakami z tekstem jawnym. Łamanie  
Enigmy w zasadzie odbywało się z tekstem jawnym - zakładali typowy znany  
początek wiadomości, albo znając format komunikatów statków meteo  
przyjmowali znaną skąd inąd pozycję tych statków, a najłatwiej było jak po  
północy ktoś nadał wiadomość z wczorajszymi kluczami, a potem ją powtórzył z  
dzisiejszymi.
Dlatego zawsze się zakłada, że atakujący zna, lub potrafi przewidzieć  
przynajmniej część tekstu jawnego.
Poza tym zawsze trzeba zakładać, że atakującym może być autor danego  
systemu.
P.G.  


Re: Problem z szyfrowaniem komunikacji między mcu
On 23.07.2013 11:13, Piotr Gałka wrote:
Quoted text here. Click to load it

To nie jest wprowadzanie złożoności a jej redukcja.

Quoted text here. Click to load it

Odważne słowa biorąc po uwagę popularność kryptografii asymetrycznej.

Quoted text here. Click to load it

Protokoły szyfrowania zapewniają zazwyczaj też potwierdzenie  
autentyczności - tylko posiadacz klucza może dokonać szyfrowania w  
sposób zapewniający odszyfrowanie.

Quoted text here. Click to load it

Tak i nie - pojawiają się możliwości ataków z tekstem jawnym, więc  
kryptografia musi być silniejsza. 32 bitowy klucz szyfrujący nieznany  
tekst może spokojnie wystarczać do typowych zastosowań, 32 bitowy klucz  
podpisujący jawne polecenie nie nadaje się do niczego o ile nie ma  
naprawdę wielu rund.

Quoted text here. Click to load it

To działa w drugą stronę - jeżeli potrzebujesz tylko uwierzytelnienie  
długiej wiadomości to używasz HMAC, który jest tańszy obliczeniowo od  
dobrego szyfrowania. Jeżeli chcesz mieć dodatkowe zapewnienia (jak np  
niemożliwość podrobienia wiadomości przez obie strony) to uciekasz się  
do kluczy asymetrycznych - i nadal jest to tańsze od szyfrowania całości  
bo podpisujesz tylko skrót wiadomości. Ale gdy wiadomość jest krótka to  
szyfrowanie może być optymalnym rozwiązaniem.

Quoted text here. Click to load it

Dla dobrych algorytmów nie ma to znaczenia. Natomiast odpowiednie  
kombinacje pozwalają na użycie słabszych ale "tańszych" algorytmów.

Quoted text here. Click to load it

Razem 32 bity - jak myślisz ile czasu zajmie kryptoanaliza wspomagana  
metodą brute-force na jakimś i7?

--  
Pozdrawiam
Michoo

Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it

Redukcja złożoności obliczeniowej, ale wprowadzanie zależności pomiędzy  
poszczególnymi funkcjami systemu.

Quoted text here. Click to load it

Mówiłem wyłącznie o kryptografii symetrycznej. O asymetrycznej wiem za mało  
aby się wypowiadać.

Quoted text here. Click to load it

Oczywiste jest, że nie posiadając klucza nie zaszyfruje się tak, aby dało  
się odszyfrować i nie ma to związku z autentycznością (cały czas mówię o  
kryptologii symetrycznej)

Co to znaczy "zazwyczaj" ?
Są takie co zapewniają i są takie co nie zapewniają.
Z tych co zapewniają słyszałem tylko o dwu:
- OCB - ale są osoby i instytucje roszczące sobie prawa patentowe do tego  
trybu.
- CCM - uważam, że przy krótkich ramkach należało by użyć jakiejś prostszej  
funkcji formatującej niż przedstawiona w standardzie, ale nie umiem być na  
100% pewien, czy wymyślona przeze mnie funkcja rzeczywiście spełnia  
określone w standardzie wymagania, a nie spełnienie jest jak rozumiem  
naruszeniem bezpieczeństwa.

Quoted text here. Click to load it

Tu mnie zadziwiasz.
Według mnie 32 bitowy podpis może być wystarczający do typowych zastosowań,  
ale w żadnym przypadku nie oznacza to klucza 32 bitowego.
Natomiast użycie 32 bitowego klucza do szyfrowania tekstu (w ogóle do  
czegokolwiek) wydaje mi się śmieszne.
Na moim (kilkuletnim) PC AES128 (napisany przez mnie tak, aby był czytelny,  
a nie optymalny) wykonuje się poniżej 1us. Zakładam, że jakiś rozsądny  
algorytm z kluczem 32 bity wykona się na przykład w 200ns. Przeszukanie  
całej przestrzeni kluczy zajmie w takiej sytuacji 14 minut. Zawsze trzeba  
zakładać atak z tekstem jawnym.
Poza tym jeśli szyfrowany jest tekst w znanym języku to komputerowa  
weryfikacja, czy uzyskany tekst ma sens w tym języku nie zajmuje dużo czasu.
Zwiększenie liczby rund ma jedynie wpływ na możliwości analitycznego  
poszukiwania klucza. Dla ataku siłowego ma znikome znaczenie bo wydłuża czas  
tego ataku tylko wprost proporcjonalnie do liczby rund.
Poza tym nie znam żadnych algorytmów z kluczem 32 bity, a stosowanie  
wymyślonych przez siebie algorytmów (nie sprawdzonych dogłębnie przez  
znających się na rzeczy) jest proszeniem się o kłopoty.

Quoted text here. Click to load it
Jak Ci wyszły te 32 bity ?
P.G.  


Re: Problem z szyfrowaniem komunikacji między mcu
On 24.07.2013 10:28, Piotr Gałka wrote:
Quoted text here. Click to load it

No właśnie redukujesz złożoność programu (jedna funkcja zamiast dwóch)  
kosztem złożoności obliczeń (szyfrowanie jest zazwyczaj droższe od  
liczenia skrótu).

Quoted text here. Click to load it

To tylko taka uwaga - całe public-key cryptography, które zajmuje się  
zapewnianiem poufności i/lub autentyczności, opiera się o jedną parę kluczy.

Szyfrowanie w tym wypadku sprowadza się prawie zawsze (ze względu na  
wydajność) do zaszyfrowania szyfrem symetrycznym i asymetrycznego  
zaszyfrowania klucza.

Quoted text here. Click to load it

Jak to nie ma? Zazwyczaj protokoły mają różnego rodzaju sumy kontrolne  
aby sprawdzić, czy deszyfrowanie się powiodło - dzięki temu fakt  
zdeszyfrowania wiadomości W kluczem K oznacza, że wiadomość została  
wygenerowana przez posiadacza klucza K.

Oczywiście wymaga to kontroli integralności i kontrola  
integralności+szyfrowanie w efekcie dają kontrolę autentyczności.


Replay attack to atak w którym w ogóle nie musisz znać tekstu jawnego i  
klucza a jedynie szyfrogram - możesz mieć idealnie zaszyfrowaną  
wiadomość z podpisami, sumami kontrolnym, etc a jeżeli jakoś nie  
kontrolujesz sekwencji to nadal jesteś podatny.

Przykład:
obserwujesz, że po wiadomości W1 sterownik wykonuje akcję A1, nie masz  
zielonego pojęcia co zawiera ta wiadomość, nie umiesz w nią ingerować  
(np zmienić kąta ruchu z 10 na 5 stopni) ale wiesz, że zawsze na  
wysłanie tej wiadomości reakcja będzie taka a taka.

Gorzej - masz algorytm działający w trybie ECB - widzisz, że zmieniają  
się tylko dwa pierwsze bajty szyfrogramu(numer seryjny) - bez kontroli
integralności można skopiować numer seryjny z bieżącej wiadomości (np  
"minął termin ważności licencji") i dokleić do starej wiadomości  
("wykonaj działanie"). A cały czas nie wiesz co jest w tych wiadomościach.



Quoted text here. Click to load it

To nadal nie rozwiązuje problemu ataku powtórzeniowego. W tym ataku  
używa się poprawnej, poprawnie podpisanej wiadomości, która została  
przechwycona wcześniej.


Quoted text here. Click to load it

Mamy system komputerowy w którym administrator wysyła polecenia z 32  
bitowym podpisem. Ile czasu potrwa wstrzelenie się sekwencyjnym podpisem  
jeżeli łącze ma 10GB/s?

Quoted text here. Click to load it

Możesz w stosunkowo krótkim czasie wygenerować wszystkie 2^32  
potencjalne teksty jawne. Jeżeli tekst jawny wygląda jak losowe słowo to  
który jest prawidłowy?

Natomiast, oczywiście, security by obscurity nie jest dobrym pomysłem.  
Choćby dlatego, że łatwo je zepsuć - powiedzmy, że zabezpieczamy się  
przed replay attack doklejając do słowa kodowego numer sekwencyjny - nie  
można użyć klasycznej sekwencji bo wyjdzie to w kryptoanalizie, zamiast  
tego musimy zastosować np tajny prng. Itd, etc.


Quoted text here. Click to load it

Zdziwiłbyś się jak często się go w praktyce nie zakłada. Faktem jest, że  
jest to nierozsądne.

Quoted text here. Click to load it

"Atak z tekstem jawnym" nie znaczy tylko że znasz dokładnie wiadomość  
ale, że znasz jej pewne własności. I np "tekst w języku naturalnym" jest  
bardzo istotną własnością.

Quoted text here. Click to load it

Jeżeli oryginalnie było 200ns to 14 minut nie jest problemem. Jeżeli  
zrobisz z tego 500ms to nagle koszt wynajęcia chmury do łamania może być  
niewart zysku z łamania.

Pamiętaj, że zdeterminowany atakujący o odpowiednim zapasie finansowym  
potrafi np zdelaminować czip i po prostu odczytać klucz razem z algorytmem.

Quoted text here. Click to load it

Zgadza się.

Quoted text here. Click to load it

Widzę "bajty" czytam "bity"... :-/

--  
Pozdrawiam
Michoo

Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it

OK.
Poprzednią Twoją wypowiedź interpretowałem trochę w oderwaniu od kontekstu i  
stąd nieporozumienie.

Quoted text here. Click to load it
Spotkałem się raczej z tezą, że złamanie szyfrowania nie powinno dawać od  
razu dostępu do podpisywania.
Dlatego algorytmy, pozwalające podpisywać i szyfrować jednym kluczem są  
bardziej złożone niż CRC (nawet 64b) i szyfrowanie.

Quoted text here. Click to load it
Oczywiste, ale nie wiem po co to piszesz. Na tym etapie byliśmy na samym  
początku wątku.

Quoted text here. Click to load it
Ciężko się z Tobą dyskutuje, bo co rusz wstawisz coś ni z gruszki ni z  
pietruszki. To się chyba nazywa trollowaniem.

Jeśli dalej będziemy dyskutować będę bez komentowania wycinał takie wstawki.
Temat algorytmów zapewniających jednocześnie szyfrowanie i podpisywanie jest  
niezależnym tematem powstałym dlatego, że ktoś (może Ty) zasugerował CRC +  
szyfrowanie.
Przecież konieczność rozróżnienia kolejnych poleceń i nie akceptowania  
powtórzonych poleceń została ustalona już ileś tam wypowiedzi temu wstecz.

Quoted text here. Click to load it
Pisałem o typowym zastosowaniu.
System nie reagujący na błędne podpisy (na przykład obniżeniem pasma) nie  
jest według mnie typowy.
Obniżenie pasma to na przykład przyjęcie kolejnej ramki dopiero po 1ms jeśli  
wystąpiły 3 kolejne błędne podpisy, po 2 ms gdy 4 błędne, po 4ms gdy 5  
błędnych itd.
Nie obniża to pasma w przypadku przypadkowego przekłamania jednej ramki, ale  
uniemożliwia atak siłowy na podpis.
Jak system przyjmuje wszystko jak leci i z pasmem 10GB/s to oczywiście  
podpis powinien być dłuższy. Dla tak głupiego systemu pewnie 128bitów  
minimum.

Quoted text here. Click to load it

Użyłeś słowa tekst, co zrozumiałem jako tekst w jakimś języku, a nie  
wiadomość wyglądającą losowo.

Quoted text here. Click to load it
Być może tak się rozumie atak z tekstem jawnym.
Ja pisząc o ataku z tekstem jawnym rozumiałem, że znam dokładnie kawałek  
tego tekstu bo wyobrażam sobie zawsze te elektroniczno/mechaniczne maszyny  
co amerykanie skonstruowali do łamania Enigmy, które sprawdzając wszystkie  
kolejne możliwości porównywały (chyba) z konkretnym założonym kawałkiem  
tekstu, a nie sprawdzały czy to co wyszło jest tekstem w języku niemieckim  
(ale może się mylę - nie wiem jak dokładnie one działały).

Quoted text here. Click to load it

Wydłużyłeś czas ataku siłowego _zaledwie_ 2 500 000 razy uzyskując przy  
okazji kompletnie nieefektywny algorytm bo _aż_ 2 500 000 razy wolniejszy.
Odpowiada to wydłużeniu klucza o 21 bitów. Czyli jakby klucz zamiast 32  
bitów (o których była mowa) miał 53 bity.
To nie ma sensu, gdy dostępne są algorytmy z kluczem 128 bitów (czy 256  
bitów) działające na tym samym sprzęcie 500 000 razy szybciej od Twojego  
rozwiązania z dodaniem całej masy rund.

Kilka lat temu był jakiś konkurs na łamanie DESa (klucz 56 bitów). Wygrał  
jakiś hacker - już nie pamiętam, ale chyba kilka dni mu wystarczyło.

Quoted text here. Click to load it
Jest to podobno coraz tańsze.
Klucza sesji nie ma w chipie. Oczywiście jeśli jest on wymieniany między  
urządzeniami za pomocą kluczy symetrycznych to podglądając taką wymianę  
atakujący pozna klucz sesji.
Ale jeśli urządzenia mają odpowiednio dobre generatory losowe a do ustalenia  
kluczy stosują na przykład algorytm DH to analiza chipa nic nie da.
P.G.  


Re: Problem z szyfrowaniem komunikacji między mcu
On 25.07.2013 12:37, Piotr Gałka wrote:
Quoted text here. Click to load it

W jakim kontekście to słyszałeś?

Quoted text here. Click to load it

Skoro napisałeś o samym podpisywaniu bez wspominania o sekwencji to  
uznałem że to przeoczyłeś, widzę, że niesłusznie.

Quoted text here. Click to load it

Jest to kolejny element systemu który należy uwzględnić. W analizie  
bezpieczeństwa nie można traktować czegoś jako "oczywiste" bo się można  
przejechać. (Dla mnie oczywiste są numery sekwencyjne i oczywiste są  
odpowiednio długie klucze oraz oczywiste są odpowiednie opóźnienia, ale  
jak się tego nie zawrze w specyfikacji to wykonawca tego prawdopodobnie  
NIE wykona.)


Quoted text here. Click to load it

Tekst jawny/wiadomość jawna - odwrotność szyfrogramu.

Quoted text here. Click to load it

Enigma szyfrowała teksty a nie bajty. Jeżeli masz ponad 50% szans, że  
losowy bajt NIE jest elementem tekstu w języku angielskim to jest to  
bardzo istotna informacja.


Quoted text here. Click to load it

Tak, to nie ma sensu jak i wiele innych rozważań. Myślałem, że  
rozmawiamy o teorii.

Quoted text here. Click to load it

To może trzeba zacząć od pytania co siedzi w urządzeniu i co tak  
właściwie atakujemy.


--  
Pozdrawiam
Michoo

Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it
Było gdzieś w książce Fergusona i Schneiera o której wcześniej pisałem.
Wyraźnie podkreślali, że trzeba rozróżnić podpisywanie od szyfrowania bo  
każde służy innemu celowi (co nie wyklucza algorytmów realizujących obie  
rzeczy na raz - chodzi o zdawanie sobie sprawy co czemu służy).
Dalej, że na przykład w systemach bankowych złamanie podpisywania jest  
groźniejsze niż złamanie szyfrowania. Złamanie szyfrowania pozwala podglądać  
czyjeś operacje, a złamanie podpisywania pozwala je za niego wykonywać.  
Dlatego oni uważają, że wiadomość należy najpierw podpisywać a dopiero potem  
całość szyfrować. Atakujący musi najpierw zaatakować szyfrowanie. Gdyby mu  
się to udało uzyska dostęp do śledzenia komunikacji, ale dopiero teraz może  
zabrać się za drugi etap - łamanie podpisywania, aby mógł nie tylko śledzić,  
ale też ingerować w wiadomości. Oni głównie zawodowo zajmują się analizą  
systemów bankowych, kartowych itp. Twierdzą, że jeszcze nie trafili na  
system bez czasem bardzo poważnych wad.
OIDP (czytałem 8 lat temu) jako przykład błędu podali, ze w jakimś systemie  
hasła przed użyciem dalej były solone i wydłużane zgodnie ze sztuką, ale  
programista wpadł na genialny pomysł przyspieszenia reakcji na błędne hasła  
i zapisywał sobie gdzieś ich CRC.
Wydaje mi się, że jeśli się najpierw szyfruje a potem podpisuje to atakujący  
może równolegle prowadzić atak na szyfrowanie i podpisywanie.

Quoted text here. Click to load it

Zgadzam się z drugim zdaniem, ale użycie w tej samej wypowiedzi też tego  
pierwszego zdania wywołuje moją reakcję.
Enigma zamieniała litery na litery a nie na bajty. Przy łamaniu brute-force  
nie dostawało się bajtów tylko litery więc z klucza było 100% że każdy  
uzyskany znak może być elementem tekstu w języku niemieckim.
Czytałem że jak w dwu kolejnych liniach napiszemy po 100 znaków dwóch  
dowolnych tekstów w języku niemieckim (bez spacji) to spodziewana liczba  
pozycji na których samogłoska będzie nad samogłoską wyniesie ileś tam (nie  
pamiętam - może 12). Jeśli jednym z tych tekstów będzie losowy ciąg to  
samogłoski wystąpią nad sobą znacznie rzadziej (jeśli tam było 12 to tu  
mogło być 6).
Nie wiem, czy maszyny łamiące Enigmę mogły korzystać z tej właściwości czy  
nie - nie wiem, czy to nie było za skomplikowane dla ówczesnego sprzętu. W  
sumie z ciekawości chętnie bym się tego kiedyś dokładnie dowiedział  
(dokładnie to najlepiej schemat takiej maszyny + jego zrozumienie) - tylko  
ten ciągły brak czasu.

Quoted text here. Click to load it

Ale nie rozmawiamy aby sobie pogadać (nie mam czasu) tylko aby rozstrzygnąć  
ewentualne wątpliwości czy różnice zdań.
Jeśli coś w sposób dość oczywisty nie ma sensu to nie powinno w ogóle być  
poruszane. Jeśli ktoś coś porusza to dla mnie oznacza, że uważa, ze to ma  
sens i jeśli mam odmienne zdanie to jesteśmy na etapie różnicy zdań i  
rozstrzygania wątpliwości.
Jeśli teraz (po tym jak się namęczyłem udowadniając, że to nie ma sensu)  
twierdzisz, że to oczywiście nie ma sensu to sugeruje, że już od początku  
wiedziałeś, że nie ma sensu. Sorry, ale jedyny wniosek jaki mi przychodzi do  
głowy - nie szanujesz mojego czasu.

Swoją drogą jestem ciekaw czy jeszcze ktoś śledzi nasze dyskusje, czy już  
sobie wszyscy odpuścili ten wątek.

Quoted text here. Click to load it
Z pierwszej wiadomości w wątku mniej więcej wynika. Urządzenie A wysyła  
jakiś rozkaz do urządzenia B. Ono go wykonuje. Podglądający zna znaczenie  
rozkazu więc nie chodzi o ukrywanie sensu tego rozkazu. Pytającemu chodzi  
jedynie o uniemożliwienie powtórzenia tego rozkazu. Wprowadzenie  
niepowtarzalności rozkazu ale w znany sposób (dodanie numeru kolejnego)  
załatwia jedną sprawę - nie można rozkazu powtórzyć. Pozostaje kwestia aby  
ktoś postronny nie mógł tej jego kolejnej wersji wygenerować. Temu służy  
podpis pozwalający urządzeniu B stwierdzić, ze rozkaz pochodzi od A. Czyli  
dyskutujemy o podpisie.
P.G.  


Re: Problem z szyfrowaniem komunikacji między mcu
W dniu 2013-07-26 12:13, Piotr Gałka pisze:
Quoted text here. Click to load it
e, czy
Śledzi. W miare wolnego czasu uważnie, ale nie komentuje ;)

Ogólnie Panowie, skoro wybiegacie już tak teoretycznie, to warto  
napomknąć jeszcze o czymś takim jak protokół AAA (authorization
,  
authentication, accounting). W prostych słowach określa potrzebne  
mechanizmy aby wszystko było ok.


--  
WS


Re: Problem z szyfrowaniem komunikacji między mcu
Quoted text here. Click to load it
asze dyskusje, czy  
Quoted text here. Click to load it

Śledzi, śledzi, ma nawet ambicje coś na tym skorzystać
 :)

Miłego, "kontyngentujcie" ;)
Irek.N.

Re: Problem z szyfrowaniem komun ikacji między mcu


Quoted text here. Click to load it


Większe audytorium podnosi samozadowolenie wypowiadającego się :)

Quoted text here. Click to load it

Temat wydaje mi się być wyczerpany lub prawie wyczerpany.
P.G.  


Re: Problem z szyfrowaniem komunikacji między mcu
On Mon, 29 Jul 2013 10:33:21 +0200, Piotr  
Quoted text here. Click to load it

Dyskusja z tematu wynikła ciekawa i pouczająca.

--  
Marek

Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it
Dopiero teraz otworzyłem sobie cały wątek (normalnie widzę tylko nowe  
wiadomości) i zauważyłem, że pierwsze pytanie pochodziło do Ciebie.
Jak zacząłeś wykładać swoją teorię Xb -> Y to wyglądało jak wypowiedź kogoś,  
kto ma sprawę dokładnie przemyślaną i chce wyłożyć ją pytającemu no i bez  
sprawdzania założyłem, że jesteś jednym z odpowiadających a nie pytającym.
Gdybym wtedy to sprawdził to pewnie bym trochę inaczej odpowiadał na twoje  
teksty - dyskutowałem jak z kimś kogo tezy trzeba zrozumieć i jak błędne  
obalić, a nie jak z kimś komu raczej trzeba wyjaśniać a nie dyskutować.

Dyskusja na grupie nie jest w stanie przekazać tyle informacji ile można  
znaleźć w książce. Ja polecam tę, co tu wspominałem. Wybrałem ją nie  
przypadkowo, ale to było dawno. Teraz może bym wybrał inną.
P.G.  


Site Timeline