Titkositas 8 bites MCU-val

Elektronika, Elektromos eszközök

Hi,

Kellene valami algoritmus, ami egy gyenge vason is elmegy, de nyujt valami vedelmet. Keresgeltem, de ha valakinek van konkret tapasztalata, megirhatna.

A cel, hogy egy 8051-es MCU-n ~16-32 byte titkosuljon, mondjuk 16 byte-nyi kulcs altal. Az MCU-ban nincs semmilyen hardware-es algoritmus amit ki lehetne aknazni (pl. AES), tehat teljesen software-bol kellene megoldani. A kulcs nem lenne publikus, valami szimmetrikus kulcsu titkositasra gondolnek. Viszont a forraskod esetleg nyilt lenne, tehat az algoritmus publikussa valna - szoval a cel, hogy az algoritmus ismereteben de a kulcs ismerete nelkul nehez legyen megfejteni az uzeneteket.

Mindezt jo lenne, ha egy 51-esen azert ms-nal (joval) rovidebb ido alatt el lehetne vegezni.

Otlet?

/sza2

  • 2428 megtekintés

( Mcsiv v | 2016. 01. 04., h – 13:39 )

Ha kellően random az adat és valóban csak 16-32 byte-ról van szó, akkor egy egyszerű XOR is megteszi ezen a procin. Én annyit még belevinnék a dologba hogy ugrókódos megoldásban csinálnám mindezt. Kis hardware igény, egészen jó titkosítás, a rövid adat és az ugrókód miatt pedig a mintázat sem adja magát

// Happy debugging, suckers
#define true (rand() > 10)

Az elso gondolatom nekem is a sima XOR-olas volt, csak gondoltam lehet talalni jobbat. Az adatok amik atmennenk, nem igazan veletlenszeruek (homerseklet, paratartalom, tapfesz, azonosito, stb).

Ugrokodosba meg nem astam bele magam. A rendszer egyebkent egy "vevo" tobb "ado" felepitesu (igazabol mindket oldal ad es vesz is, szoval inkabb source / drain) es elvileg barmikor bekapcsolodhat egy ujabb source, emiatt az ugrokodos megoldason lehet, hogy tobbet kellene agyalni.

hint :-)

/sza2

Nyilvan, itt nem lenyeges (bar miert lassa barki a lakas adatait), de kesobb esetleg vezerles is ezen menne es az mar nem tetszene, ha valaki ki / be tudna kapcsolgatni pl. a kazant, allitgatni a termosztatokat. Viszont az is jo lenne, ha ugyanaz a kommunikacio lenne hasznalhato a rendszer tobbi osszetevojevel is.

/sza2

Akkor neked nem titkosítás kell:
https://en.wikipedia.org/wiki/Message_authentication_code
https://en.wikipedia.org/wiki/Hash-based_message_authentication_code

És vigyázz, általában nem az algoritmusokon szokott elbukni a rendszer, hanem a sémán. Például használhatsz te bármilyen hash-t, ha buta sémát használsz, akkor egyszerű üzenet ismétléssel tudják például kapcsolni a kazánt..

Ez sajnos igaz az RC4-re is. Pont az első párszáz byte, ami nagyon könnyen törhető, ezért (ahonnan még nem dobták ki teljesen, de valamit próbáltak javítani rajta), eldobják a keystream elejét és csak utána xor-olnak vele. Ez ide pont nem lesz jó.
---
Régóta vágyok én, az androidok mezonkincsére már!

( STP | 2016. 01. 04., h – 18:19 )

Mennyi memóriád van a titkosító kódra?

( sza2king v | 2016. 01. 05., k – 15:57 )

Koszi mindenkinek az otleteket, linkeket, segitseget.

Ebben a temaban eleg kevesse vagyok jaratos, szoval most az emlitett dolgoknak megprobalok melyebben utanajarni, aztan valamit leszurni es alkotni.

Az eddig osszegyulteket igyekszem megnezni, de ha van barmi tovabbi, szivesen veszem, ha bovul ez a topic :-)

/sza2

( XMI | 2016. 01. 05., k – 17:00 )

Még egy dolog eszembe jutott: amit csinálsz, azt tudja a collectd network plugin protokollja. Kb kőbalta egyszerűségű, annyira hogy egy mérési adatforrást mikrokontrolleren is lehet implementálni. Van hozzá titkosítás és aláírási lehetőség is, valamint egy csomó programnyelven implementáció (mondjuk 8051 assembly-re szerintem nincs). Lehet, hogy érdemes volna ezzel kompatibilis módon megcsinálni.
---
Régóta vágyok én, az androidok mezonkincsére már!

( apal v | 2016. 01. 05., k – 17:26 )

GF(2^32) felett egy egyszeru" a*x+b kiszamolasa. Ha a=1, akkor mindez az XOR-ral egyenerteku, de az a != 1 esetben azert tud trukkos lenni. A "valami vedelemre" vsz eleg. AVR alatt hasznaltam ilyesmit inkabb csak gyakorlaskent, gyorsan fel lehet programozni. Tudok kuldeni es/vagy ide bemasolni kodot, ha erdekel, kb 60 sor.