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.