KodeZwergs TIniHelper Klasse

[hoika]

Hallo,
hm, abgesehen von der AES-Verschlüsselung sehe ich hier sehe ich nichts Neues?
Und 128 ist zu wenig, ich würde 192 nehmen.

[EWeiss]

Zitat von hoika:

Hallo,
hm, abgesehen von der AES-Verschlüsselung sehe ich hier sehe ich nichts Neues?
Und 128 ist zu wenig, ich würde 192 nehmen.

Es wäre vielleicht nicht schlecht wenn er sich mal Emil's TIniFormater Klasse ansehen würde.

gruss

[p80286]

Zitat von EWeiss:

Zitat von hoika:

Hallo,
hm, abgesehen von der AES-Verschlüsselung sehe ich hier sehe ich nichts Neues?
Und 128 ist zu wenig, ich würde 192 nehmen.

Es wäre vielleicht nicht schlecht wenn er sich mal Emil's TIniFormater Klasse ansehen würde.

gruss

Ich würde das gerne. Aber sowohl die eingebaute Suchfunktion sowie mein favorisierter Suchanbieter finden nichts bei "TIniFormater".

Gruß
K-H

[KodeZwerg]

Wenn ich AES196 fertig habe sagt der nächste wieder zu wenig -> 256 usw.

Kannst Du echt einen AES128 verschlüsselten Inhalt wieder lesbar machen ohne Ahnung vom Passwort zu haben?

Zitat:

[qDRo1pi]
Ot9XOsjjPG=LZ1eOpbfCbHDIs5qIMH9MdetS7CsLtDiIa5ZApH tTN5pDdOtH6usHb9DL3TNDbLMQ6nfSq5NJL9fLdXYJaXZIsL2J s97ULTYHqvqHMqpGNXwCrPORK4zFG

Bin gespannt wie ein Flitzeboden wer das obige Lesbar machen kann. Es ist nur ein Text, kein Binärkrams.
Erstellt mit meiner IniHelper Klasse.

Emils TIniFormater finde auch ich nicht, häng das doch, wenn es zum Thema passt, hier mit ran?

[SProske]

Zitat von hoika:

Hallo,
hm, abgesehen von der AES-Verschlüsselung sehe ich hier sehe ich nichts Neues?
Und 128 ist zu wenig, ich würde 192 nehmen.

Gibt es irgendeine (seriöse) Quelle, die erklärt, wieso AES128 "zu wenig" wäre?

[DieDolly]

Seriös weiß ich nicht. Aber lesenswert. AES 128 reicht vollkommen aus.
https://www.eetimes.com/document.asp?doc_id=1279619

[Daniel]

Seriös ist wohl das BSI und deren jeweils aktuelle Fassung der technischen Richtlinien für die Schlüssellängen:

https://www.bsi.bund.de/SharedDocs/D...cationFile&v=8


Ja, AES128 gilt derzeit noch als sicher. Wobei natürlich die Frage zu stellen ist, warum die Wahl ausgerechnet auf AES128 fiel. Wenn man heute schon etwas Neues startet und auch noch Wincrypt nutzt, dann kann man gleich die heute stärkste Variante nutzen. Kostet nicht mehr und wenn Datensicherheit tatsächlich von Bedeutung ist, fällt der mangelnde WindowsXP-Support auch nicht ins Gewicht.

//edit: Der EETimes-Artikel ist sechs Jahre alt. Eine derart alte Aussage über Sicherheit und Unsicherheit von Algorithmen auf die Gegenwart übertragen zu wollen, kann ein fataler Fehler sein.

[EWeiss]

Zitat:

Ich würde das gerne. Aber sowohl die eingebaute Suchfunktion sowie mein favorisierter Suchanbieter finden nichts bei "TIniFormater".

[Ironie]Es war eine Anspielung auf "KodeZwergs TIniHelper Klasse"[/Ironie]

Abgesehen von der AES-Verschlüsselung (deine Worte) sehe ich auch keinen Sinn darin eine Klasse zu erstellen die im Grundfundament schon besteht.
Siehe TIniFile!
Warum das Rad neu erfinden ohne wirklich fundamental Neues.

Und wenn schon dann sollte so etwas wie eine Funktion zum Formatieren einer IniDatei schon Enthalten sein.
Es macht schon sinn alleine der Lesbarkeit halber nicht alles Untereinander zu klatschen, zwischen den Section sollte schon eine Leerzeile stehen.

