AES als Datei Container: Automatische Schlüsselgenerierung und Formatierung Fehler

Anfängerfragen zum Programmieren mit PureBasic.
Benutzeravatar
ChrigiGee
Beiträge: 125
Registriert: 18.07.2024 12:14
Computerausstattung: Lenovo ThinkPad i7, 32GB Ram, 1TB SSD
PB 6.11 LTS, proGUI, IceDesigner
Wohnort: Bern

AES als Datei Container: Automatische Schlüsselgenerierung und Formatierung Fehler

Beitrag von ChrigiGee »

Hallo @All
Hallo DarkDragon,
Hallo jacdelad,
Hallo H.Brill,

Grundlage zur genannten Fragestellung war:
https://www.purebasic.fr/german/viewtopic.php?t=33233

Resp. Weitergehend wurde Empfohlen mit AES weiter zu machen.
Ab Posting und Folgende.
https://www.purebasic.fr/german/viewtop ... 21#p366321

Konkreter Problematik bei Verwendung des AES:
https://www.purebasic.fr/german/viewtop ... 23#p366323

In den vorhandenen Beispielen aus PureBasic resp. der Hilfe entnommen.
Resp. im Forum oder über PureArea.

Zugrunde liegender Teil für die Generierung eines AES Schlüssel (Key)
war die Idee dass man den Schlüssel unter Zuhilfenahme der HWID (GUID)
erstellen könnte.

Der daraus erstellte HEX Wert liegt in der Form vor:
18 B6 E7 89 97 DE 0D FE 84 89 15 4B 57 A2 51 B2

Das Besispiel Projekt aus PureBasic sieht jedoch eine Formatierung vor
des vorhandenen HEX Wertes in etwa:
$06, $a9, $21, $40, $36, $b8, $a1, $5b, $51, $2e, $03, $d5, $34, $12, $00, $06

Entnehme ich den HEX Wert direkt:
18 B6 E7 89 97 DE 0D FE 84 89 15 4B 57 A2 51 B2
als Daten ergibt mir dies eine Fehlermeldung

Verwende ich jedoch die Variable "*Key"
Ergibt sich wieder eine Fehlermeldung.

Konkrets Beispiel als Teil Code:

Code: Alles auswählen

DataSection
    Key:
    Data.a $06, $a9, $21, $40, $36, $b8, $a1, $5b, $51, $2e, $03, $d5, $34, $12, $00, $06
  EndDataSection
Nicht Funktionsfähig hingegen:

Code: Alles auswählen

DataSection
    Key:
    Data.a 18 B6 E7 89 97 DE 0D FE 84 89 15 4B 57 A2 51 B2
  EndDataSection
Resp. gleiches Problem:

Code: Alles auswählen

DataSection
    Key:
    Data.a = *Key
  EndDataSection
Oder:

Code: Alles auswählen

DataSection
    Key:
    Data.a  *Key
  EndDataSection
Ich bin mir nicht sicher ob ich bei der DataSection evtl. auch eine Variable übergeben kann anstelle eines
Hart Hinterlegten Wertes.

Wenn ich also eine Variable hinterlegen kann, müsste ich den erhaltenen HEX Wert jedoch zuerst so Formatieren dass er
der Konvention entspricht welche von der DataSection verlangt wird.

Was zu meiner nächsten Problematik führte welche sich eröffnete, WIE kann ich diesen entsprechend Formatieren.

Liebe Grüsse
Christian

Erstellen GUID:

Code: Alles auswählen

EnableExplicit

