-
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
- CGNAT i ewentualne problemy
- wzmacniacz mocy
- Linuks od wer. 6.15 przestanie wspierać procesory 486 i będzie wymagać min. Pentium
- Propagation velocity v/c dla kabli RF
- Jakie natynkowe podwójne gniazdo z bolcem (2P+PE)
- Czujnik nacisku
- Protoków komunikacyjny do urządzenia pomiarowego
- Hiszpania bez pradu
- amperomierz w plusie
- 3G-nadal działa
- Historia pewnego miernika kalibratora
- Ustym 4k Pro i wyświetlacz
- Czemu rozwaliło celę?
- Wojna w portfelu
- Jaki trojfazowy licznik tuya lub podobny?
Najnowsze wątki
- 2025-05-23 Re: Wyzywanie Bodnara od "gangstera i bandyty" wycenione (w pozwie) na 20_000 PLN
- 2025-05-23 Gdańsk => Programista Delphi <=
- 2025-05-23 Warszawa => Senior Key Account Manager IT <=
- 2025-05-23 Zielonka => Key Account Manager IT <=
- 2025-05-23 Poznań => Konsultant wdrożeniowy Comarch XL (Logistyka, WMS, Produkc
- 2025-05-23 Elektrozawór do tlenu
- 2025-05-23 Białystok => NMS System Administrator <=
- 2025-05-23 Warszawa => Cloud Engineer (Azure) <=
- 2025-05-23 Warszawa => Inżynier cloud (Azure) <=
- 2025-05-23 Warszawa => Programista Full Stack .Net <=
- 2025-05-23 Warszawa => Software .Net Developer <=
- 2025-05-23 Łódź => Programista Mainframe (z/OS, Assembler) <=
- 2025-05-23 Warszawa => Starszy Programista C <=
- 2025-05-23 Polskie Obserwatorium Bezpiecze?stwa Ruchu Drogowego (POBR) mapa wypadk??w
- 2025-05-23 Warszawa => Team Lead Data Engineer (obszar Snowflake) <=