Nicht deklarierter Bezeichner beim DEC trotz eingeb. Units

[Die Muhkuh]

Hi,

ich binde die folgenden Units vom DEC ein:

DECCipher, DECHash, DECRandom, DECFmt, DECUtil Michael (aka Luckie) hat mal einen Weg gezeigt, wie man das DEC nutzen soll (ist leicht abgeändert, da ich keinen Salt nutze):

Delphi-Quellcode:

function TSomeClass.GetSomePW: string;
var
  Key: Binary;
begin
  with ValidCipher(ACipherclass).Create, Context do
  begin
    try
      Mode := ACipherMode;
      Key := ValidHash(AHashClass).KDFx('somepw', '', KeySize,
        TFormat_Copy, AKDFIndex);
      Init(Key);
      Result := DecodeBinary(FSomePW, TFormat_MIME64);
    finally
      Free;
      ProtectBinary(Key);
    end;
  end;
end;

Das nervige ist, dass mir Delphi z.B. bei Mode, KeySize, Init und DecodeBinary anzeigt, dass es nicht deklarierte Bezeichner sind. Kompilieren kann ich es allerdings einwandfrei. Das DEC ist brav in den Bibliothekspfad aufgenommen und auch die Code-Vervollständigung zeigt mir die Sachen wie Mode etc. an.

Woran könnte es liegen, dass diese dennoch rot unterkringelt werden?

Grüße

[negaH]

am Compiler bzw. der IDE (Parser) liegt es.

Er kann die with do Klausel nicht auflösen, und in dieser wurden zwei verschiedene Datentypen angesprochen. Einmal ein Objekt als Rückgabewert einer Funktion und danach ein Zugriff auf eine Methode -> .Context, die einen Record zurückgibt.

Im Grunde also ein gültiges Pascal Konstrukt das der Borland Parser eigentlich auch auflösen können muß. Da es aber ein sehr selten genutztes Konstrukt ist, wird wohl Borland dieses Feature nicht richtig getestet haben, oder gar, wenn dieser Fehler bei denen bekannt ist, nicht beseitigt haben auf Grund von Zeitmangel oder sonstwas.

Gruß Hagen

[Muetze1]

Moin!

Zitat von Die Muhkuh:

Woran könnte es liegen, dass diese dennoch rot unterkringelt werden?

Ignoriere diese unsinnige Funktion und deaktiviere sie. Diese Funktion übernimmt nicht alle Projekteinstellungen für seinen Hintergrundcompiler und ignoriert z.T. Environments in den Pfadangaben. Von daher einfach ignorieren oder besser noch deaktivieren.

Ich kann dir Units zeigen die komplett rot gekringelt werden aber einwandfrei compilieren. Dieses Feature ist noch weit von einer stabilen Funktionalität entfernt und bis dahin kann man sich definitiv nicht mal ansatzweise drauf beziehen.

MfG
Muetze1

[Die Muhkuh]

Hallo Hagen,

danke für die schnelle Antwort, aus der ich leider lese, dass es nicht möglich ist, das zu ändern bzw. das with do Konstrukt so umzuschreiben, dass es erkannt wird? Umschreiben geht, das ist klar, aber ob es dann noch "so sicher" wie mit dem with do ist, ist die andere Sache.

Muetze, wäre auch eine Möglichkeit, wobei es doch manchmal ganz praktisch ist.

[sx2008]

Zitat von Die Muhkuh:

... das with do Konstrukt zu umzuschreiben...

Das With-Statement ist ja schon ziemlich kritisch zu betrachten, da es einige Unsicherheit bringt, was eigentlich gemeint ist.
Auch bekannt als das "Goto der OOP".

Delphi-Quellcode:

// Beispiel
procedure TForm1.Test;
begin
  with Foo do
    Caption := 'Test';
  // auf welche Caption wird hier zugewiesen, die von Foo oder die von TForm1 ??
  // tja, kommt drauf an, ob Foo.Caption existiert
end;

