Użytkownik "Marek" <f...@f...com> napisał w wiadomości
news:almarsoft.4145414839725222301@news.neostrada.pl
...
> On Thu, 25 Jul 2013 10:54:14 +0200, Piotr
> Gałka<p...@c...pl> wrote:
>> Nie rozumiem koncepcji "w środku".
>
> Kryptografie analizuje jako strumien bajtów dający reakcje Y, nie wnikam w
> sens strumienia (czy jest to szyfrowany komunikaty, czy komunikaty z
> podpisem itp).
> Wiec jeszcze raz:
> Xb -> Y
> Xb to ciąg bajtów o ograniczonej długości b wysłany z nadajnika, który
> odpowiada za reakcje Y u odbiornika (wykonanie polecenia). Transmisja
> jest zawsze jednokierunkowa i każda jedna transmisja (prawidłowa) daje
> prawidłową reakcje Y.
>
> W Twojej propozycji Xb było komunikatem zawierającym polecenie, nrsekw i
> podpis. Ten nrsekw jest wlaśnie "w środku" strumienia komunikatu i ma
> zapewnić unikalnosc.
> Analizujac strumień Xb jest to nic innego jak jeden wielki nr sekwencyjny,
> ktory może się pojawić tylko raz, ergo liczbę poleceń mamy ograniczona
> liczba kombinacji Xb - liczba prawidłowych Xb.

Tu nie rozumiem.
Jaką liczbę poleceń liczysz, że od wszystkich kombinacji odejmujesz
kombinacje prawidłowe ?
Prawidłowe to są te które można w danym momencie wysłać, aby uzyskać Y, czy
te które do tej pory wysłano ?
Nadal nie rozumiem dlaczego w jakiś specjalny sposób wyróżniasz to, że
nrsekw jest w środku strumienia. Czy to coś zmienia jakby był na początku ?

>
> Pytanie dodatkowe: czy proponowana przez Ciebie metoda podpisu daje ten
> sam podpis dla tego samego komunikatu, czy ten sam komunikat może
> generowac różne (prawidlowe) podpisy (podobnie jak hash ograniczony
> kombinacja możliwych saltow)
>
Proponowana przeze mnie metoda daje dla tej samej podpisywanej treści
(polecenie+nrsekw) ten sam podpis.
Nie widzę najmniejszego sensu w podpisie, który mógłby mieć wiele różnych
wartości dla tej samej treści bo:
- atakujący miałby odpowiednio większą szansę losowego trafienia w
prawidłowy podpis,
- odbiornik miałby znacznie więcej roboty, aby sprawdzić, czy podpis jest
jednym z prawidłowych.
P.G.

do góry

On Thu, 25 Jul 2013 13:05:09 +0200, Piotr
Gałka<p...@c...pl> wrote:
> Tu nie rozumiem.
> Jaką liczbę poleceń liczysz, że od wszystkich kombinacji odejmujesz
> kombinacje prawidłowe ?
> Prawidłowe to są te które można w danym momencie wysłać, aby
uzyskać Y, czy
> te które do tej pory wysłano ?

Te, które dają Y. Nie ma znaczenia czy już wysłane czy jeszcze nie
(zakładamy na razie poczatkowa "przestrzeń zbioru").

> Nadal nie rozumiem dlaczego w jakiś specjalny sposób wyróżniasz to,
że
> nrsekw jest w środku strumienia. Czy to coś zmienia jakby był na
początku ?

W środku, czyli podpis jest częścią strumienia (bez znaczenia w
środku czy na początku).


> Proponowana przeze mnie metoda daje dla tej samej podpisywanej
treści
> (polecenie+nrsekw) ten sam podpis.
> Nie widzę najmniejszego sensu w podpisie, który mógłby mieć wiele
różnych
> wartości dla tej samej treści bo:
> - atakujący miałby odpowiednio większą szansę losowego trafienia w
> prawidłowy podpis,
> - odbiornik miałby znacznie więcej roboty, aby sprawdzić, czy
podpis jest
> jednym z prawidłowych.

Skoro podpis taki sam dla tej samej komendy, to oznacza ze trzeba
wprowadzić jakaś unikalnosc, aby ta sama komenda była prawidłowa dla
różnych Xb, aby nie można było wykorzystać tego samego Xb drugi raz,
ta unikalnosc daje nam nr sekwencyjny, czyli mamy komunikat
Xb=(cmd+nrsek+podpis)

