On 23.07.2013 11:13, Piotr Gałka wrote:
> 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.

> Złamanie szyfrowania nie powinno oznaczać jednoczesnego złamania
> podpisywania i odwrotnie.

Odważne słowa biorąc po uwagę popularność kryptografii asymetrycznej.

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

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

> Nie znam się na tyle aby być pewnym, ale coś podejrzewam,
> że kryptolodzy z jakiegoś powodu uzupełnienia wiadomości crc i
> zaszyfrowania tego nie uznają za dobrej jakości podpisywanie bo gdyby
> tak uznawali to nie kombinowali by z jakimiś CMAC czy HMAC.

To działa w drugą stronę - jeżeli potrzebujesz tylko uwierzytelnienie
długiej wiadomości to używasz HMAC, który jest tańszy obliczeniowo od
dobrego szyfrowania. Jeżeli chcesz mieć dodatkowe zapewnienia (jak np
niemożliwość podrobienia wiadomości przez obie strony) to uciekasz się
do kluczy asymetrycznych - i nadal jest to tańsze od szyfrowania całości
bo podpisujesz tylko skrót wiadomości. Ale gdy wiadomość jest krótka to
szyfrowanie może być optymalnym rozwiązaniem.

> Też na podstawie tej książki - nie ma jednomyślności wśród kryptologów
> czy wiadomość najpierw podpisywać, czy najpierw kodować.

Dla dobrych algorytmów nie ma to znaczenia. Natomiast odpowiednie
kombinacje pozwalają na użycie słabszych ale "tańszych" algorytmów.

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

--
Pozdrawiam
Michoo