www.mikrocontroller.net

Forum: Projekte & Code Crypto avr lib (diverse Kryptographie Algorithmen)


Autor: Peter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

das Projekt ist nicht von mir selber, aber es sollte hier nicht fehlen:

http://www.das-labor.org/wiki/Crypto-avr-lib


Short Facts

    * kleine Implementierungen von Kryptofunktionen in C (fast alle 
Mikrocontroller)
    * noch kleinere Implementierungen von Kryptofunktionen in Assembler 
(ATmega, gnu-avr-as)
    * Lizenz: GPLv2 (nahezu alles)


About

Die crypto-avr-lib stellt ein reihe kryptographischer Funktionen für 
Atmels AVR Mikrocontroller zur Verfügung. Aufgrund der besonderen 
Begrenzungen in Mikrocontrollern (sehr wenig Speicher, sowohl RAM als 
auch Flash bewegen sich je nach Controller im Byte oder im unteren KiB 
Bereich), kann in der Regel nicht eine Standard oder 
Referenzimplementierung (in C) für den Mikrocontroller genutzt werden. 
Daher werden hier zum einen an die Anforderungen angepasste C 
Implementierungen zur Verfügung gestellt (die sich auch leicht auf 
andere Systeme portieren lassen) wie auch optimierte Assembler 
Implementierungen.


---Was soll rein---
Symmetrisch
Block

    * aes (davon gibt es eigentlich schon eine Menge)
    * serpent
    * cast6
    * twofish
    * idea
    * kasumi

Stream

    * seal
    * A5/1
    * Turing
    * Rabbit

Hashes

    * ripemd

Asymmetrisch

    * DH
    * RSA
    * ElGamal
    * EC
    * DSA

---Was ist da---
Symmetrisch
Block

    * XTEA
    * CAST5
    * Camellia
    * Skipjack
    * RC6
    * SEED
    * DES
    * SHABEA

Stream

    * ARCFOUR (RC4 kompatibel)

Asymmetrisch
Hashes

    * SHA-256
    * SHA-1
    * MD5

Sonstiges

    * HMAC-SHA256 (nach RFC2104)
    * PRNG

Stand 11.07.2007/Revision 1602

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Extrem schwach kommentierter Code. Hat jemand Lust, sich damit zu 
beschäftigen?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mich brennend interessieren würde, worin siehst Du die 
Anwendungsfelder für  Kryptographie auf nem MC ?

Mir fallen da keine ein.

Ich baue hauptsächlich Systemsteuerungen und da ist man schon froh, wenn 
alles mit Klardaten richtig zusammenspielt.

Wenn man bei der Fehlersuche dann noch alles erstmal entschlüsseln 
müßte, würde ich wahnsinnig, bzw. ließen sich gestörte Daten 
warscheinlich nicht mehr entschlüsseln.

Man müßte daher die ganze Kommunikationsabsicherung erstmal in Klardaten 
machen, die dann einen Container transportieren, der verschlüsselte 
Daten enthält.
Und darin überträgt man dann Temperaturen, Drücke, Spannungswerte usw. 
verschlüsselt, naja, sowas kann ich mir grad noch verkneifen.


Peter

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verschlüsselung ist für Firmware-Updates nicht ungewöhnlich, um 
unlizensierten Nachbau von Geräten inkl. Controllerfirmware zu 
unterbinden oder zu vermeiden, dass "gepatchte" Firmware auf das Gerät 
übertragen wird. Controller per Lock-Bits geschützt, Update der Firmware 
nur per Bootloader, der den verschlüsselt übertragenen Firmwarecode erst 
entschlüsselt und dann ins Flash schreibt.
Weiterer Einsatzzweck: Konfiguration von Geräteparametern oder 
Steuereingriffe zu Testzwecken, die der Endanwender nicht verändern bzw. 
durchführen soll/darf. Meist reicht zur Sicherung eine PIN aber der 
Endanweder kann evtl. einfach mitlauschen (im einfachsten Fall UART-RX 
des Controllers an einen PC "abzweigen"), die PIN abfangen und damit 
dann selbst Parameter "manipulieren" oder Testfunktionen auslösen. 
Verschlüsselung evtl. inkl. Challenge-Response hilft, dies zu vermeiden.
Beides wurde schon von Auftraggebern gefordert. Zumindest die 
Firmware-Update-Verschlüsselung scheint auch keine unübliche Forderung, 
sonst hätte Atmel nicht zwei Application-Note dazu herausgebracht. 
Verschlüsselung bei Parametereinstellungen sind m.W. auch im 
Automotive-Bereich nicht unüblich.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist auch vorallem Firmware Verschlüsselung bekannt.
Ich selber brauchte den md5 Algo für einen AVR Webserver um ein http 
Digest Auth zu implementieren.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo *,

