W dniu 25.07.2013 09:57, Marek pisze:
> On Tue, 23 Jul 2013 10:25:36 +0200, Piotr
> Gałka<p...@c...pl> wrote:
>> Potrzebujesz podpisywania, a nie szyfrowania.
>> Przed poleceniem (nawet jawnym) umieść kolejny numer i całość
> podpisz (CMAC,
>> HMAC).
>> Odbiornik akceptuje tylko polecenia z dowolnym wyższym numerem od
> aby
>> poprzedniego, ale prawidłowo podpisane.
>
>
>
> Ale to jest sposób komunikacji, w którym:
>
> Xb -> Y
>
> gdzie Xb polecenie o ilosci bajtow b wysłane z nadajnika
> Y akcja odbiornika (wykonanie polecania Xb)
>
>
> nie analizujac zupełnie zawartości Xb daje nam
> ograniczona liczbę możliwych Xb tj. ograniczoną wielkością możliwych
> kombinacji zbioru b. Jeśli b będzie małe, a założenie jest takie aby
> komunikacja była jak najkrótsza, to wystarczy wypróbować wszystkie
> możliwe kombinacje. Model wręcz stworzony do replay attack.
> Odbiornik musiałby pamiętać ostatni nr sekwencyjny aby nie przyjąć już
> użytego. Takie rozwiązanie ma kolejne dwa zastrzeżenia:
> 1. jawna komunikacja, skrót dostępny jak na dłoni, można go użyć jako
> wsad do analizy krypto w celu wykrycia jego słabości.
> 2. nr sekwencyjny musiałby być zapisywany w jakieś pamieci nieulotnej,
> przy kilku tysiącu poleceń na godzinę flash mcu może szybko przekroczyć
> gwarantowana liczbe zapisów. Trzeba by mieć jakiś zewnętrzny,
> odpowiednio duży flash. A mając zewnętrzna pamięć ja trzeba by też
> chronić, by nie można było zewnętrznie zmodyfikować jej zawartość
> (zmniejszyć numer sekwencyjny).
> PozostajeStosowanie nr sekwencyjnego "w środku" działa dodatkowo na
> niekorzyść, bo powoduje, ze dla różnych b istnieje takie samo Y
> (dokładnie tyle ile jest możliwych nr sekwencyjnych).

A na końcu okaże się, że taniej jest zlecić chińczykowi wydłubanie
programu z uC i nie trzeba się bawić w żadne łamanie podpisów/szyfrów.
(no chyba, że klucze trzymamy w RAMie podtrzymywanym bateryjnie i przy
próbie otwarcia urządzenia jest on czyszczony)

Ostatnio taki fajny spam dostałem: http://hack-mcu.com/

do góry

On Thu, 25 Jul 2013 09:57:33 +0200, Marek <f...@f...com> wrote:
> Stosowanie nr sekwencyjnego "w środku" działa dodatkowo na
> niekorzyść, bo powoduje, ze dla różnych b istnieje takie samo Y
> (dokładnie tyle ile jest możliwych nr sekwencyjnych).

Tak naprawdę nie widzę różnicy między podpisywaniem a zwykłym
cmd+nrsek, gdzie nrsek jest jednorazowy. Bo w przypadku podpisywania
i bez niego mamy taka sama liczbę możliwych komunikatów
autoryzujacych dane polecenie. A jeśli polecenie miałoby być jedno to
w ogóle szał, bo wystarczyłby sam nrsek :-)

--
Marek

do góry

Użytkownik "Zbych" <a...@o...pl> napisał w wiadomości
news:51f0dd5d$0$1228$65785112@news.neostrada.pl...
>
> A na końcu okaże się, że taniej jest zlecić chińczykowi wydłubanie
> programu z uC i nie trzeba się bawić w żadne łamanie podpisów/szyfrów.
> (no chyba, że klucze trzymamy w RAMie podtrzymywanym bateryjnie i przy
> próbie otwarcia urządzenia jest on czyszczony)
>
Jakie oprogramowanie miałby wydłubać chińczyk aby bez łamania podpisów
zainstalowany na przykład wewnątrz sejfu odbiornik wykonał polecenie
"otwórz" ?
P.G.

do góry

