On 24.07.2013 10:28, Piotr Gałka wrote:
>
> Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
> news:ksmrgi$5rd$1@mx1.internetia.pl...
>>> Według nich złożoność każdego systemu to wróg bezpieczeństwa i nie
>>> należy tej złożoności podnosić wprowadzając zależność między
>>> podpisywaniem wiadomości, a jej szyfrowaniem.
>>
>> To nie jest wprowadzanie złożoności a jej redukcja.
>
> Redukcja złożoności obliczeniowej, ale wprowadzanie zależności pomiędzy
> poszczególnymi funkcjami systemu.

No właśnie redukujesz złożoność programu (jedna funkcja zamiast dwóch)
kosztem złożoności obliczeń (szyfrowanie jest zazwyczaj droższe od
liczenia skrótu).

>
>>> Złamanie szyfrowania nie powinno oznaczać jednoczesnego złamania
>>> podpisywania i odwrotnie.
>>
>> Odważne słowa biorąc po uwagę popularność kryptografii asymetrycznej.
>
> Mówiłem wyłącznie o kryptografii symetrycznej. O asymetrycznej wiem za
> mało aby się wypowiadać.

To tylko taka uwaga - całe public-key cryptography, które zajmuje się
zapewnianiem poufności i/lub autentyczności, opiera się o jedną parę kluczy.

Szyfrowanie w tym wypadku sprowadza się prawie zawsze (ze względu na
wydajność) do zaszyfrowania szyfrem symetrycznym i asymetrycznego
zaszyfrowania klucza.

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

Oczywiście wymaga to kontroli integralności i kontrola
integralności+szyfrowanie w efekcie dają kontrolę autentyczności.


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.

Gorzej - masz algorytm działający w trybie ECB - widzisz, że zmieniają
się tylko dwa pierwsze bajty szyfrogramu(numer seryjny) - bez kontroli
integralności można skopiować numer seryjny z bieżącej wiadomości (np
"minął termin ważności licencji") i dokleić do starej wiadomości
("wykonaj działanie"). A cały czas nie wiesz co jest w tych wiadomościach.



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


>
>>
>>> Jeśli treść rozkazu
>>> nie musi być ukrywana to można zakładać, że takie działanie to tylko
>>> podpisywanie.
>>
>> Tak i nie - pojawiają się możliwości ataków z tekstem jawnym, więc
>> kryptografia musi być silniejsza. 32 bitowy klucz szyfrujący nieznany
>> tekst może spokojnie wystarczać do typowych zastosowań, 32 bitowy
>> klucz podpisujący jawne polecenie nie nadaje się do niczego o ile nie
>> ma naprawdę wielu rund.
>
> 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?

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

Natomiast, oczywiście, security by obscurity nie jest dobrym pomysłem.
Choćby dlatego, że łatwo je zepsuć - powiedzmy, że zabezpieczamy się
przed replay attack doklejając do słowa kodowego numer sekwencyjny - nie
można użyć klasycznej sekwencji bo wyjdzie to w kryptoanalizie, zamiast
tego musimy zastosować np tajny prng. Itd, etc.


> Zawsze trzeba zakładać atak z tekstem jawnym.

Zdziwiłbyś się jak często się go w praktyce nie zakłada. Faktem jest, że
jest to nierozsądne.

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

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

Pamiętaj, że zdeterminowany atakujący o odpowiednim zapasie finansowym
potrafi np zdelaminować czip i po prostu odczytać klucz razem z algorytmem.

> Poza tym nie znam żadnych algorytmów z kluczem 32 bity, a stosowanie
> wymyślonych przez siebie algorytmów (nie sprawdzonych dogłębnie przez
> znających się na rzeczy) jest proszeniem się o kłopoty.

Zgadza się.

>
>>> Numer może być przesyłany jawnie - można zaoszczędzić kodowania.
>>> Na przykład numer 8 bajtów, rozkaz 8 bajtów, podpis 8 bajtów. Podpis
>>> obejmuje numer i rozkaz = jeden blok 16 bajtowy. Wysyłany jest numer i
>>> 16 bajtowy wynik zakodowania rozkazu i podpisu.
>>
>> Razem 32 bity - jak myślisz ile czasu zajmie kryptoanaliza wspomagana
>> metodą brute-force na jakimś i7?
>>
> Jak Ci wyszły te 32 bity ?

Widzę "bajty" czytam "bity"... :-/

--
Pozdrawiam
Michoo