Xb de facto staje się strumieniem bajtów o dkugosci b, który powoduje
wykonanie Y.

Jeśli b będzie małe, można bez trudu wygenerować wszystkie możliwe
kombinacje Xb i trafić na te, które wywołają Y (pisal o tym Michoo),
bez żadnej "analizy kryptograficznej"... Wniosek jest taki, ze
kryptografia daje jedynie algorytm i narzędzie do wygenerowania i
weryfikacji tych unikalnych Xb, to samo mozna by uzyskać bez
kryptografii umieszczając w obu mcu bazę kolejnych Xb autoryzujacych
Y, ważne aby Xb było na tyle długie by zgadywanie kolejnego
prawidlowego było czasowo nieopłacalne.

--
Marek

do góry

Użytkownik "Marek" <f...@f...com> napisał w wiadomości
news:almarsoft.5927629346930432473@news.neostrada.pl
...
>
> Skoro podpis taki sam dla tej samej komendy, to oznacza ze trzeba
> wprowadzić jakaś unikalnosc, aby ta sama komenda była prawidłowa dla
> różnych Xb, aby nie można było wykorzystać tego samego Xb drugi raz, ta
> unikalnosc daje nam nr sekwencyjny, czyli mamy komunikat
> Xb=(cmd+nrsek+podpis)
>
> Xb de facto staje się strumieniem bajtów o dkugosci b, który powoduje
> wykonanie Y.
> Jeśli b będzie małe, można bez trudu wygenerować wszystkie możliwe
> kombinacje Xb i trafić na te, które wywołają Y (pisal o tym Michoo), bez
> żadnej "analizy kryptograficznej"... Wniosek jest taki, ze kryptografia
> daje jedynie algorytm i narzędzie do wygenerowania i weryfikacji tych
> unikalnych Xb, to samo mozna by uzyskać bez kryptografii umieszczając w
> obu mcu bazę kolejnych Xb autoryzujacych Y, ważne aby Xb było na tyle
> długie by zgadywanie kolejnego prawidlowego było czasowo nieopłacalne.
>
Masz rację, przy założeniu, że odbiornik w żaden sposób nie reaguje na
błędne podpisy.
O wymaganej długości podpisu decyduje pasmo kanału pozwalającego atakującemu
weryfikować swoje kolejne próby.
Jak pasmo jest wąskie (RS232 300 Bodów) lub szerokie, ale w przypadku błędów
celowo zawężane, to wystarczy względnie krótki podpis - 32 bity. Dla innych
systemów może być potrzeba 48 bitów lub 64.
Atak na podpis tym się różni od ataku na szyfrowanie, że nie można go
przeprowadzić u siebie na superkomputerze w oderwaniu od atakowanego sprzętu
bo tylko atakowany sprzęt pozwala ustalić, czy podpis jest prawidłowy.
Moim zdaniem podpis nie powinien być dłuższy niż połowa długości klucza
używanego do podpisu. Gdyby podpis był tak długi jak klucz to atakujący może
założyć, że tylko jeden klucz da prawidłowy podpis i przenieść poszukiwanie
klucza podpisu na swój sprzęt i ograniczenia pasma przestają działać.

Nie rozumiem przyjmowanego przez Ciebie podejścia celowo wydłużającego czas
ataku. Przyjmując takie podejście przy ocenie odporności systemu można się
nieźle pośliznąć.
Jednym z założeń kryptografii jest to, że algorytmy, formaty danych są
znane. Czyli przy rozważaniu takiego przypadku wiadomo, gdzie jest rozkaz i
jaki ma być, gdzie jest kolejny numer i jakie może w danym momencie przyjąć
wartości i gdzie jest podpis. Nie ma sensu próbować wszystkich kombinacji
dla całej wiadomości bo jeśli na przykład rozkaz jest tylko 1 bajtowy to z
góry skazujemy 255 z każdych naszych 256 prób na porażkę - wydłużamy
szacowany czas ataku 256 razy (wyjdzie nam, że atak potrwa 256 lat, gdy
faktycznie wystarczy rok - a to jest zasadnicza różnica). A jak zależy nam
na wymuszeniu konkretnego rozkazu, gdy rozkaz jest kodowany na większej
liczbie bajtów - wyjdą nam lata, a faktycznie wystarczą milisekundy.