Wenn man das With-Statement mit zwei Ausdrücken einsetzt, dann multiplizieren sich diese Unsicherheiten.
Bei drei Ausdrücken ist jeder Programmierer überfordert.
Hier die goldenen Regeln aus langjähriger Erfahrung:
* grundsätzlich das With-Statement nur sehr sparsam verwenden
* With nicht verwenden, wenn Unsicherheit über den Scope besteht
* niemals With-Statements schachteln
* niemals With in Verbindung mit zwei oder mehr Ausdrücken verwenden (sieht cool aus, bringt aber nur Verwirrung)

[Die Muhkuh]

Hi,

ich bin mir über die Verwendung des with-Statements durch aus bewusst und verwende dieses auch nicht, allerdings hat es einen Grund, warum man es beim DEC verwenden soll. Warum, kann ich Dir auf Anhieb nicht sagen, steht *irgendwo* hier im Forum.

Dennoch Danke

[negaH]

Das with do kann man natürlich auflösen, so wie es der Compiler dann bei der Compilation ja auch macht.

Delphi-Quellcode:

function TSomeClass.GetSomePW: string;
var
  Key: Binary;
  Cipher: TDECCipher;
begin
  Cipher := ValidCipher(ACipherclass).Create;
  try
    Cipher.Mode := ACipherMode;
    Key := ValidHash(AHashClass).KDFx('somepw', '', Cipher.Context.KeySize, TFormat_Copy, AKDFIndex);
    Cipher.Init(Key);
    Result := Cipher.DecodeBinary(FSomePW, TFormat_MIME64);
  finally
    Cipher.Free;
    ProtectBinary(Key);
  end;
end;

Das ist alles. Es gibt ürbigens keinen technisch relevanten Grund aus Sicht des DECs das man unbedingt mit der with do Konstruktion arbeiten muß. Es ist einfach eine Stilfrage des Programmierers.

With do ist kein "Goto der OOP", diese Aussage halte ich für falsch, da dann die Auflistung von Units in den USES Klauseln ebenfalls ein "Goto der OOP" wären. So wie die Reihenfolge der Units in der USES Klausel bestimmte Abhängigkeiten der in den Units deklarierten und doppeltdeutigen Typen mit sich bringt tut es auch das WITH DO Konstrukt.

Wenn nun der Programmierer nicht geschlampt hat, bzw. sein System exakt konsturiert hat dann besteht mit WITH DO keinerlei Gefahr, und so ist es auch in diesem speziellen Fall. Der Cipher und Cipher.Context innerhalb der WITH DO Klausel sind Teile des gleichen Objekttypes, der gleichen Unit, und es wurde sichergestellt das es darin keine Doppeldeutigkeiten in den Benamungen der Typen, Objektfelder, Recordelemente gibt.

Bedenklicher an diesem geänderten Source ist das Weglassen des zufällig gewähltem Salt, da es die Funktionalität und somit kryptographische Sicherheit stark beeinflußt. Aus Sicht der Kryptographie ist die Anwendung der KDF ohne Salt im Vergleich zu mit Salt, nur mariginal stärker als komplett ohne KDF zu arbeiten. Die KDF hat 2 Aufgaben:
1.) Schutz des Passwortes vor dem "Zurückrechnen" aus einem so erzeugten Sessionkey
2.) Randomisierung des Sessionkeys um sicherzustellen das der Cipher mit gleichen Passwort immer ein anderen Sessionkey benutzt und somit die Erhöhung der Sicherheit des Ciphers bzw. dessen verschlüsseltem Output

Ohne Salt träfe bedingt nur noch Punkt 1.) zu. Bedingt deshalb weil man mit speziellen offline Brute Force Angriffen wie die Rainbow Tabellen sehr wohl diesen Schritt 1.) effizient angreifen kann. Würde man aber einen zufälligen Salt benutzen so ist auch 1.) sicher vor diesen Angriffen. Also auch Punkt 1.) wird durch das Fehlen des Salts in der Sicherheit stark reduziert.