Użytkownik "Marek" <f...@f...com> napisał w wiadomości
news:almarsoft.333176445241953322@news.neostrada.pl.
..
> On Thu, 25 Jul 2013 09:57:33 +0200, Marek <f...@f...com> wrote:
>> Stosowanie nr sekwencyjnego "w środku" działa dodatkowo na niekorzyść,
>> bo powoduje, ze dla różnych b istnieje takie samo Y (dokładnie tyle ile
>> jest możliwych nr sekwencyjnych).
>
> Tak naprawdę nie widzę różnicy między podpisywaniem a zwykłym cmd+nrsek,
> gdzie nrsek jest jednorazowy. Bo w przypadku podpisywania i bez niego mamy
> taka sama liczbę możliwych komunikatów autoryzujacych dane polecenie. A
> jeśli polecenie miałoby być jedno to w ogóle szał, bo wystarczyłby sam
> nrsek :-)
>
A widzisz różnicę między złożonym w US PITem (nrsek to rok) z podpisem i bez
podpisu?
P.G.

do góry

Użytkownik "Marek" <f...@f...com> napisał w wiadomości
news:almarsoft.1189924782676989363@news.neostrada.pl
...
> Ale to jest sposób komunikacji, w którym:
>
> Xb -> Y
>
> gdzie Xb polecenie o ilosci bajtow b wysłane z nadajnika
> Y akcja odbiornika (wykonanie polecania Xb)
>
>
> nie analizujac zupełnie zawartości Xb daje nam
> ograniczona liczbę możliwych Xb tj. ograniczoną wielkością możliwych
> kombinacji zbioru b. Jeśli b będzie małe, a założenie jest takie aby
> komunikacja była jak najkrótsza, to wystarczy wypróbować wszystkie możliwe
> kombinacje. Model wręcz stworzony do replay attack.

Jeśli znasz chociaż trochę angielski to powinieneś wiedzieć, że replay
oznacza "ponowne odtworzenie".
Rozmiar b nie ma nic wspólnego z możliwością lub niemożliwością ponownego
odtworzenia podsłuchanej komunikacji.

Natomiast możliwość łatwego wypróbowania wszystkich kombinacji jest
czynnikiem sprzyjającym atakowi siłowemu właśnie na tym polegającemu.

> Odbiornik musiałby pamiętać ostatni nr sekwencyjny aby nie przyjąć już
> użytego. Takie rozwiązanie ma kolejne dwa zastrzeżenia:
> 1. jawna komunikacja, skrót dostępny jak na dłoni, można go użyć jako wsad
> do analizy krypto w celu wykrycia jego słabości.

Podpisy CMAC HMAC nie muszą być ukrywane aby były bezpieczne.

> 2. nr sekwencyjny musiałby być zapisywany w jakieś pamieci nieulotnej,
> przy kilku tysiącu poleceń na godzinę flash mcu może szybko przekroczyć
> gwarantowana liczbe zapisów. Trzeba by mieć jakiś zewnętrzny, odpowiednio
> duży flash. A mając zewnętrzna pamięć ja trzeba by też chronić, by nie
> można było zewnętrznie zmodyfikować jej zawartość (zmniejszyć numer
> sekwencyjny).

Ten nierozwiązywalny według Ciebie problem da się rozwiązać na co najmniej
kilka sposobów.

> PozostajeStosowanie nr sekwencyjnego "w środku" działa dodatkowo na
> niekorzyść, bo powoduje, ze dla różnych b istnieje takie samo Y (dokładnie
> tyle ile jest możliwych nr sekwencyjnych).

Nie rozumiem koncepcji "w środku".
P.G.

do góry

On 25.07.2013 10:26, Piotr Gałka wrote:
>
> Użytkownik "Zbych" <a...@o...pl> napisał w wiadomości
> news:51f0dd5d$0$1228$65785112@news.neostrada.pl...
>>
>> A na końcu okaże się, że taniej jest zlecić chińczykowi wydłubanie
>> programu z uC i nie trzeba się bawić w żadne łamanie podpisów/szyfrów.
>> (no chyba, że klucze trzymamy w RAMie podtrzymywanym bateryjnie i przy
>> próbie otwarcia urządzenia jest on czyszczony)
>>
> Jakie oprogramowanie miałby wydłubać chińczyk aby bez łamania podpisów
> zainstalowany na przykład wewnątrz sejfu odbiornik wykonał polecenie
> "otwórz" ?