Takie podejście prowadzi do absurdu bo jeśli rozkaz jest 16 bajtowy i tylko
jeden konkretny kod spowoduje akcję Y to dojdziemy do wniosku, że podpis
jest w ogóle niepotrzebny bo atakujący musi prawdopodobnie sprawdzić 2^127
kombinacji (połowę wszystkich) zanim trafi na właściwą.
P.G.

do góry

On 25.07.2013 19:56, Piotr Gałka wrote:
>>
> Masz rację, przy założeniu, że odbiornik w żaden sposób nie reaguje na
> błędne podpisy.

To jest _kolejna_ rzecz którą trzeba rozpatrzyć przy analizie
bezpieczeństwa _systemu_. Natomiast tak - jest dość prosta i dość
skuteczna - kilkaset ms odstępu praktycznie niweluje możliwość ataku
brute-force (ale czasami generuje możliwość DoS).

> Atak na podpis tym się różni od ataku na szyfrowanie, że nie można go
> przeprowadzić u siebie na superkomputerze w oderwaniu od atakowanego
> sprzętu bo tylko atakowany sprzęt pozwala ustalić, czy podpis jest
> prawidłowy.

Zakładasz security through obscurity? - niejawna funkcja generowania
podpisu. Nie różni się to wtedy od ataku na nieznany algorytm
szyfrujący. Jeśli nie - to masz prawie to samo.


> Moim zdaniem podpis nie powinien być dłuższy niż połowa długości klucza
> używanego do podpisu. Gdyby podpis był tak długi jak klucz to atakujący
> może założyć, że tylko jeden klucz da prawidłowy podpis i przenieść
> poszukiwanie klucza podpisu na swój sprzęt i ograniczenia pasma
> przestają działać.

Atakujący zazwyczaj jeżeli będzie rozważał brute-force to wykona go na
swoim klastrze a "na żywo" będzie testował tylko kolizje tam znalezione.

--
Pozdrawiam
Michoo

do góry

On 25.07.2013 12:37, Piotr Gałka wrote:
>
> Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
> news:ksqqvl$rli$1@mx1.internetia.pl...
>>>>
>>>>> W tym co proponujesz CRC ma być podpisem (rozumiem, że ciąg
>>>>> {numer|rozkaz|crc} jest szyfrowany, lub crc po szyfrowaniu). Złamanie
>>>>> szyfrowania natychmiast daje dostęp do podpisywania.
>>>>
>>>> Protokoły szyfrowania zapewniają zazwyczaj też potwierdzenie
>>>> autentyczności - tylko posiadacz klucza może dokonać szyfrowania w
>>>> sposób zapewniający odszyfrowanie.
>>>
>>> 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)
>>
>> 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.
>
> OK.
> Poprzednią Twoją wypowiedź interpretowałem trochę w oderwaniu od
> kontekstu i stąd nieporozumienie.
>
>>
>> Oczywiście wymaga to kontroli integralności i kontrola
>> integralności+szyfrowanie w efekcie dają kontrolę autentyczności.
>>
> Spotkałem się raczej z tezą, że złamanie szyfrowania nie powinno dawać
> od razu dostępu do podpisywania.

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

>>
> 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.

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

>>> 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.
>>
>> 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?
>>
> 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.

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.)


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

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

>
>>
>>> 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.
>>
>> "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ą.
>>
> 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).

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.


> [...]To nie ma sensu, gdy dostępne są[...]

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

> 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.

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


--
Pozdrawiam
Michoo

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:kssa4v$ish$1@mx1.internetia.pl...

