Passwörter mit Masterpasswort ver- und entschlüsseln

Wenn dein Masterkey sowieso auch im Flash liegt:
ein simples XOR mit dem Masterkey (am besten mindestens so lang wie das 
längste Passwort, was er "beschützt") ist (in diesem speziellen Fall) 
auch nicht unsicherer als AES.

1

return password == „Geheim“;

Oliver

Εrnst B. schrieb:
> Wenn dein Masterkey sowieso auch im Flash liegt:
> ein simples XOR mit dem Masterkey (am besten mindestens so lang wie das
> längste Passwort, was er "beschützt") ist (in diesem speziellen Fall)
> auch nicht unsicherer als AES.

Hallo, nein der Masterkey soll nicht im Flash liegen, er soll aus einem 
eingegebenem Passwort "generiert" werden.

Thomas H. schrieb:
> Hallo, nein der Masterkey soll nicht im Flash liegen, er soll aus einem
> eingegebenem Passwort "generiert" werden.

Je nachdem welche Angriffsvektoren es da gibt, bleibt XOR eine 
Möglichkeit.

Problem wäre z.B. wenn der Angreifer den EEPROM-Inhalt kennt und ein 
entschlüsseltes Passwort bei Verwendung mitlesen kann, kann er die 
anderen Passwörter und den Masterkey errechnen.

Thomas H. schrieb:
> String message = encypt(String ciphertext, byte* key);

Un was machst du dann mit dem Klartext in message?

Oliver

Oliver S. schrieb:
> Thomas H. schrieb:
>> String message = encypt(String ciphertext, byte* key);
>
> Un was machst du dann mit dem Klartext in message?
>
> Oliver

Auf einem Display anzeigen.
Es geht mir nur darum, dass niemand wenn er das EEPROM auslesen würde, 
an die Passwörter kommt.

Ich hoffe für dich dass das nur eine Bastelei ist und du das nicht am 
Ende produktiv einsetzen willst.

Dieter D. schrieb:
> Ich hoffe für dich dass das nur eine Bastelei ist und du das nicht am
> Ende produktiv einsetzen willst.

Na, ja. Besser als ein Zettel unter dem Kopfkissen wird das schon 
werden. ;-)

Thomas H. schrieb:
> Auf einem Display anzeigen.
> Es geht mir nur darum, dass niemand wenn er das EEPROM auslesen würde,
> an die Passwörter kommt.

Dann frage ich nochmal:

Wie programmierst du dann die Abfrage, ob jemand das richtige Passwort 
eingegeben hat?

Oliver

🐧 DPA 🐧 schrieb:
> Ein-Weg Hash Funktionen - Wurden noch nicht erfunden, oh, warte, doch,
> wurden sie.

Die Frage war nicht, wie DU das lösen würdest, sondern der TO.

Oliver

Oliver S. schrieb:
> Die Frage war nicht, wie DU das lösen würdest, sondern der TO.
>
> Oliver

Die Idee ist, dass gar keine Abfrage erfolgt. D.h., wird ein falsches 
Passwort eingegeben, werden die Daten falsch entschlüsselt und sind 
somit nutzlos ;-)

Ach so. Dann liegen nur die verschlüsselten Zugangsdaten im EEprom, der 
Key braucht dann doch gar nicht gespeichert werden.

Oliver

chris schrieb:
> key[i]^= pgm_read_byte(val++);
> durch
> key[i] = pgm_read_byte(val++);

chris schrieb:
> Bei load_key,
> key[i]^= pgm_read_byte(val++);
> durch
> key[i] = pgm_read_byte(val++);
> ersetzen, ich verwende xor, damit ich nach dem init einen Bereich von
> Daten zugreifen kann, mit anderer Verschluesselung, was danach nicht
> mehr
> moeglich ist.

Hallo und danke für den Beispielcode!
Muss ich für das Beispiel die "XTEA-Cipher library for Arduino" 
installieren?

Ich bekomme es noch nicht ans laufen, die lib hat keine Methoden 
"xtea_dec" und "xtea_end".

Des weiteren habe ich, um erstmal das kompilieren zu testen, die defines

#define XTEA_KEYSIZEB 16
#define XTEA_BLOCKSIZEB 16

gesetzt, Keysize müsste ja 16 sein und blocksize?
und noch die Variable

unsigned char key[XTEA_KEYSIZEB] = { 
193,104,46,209,249,154,141,242,31,247,183,73,175,133,168,105 };

deklariert.
Ist das so richtig?

Danke!