Skoro rozpatrujemy atak powtórzeniowy to zakładamy dostęp do urządzenia
"zewnętrznego".

Więc po co oprogramowanie? Chińczyk bierze układ i rozpuszcza mu górę
opakowania, wkłada w mikroskop i robi zdjęcie. Pobiera z bazy informację
gdzie leżą lockbity i strzela np 3 razy laserem. Podpina układ do
programatora i odczytuje cały kod i eeprom.

Teraz można zrobić dokładną kopię układu.


--
Pozdrawiam
Michoo

do góry

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

do góry

Użytkownik "Piotr Gałka" <p...@c...pl> napisał w
wiadomości news:ksqnfo$nmp$1@somewhere.invalid...
>
> Użytkownik "Zbych" <a...@o...pl> napisał w wiadomości
> news:51f0dd5d$0$1228$65785112@news.neostrada.pl...
>>
>> A na końcu okaże się, że taniej jest zlecić chińczykowi wydłubanie
>> programu z uC i nie trzeba się bawić w żadne łamanie podpisów/szyfrów.
>> (no chyba, że klucze trzymamy w RAMie podtrzymywanym bateryjnie i przy
>> próbie otwarcia urządzenia jest on czyszczony)
>>
> Jakie oprogramowanie miałby wydłubać chińczyk aby bez łamania podpisów
> zainstalowany na przykład wewnątrz sejfu odbiornik wykonał polecenie
> "otwórz" ?

Przy pierwszym czytaniu "wydłubanie" mylnie zrozumiałem jako napisanie od
nowa, a nie reverse engineering.
Kwestia zarządzania kluczami to oddzielne, bardzo złożone zagadnienie, o
którym mam zaledwie blade pojęcie.
Przede wszystkim w każdej instalacji klucze powinny być inne, ustalone
(wylosowane) przez użytkownika i nie znane producentowi urządzenia.
Zatem nie da się ich wydłubać z pierwszego lepszego urządzenia tego typu -
musi to być urządzenie z tego systemu.
Kradzież urządzenia z tego systemu powinna być zauważona i klucze zmienione
zanim chińczyk zdąży wydłubać te klucze i je dostarczyć.
Poza tym stosowane do podpisywania klucze są zazwyczaj wylosowanymi kluczami
sesji. Istnieją algorytmy (np. DH) pozwalające ustalić wspólny klucz sesji
tak, że ktoś podglądający całą transmisję i nawet znający całe zawartości
pamięci flash obu uzgadniających ze sobą klucz urządzeń nie jest w stanie
ustalić jaki klucz uzgodniono.
P.G.

do góry

On Thu, 25 Jul 2013 10:54:14 +0200, Piotr
Gałka<p...@c...pl> wrote:
> Nie rozumiem koncepcji "w środku".

Kryptografie analizuje jako strumien bajtów dający reakcje Y, nie
wnikam w sens strumienia (czy jest to szyfrowany komunikaty, czy
komunikaty z podpisem itp).
Wiec jeszcze raz:
Xb -> Y
Xb to ciąg bajtów o ograniczonej długości b wysłany z nadajnika,
który odpowiada za reakcje Y u odbiornika (wykonanie polecenia).
Transmisja jest zawsze jednokierunkowa i każda jedna transmisja
(prawidłowa) daje prawidłową reakcje Y.

W Twojej propozycji Xb było komunikatem zawierającym polecenie,
nrsekw i podpis. Ten nrsekw jest wlaśnie "w środku" strumienia
komunikatu i ma zapewnić unikalnosc.
Analizujac strumień Xb jest to nic innego jak jeden wielki nr
sekwencyjny, ktory może się pojawić tylko raz, ergo liczbę poleceń
mamy ograniczona liczba kombinacji Xb - liczba prawidłowych Xb.

Pytanie dodatkowe: czy proponowana przez Ciebie metoda podpisu daje
ten sam podpis dla tego samego komunikatu, czy ten sam komunikat
może generowac różne (prawidlowe) podpisy (podobnie jak hash
ograniczony kombinacja możliwych saltow)

--
Marek

do góry

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.

do góry