warum Kryptographie auf MC??
Nun, wenn der MC Messdaten erfasst und sie via TCP/IP an einen Host 
überträgt, dann könnte es schon interessant werden. Schließlich wollen 
wir ja sicher gehen, dass die Daten die wir bekommen auch wirklich von 
unserer Messstation kommen. In gesicherten Netzwerken mag das vielleicht 
(und selbst da hätte ich meine Zweifel!!!) nicht so die Rolle spielen, 
aber spätetens wenn ich anfange Daten über das Internet zu schicken, 
wäre die Frage wie ich die Authenzität und evtl. auch die 
Vertraulichkeit der Daten sicher stellen kann.
Nehem wir als Beispiel den bakanntesten deutschen Wetterfrosch. Er baut 
Messstationen auf deren Messwerte er jeden Abend präsentiert. Wäre doch 
peinlich wenn er für Oberbayern im Dezember 25°C melden würde weil ihm 
jemand was untergeschoben hat....

Gruß
Sebastian

Autor: af (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe da 100 Möglichkeiten wo man die Crypt-Funktionen einsetzen 
könnte, wobei ich es zur Zeit selbst nicht unbedingt brauche.

@ Peter: Poste es doch im CCC Forum, da wird sich manch einer freuen :)

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger wrote:
> Was mich brennend interessieren würde, worin siehst Du die
> Anwendungsfelder für  Kryptographie auf nem MC ?
>
> Mir fallen da keine ein.


Naja, stell Dir mal vor, Du möchtest ein Zahlenschloss bauen.
Die einfache Lösung dafür ist, Du baust hinter die Tastatur einen 
Mikrocontroller welcher den Code auswertet und dann einen Relaiskontakt 
schließt. Das kann man einfach dadurch überlisten, in dem man den 
Relaiskontakt manuell überbrückt. Um dies zu verhindern muss man das 
Gehäuse sehr gut bauen.

Mit Kryptographie kannst du das schöner machen. Du kannst die Tastatur 
von der Auswertung trennen und die Kommunikation verschlüsseln. Somit 
muss das Teil, welches sicher sein muss, nicht mehr in der Nähe der 
Tastatur sein.

Autor: C. D. (schnack)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ist folgende Anwendung lebensnah?
Zugangskontrolle mit IR-Sender/Empänger anstatt RFID.
Nach bewährtem Muster könnte man z.B. die in RFID-Verfahren eingesetzten 
Challenge-Response-Verfahren zur Authentifizierung verwenden.
Dazu müßten beide Seiten mit einem IR-Sender & IR-Empfänger ausgestattet 
werden und Ver/Entschlüsselungslogik. Das hätte den Charme einer 
individuellen (=weithin unbekannten) Lösung und die kryptographischen 
Verfahren oder Schlüssel könnten auch nach Bedarf in Eigenregie 
ausgetauscht werden.

Mir ist allerdings nicht klar, welche Datenmengen jeweils bewegt werden 
müssen, um so eine Kommunikation durchzuführen, d.h. ob die mit IR 
erreichbaren Datenraten hierfür praktisch ausreichend sind.

Grüße
schnack

Autor: Manni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn der Beitrag schon älter ist, mich würde mal interessieren, wo 
Peter (Gast) den Code her hat, wenn er sagt, dass er nicht von ihm ist 
(ist ja schon mal rühmlich, dies zumindest zu erwähnen!).

Aber ich habe so den Eindruck, dass er den Schnipsel irgendwo beim 
Googlen gefunden hat und knallt ihn so ohne Beispiele  Kommentare  
Implementierungsergebnisse hier rein, von der sehr dürftigen 
Kommentierung mal abgesehen, denn ohne diese sind die Codes nahezu nicht 
nachvollziebar, speziell, wenn es, wie er sagt, "gestutzte" Codes sind, 
die gerade noch in einen uC passen.