Aus meiner Sicht heraus ist also das Weglassen des zufälligen Salts ein grober konzeptionell-kryptograpischer Fehler. Man kann eine OpenGL 3D Vektor Berechnung für Grafiken aus performancegründen in der Exaktheit/Genauigkjeit ohne Probleme reduzieren, das geht mit fast allen Aufgaben der Informatik, aber in der Informatik der Kryptographie ist das eine absolut falsche Herangehensweise. Und das erst recht wenn dieser Salt nur 5% des Gesamtaufwandes darstellen aber die Sicherheit ver-2^128'facht, also nicht 100% oder 1000% oder Millionen Prozent mehr Sicherheit bringt sondern 2^128 mal sicherer wenn man mit 128 Bit Kryptographie arbeitet.

Es besteht also alle Notwendigkeit, gerade auch vom Aufwand-Nutzen-Verhältnis betrachtet den Salt nicht zu entfernen.

Gruß Hagen

[Die Muhkuh]

Hallo Hagen,

danke für Deine ausführliche Antwort. Ich hatte den Salt eigentlich weggelassen, weil das Passwort in einer XML-Datei gespeichert wird und diese nicht weitergegeben wird. Es geht nur drum, dass man auf der lokalen Platte das Passwort nicht im Klartext lesen kann.

Wobei der Salt ja wieder recht schnell eingebaut ist (wie Du schon sagtest), müsste diesen halt nur noch in der XML-Datei mit abspeichern.

Es geht mir nicht drum, dass es "100%" kryptographisch sicher ist, sondern nur, dass man das Passwort nicht lesen kann. Eine einfache XOR-Verschlüsselung würde demnach also auch reichen. *g*

[negaH]

Gerade wenn es ein verschlüsseltes Passwort ist sollte man es möglichst gut schützen, besonders wenn der nötige Mehraufwand im Vergleich zur Sicherheit die man gewinnt so dramatisch gering ist. Benutzt du dieses in der XML so geschützte Passwort als Schlüssel zur Verschlüselung anderer Daten sollte auch dort mit einem Salt gearbeitet werden. Wenn man ohne diesen Salt arbeitet und mit zu verschlüsselenden Nachrichten arbeitet die selber feste Header enthalten oder sogar identisch sind dann wird der verschl. Output immer gleich sein, da ja Nachricht und Schlüssel immer gleich sind. Sowas ermöglicht dann einen Haufen Angriffe die man mit Salt einfach unmöglich machen könnte.

Also, immer mit Salts und KDFs den Key in einen pseudozufälligen Sessionkey umwandeln, egal ob das Passwort nun in einer XML gespeichert wurde oder nicht, besser natürlich nicht speichern.

Eine Ausrede wie "ich möchte es nicht 100% sicher" zeugt gelinde gesagt nur von Unwissenheit. Entweder möchte man was elektronisch schützen oder man lässt es. Möchte man was schützen dann kann man dies aber nur im Rahmen mathematisch beweisbar sicherer Kryptographie. Geht man nicht diesen Weg, zb. weil man XOR benutzt, dann reden wir eben nicht mehr von Kryptographie und man könnte diese Pseudotricks auch gleich ganz bleiben lassen. Sowas übersteht im Ernstfall, also wenn ein Profi Interesse daran hat, nur 2 Stunden. Das Ziel dieser Kryptographie ist es immer mit verhältnismäßig geringstem Aufwand das Leben eines Angreifers unendlich schwer zu machen. Und vergleicht man den Aufwand eines Angreifers bei richtig angewendeter Kryptographie zu zb. einen Delphi Source der das DEC benutzt so trifft dies auch zu.

Nun gilt aber auch noch das es garkeine 100% sichere und praktische Kryptographie gegen kann. Nichts ist also 100% sicher, aber heutige Verfahren sind aus sicht des Machbaren zu 99.9....9% sicher. Entscheidend ist aber das Verhältnis dieser Sicherheit zu zb. abgespeckten Verfahren oder gar XOR Verfahren. Diese sind dann meinstens nicht mal 0.00000....1% sicher. Mit ein par Sourcezeilen mehr entscheidet man also über eine "Alles oder Nichts" Frage.