Procedure.s MakeGUID()
  Protected guid.GUID, lpsz.s{76}
  If CoCreateGuid_(@guid) = #S_OK
    ProcedureReturn PeekS(@lpsz, StringFromGUID2_(guid, @lpsz, 76), #PB_Unicode)
  EndIf
EndProcedure

MessageRequester("","GUID: "+MakeGUID(),0)
GUID als Basis für HEX Schlüssel Generieren:

Code: Alles auswählen

EnableExplicit

Procedure.s MakeGUID()
  Protected guid.GUID, lpsz.s{76}
  If CoCreateGuid_(@guid) = #S_OK
    ProcedureReturn PeekS(@lpsz, StringFromGUID2_(guid, @lpsz, 76), #PB_Unicode)
  EndIf
EndProcedure

MessageRequester("","GUID: "+MakeGUID(),0)
AES Beispiel Code etwas Angepasst:

Code: Alles auswählen



Structure HW_PROFILE_INFO
  DockInfo.l
  szHWProfileGUID.s{38}
EndStructure

GetCurrentHwProfile_(hwp.HW_PROFILE_INFO)
hwGUID.s = hwp\szHWProfileGUID

  String$ = hwGUID
  
  ; Kodieren eines UTF-8 Strings
  *Text = UTF8(String$)
  Encoded$ = Base64Encoder(*Text, StringByteLength(String$, #PB_UTF8))

UseSHA3Fingerprint()
  *Key = AllocateMemory(32)

  ; Erstellt einen 256-Bit-Schlüssel mithilfe der SHA-512-Hash-Funktion und 500.000 Iterationen
  DeriveCipherKey(hwGUID, Encoded$, 500000, *Key, 256, #PB_Cipher_SHA3, 512)



String$ = "Hello this is a test for AES"
  
  *CipheredString   = AllocateMemory(StringByteLength(String$) + SizeOf(Character)) ; Platz für den null-terminierten String
  *DecipheredString = AllocateMemory(StringByteLength(String$) + SizeOf(Character)) ; mit seiner abschließenden Null
  
  If AESEncoder(@String$, *CipheredString, MemorySize(*CipheredString), ?Key, 128, 0, #PB_Cipher_ECB)
    Debug "Ciphered: " + PeekS(*CipheredString)
    
    AESDecoder(*CipheredString, *DecipheredString, MemorySize(*DecipheredString), ?Key, 128, 0, #PB_Cipher_ECB)
    Debug "Deciphered: " + PeekS(*DecipheredString)
  EndIf
  
  DataSection
    Key:
    Data.a *Key
    ;    Data.a  18 B6 E7 89 97 DE 0D FE 84 89 15 4B 57 A2 51 B2  
;    Data.a $06, $a9, $21, $40, $36, $b8, $a1, $5b, $51, $2e, $03, $d5, $34, $12, $00, $06
  EndDataSection
Wer nicht fragt, der nichts lernt.
Wer keine Fehler macht, kann sich nicht verbessern.
Das Mysterium, ein wandelndes Lexikon. :mrgreen:

Wer Fragen zu meinem Textstil hat oder sich wundert über mich,
der darf seelenruhig mich direkt ansprechen. Ich beiße noch nicht.
jogo
Beiträge: 123
Registriert: 22.11.2020 20:05
Computerausstattung: 'ne Handvoll gebrauchte Laptops & PCs mit Mint und LMDE

Re: AES als Datei Container: Automatische Schlüsselgenerierung und Formatierung Fehler

Beitrag von jogo »

aber die Fenster ID ist doch beim nächsten Programmstart eine andere, also stimmt dann dein AES-Schlüssel nicht mehr.
--
Ideen gibt es viele - man muss sie nur haben...
Mint / LMDE5+6 // PureBasic 6.21
Benutzeravatar
ChrigiGee
Beiträge: 125
Registriert: 18.07.2024 12:14
Computerausstattung: Lenovo ThinkPad i7, 32GB Ram, 1TB SSD
PB 6.11 LTS, proGUI, IceDesigner
Wohnort: Bern

Re: AES als Datei Container: Automatische Schlüsselgenerierung und Formatierung Fehler

Beitrag von ChrigiGee »

Hallo Lieber Jogo,

Vielen Dank, für Deine Berichtigung. Da ist bei mir ein Fehler bei der Überlegung geblieben.
Ich hätte NICHT Den Teil GUID mit einer anderen GUID Berechnung mischen sollen.

Du hast Recht, dass dieser jedes mal beim Start eine NEUE ID Generiert.

Code: Alles auswählen

EnableExplicit

Procedure.s MakeGUID()
  Protected guid.GUID, lpsz.s{76}
  If CoCreateGuid_(@guid) = #S_OK
    ProcedureReturn PeekS(@lpsz, StringFromGUID2_(guid, @lpsz, 76), #PB_Unicode)
  EndIf
EndProcedure

MessageRequester("","GUID: "+MakeGUID(),0)
Sommit ist dieser nicht Anwedbar. Danke...

Und bei diesem wird immer wieder der Gleiche Schlüssel Generiert:

Code: Alles auswählen

Structure HW_PROFILE_INFO
  DockInfo.l
  szHWProfileGUID.s{38}
EndStructure

GetCurrentHwProfile_(hwp.HW_PROFILE_INFO)
hwGUID.s = hwp\szHWProfileGUID

  String$ = hwGUID
  
  ; Kodieren eines UTF-8 Strings
  *Text = UTF8(String$)
  Encoded$ = Base64Encoder(*Text, StringByteLength(String$, #PB_UTF8))

UseSHA3Fingerprint()
  *Key = AllocateMemory(32)

  ; Erstellt einen 256-Bit-Schlüssel mithilfe der SHA-512-Hash-Funktion und 500.000 Iterationen
  DeriveCipherKey(hwGUID, Encoded$, 500000, *Key, 256, #PB_Cipher_SHA3, 512)

  ; Zeigt den Schlüssel an
  ShowMemoryViewer(*Key, 32)
   
Somit sollte auch bei mehrmaligem oder Späteren Starten der Selbe Schlüssel gebildet werden.
Was meiner Ursprünglichen Überlegung entsprochen hatte.

Die Fragestellung änderst sich nicht, ausser dass ich einen Falschen Code reingeschmuggelt hatte
beim Posting zuvor.

Liebe Grüsse
Christian
Wer nicht fragt, der nichts lernt.
Wer keine Fehler macht, kann sich nicht verbessern.
Das Mysterium, ein wandelndes Lexikon. :mrgreen:

Wer Fragen zu meinem Textstil hat oder sich wundert über mich,
der darf seelenruhig mich direkt ansprechen. Ich beiße noch nicht.
jogo
Beiträge: 123
Registriert: 22.11.2020 20:05
Computerausstattung: 'ne Handvoll gebrauchte Laptops & PCs mit Mint und LMDE

Re: AES als Datei Container: Automatische Schlüsselgenerierung und Formatierung Fehler

Beitrag von jogo »

probier mal diese Variante:

Code: Alles auswählen

DataSection
 Key:
 Data.b $06, $a9, $21, $40, $36, $b8, $a1, $5b, $51, $2e, $03, $d5, $34, $12, $00, $06
EndDataSection
--
Ideen gibt es viele - man muss sie nur haben...
Mint / LMDE5+6 // PureBasic 6.21
Benutzeravatar
jacdelad
Beiträge: 404
Registriert: 03.02.2021 13:39
Wohnort: Riesa
Kontaktdaten:

Re: AES als Datei Container: Automatische Schlüsselgenerierung und Formatierung Fehler

Beitrag von jacdelad »

Hallo ChrigiGee,
bezogen auf deinen ersten Post: ich glaube, du bist noch nicht ganz dahintergestiegen, wie die DataSection funktioniert (das ist jetzt nicht böse gemeint!).

In der DataSection werden Daten abgelegt, die fest in deinem Programm eingbaut sind. Als Anfänger sind nur 3 Dinge für dich relevant: Adressen, Data und IncludeFile. Einzelne, einfache Werte oder Strings speichert man in der Regel gleich als Konstante ab, also

Code: Alles auswählen

#MyConstant = 1.995
Adressen werden mit einem Bezeichner und einem Doppelpunkt am angegeben. Auf diese Adressen kannst du mit einem vorangehenden Fragezeichen zugreifen und quasi alle Operationen ausführen, die auch mit einer dynamisch erzeugten Adresse eines Speicherbereichs machbar sind. Mehr macht die Adresse nicht; Beispiele unten.

Wenn die Konstanten überhand nehmen oder es aus anderen Gründen sinnvoll ist, dann lohnt sich auch da eine DataSection. Mittels Data.[Typ] fügst du einen oder mehrere Werte ein:

Code: Alles auswählen

DataSection
  Adresse:
  Data.a 1,2,3,4,5
EndDataSection
speichert die Werte 1 bis 5 in jeweils einem Byte.

Code: Alles auswählen

DataSection
  Adresse:
  Data.l 1,2,3,4,5
EndDataSection
speichert die selben Werte, ABER als Long! Das ist wichtig beim Lesen:

Um das erste Beispiel zu lesen, musst du PeekA() verwenden:

Code: Alles auswählen

DataSection
  Adresse:
  Data.a 1,2,3,4,5
EndDataSection

Debug PeekA(?Adresse)
Debug PeekA(?Adresse+1)
Debug PeekA(?Adresse+2)
Debug PeekA(?Adresse+3)
Debug PeekA(?Adresse+4)
Beim zweiten PeekL(), weil es ja Long-Werte sind, die 4 Byte im Speicher belegen:

Code: Alles auswählen

DataSection
  Adresse:
  Data.L 1,2,3,4,5
EndDataSection

Debug PeekL(?Adresse)
Debug PeekL(?Adresse+4)
Debug PeekL(?Adresse+8)
Debug PeekL(?Adresse+12)
Debug PeekL(?Adresse+16)
...und den Zeiger auch immer 4 Byte weiterschieben.

IncludeBinary fügt an der Stelle eine Datei ein. Das kann jede beliebige Datei mit jedem beliebigen Inhalt sein, das bleibt komplett dir überlassen. Du kannst die Datei mittels der Catch...()-Befehle einlesen oder wie einen normalen Speicherbereich behandeln.

So, jetzt zu deinem ersten Post:

Erstes und zweites Beispiel:
Jede Zahl, die ein "$" vorangestellt hat, wird als Hex-Wert interpretiert. Wenn du das "$" weglässt, wie in deinem zweiten Code, dann funktioniert das natürlich nicht mehr, weil "B6" keine Zahl ist; "B6" aber schon! Zu beachten ist, dass "18" keinen Fehler produziert (es ist ja eine Zahl), aber 18 und $18 sind natürlich zwei komplett unterschiedliche Zahlen!

Drittes Beispiel:
Hier versuchst du in einer DataSection auf einen Speicherbereich zuzugreifen, den es bei Erzeugung des Programms noch nicht gibt. Das geht nicht.

Viertes Beispiel:
Hier versuchst du etwas ähnliches, also einen zur Laufzeit erzeugten Speicherbereich in die DataSection zu legen. Das geht auch nicht.

Du hast jetzt 2 Möglichkeiten:
Entweder du speicherst deinen Schlüssel fest ins Programm. Dazu machst du es wie im Beispiel mit einer DataSection oder einer Konstante.
Oder du erzeugst den Schlüssel während der Laufzeit. Dann muss er in einer Datei, der Registry oder sonstwo gespeichert werden. Oder er wird dem Benutzer angezeigt und er muss ihn auf Papier bringen. So oder so hat das nichts mit der DataSection zu tun.

Kommen wir nun zu etwas ganz anderem:
Nochmal zur DataSection, dem Schlüssel und den Variablentypen: Der Schlüssel ist 16 Byte lang. Die kannst du als einzelne Byte oder z.B. als Long behandeln. In beiden Fällen ist das für den Schlüssel unerheblich, die 16 Byte müssen nur nacheinander im Speicher stehen. Ich kann den Schlüssel aus dem Beispiel also in etlichen Varianten ablegen, er ist aber immer der gleiche Schlüssel:

Code: Alles auswählen

DataSection
    Key:
    Data.a $06, $a9, $21, $40, $36, $b8, $a1, $5b, $51, $2e, $03, $d5, $34, $12, $00, $06
    Key2:
    Data.w $A906, $4021, $B836, $5BA1, $2E51, $D503, $1234, $600
    Key3:
    Data.l $4021A906, $5BA1B836, $D5032E51, $6001234
    Key4:
    Data.q $5BA1B8364021A906, $6001234D5032E51
  EndDataSection
In dieser DataSection ist 4 Mal der gleiche Schlüssel abgelegt. nur unterschiedlich dargestellt.
Und das Ganze ginge natürlich auch mit Dezimalwerten. Letztendlich bleibt die überlassen, welche Darstellungsweise du benutzt.

Ich bin nicht wirklich gut im Erklären und vielleicht kann jemand noch was ergänzen. Ansonsten einfach weiter fragen!
Guten Morgen, das ist ein schöner Tnetennba!

PureBasic 6.21/Windows 11 x64/Ryzen 7900X/32GB RAM/3 TB SSD
Synology DS1821+/DX517, 130.9TB+50.8TB+2TB SSD
Benutzeravatar
ChrigiGee
Beiträge: 125
Registriert: 18.07.2024 12:14
Computerausstattung: Lenovo ThinkPad i7, 32GB Ram, 1TB SSD
PB 6.11 LTS, proGUI, IceDesigner
Wohnort: Bern

Re: AES als Datei Container: Automatische Schlüsselgenerierung und Formatierung Fehler

Beitrag von ChrigiGee »

Lieber Jacdelad,
Lieber Jogo,

@Jacdelad, Nein ,ich bin niemandem böse wenn man nicht beleidigend wird.
Und ich mache die Fehler in meinen Überlegungen.

Somit bin ich über jede Berichtigung meiner Gedankengänge überaus Dankbar. :praise:
Auch ich bin nicht Gut im Erklären, es gibt bei mir sehr oft eine grosse Diskrepanz zu dem was ich denke und was
ich schreibe. So kann es dann durchaus vorkommen dass es zu kompliziert wird.... :mrgreen:

Auch wenn ich nicht mehr der Jüngste bin, und ich mit verschiedenen Programmiersprachen etwas gearbeitet habe,
fehlen einige Kenntnisbausteine und die versuche ich mir anzueignen. (Dadurch auch dass ich viele Jahre Garnichts mehr gemacht habe)

Am besten gelingt es mir wenn ich mich mit dem Source Code direkt befasse, auch wenn ich viele Fehler mache, kann ich so besser lernen als
mit reiner Theorie, Bücher lesen.

Das mit Include Files hast Du mir mit diesem Post auch bereits vorneweg genommen, ich war den ganzen Abend am überlegen ob es nicht besser wäre, gewisse Elemente auslagern in eine PBI Datei und dann kam bei mir auch bereits wieder der Punkt wie stelle ich es dann an dass ich diesen Code wieder benutzen kann.

Danke auch dafür. Aber ich habe auch über etwas Umwege begriffen dass ich Includes erst zur Zeit der Benutzung am besten aufrufe oder liege ich Falsch ? Naja, Ist jedoch ein etwas anderes Thema als das vorliegende.

Konstante, glaube ich habe es erst Jetzt erkannt, dass die Überlegung von mir DataSection NICHT einer Variable Entspricht und ich somit Falsch gelegen bin und ich auch nicht so wie SIE Aufgebaut wurde in den Beispielen diese als Variable verwenden kann.

Das mit der Differenzierung als "Zahl" und als HEX Wert war mir schon klarer geworden.
$D8 und D8 sind zwei gänzlich Unterschiedliche Angelegenheiten.

Mir ist auch bewusst gewesen, dass die Unterteilung des Wertes "$D8" mittels eines Komma getrennt wird.
Sprich $D12$B1$C8$35 wahrscheinlich zu einem Konflikt führt für den Compiler.

OK, Sorry wenn ich Deinen Post wiederhole, Du meinst ich kann nicht zur Laufzeit den Schlüsselgenerieren als HEX Wert um ihn anschliessend
für die AES Verschlüsselung zu verwenden.

Der HEX Wert muss bereits in Form was weis ich, INI Datei, Registry Eintrag oder Inputfeld für den Benutzer Existieren,
um AES verwenden zu können ?

Heisst, andersrum, wenn ich die Haupt-Applikation starte verweise ich zum Beispiel auf einer Includ Datei,
welche nur einmal gestartet werden müsste um zu Referenzieren ob ein HEX Eintrag existiert und gegebenenfalls erstellt.

Ich könnte dort jedoch auch schauen ob der hinterlegte HEX Wert Korrekt wäre für eine weitere Ausführung und ansonsten
einen Error ausweisen.

Wenn ich AES benutzen will als (Annahme Includ Datei) müsste sie auf genau diesen Eintrag zugreifen können.

Die Reihenfolge dieser beiden Include Dateien muss jedoch zwingend zuerst HEX Wert erstellen und anschliessend AES Verschlüsselung / Entschlüsselung sein. (Somit hätte ich auch das mit den Include Files wahrscheinlich richtig begriffen.)

Ich hoffe meine Gedanken sind nicht zu Spanisch oder Chinesisch sondern sind halbwegs verständlich Formuliert dieses Mal.

Und wirklich Vielen Dank für die Mühe die Ihr alle in meine Fragen steckt um sie zu klären.

Ich werde mich mal zuerst also dem Teil HEX Wert und deren Speicherung wie auch immer widmen bevor ich mich wieder dem
Verständnis AES und meiner Makro Datei widmen kann.

Gelöst noch nicht ganz, ABER, 100% verstehe ich dass meine Überlegung in eine Falsche Richtung gegangen sind.

Ich wünsche Euch alle einen ganz Speziell schönen Tag mit den Besten Grüssen aus Bern
Christian
Wer nicht fragt, der nichts lernt.
Wer keine Fehler macht, kann sich nicht verbessern.
Das Mysterium, ein wandelndes Lexikon. :mrgreen:

Wer Fragen zu meinem Textstil hat oder sich wundert über mich,
der darf seelenruhig mich direkt ansprechen. Ich beiße noch nicht.
Benutzeravatar
jacdelad
Beiträge: 404
Registriert: 03.02.2021 13:39
Wohnort: Riesa
Kontaktdaten:

Re: AES als Datei Container: Automatische Schlüsselgenerierung und Formatierung Fehler

Beitrag von jacdelad »

Hallo,
ich hab Nachtschicht und muss gleich nochmal weg, deshalb hab ich deinen Beitrag nur überflogen.

Also, zuerst eine Entschuldigung, mir ist schon wieder ein Fehler unterlaufen: IncludeFile/XIncludeFile wird verwendet um Dateien direkt in den Quelltext einzubinden. Damit kannst du deinen in mehrere, logiahce Blöcke aufteilen und er wir du ersichtlicher.
Was ich eigentlich an der Stelle meinte ist IncludeBinary. Damit wird eine Datei in eine DataSection übernommen und die kannst auf sie zugreifen, als wäre sie in den Speicher geladen worden (was sie bei Laufzeit ja auch wird). So kannst du Bilder, Musikdateien usw. einbinden, ohne dass die mit deinem Programm extern mitgeliefert werden müssen.

Des Weiteren kannst du natürlich jederzeit in deinem Programm einen Schlüssel erstellen. Nur kannst du ihn nicht während der Laufzeit in die DataSection speichern, das meinte ich. Die DataSection ist fix, da wird nie was verändert. Ich hab mich sicher etwas unbeholfen ausgedrückt. Also, erstelle deinen Schlüssel it welchen Verfahren auch immer, und speichere ihn dann irgendwo, damit du ihn immer wieder verwenden kannst.
Guten Morgen, das ist ein schöner Tnetennba!

PureBasic 6.21/Windows 11 x64/Ryzen 7900X/32GB RAM/3 TB SSD
Synology DS1821+/DX517, 130.9TB+50.8TB+2TB SSD
Benutzeravatar
TroaX
Beiträge: 684
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Linux Mint | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Linux Mint
Wohnort: NRW
Kontaktdaten:

Re: AES als Datei Container: Automatische Schlüsselgenerierung und Formatierung Fehler

Beitrag von TroaX »

Uhhh da ist aber viel Text :lol:

Ich möchte nur ein paar Kleinigkeiten zur Hilfe anmerken.

Die Include-Prozeduren IncludeFile, XIncludeFIle und IncludeBinary sind im Kern nur dazu da, deinen Code sinnvoll zu strukturieren (IncludeFile/XIncludeFile) und statische Daten in die Executable einzubetten (IncludeBinary). Zur Laufzeit deines Programms sind die Effekte dieser Prozeduren so gut wie nicht mehr (eigentlich garnicht) zu merken. Denn in der Produktivversion wird dein Tool ja nicht mehr kompiliert.

Schlüssel solltest du in der Regel nicht am Stück irgendwo ablegen. Weder im Executable noch in einer einzelnen Datei. Wenn die ver-/entschlüsselung ohne weitere Benutzereingaben erfolgen soll, solltest du nach Datenstücken auf dem System suchen, die nur schwer veränderlich sind und aus diesen den Schlüssel generieren. Aber dabei ist zu bedenken, das du sicherstellen musst, das auch in Worst-Case Szenarien eine gewisse Wiederherstellbarkeit der Daten möglich ist. Nutzt du zum Beispiel die GUID, kann es auf einem anderen System zu Problemen kommen, da der Schlüssel nicht mehr sauber hergeleitet werden kann.

Nutzt du den Systemnamen, bist du bereits nach dem Wechsel des selbigen gekniffen. Wie weit du dabei gehen willst, ist natürlich dir überlassen. Das einfachste wäre es, aus einem Passwort ein Schlüssel zu generieren. So arbeiten in der Regel ein Passwortmanager in der einfachsten Form. Setzt aber auch bei jeder Nutzung die Eingabe des Passworts voraus. Dafür kann z.B. ich ein und die selbe Passwortdatenbank auf allen meinen Endgeräten verwenden. Alternativ können dort aber auch Schlüsseldateien verwendet werden. Diese enthalten aber in der Regel nicht den fertigen Schlüssel, sondern wieder Daten, aus denen der endgültige Schlüssel hergeleitet werden kann. Dafür muss ich aber auch diese Schlüsseldateien zum einen sichern und zum anderen auf jeden Endgerät vorliegen haben. Wie das genau mit diesen Schlüsseldateien funktioniert, weiß ich aktuell auch nicht. Ist schon sehr lange her, das ich mich damit beschäftigt habe. Früher war das mal mit einem 256bit Block, der dann durch einer KDF-Routine erneut auf 256bit gehashed wurde. Aber wirklich sicher kommt mir das nicht vor. Wirkt für mich nach einem Schlüssel, der beim aufschließen nur etwas klemmt :D

Das ganze ist also grundsätzlich immer mit Kompromissen behaftet. Und du musst dir überlegen, wie weit du gehen willst. Denke immer daran. das beste Schloss hilft dir nicht, wenn du den Schlüssel direkt an den Türgriff hängst ;)
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Linux Mint
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Linux Mint
NAS: Fritz.Box 5690 Pro (Nur für Keepass-DB)
Coding: Purebasic, Spiderbasic, GDevelop, Javascript/Node
Benutzeravatar
ChrigiGee
Beiträge: 125
Registriert: 18.07.2024 12:14
Computerausstattung: Lenovo ThinkPad i7, 32GB Ram, 1TB SSD
PB 6.11 LTS, proGUI, IceDesigner
Wohnort: Bern

Re: AES als Datei Container: Automatische Schlüsselgenerierung und Formatierung Fehler

Beitrag von ChrigiGee »

Hallo Lieber jacdelad,

Absolut kein Problem, keine etwas Skurrile Fragestellung macht es vielleicht auch nicht einfacher.
Den Bereich mit Include Dateien ist mir klar geworden, sehr Praktisch, genau das war es, was ich erhoffte.
Elemente aus der Haupt Datei rausnehmen zu können der Übersichtlichkeit halber.

Wie man vielleicht unlängst an meinen Postings erkennt, ist meine Tendenz zu Unübersichtlichkeit extrem hoch.
Ich versuche es, jedoch gelingt es weder bei den Postings noch auf Basis des Source und da kommt es gelegen dass
ich auslagern kann. :mrgreen:

Nach einem Schweizer Natitional Feiertag mit böllerei, musste ich meine Versuche zum AES auf den Nachmittag verschieben.
So bin ich dann auch über den Bereich IncludeBinary gestossen, somit könnte man als Fauler Mensch eine bestehende Datei,
welche man weiss dass SIE nicht ändert und nicht "verschwindet" als Grundlage für einen Schlüssel verwenden.

Aber da es Heute etwas wenig Tag ist, verschiebe ich meine Bemühungen auf einen Tag wo ich mehr Zeit habe daran zu arbeiten.

Grundsatz habe ich begriffen, AES Schlüssel muss existieren bevor er verwendet wird.
Und sollte nicht zur Laufzeit generiert werden wen man in verwenden möchte.

So meine vereinfachte Erkenntnis damit man Probleme vermeidet.


Liebe Grüsse
Christian
jacdelad hat geschrieben: 01.08.2024 16:28 Hallo,
ich hab Nachtschicht und muss gleich nochmal weg, deshalb hab ich deinen Beitrag nur überflogen.

Also, zuerst eine Entschuldigung, mir ist schon wieder ein Fehler unterlaufen: IncludeFile/XIncludeFile wird verwendet um Dateien direkt in den Quelltext einzubinden. Damit kannst du deinen in mehrere, logiahce Blöcke aufteilen und er wir du ersichtlicher.
Was ich eigentlich an der Stelle meinte ist IncludeBinary. Damit wird eine Datei in eine DataSection übernommen und die kannst auf sie zugreifen, als wäre sie in den Speicher geladen worden (was sie bei Laufzeit ja auch wird). So kannst du Bilder, Musikdateien usw. einbinden, ohne dass die mit deinem Programm extern mitgeliefert werden müssen.

Des Weiteren kannst du natürlich jederzeit in deinem Programm einen Schlüssel erstellen. Nur kannst du ihn nicht während der Laufzeit in die DataSection speichern, das meinte ich. Die DataSection ist fix, da wird nie was verändert. Ich hab mich sicher etwas unbeholfen ausgedrückt. Also, erstelle deinen Schlüssel it welchen Verfahren auch immer, und speichere ihn dann irgendwo, damit du ihn immer wieder verwenden kannst.
Wer nicht fragt, der nichts lernt.
Wer keine Fehler macht, kann sich nicht verbessern.
Das Mysterium, ein wandelndes Lexikon. :mrgreen:

Wer Fragen zu meinem Textstil hat oder sich wundert über mich,
der darf seelenruhig mich direkt ansprechen. Ich beiße noch nicht.
Benutzeravatar
ChrigiGee
Beiträge: 125
Registriert: 18.07.2024 12:14
Computerausstattung: Lenovo ThinkPad i7, 32GB Ram, 1TB SSD
PB 6.11 LTS, proGUI, IceDesigner
Wohnort: Bern

Re: AES als Datei Container: Automatische Schlüsselgenerierung und Formatierung Fehler

Beitrag von ChrigiGee »

Hallo Lieber TroaX,

Hui, heute Antworte ich Dir viel ich hoffe meine Posts und Formulierungen werden in der nächsten Zeit auch etwas
weniger Text Lastig.

So dass es verständlicher wird......

Include begriffen unterdessen.
War mir über den Sinne nicht ganz im klaren.

Das mit einem Passwort ist mir bewusst, jedoch bei einem Kollegen,
für den ich da auch etwas am machen bin, und dieser zu Paranoia tendiert, ist das erstellen eines
eigenen Passwortes, nicht geeignet.

Am liebsten Wöchentlich ein neues Passwort. Und dann hätte ich bei den gespeicherten Dateien meinen Worstcase.

wenn ich ihm die Verwendung der Passwort erst gar nicht offeriere und die erstellten Dateien für andere nicht ersichtlich sind,
kann jemand die Datei nicht gegen Ihn verwenden und auch nicht eruieren was für Daten es sich handeln könnte.

Problematik, das mit dem Tressor Schloss und drei Schlüssel in der Bank schützt, ich aber die Schlüssel jede Nacht
an der Tressor Türe stecken lasse ist natürlich eine Einladung.

Was für eine Datei nehme ich um den Schlüssel zu generieren oder zu sein.
Wo ist diese Datei so dass sie nicht offensichtlich ist.

Echt gute Frage.
Eine Datei welche nicht von mir stammt wird schwierig zu garantieren dass sie nicht verändert wird.

Programm Ordner / Temp Verzeichnis sind wie der Schlüssel am Tressor.
Aber auch einen im ProgrammData / AppData abgelegten Order / Datei welcher offensichtlich mit meiner Anwendung zu tun hat
ist eine Freikarte zum Tressor öffnen.

Dennoch ProgrammData oder AppData wären wahrscheinlich der bessere Ort damit nicht gelöscht wird.
Datei Ordner / Name darf nicht in Verbindung zur eigentlichen Anwendung stehen so dass er beim suchen nicht gerade gefunden wird.

Da es sich im erste Projekt, "nur" um einen Makro Rekorder handelt, wäre der Verlust der Schlüssel weitaus weniger Kritisch.
Zum Schutze vor Paranoia ist eine verschlüsselte Datei welche die Steuerung der Maus und der Tasten speichert sicher von Vorteil.

Bei Anwendungen welche mehr Sicherheit erfordern und es erforderlich wäre den Datenbestand wiederherstellen zu können
Wäre meine Herangehensweise wohl Dilettantisch.

Worst-Case "Datenverlust" wäre in meinem Fall ganz klar gegeben.
In einem ersten Schritt des Makro Rekorder wäre das noch nicht die oberste Priorität, aber sicherlich
einen Punkt welcher man bei weitern Releases einbauen könnte / müsste.

Herzlichen Dank für Deine Einwände, welche mich soeben auch wieder angeregt haben darüber nachzudenken.
Christian

TroaX hat geschrieben: 01.08.2024 22:58 Uhhh da ist aber viel Text :lol:

Ich möchte nur ein paar Kleinigkeiten zur Hilfe anmerken.

Die Include-Prozeduren IncludeFile, XIncludeFIle und IncludeBinary sind im Kern nur dazu da, deinen Code sinnvoll zu strukturieren (IncludeFile/XIncludeFile) und statische Daten in die Executable einzubetten (IncludeBinary). Zur Laufzeit deines Programms sind die Effekte dieser Prozeduren so gut wie nicht mehr (eigentlich garnicht) zu merken. Denn in der Produktivversion wird dein Tool ja nicht mehr kompiliert.

Schlüssel solltest du in der Regel nicht am Stück irgendwo ablegen. Weder im Executable noch in einer einzelnen Datei. Wenn die ver-/entschlüsselung ohne weitere Benutzereingaben erfolgen soll, solltest du nach Datenstücken auf dem System suchen, die nur schwer veränderlich sind und aus diesen den Schlüssel generieren. Aber dabei ist zu bedenken, das du sicherstellen musst, das auch in Worst-Case Szenarien eine gewisse Wiederherstellbarkeit der Daten möglich ist. Nutzt du zum Beispiel die GUID, kann es auf einem anderen System zu Problemen kommen, da der Schlüssel nicht mehr sauber hergeleitet werden kann.

Nutzt du den Systemnamen, bist du bereits nach dem Wechsel des selbigen gekniffen. Wie weit du dabei gehen willst, ist natürlich dir überlassen. Das einfachste wäre es, aus einem Passwort ein Schlüssel zu generieren. So arbeiten in der Regel ein Passwortmanager in der einfachsten Form. Setzt aber auch bei jeder Nutzung die Eingabe des Passworts voraus. Dafür kann z.B. ich ein und die selbe Passwortdatenbank auf allen meinen Endgeräten verwenden. Alternativ können dort aber auch Schlüsseldateien verwendet werden. Diese enthalten aber in der Regel nicht den fertigen Schlüssel, sondern wieder Daten, aus denen der endgültige Schlüssel hergeleitet werden kann. Dafür muss ich aber auch diese Schlüsseldateien zum einen sichern und zum anderen auf jeden Endgerät vorliegen haben. Wie das genau mit diesen Schlüsseldateien funktioniert, weiß ich aktuell auch nicht. Ist schon sehr lange her, das ich mich damit beschäftigt habe. Früher war das mal mit einem 256bit Block, der dann durch einer KDF-Routine erneut auf 256bit gehashed wurde. Aber wirklich sicher kommt mir das nicht vor. Wirkt für mich nach einem Schlüssel, der beim aufschließen nur etwas klemmt :D

Das ganze ist also grundsätzlich immer mit Kompromissen behaftet. Und du musst dir überlegen, wie weit du gehen willst. Denke immer daran. das beste Schloss hilft dir nicht, wenn du den Schlüssel direkt an den Türgriff hängst ;)
Wer nicht fragt, der nichts lernt.
Wer keine Fehler macht, kann sich nicht verbessern.
Das Mysterium, ein wandelndes Lexikon. :mrgreen:

Wer Fragen zu meinem Textstil hat oder sich wundert über mich,
der darf seelenruhig mich direkt ansprechen. Ich beiße noch nicht.
Antworten