Autor Wątek: Proste, szybkie i bezpieczne szyfrowanie pakietów.  (Przeczytany 1864 razy)

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Listopad 07, 2015, 12:39:17
Hej!

Poszukuję algorytmu, który byłby w stanie zaszyfrować strumień danych na dość ograniczonym CPU - 8-bit AVR (coś typu Arduino). Planowana prędkość transmisji to 115200 kbps, czyli jakieś 11 kB/s. CPU pracuje z taktowaniem 8-16 MHz, ale musi robić jeszcze parę innych rzeczy. Dodatkowe ograniczenie: jest tylko 1 kB RAM. Pasowało by więc coś pokroju RC4, ale jak na RC4 wyszedł WEP, to chyba wszyscy wiedzą. :)

Wszelkie propozycje/pytania/sugestie mile widziane. :)

Pozdrawiam,
KK

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline magik6000

  • Użytkownik

# Listopad 07, 2015, 13:53:32

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Listopad 07, 2015, 22:51:20
http://point-at-infinity.org/avraes/
Całkiem fajne, acz cóż z tego, skoro to GPL.

Czekam na jakieś inne propozycje.

Offline 10log

  • Użytkownik

# Listopad 07, 2015, 22:56:01
Zawsze możesz poprosić o komercyjną licencję.

Cytuj
If you are interested in embedding the code in your application but need a different license than GPL, feel free to contact me (avraes AT point-at-infinity.org).

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Listopad 07, 2015, 23:08:52
Zawsze możesz poprosić o komercyjną licencję.
Nie wiem jak tutaj to wygląda, ale widziałem cenniki podobnych bibliotek. Raczej nie przejdzie w tym przypadku. :)

Offline wonderboy

  • Użytkownik

# Listopad 08, 2015, 00:34:39
Jeśli to projekt tylko dla ciebie, to GPL nie przeszkadza. A w ogóle to na takim procku za wiele chyba nie można oczekiwać.

Może TEA - Tiny Encryption Algorithm (albo upgrade typu XXTEA):
https://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm

EDIT:
Jest jeszcze np. libcrypto++. Nie wiem czy działa na avr, ale kod jest chyba w public domain:
https://en.wikipedia.org/wiki/Crypto%2B%2B

Pytanie czy chcesz sam implementować, czy wolisz mieć podane;)

EDIT2:
Na początek może się przydać lista algorytmów:
https://en.wikipedia.org/wiki/Stream_cipher
https://en.wikipedia.org/wiki/Block_cipher
« Ostatnia zmiana: Listopad 08, 2015, 01:19:18 wysłana przez wonderboy »

Offline Xender

  • Użytkownik

# Listopad 08, 2015, 12:43:59
Pytanie czy chcesz sam implementować, czy wolisz mieć podane;)

EDIT2:
Na początek może się przydać lista algorytmów:
https://en.wikipedia.org/wiki/Stream_cipher
https://en.wikipedia.org/wiki/Block_cipher

No bez jaj.

"One does not simply implement their own crypto".

Serio, "nie implementuj własnego crypto" to wskazówka, którą można znaleźć wszędzie.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Listopad 08, 2015, 14:18:29
Cytuj
Jeśli to projekt tylko dla ciebie, to GPL nie przeszkadza. A w ogóle to na takim procku za wiele chyba nie można oczekiwać.
Projekt własny, ale mam nadzieję że komercyjny.

Cytuj
Może TEA - Tiny Encryption Algorithm (albo upgrade typu XXTEA):
https://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm
W XXTEA trochę dużo rund się robi, więc AES-128 może być już szybszy. Poza tym *TEA są przygotowane pod 32-bitowce.

Cytuj
Jest jeszcze np. libcrypto++. Nie wiem czy działa na avr, ale kod jest chyba w public domain:
https://en.wikipedia.org/wiki/Crypto%2B%2B
Nie mam problemu "skąd" wziąć algorytm (większość ma referencyjne implementacje public domain, które łatwo na AVR przenieść). Mam problem "który" oraz czy będzie wystarczająco szybki by na AVR 8..16 MHz zaszyfrować lub odszyfrować strumień 115200 kbps i jeszcze coś na boku robić (w szczególności obsługiwać peryferia przez które ten strumień przepływa - nie ma DMA, są tylko przerwania).

Cytuj
Pytanie czy chcesz sam implementować, czy wolisz mieć podane;)
Zależy co przez to rozumiesz. Nie mam problemu z przeportowaniem kawałka kodu na AVR.

Cytuj
"One does not simply implement their own crypto".

Serio, "nie implementuj własnego crypto" to wskazówka, którą można znaleźć wszędzie.
I stąd ten wątek powstał. I dlatego też jeśli wszystko inne zawiedzie to wolał bym od wymyślania użyć RC4, który był łamany tyle razy, że wiadomo że jest niebezpieczny, ale też wiadomo jakich błędów z nim nie robić.

Inna kwestia że RC4 nie rozwiązuje kompletnie kwestii zapewnienia autentyczności pakietów (bit flipping attack).

Offline sebas86

  • Użytkownik

# Listopad 08, 2015, 16:04:29
Zmień mikrokontroler na coś co posiada sprzętowe wsparcie dla szyfrowania, jeśli lubisz AVR może polubisz XMegi (http://www.atmel.com/products/microcontrollers/avr/AVR_XMEGA.aspx), przy okazji będzie trochę więcej mocy obliczeniowej do wykorzystania.