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