Problem z szyfrowaniem komunikacji między mcu - Page 3

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

Translate This Thread From Polish to

Threaded View
Re: Problem z szyfrowaniem komunikacji między mcu
On Thu, 25 Jul 2013 10:54:14 +0200, Piotr  
Quoted text here. Click to load it

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.  

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)

--  
Marek

Re: Problem z szyfrowaniem komun ikacji między mcu

Quoted text here. Click to load it

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 ?

Quoted text here. Click to load it
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.  


Re: Problem z szyfrowaniem komunikacji między mcu
On Thu, 25 Jul 2013 13:05:09 +0200, Piotr  
Quoted text here. Click to load it
uzyskać Y, czy  
Quoted text here. Click to load it

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

Quoted text here. Click to load it
że  
Quoted text here. Click to load it
początku ?

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

Quoted text here. Click to load it
treści  
Quoted text here. Click to load it
różnych  
Quoted text here. Click to load it
podpis jest  
Quoted text here. Click to load it

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

Site Timeline