Also etwas mehr "Background Intelligence" wäre hier im Forum schon 
angemessen.

Zum Thema: "Worin siehst Du die Anwendungsfelder?" von Peter:
Da könnten mir auch Tausend Beispiele einfallen, wenn ich darüber 
nachdenke, was alles so über die RFM12 Module (oder auch ähnliche) 
gesendet wird. Es muß ja nicht gleich die ganze Nachbarschaft wissen, 
was man da so treibt. Zugegeben, meinen Bank-Pin werde ich darüber noch 
lange nicht senden.

Gruß
Manni

Autor: Bernhard M. (boregard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manni schrieb:
> Auch wenn der Beitrag schon älter ist, mich würde mal interessieren, wo
> Peter (Gast) den Code her hat, wenn er sagt, dass er nicht von ihm ist
> (ist ja schon mal rühmlich, dies zumindest zu erwähnen!).
>

sieht man doch am Link, den er angegeben hat: Das Labor, die Seite 
sollte eigentlich hier nicht unbekannt sein...

Autor: Daniel Otte (nerilex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich möchte mich auch mal kurz dazu äußern (als Autor).
Ich finde durch den Link wird eigentlich gut ausgedrückt woher das kommt 
(im Zweifelsfall steht das auch im Kopf der meisten Dateien).

Der Code ist auch bestimmt noch nicht optimal kommentiert, aber der Code 
ist auch nicht dazu gedacht die Algorithmen zu verstehen, dafür sind die 
jeweiligen Spezifikationen gedacht.

In den Dateien USAGE.blockciphers, USAGE.hashfunctions und 
USAGE.streamciphers wird die Verwendung der einzelnen Primitiven 
erklärt, diese sollten als Ausgangspunkt für die Nutzung dienen.

Es sollte auch ein checkout aus dem SVN oder Bazaar genutzt werden und 
nicht das Zipfile aus dem ersten Posting. Wie man an so ein checkout 
kommt ist im verlinkten Wiki beschrieben.

mit freundlichen Grüßen,
  Daniel

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Projekt ist sehr interessant. Und die Implementierung schön klein.

Da der SourceCode aber unter der GPL steht, ist er für mich unbrauchbar. 
Ich kann es mir nicht leisten meinen SourceCode zu veröffentlichen (was 
ich ja müsste wenn ich Teile der lib einbaue). Dann wäre das ganze 
Projekt für die Tonne. :-(

@ Daniel Otte
Gibt es da eine Möglichkeit einer Ausnamegenehmigung?

Autor: Daniel Otte (nerilex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, wer Probleme mit der GPL hat kann sich via E-Mail an mich wenden. Am 
besten mit ein paar Projektdetails, damit wir eine entsprechenden 
(Lizenz-)Vertrag erarbeiten können.

mit freundlichen Grüßen
  Daniel

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok. Ich hab Ihnen eine Mail an die im Sourcecode angegebene Adresse 
geschickt.

Autor: Stephan M. (stmz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

erstmal danke für die tolle Bibliothek :)
Eine Frage: Auf welchen Atmegas besteht denn die Möglichkeit RSA zu 
nutzen? Wie hoch ist denn der benötigte RAM-Speicher dieser 
Implementierung?

Ich weiß nur von einer anderen Implementierung (relic-toolkit), welche 
fast 30 KB an Arbeitsspeicher genutzt hat ...

Falls jemand hier Erfahrungswerte hat, bin ich sehr dankbar :)

Gruß
Stephan

Autor: Daniel Otte (nerilex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Stephan,
wenn ich mich richtig erinnere, hab ich damals DSA mit 1024 Bit auf 
einem Atmega644 (4KiB RAM) getestet. DSA benutzt wie RSA modulare 
exponentiation, daher sollte RSA mit 1024 Bit mit unter 4KiB RAM 
auskommen.
Von RSA mit unter 1024 Bit ist dringend abzuraten und eigentlich sollte 
man schon 2048 Bit verwenden.
Ein anderes entscheidendes Problem ist allerdings die Laufzeit. Ich 
meine auf dem Atmega644 bei 20MHz dauerte das mehrere Minuten.
Ich werde mich gleich nochmal dran setzten OAEP zu implementieren und 
dann das ganze auf den AVR zurück zu portieren.
Wenn ich dabei bin, werde ich auch mal versuchen den Speicherverbrauch 
zu messen.

Den meisten Leuten die asymmetrische Kryptographie machen wollen 
empfehle ich zur Zeit die Verwendung von schnelleren ARM-Prozessoren.

mfg
  Daniel

Autor: Stephan M. (stmz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

danke für deine Antwort und vorallem deine Mühe!

Leider ist der Prozessor festgelegt, weshalb dies auf einem AVR laufen 
sollte (auch wenn die Berechnung wohl recht lange dauern dürfte ...).

1024 Bit Keys wären schon die minimale Schlüssellänge, welche für mich 
noch in Frage kommen würde. In Hinblick auf die Rechenzeit werde ich 
gegebenenfalls bewusst auf 2048 Bit Keys verzichten.

Gruß und Danke

Stephan

Autor: Stephan M. (stmz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

ich versuche im Moment deine RSA-Bibliothek auf einem Atmega644 und 
einem Atmega1284P zu nutzen. Leider ohne Erfolg.

Mein Code sieht wie folgt aus (angelehnt an deine main-rsa-test.c):
rsa_ctx_t rsa_ctx;



uint8_t testmsg[128] PROGMEM = {
    0x25, 0x11, 0x1e, 0x08, 0x1c, 0x72, 0x57, 0xbf,
    0x46, 0xbb, 0x56, 0xe8, 0x0b, 0x24, 0x0d, 0x72,
    0x77, 0x11, 0x12, 0x10, 0xec, 0xb9, 0xe4, 0x6f,
    0xe0, 0x6c, 0x83, 0x65, 0xe2, 0xe5, 0x1a, 0x3c,
    0xdb, 0x6c, 0x51, 0x8d, 0xbc, 0xd0, 0x30, 0xb6,
    0xca, 0x01, 0xb4, 0x03, 0x03, 0xe9, 0x86, 0x86,
    0xfe, 0x76, 0x4e, 0xb7, 0x47, 0xb5, 0x06, 0x15,
    0x92, 0x38, 0xc2, 0x0d, 0x3c, 0xfa, 0x53, 0xe3,
    0xe3, 0x57, 0xeb, 0x34, 0xb8, 0xda, 0x7b, 0x0e,
    0x06, 0x28, 0x1d, 0x4a, 0x14, 0xcc, 0x56, 0x8d,
    0xf3, 0x0f, 0x40, 0x2e, 0x23, 0x45, 0xe7, 0xcd,
    0xc5, 0x83, 0x8f, 0xaa, 0x55, 0x55, 0x7d, 0xbd,
    0x19, 0x63, 0xbd, 0x17, 0xda, 0xfd, 0x18, 0xd1,
    0x62, 0x43, 0xc7, 0x33, 0x39, 0x2c, 0xda, 0x64,
    0x27, 0x96, 0xa0, 0x83, 0xa0, 0xf9, 0x3b, 0x1e,
    0x17, 0x71, 0x59, 0xaa, 0x43, 0x3b, 0xeb, 0x80
};


void load_fix_rsa(void){
  load_rsa_key_blob(&rsa_ctx);
}


int main(void)
{
  uint8_t mw[rsa_ctx.modulus.length_B], cw[rsa_ctx.modulus.length_B], m_w[rsa_ctx.modulus.length_B];  
  bigint_t m,c,m_;

  load_fix_rsa();

  m.wordv = mw;
  c.wordv = cw;
  m_.wordv = m_w;
  m.length_B = rsa_ctx.modulus.length_B;
  m.info = 0;

  memcpy_P(mw, testmsg, 128);    
  bigint_changeendianess(&m);
    
  bigint_adjust(&m);
    
  rsa_enc_bigint(&c, &m, &rsa_ctx);

    while(1)
    {
        //TODO:: Please write your application code 
    }
}

Ich versuche das ganze mittels JTAGICE3 zu debuggen. Das Problem ist, 
dass er bei "bigint_adjust(&m)" einen Fehler wirft:

> # An unknown failure occurred.
> # Error terminating session: Prog Mode Leave failed:
> # An unknown failure occurred.
> # jtagice3: Unknown event: 0xA

Und direkt danach wieder ganz von Vorne beginnt. Auch ohne Debugger und 
dafür mit Ausgaben auf der UART scheint dieses Codestück Probleme zu 
machen. Habe ich irgendwas übersehen?

Gruß
Stephan

Autor: Daniel Otte (nerilex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube der Fehler ist, dass du die Größe der Arrays mit 
rsa_ctx.modulus.length_B angibst, bevor dieser Wert durch load_fix_rsa() 
initialisiert wurde.

Ich empfehle allerdings, noch 1-3 Tage zu warten, da ich RSA komplett 
umgestrickt habe (z.Zt. in der ARM-Crypto-Lib). Ich werde das Zeitnah 
auf die AVR-Crypto-Lib zu portieren. Dann gibt es unter anderem RSA-OAEP 
(PKCS#1).

Ich bin gerade dabei den Code zu testen, aber insbesondere die Tests auf 
dem AVR werden lange dauern, daher bitte ich noch um ein wenig Geduld.

mfg
  Daniel

Autor: Stephan M. (stmz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

> Ich glaube der Fehler ist

argh, ja. Das kann so nicht funktionieren.

> Ich empfehle allerdings, noch 1-3 Tage zu warten

dann warte ich noch ab :)
Vielen Dank nochmal für deine Mühe.

Gruß
Stephan

Autor: Stephan M. (stmz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

so, ich hab jetzt doch nochmal das ganze mit korrekt initialisieren 
Arrays testen müssen ;) . Allerdings scheint beim Entschlüsseln nicht 
die Klartextnachricht heraus zu kommen. Mein Code.
int main(void)
{
  
  load_fix_rsa();
  
  uint8_t mw[rsa_ctx.modulus.length_B], cw[rsa_ctx.modulus.length_B], m_w[rsa_ctx.modulus.length_B];  
  bigint_t m,c,m_;

  DDRB = 0xFF;
  
    uart_init( UART_BAUD_SELECT(UART_BAUD_RATE,F_CPU) ); 
    sei();
  
  uart_puts_P("INIT\n");

  m.wordv = mw;
  c.wordv = cw;
  m_.wordv = m_w;
  m.length_B = rsa_ctx.modulus.length_B;
  m.info = 0;

  uart_puts_P("memcpy_P\n");  
  memcpy_P(mw, testmsg, 128);
  
  uart_puts_P("bigint_changeendianess\n");    
  bigint_changeendianess(&m);
  
  uart_puts_P("bigint_adjust\n");    
  bigint_adjust(&m);  

  uart_puts_P("rsa_enc_bigint\n");      
  rsa_enc_bigint(&c, &m, &rsa_ctx);
  
  uart_puts_P("rsa_dec_bigint\n");
  rsa_dec_bigint(&m_, &c, &rsa_ctx);

  uart_puts_P("compare\n");
  if(bigint_cmp_s(&m, &m_)){
    uart_puts_P("true\n");
  }else{
    uart_puts_P("false\n");
  }
  
  PORTB |= (1<<PB1);
  uart_puts_P("FERTIG\n");    

  
    
    while(1)
    {
        //TODO:: Please write your application code 
    }
}

Auf einem Atmega644 und einer Taktfrequenz von etwas über 7 MHz habe ich 
folgende Laufzeiten feststellen können:

rsa_enc_bigint: ca. 30-40 Sekunden
rsa_dec_bigint: ca. 45 Minuten

Allerdings liefert:
if(bigint_cmp_s(&m, &m_))

false zurück. Sind denn die Laufzeiten einigermaßen plausibel? 45 
Minuten zum Enschlüsseln kommen mir schon relativ lange vor ...

//Nachtrag: Die Schlüssellänge betrug 1024 Bit

Gruß
Stephan

Autor: Daniel Otte (nerilex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Stephan,
als mögliche Fehlerquelle fällt mir ein, dass evtl. deine test-nachricht 
größer als N, also der Modulus ist.
Ich mag auch nicht ausschließen, dass in der bigint-Bibliothek noch 
Fehler sind (ich bin mir eher sicher, dass da noch welche sind, ich hab 
nämlich noch Fehler in der ARM-Variante gefunden).

Ich meine, dass so Zeiten um 17min normal waren zum entschlüsseln.
Das wird aber noch besser werden.

Ich möchte aber dringend_ davon _abraten direkt diese Variante von RSA 
zu benutzen. Die Verwendung von Plain-RSA bringt einen Haufen von 
Sicherheitsproblemen mit sich. Normalerweise kapselt und kodiert man die 
Nachricht speziell und wendet dann die Exponentiation an.

mfg
  Daniel

Autor: Stephan M. (stmz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

Die Testnachricht und der Modulus waren gleich groß. Ich habe einfach 
deine Testnachricht aus "main-rsa-test.c" kopiert. Das sollte dann für 
den 1024-Bit-Key eigentlich passen.
#define N_LEN_B (16*8)

und
uint8_t testmsg[128] PROGMEM = {

Ich würde daher tatsächlich auf einen Fehler in der Bigint-Bibliothek 
tippen. Bezüglich neuer Bibliothek: Ich werde auf die neue Version 
warten. Allerdings wollte ich (nachdem ich eh schon so viel probiert 
habe) noch ein paar Experimente mit der jetzigen Version durchführen. 
Gerade auch um ein Gefühl dafür zu bekommen, wie lange der Prozessor 
tatsächlich für die Durchführung der Operationen benötigt ;)

Im Moment versuch ich noch deine DSA-Implementierung zu nutzen. Fragt 
sich nur, ob diese funktionieren wird ... immerhin greift sie auf 
dieselbe Bigint-Library zurück. Aber ich werde das einfach mal testen :)

Die Fehler in der Bigint-Lib sind in deiner ARM-Version behoben? Sprich 
ich könnte z.B. versuchen die ARM-Version der Bibliothek zurück zu 
portieren?


Gruß
Stephan

Autor: Stephan M. (stmz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,

also DSA passt. Ich konnte eine erstellte Signatur erfolgreich 
überprüfen :)

Dauer bei 512-bit-Keys und 7,xx MHz:
dsa_sign_message: 2:30 min
dsa_verify_message: 5:20 min

Ich werde die Geschwindigkeit mal mit ECDSA vergleichen. Das war in 
meiner Erinnerung auf dem AVR nämlich recht schnell.

Gruß
Stephan

Autor: Daniel Otte (nerilex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Stephan und alle anderen Interessierten,
ich habe soeben RSA-OAEP eingecheckt.
RSA-PKCS#1-v1.5 wird gerade getestet.
Tut mir leid, dass es nun doch länger gedauert hat. Ich war überrascht, 
dass es so viele Veränderungen im GCC und der avr-libc gab, dass die 
Bibliothek nicht mehr gebaut hat. Daher musste ich zunächst viel Arbeit 
darein investieren, alles auf Vordermann zu bringen. Und da ich so viel 
Source-Code angefasst habe, musste das ganze auch nochmal getestet 
werden.
Insgesammt wurden mehrere Bugs beseitigt, und ich bin recht 
zuversichtlich, dass RSA-OAEP gut funktionieren wird (habe bisher nur 
die Testvektoren von RSA benutzt, der NESSIE-Test muss noch, aber das 
wird lange dauern).

1024 Bit hat auf einem ATmega644 (4KiB RAM) @ 20MHz funktioniert.
Zur groben Orientierung, habe ich Zeiten um 30-40s für das Verschlüsseln 
und ca. 4-5min für das Entschlüsseln beobachtet.

Die Umsetzung in Assembler wird wohl die Geschwindigkeit verdoppeln, und 
die Code-Size halbieren (dass sind grobe Werte die in etwa dem 
entsprechen, was bei anderen Algorithmen passiert ist).

Zudem plane ich in nächster Zeit, den Reduktions-Algorithmus zu 
verbessern, der ist im Moment noch sehr rudimentär.

1536 Bit hat übrigens mit 4KiB nicht mehr funktioniert.
2048 Bit hat auf meinem Ethernut 2.1 (ATmega128  (4KiB RAM) + externes 
RAM) funktioniert. Ich meine dabei allerdings Zeiten um 45min für das 
entschlüsseln gemessen zu habe.

mfg
  Daniel

Autor: Stephan M. (stmz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel

erstmal vielen vielen Dank für all deine Mühe! Ich werde mir deine neue 
Library auf jeden Fall ansehen. Asymmetrische Kryptographie auf einem 
Atmega scheint schon eine ziemlich grenzwertige Sache zu sein. Da ist 
natürlich auch der Einsatz zusätzlicher ICs interessant, welche solche 
Kryptographie von sich aus schon anbieten und in Hardware implementiert 
haben.

Gruß
Stephan

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat mal jemand die Geschwindigkeit mit http://www.basiccard.com/ 
verglichen ?
Würde mich interessieren.

Autor: Stephan M. (stmz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris schrieb:
> Hat mal jemand die Geschwindigkeit mit http://www.basiccard.com/
> verglichen ?
> Würde mich interessieren.

die Karte kenne ich nicht. Ich habe aber diverse Vergleiche angestellt 
mit reinen Softwarebibliotheken mit einem dedizierten VaultIC-Kryptochip 
(http://www.insidesecure.com/eng/Products/Secure-So...). 
Gerade bei asymmetrischer Kryptographie sind die Unterschiede ganz 
beträchtlich. Wenn es um die Erstellung digitaler Signaturen rein in 
Software geht, so würde ich auch kein RSA auf einem Microcontroller 
verwenden. ECDSA ist hier um einige Faktoren schneller bei gleichem 
Sicherheitsniveau. Zusätzlich belegen die kleineren Schlüssel bei ECDSA 
weniger Arbeitsspeicher auf dem Microcontroller. Die Erstellung einer 
ECDSA-Signatur mit 224-bit Schlüsseln dauerte auf einem Atmega1281 mit 
7,xx MHz Quarz gerade mal 2,x Sekunden. Das entspricht in etwa der 
Sicherheit von RSA mit 2048-bit Keys. Bei symmetrischen Algorithmen sind 
die Unterschiede dann nicht mehr so groß ...

Aber unabhängig davon bietet ein Kryptochip natürlich auch einen 
sicheren Schlüsselspeicher.

Gruß
Stephan

Autor: Tobbi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, es war hier immer mal die Rede von einer ECDSA Implementierung..

Gibt es die irgendwo zu sehen / zu bekommen ? (@ stmz,..)

In der AVR crypto lib ist nichts mit EC integriert, stimmt das?
Ist das in Planung oder eher nicht ?

Autor: Stephan M. (stmz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tobbi,

Tobbi schrieb:
> Hallo, es war hier immer mal die Rede von einer ECDSA Implementierung..
>
> Gibt es die irgendwo zu sehen / zu bekommen ? (@ stmz,..)

im Rahmen meiner Versuche habe ich die TinyECC-Bibliothek verwendet: 
http://discovery.csc.ncsu.edu/software/TinyECC/

Hier gilt zu beachten, dass die Bibliothek für TinyOS geschrieben wurde 
und mit nesC umgesetzt wurde (einer Erweiterung von C).

Gruß
Stephan

Autor: Tobbi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,

Danke für die schnelle Reaktion.

Und wie sind deine Erfahrungen / Ergebnisse ?  (Was genau war/ist dein 
Target? - bei mir ists ein Freescale Coldfire [32bit])

Autor: Tobbi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
entschuldige, 'Stephan' ist dein Name. :/

Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weiß einer wie es eigentlich um die AVR CryptoLib steht? Laut 
wiki-Eintrag sind die Informationen ja veraltet... wird die noch 
gepflegt?

Leider konnte ich auch kein Beispielcode finden, wie ich z.B. AES 
verschlüssel und entschlüssel...

Autor: Daniel Otte (nerilex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

die Lib wird noch gepflegt und weiter entwickelt. Leider bin ich schon 
lange nicht mehr dazu gekommen die Wiki-Seiten zu updaten.

Beispiele für AES kannst du dem entsprchendem Test entnehmen 
(test_src/main-aes-test.c). Darin befinden sich auch Beispiele/Tests für 
die diversen Betriebsmodi.

mfg
  nerilex

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.