Übrigens das Problem bei deinem Verfahren ist nicht das in der XML gespeicherte Passwort sondern das hardcoded Passwort innerhalb deiner Software das zur Verschlüsselung des XML Passwortes dient. Und diese objektive Sichtweise verändert auch gleichmal konzeptionell die Kryptoanalyse. Denn wenn man dieses XML Passwort richtig schützt und der Angreifer hat nicht die Software sondern nur die XML Daten so wird es sicher sein. Das ist weit mehr Sicherheit als wenn man dieses XML Passwort eben nur mit XOR oder abgespeckten Verfahren schützt. Denn dann ist die Wahrscheinlichkeit das man ohne Software und nur den XML Daten dieses Passwort knacken kann weitaus größer.
Hat der Angreifer aber Zugriff auf diese Software so kann er ein XML Passwort auch sofort knacken durch Reverse Engineering der Software. Wurden aber nun sehr viele Daten mit unterschiedlichen XML Passwörtern verschlüsselt, und zwar korrekt mit Salt usw., dann inkrementiert sich denoch der Aufwand für den Angreifer. Denn er braucht Zugriff auf alle XML-Daten zu diesen verschlüsselten Dateien die er ja knacken möchte. Also auch die Benutzung der veschl. XML-Passwörter als Schlüsel sollte kryptographsich richtig erfolgen um das Gesamtsystem bestehend aus vielen Benutzern mit vielen verschlüsselten Daten sicherer zu machen.

Wie man sieht muß man bei der Kryptoanalyse das Gesamtsystem betrachten und deshalb ist es so schwierig die Frage "wie sicher ist DECs AES Rijndael wenn ich diesen so oder so benutze" zu beantworten wenn man das Gesamtsytem in dem es als Teil benutzt wird nicht kennt. Man kann aber sehr wohl eine Vorgehensweise bei der Benutzung dieser Verfahren empfehlen die mit großer Wahrscheilnlichkeit immer sicher sein wird wenn man sie im Gesamtssystem auch richtig einbaut. Und das ist eben die Benutzung von Salts + KDFs zur Erzeugung von Sessionkey.

Deine Aussage "man hätte das XML Passwort auch nur verstecken können" hat also weitreichende Konsequenzen innerhalb des Gesamtsytemes, es ermöglicht dann eben das Knacken von Benutzerdaten mit für den Angreifer leichter verfügbaren Datenquellen und dekemntiert somit die Gesamtsicherheit aller Benutzer und deren Daten. Kryptoanalysiert man also den Fakt das deine Software ein hardcoded Passwort benutzt so heist dies nicht autom. das nun das Gesamtsystem sofort absolut unsicher wäre und man deshalb von Vornherein alles hinschlampen kann.

Gruß Hagen

[Die Muhkuh]

Hallo Hagen,

nochmal herzlichen Dank für Deine ausführliche Antwort!

Trotzdem muss ich noch mal feststellen, dass es mir nicht drum geht, es 100% sicher zu haben, was ja auch nicht funktioniert, wie Du geschrieben hast.

Sache ist folgende: Der Benutzer legt ein neues Projekt an und gibt die Daten für sein FTP-Account ein, darunter eben auch sein Passwort. Diese Daten werden dann in der Datei project.xml abgespeichert, die niemals weitergegeben werden muss. Wenn es nach mir ginge, würde ich das Passwort auch nicht verschlüsseln, aber dann kommt nicht lange später ein DPler angerannt und meint, dass es nicht gut ist, wenn ich es im Klartext speichere, deswegen "reicht" mir eine "Pseudosicherheit". Du brauchst jetzt nicht zu sagen, was Du eh schon getan hast, entweder richtig oder gar nicht, das ist soweit klar. Die Projektdatei ist nur dafür da, ein paar Daten zusammen zu halten. In der Datei, die dann später verteilt werden soll, stehen diese FTP-Daten sowieso nicht mehr drin. Diese sind nur relevant für den Erzeuger des Projekts, da er die Möglichkeit haben soll, die Daten auf seinen FTP-Server zu laden.

Wie dem auch sei, werde ich mir morgen die Sache mit dem Salt noch mal anschauen, ich hatte es heute nachmittag noch versucht, allerdings noch Probleme beim Abspeichern in der XML, da mir die Meldung "Invalid character in text" an den Kopf geworfen wurde.

Schönen Abend noch!