-
Data: 2013-07-30 13:18:18
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 "Marek" <f...@f...com> napisał w wiadomości
news:almarsoft.3432653674957594115@news.neostrada.pl
...
>
> Historia była prosta, chciałem użyć XTEA bo jest w sam raz na ograniczone
> zasoby i używałem go wcześniej z bootloaderem. Załozenie było takie, aby
> komunikacja była tylko w jedną stronę (polecenie-> wykonanie) i była jak
> najkrótsza. Ustaliłem sobie klucz, liczbę rund ustaliłem na 64.
> Zaszyfrowalem polecenie "włącz P1" aby przesłać je do drugiego mcu. XTEA
> "zmieniła" polecenie na ciąg bajtów "0x5693290689607436". Mcu2 odebrał ten
> strumień i prawidłowo rozszyfrował na "włącz P1". Tylko, że jak ponownie
> wysłać ten sam "tekst" to xtea wygeneruje ten sam ciąg
> "0x5693290689607436". Taki sposób szyfrowania komunikacji nic nie da bo
> wystarczy powtórzyć sam zaszyfrowany ciąg aby uzyskać ten sam efekt.
> Zdziwiło mnie, że zawsze dostaję ten sam zaszyfrowany ciąg... i tak
> powstał ten wątek.
>
> W gpg przy szyfrowaniu tego samego tekstu tym samym kluczem/hasłem zawsze
> na wyjściu jest inny ciąg bajtów, od czego to zależy?
>
Nie mam zielonego pojęcia o dostępnych gdzieś narzędziach. Nie wiem co to
XTEA, gpg.
Obiło mi się o uszy pgp (może to miałeś na myśli) ale nic poza obiło się o
uszy.
Jak coś wydaje mi się ciekawe (a kryptologia jest ciekawa) to jest to dla
mnie wystarczający powód aby zrozumieć to dokładnie.
Nie znam tych narzędzi, gdyż na swoje potrzeby piszę wszystko od zera (w
oparciu o dokumenty NIST) - w ten sposób uważam, że lepiej można zrozumieć.
Algorytmy to jedno, a ich praktyczne zastosowanie to drugie. W tym drugim
łatwiej popełnić błąd.
Jak rozkaz jest szyfrowany zawsze tak samo to jest właśnie błąd w
praktycznym stosowaniu algorytmu.
Przykład błędu w stosowaniu algorytmu.
Masz super dobry algorytm. Szyfrujesz bitmapę, na której na białym tle jest
parę kresek rysunku (bajt = poziom szarości). Jeśli po prostu każde kolejne
16 bajtów przepuścisz przez ten algorytm to w szyfrogramie w zasadzie będzie
widać ten rysunek.
W większości zastosowań kryptologii atakujący nie powinien móc nic zrobić.
Jeśli szyfrogram jest zawsze taki sam, to atakujący może powtarzać stare
szyfrogramy (nawet ich nie rozumiejąc) a odbiorca przyjmie je jako
prawidłowe pochodzące od nadawcy. A to już jest coś a nie nic więc coś jest
nie tak.
P.G.
Następne wpisy z tego wątku
- 30.07.13 14:08 Marek
- 30.07.13 17:51 Piotr Gałka
Najnowsze wątki z tej grupy
- SFP, 10G, simplex sc/apc
- [słabe wiatry powodują - przyp. JMJ] Energetyczny paraliż w Niemczech
- NxtPaper
- Programiści nie przestają zadziwiać świat
- Długi kabel zasilający a na końcu procek
- Dlaczego nam nie idzie
- Co czujnik to inna temperatura
- Jak naprawić pilota
- Dlaczego TMP wer. 2.0 nie może być sprzedawany jako patyk USB lub karta PCIe 1x?!?
- produkcja w UE
- Pamięć SRAM nie działa z Z80182
- plyta indukcyjna - naprawa
- założyłem kamerę
- syrenki alarmów
- Czym obecnie programuje się EPROM-y?
Najnowsze wątki
- 2025-09-15 Warszawa => Specjalista rekrutacji IT <=
- 2025-09-15 Warszawa => International Freight Forwarder <=
- 2025-09-15 Lublin => ERP Implementation Consultant (AP Module) <=
- 2025-09-15 Warszawa => Engineering Manager (doświadczenie w branży lotniczej lu
- 2025-09-15 "Jestem z ..."
- 2025-09-15 jak sprawdzić czy zerwałem gwint
- 2025-09-14 UWAGA: MAM PODEJRZENIE, ŻE onet.pl DOKONUJE ATAKÓW!!!
- 2025-09-14 zarobki w 1995r
- 2025-09-13 Korea Południowa odpowie za niewolnictwo seksualne armii USA
- 2025-09-13 Zatrzymano zabójcę Charliego Kirka
- 2025-09-13 Wrześniowe promocje na ładowarkach
- 2025-09-13 Warszawa => BI Developer <=
- 2025-09-13 Warszawa => Sales Assistant <=
- 2025-09-13 Warszawa => Lead SAP PP Consultant <=
- 2025-09-13 Jestem pod wrażeniem. Komputery bankowe w łikendy nie odpoczywają ;-)