-
Data: 2013-07-23 11:13:48
Temat: Re: Problem z szyfrowaniem komunikacji między mcu
Od: Piotr Gałka <p...@c...pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]
Użytkownik "Michoo" <m...@v...pl> napisał w wiadomości
news:ksleqr$lsb$1@mx1.internetia.pl...
>>
>> Czyli nie da się przeprowadzić bezpiecznej komunikacji TYLKO w jedną
>> stronę (polecenie -> wykonanie) bez stosowania wzajemnej synchronizacji
>> (nr sekwencyjne/jednorazowe kody/timestampy itp),
>>
>
> Niestety nie. (Można wprawdzie robić "sec-by-obscurity" np doklejając
> przed szyfrowaniem trochę losowego śmiecia tak aby zaszyfrowany ciąg był
> za każdym razem inny istnieje ryzyko, że atakujący spróbuje wysłać ciąg
> bez odkodowania i ze zdziwieniem stwierdzi, że to działa.)
>
> Zauważ tylko, że numer sekwencyjny jest rozwiązaniem prostym a
> jednocześnie wymaga synchronizacji jedynie na początku(a wtedy umieszczasz
> choćby klucze w obu procesorach). W czasie pracy odbiornik musi tylko
> sprawdzać, czy aktualny serial jest większy od ostatniego i jeżeli tak to
> go sobie zapisywać - komunikacja w jedną stronę wystarcza. Musisz
> oczywiście mieć jakieś sumy kontrolne, żeby odkodowanie śmieci (np z
> powodu zakłóceń) nie spowodowało padu komunikacji.
>
Moją wiedzę o kryptografii opieram wyłącznie na moim zdaniem genialnej
książce Ferguson, Schneier "Kryptografia w praktyce".
Treść zgodna z tytułem = "w praktyce".
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.
Złamanie szyfrowania nie powinno oznaczać jednoczesnego złamania
podpisywania i odwrotnie.
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. Jeśli treść rozkazu nie
musi być ukrywana to można zakładać, że takie działanie to tylko
podpisywanie. 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.
Też na podstawie tej książki - nie ma jednomyślności wśród kryptologów czy
wiadomość najpierw podpisywać, czy najpierw kodować.
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.
P.G.
Następne wpisy z tego wątku
- 23.07.13 11:46 Zbych
- 23.07.13 12:54 Piotr Gałka
- 23.07.13 15:29 Adam Wysocki
- 23.07.13 22:57 Michoo
- 23.07.13 22:59 Michoo
- 24.07.13 08:50 Piotr Gałka
- 24.07.13 10:28 Piotr Gałka
- 25.07.13 09:57 Marek
- 25.07.13 10:10 Zbych
- 25.07.13 10:15 Marek
- 25.07.13 10:26 Piotr Gałka
- 25.07.13 10:39 Piotr Gałka
- 25.07.13 10:54 Piotr Gałka
- 25.07.13 11:12 Michoo
- 25.07.13 11:15 Michoo
Najnowsze wątki z tej grupy
- Dławik CM
- JDG i utylizacja sprzetu
- Identyfikacja układ SO8 w sterowniku migających światełek choinkowych
- DS1813-10 się psuje
- Taki tam szkolny problem...
- LIR2032 a ML2032
- SmartWatch Multimetr bezprzewodowy
- olej psuje?
- Internet w lesie - Starlink
- Opis produktu z Aliexpress
- No proszę, a śmialiście się z hindusów.
- Zewnętrzne napięcie referencyjne LM385 1,2V -> 100mV dla ICL7106, Metex M-3800
- karta parkingowa
- Wl/Wyl (On/Off) bialy/niebieski
- I3C
Najnowsze wątki
- 2024-11-29 Dławik CM
- 2024-11-29 [OT] Lewe oprogramowanie
- 2024-11-29 Błonie => Sales Specialist <=
- 2024-11-29 Warszawa => IT Expert (Network Systems area) <=
- 2024-11-29 Warszawa => Ekspert IT (obszar systemów sieciowych) <=
- 2024-11-29 Warszawa => Head of International Freight Forwarding Department <=
- 2024-11-29 Białystok => Inżynier Serwisu Sprzętu Medycznego <=
- 2024-11-29 Pómpy ciepła darmo rozdajoo
- 2024-11-29 Białystok => Application Security Engineer <=
- 2024-11-29 Białystok => Programista Full Stack (.Net Core) <=
- 2024-11-29 Gdańsk => Software .Net Developer <=
- 2024-11-29 Wrocław => Key Account Manager <=
- 2024-11-29 Gdańsk => Specjalista ds. Sprzedaży <=
- 2024-11-29 Chrzanów => Specjalista ds. public relations <=
- 2024-11-27 Re: UseGalileo -- PRODUKTY I APLIKACJE UŻYWAJĄ JUŻ DZIŚ SYSTEMU GALILEO