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.

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

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

Co to znaczy "zazwyczaj" ?
Są takie co zapewniają i są takie co nie zapewniają.
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.

>
>> 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.
Natomiast użycie 32 bitowego klucza do szyfrowania tekstu (w ogóle do
czegokolwiek) wydaje mi się śmieszne.
Na moim (kilkuletnim) PC AES128 (napisany przez mnie tak, aby był czytelny,
a nie optymalny) wykonuje się poniżej 1us. Zakładam, że jakiś rozsądny
algorytm z kluczem 32 bity wykona się na przykład w 200ns. Przeszukanie
całej przestrzeni kluczy zajmie w takiej sytuacji 14 minut. Zawsze trzeba
zakładać atak z tekstem jawnym.
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.
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.
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.

>> 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 ?
P.G.