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.
Dlatego algorytmy, pozwalające podpisywać i szyfrować jednym kluczem są
bardziej złożone niż CRC (nawet 64b) i szyfrowanie.

>
> 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.
>
Oczywiste, ale nie wiem po co to piszesz. Na tym etapie byliśmy na samym
początku wątku.

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

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

>> Natomiast użycie 32 bitowego klucza do szyfrowania tekstu (w ogóle do
>> czegokolwiek) wydaje mi się śmieszne.
>
> 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?

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

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

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

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.

>
> Pamiętaj, że zdeterminowany atakujący o odpowiednim zapasie finansowym
> potrafi np zdelaminować czip i po prostu odczytać klucz razem z
> algorytmem.
>
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.