>> Atak na podpis tym się różni od ataku na szyfrowanie, że nie można go
>> przeprowadzić u siebie na superkomputerze w oderwaniu od atakowanego
>> sprzętu bo tylko atakowany sprzęt pozwala ustalić, czy podpis jest
>> prawidłowy.
>
> Zakładasz security through obscurity? - niejawna funkcja generowania
> podpisu. Nie różni się to wtedy od ataku na nieznany algorytm szyfrujący.
> Jeśli nie - to masz prawie to samo.
>
Wydawało mi się, że tu to już nie ma mowy o jakichkolwiek wątpliwościach.
Zawsze zakładam, że niejawne są tylko klucze, a algorytmy jawne = zakładam
jawną funkcję generowania podpisu z niejawnym kluczem.
>
>> Moim zdaniem podpis nie powinien być dłuższy niż połowa długości klucza
>> używanego do podpisu. Gdyby podpis był tak długi jak klucz to atakujący
>> może założyć, że tylko jeden klucz da prawidłowy podpis i przenieść
>> poszukiwanie klucza podpisu na swój sprzęt i ograniczenia pasma
>> przestają działać.
>
> Atakujący zazwyczaj jeżeli będzie rozważał brute-force to wykona go na
> swoim klastrze a "na żywo" będzie testował tylko kolizje tam znalezione.
>
Nie rozumiem o jakich kolizjach piszesz - na co dzień nie mam wiele do
czynienia z kryptologią i pewne pojęcia jedynie obiły mi się o uszy.
To co poniżej piszę opieram na mojej matematycznej intuicji - nie mam
pewności, czy się gdzieś nie mylę.
Według mnie jeśli podpis jest na przykład 48 bitowy, a klucz podpisu 128
bitowy to przy metodzie brute firce po analizie jednej podpisanej transmisji
na swoim klastrze atakujący uzyska 2^80 domniemanych pasujących kluczy
(pracochłonność 2^128 na klastrze). Wśród wygenerowanych następnie dla
podpisania rozkazu, który chce się przesłać do systemu domniemanych 2^80
podpisów prawdopodobnie znajdą się wszystkie możliwe podpisy (jest ich tylko
2^48) więc na razie nie zbliżyliśmy się do celu.
Gdyby nawet przeanalizował podglądnięte 2^48 prawidłowo podpisanych
transmisji (analiza każdej to chyba kolejne 2^128 pracy dla klastra) to
zredukuje mu się liczba możliwych kluczy do 2^32. Teraz może już wygenerować
domniemane 2^32 podpisy. Jest ich mniej. Do ich sprawdzenia potrzebne jest
pasmo 2^32 atakowanego systemu, ale podglądnięcie 2^48 ramek wymagało pasma
2^48 atakowanego systemu - razem potrzebne pasmo atakowanego systemu 2^80
(no i robocizna klastra 2^176).

Bez korzystania ze swojego klastra do ataku brute force wymagane jest pasmo
2^48 atakowanego układu (a najprawdopodobniej 2^47) i ten jeden potrzebny
podpis jest znaleziony (klucza nadal nie mamy).

Wydaje mi się, że to oznacza, że atakowanie podpisu na swoim klastrze mija
się z celem.

Przy podpisie 64 bitowym wyjdzie mi, że można albo:
- generować losowe 2^64 podpisy i prawdopodobnie po 2^63 próbach się trafi,
- podglądać 2^64 transmisje i przy zaangażowaniu 2^192 robocizny klastra
uzyska się klucz.

Przy podpisie 96 bitowym wyjdzie mi (cały czas podkreślam, że to jest tylko
moje domniemanie):
- generowanie losowe 2^96 podpisów lub,
- podglądnięcie 2^32 ramek i 2^160 robocizny klastra i uzyska się klucz.

Widać, że podpis dłuższy od połowy długości klucza redukuje nakład pracy na
jego zaatakowanie brute-force.
Dlatego uważam, że podpis nie powinien być dłuższy od połowy długości klucza
podpisu.

Jak komuś 64 bitowy podpis za krótki to AES256 to tylko ze dwa razy więcej
roboty niż AES128 i można mieć podpis do 128 bitów.
P.G.

do góry

Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:kssb3h$l24$1@mx1.internetia.pl...
>>>
>> Spotkałem się raczej z tezą, że złamanie szyfrowania nie powinno dawać
>> od razu dostępu do podpisywania.
>
> W jakim kontekście to słyszałeś?
>
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.

>
> 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.

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.

>> [...]To nie ma sensu, gdy dostępne są[...]
>
> Tak, to nie ma sensu jak i wiele innych rozważań. Myślałem, że rozmawiamy
> o teorii.

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.

>> 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.
>
> To może trzeba zacząć od pytania co siedzi w urządzeniu i co tak właściwie
> atakujemy.
>
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.

do góry

W dniu 2013-07-26 12:13, Piotr Gałka pisze:
>
> Swoją drogą jestem ciekaw czy jeszcze ktoś śledzi nasze dyskusje, czy
> już sobie wszyscy odpuścili ten wątek.
>
Ś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

do góry

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

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

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

do góry

Użytkownik "Irek N." <j...@t...tajny.jest> napisał w wiadomości
news:kt15ma$hmi$1@news.dialog.net.pl...

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


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

> Miłego, "kontyngentujcie" ;)

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

do góry