Meine einfache Funktion.. Nein keine Klasse warum auch geht auch anders.

Delphi-Quellcode:

type
  PParseFile = ^TParseFile;
  TParseFile = record
    Nr: Integer;
    Str: string;
    Ptr: PParseFile;
    Max: Integer;
  end;
//....
var
  LineStart: PParseFile;
  FPBuffer: PParseFile;
  FToPBuffer: PParseFile;
  nReading: Integer;
//...

{$REGION 'procedure FormatINI'}
procedure FormatINI(Filename: string);
var
  sBuffer: string;
  ParseFile: TextFile;
  StringList: TStringList;
  StringParse: string;

procedure AppendToLinkedList(nReading: Integer; sBuffer: string);
begin

  New(FPBuffer);

  if nReading = 0 then
  Begin
    New(FToPBuffer);
    LineStart := FToPBuffer;
    LineStart^.Nr := 0;
  end;

  FPBuffer^.Nr := nReading;
  FPBuffer^.Str := sBuffer;
  LineStart^.Max := FPBuffer^.Nr;
  FToPBuffer^.Ptr := FPBuffer;
  FToPBuffer := FPBuffer;
end;

begin
  StringList := TStringList.Create;

  Assignfile(ParseFile, Filename);
  reset(ParseFile);

  try
    try
      while not eof(ParseFile) do
      begin
        ReadLN(ParseFile, sBuffer);
        AppendToLinkedList(nReading, sBuffer);
        inc(nReading);
      end;
    except
      raise Exception.Create(SysErrorMessage(GetLastError));
    end;
  finally
    nReading := 0;
    CloseFile(ParseFile);
  end;

  FPBuffer := LineStart;
  while (FPBuffer.Nr <= LineStart.Max - 1) do
  begin
    FPBuffer := FPBuffer.Ptr;
    StringParse := LeftTrim(FPBuffer.Str);
    if Length(StringParse) <> 0 then
      StringList.Add(FPBuffer^.Str);

    if FPBuffer.Nr > 0 then
      if LeftStr(FPBuffer^.Str, 1) = '[' then
        StringList.Insert(StringList.IndexOf(StringParse), '');
  end;

  StringList.SaveToFile(Filename);
  StringList.Free;

  Dispose(FPBuffer);
  FPBuffer := nil;
  LineStart := nil;

end;
{$ENDREGION}

Geht bestimmt schöner aber ist meine art.

Aufruf nachdem die INI erstellt wurde.

Delphi-Quellcode:

var
  ConfigIni: TIniFile;
//...
FormatINI(ConfigIni.FileName);

gruss

[KodeZwerg]

Öhm... also der Grundgedanke war nicht das Rad (IniFiles.pas) neu zu erfinden, nur die Handhabung stark zu simplifizieren.

Vielleicht einmal global definiert, ab da nurnoch mit den einfachen Befehlen zum lesen/schreiben aufrufen.
Ob nun mit oder ohne Crypt sei mal dahingestellt.

Wenn ich alle Typen in der Klasse aufgenommen habe kommt weitere funktionalität hinzu, wie die Ausnutzung der MemIniFile Klasse um mehrere Dinge abarbeiten zu können ohne dauernd öffnen/schließen zu müssen und zu guter letzt System-Registry einbindung.

Ich schaue mich mal auf Gammatesters Seite nach Crypt Alternativen um und wie da so die Lizensen sind.
Oder ich lasse es komplett raus und biete lediglich Schnittstellen an damit jeder das Einbinden kann was er hat oder eben nichts.

Großprojekte wie DEC oder DPCrypt als Voraussetzung zu stellen ist ja auch nicht jedermanns Sache.

Eine Formatierung der .ini Datei werde ich mit Sicherheit erstmal nicht berücksichtigen da es mir schlicht weg egal ist.
Aber netter Gedanke.

Da das Projekt anscheinend abgelehnt wird bleibt es wohl dabei. Danke für Feedback.

[mkinzler]

Zitat:

Großprojekte wie DEC oder DPCrypt als Voraussetzung zu stellen ist ja auch nicht jedermanns Sache.

Besser als externe Abhängigkeiten. Oder man verwendet die direkte Unterstützung des Betriebsystems.