Re: Eure Anregungen für das DEC 5.3 gebraucht
Zitat:
Hier wird nur ausgesagt, daß der Datenstrom in einer bestimmten Art mit 32/64 Zeichen dargestellt wird. Welche Zeichen verwendet werden und wie die Endemarkierung vorgenommen wird (es werden ja immer Guppen zu 3 Bytes umkodiert, aber was ist, wenn der Datenstrom am Ende nur 1 oder 2 Byte hat) Mime32/Mime64 ist eine Unterart von Base32/Base64, wo auch noch festgelegt ist, welche Zeichen verwendet werden und wie der Abschluß aussieht. Also Korrekt wäre es, wenn es es eine Base32-Klasse gibt, von welcher die Mime32-Klasse abgeleitet ist, in welcher nur der Zeichensatz und die Endebehandlung geändert/behandelt werden. |
Re: Eure Anregungen für das DEC 5.3 gebraucht
Hallo,
Zitat:
Zitat:
Die alten Encodings laufen nun alle, sprich: Base16 (HEX), Base16L (HEX Lowercase), DEC MIME32, Base64, Radix-64 (PGP Base64 mit 24-bit CRC), UU, XX und ESCAPE Encoding sind wieder lauffähig :-D Die Cipher und Utils sind auch nahezu fertig. Jetzt kommt noch Base32, Base32hex und dann ca. 1-2 Wochen Self-Tests Vektoren aufsetzen, UnitTests, Demos etc. Ich hatte auch schon einen Monte Carlo Test für Rijndael fertig (ja, die DEC besteht diesen natürlich) - mal sehen ob ich den noch mit als extra Test reinbekomme. Da jetzt alles auf Bytes arbeitet, wird es einen neuen Wrapper zum kombinieren von Salt, Data und MAC geben. Ebenso einen Splitter für das Decoding. Das sollte die Nutzung mit früherem Code erleichtern. Für normale Strings bleibt, soweit ich es überblicken kann, alles gleich. Das ganze war bisher ziemlich aufwendig... Sehr vereinfacht gesagt, mußte für die Umstellung auf Byte Encoding und echte Unicode-Unterstützung (ohne auf Benutzerseite "* SizeOf(Char)" machen zu müssen) der ganze Code angefasst werden und die Zusammenarbeit zwischen den Teilbereichen angepasst werden. Zusätzlich war meine Voraussetzung für die Änderungen, dass keine Duplizierung von Plaintext-Daten im Speicher erfolgen darf, da dies die Sicherheit kompromitieren könnte. Dieses Ziel ist nun erreicht - wie Hagen in einem früheren Thread mal sinngemäß sagte: Diese Umstellung ist viel Arbeit und wenn man es macht, muß man große Brötchen backen ;) Bisher läuft alles gut, aber ich werde noch einige Tests mit altem Code machen müssen, um sicherzustellen das Daten aus der DEC 5.1, 5.2 und 5.3 kompatibel zueinander sind. Da die meisten DEC Anwender wohl ohne Salt, Key Derivation / Mask Generation und MAC unterwegs sind, wird es auch einen Wrapper geben der dies automatisch und anpassbar erledigt. Das soll Anfängern den Einstieg erleichtern. Gruß, Assertor P.S.: @taaktaak - Es kommt immer auf das Hobby an ;) |
Re: Eure Anregungen für das DEC 5.3 gebraucht
PS: bei so großen Änderungen ... warum dann nicht DEC 6.0 ?
|
Re: Eure Anregungen für das DEC 5.3 gebraucht
Hallo Himitsu,
Zitat:
Eigentlich bin ich kein Freund von inflationär gebrauchten Versionsnummern. Dafür sollte es schon immer einen guten Grund geben, z.B. ein Rewrite. Wobei, je länger ich darüber nachdenke, die Idee mit DEC 6.0 gefällt mir :thumb: So gesehen ist es ein "kleiner Rewrite". Und man kann man schnell unterscheiden, wenn eine Frage kommt (kenne das ja von Indy, da sagt jemand er nutzt 10.5.7 und stellt eine Frage mit Codeauszug aus 10.2.5). Gruß, Assertor |
Re: Eure Anregungen für das DEC 5.3 gebraucht
Zitat:
|
Re: Eure Anregungen für das DEC 5.3 gebraucht
Hallo,
habe soeben ein D5 Projekt auf D2009 umgestellt. Dabei habe ich erst an der DEC-5.1 rumgefummelt, bis ich dann die Dec-5.2 gefunden habe. Mit zwei Fehler habe ich mit zu kämpfen gehabt. 1) Zu erst waren alle Identity gleich (in der 5.2 wohl gelößt). Doch ich konnte es auch in der 5.1 zum laufen bringen, indem ich die Procedure CRCTab in eine Konstante umsetzte.
Code:
Die Procedure CRCTab erinnerte mich an meine Assembler Zeiten vor 30 Jahren. Daten in Code zu speichern wurde nicht richtig umgesetzt. Auch sollten wohl bald Daten und Code sauber getrennt sein, so das ich es in der 5.2 für mich geändert habe.
const
CRCTab : TCRCTab = ( (Poly:$000000D1; Bits:8; Init:$00000000; FInit:$00000000; Inverse:true), // CRC_8 GSM/ERR (Poly:$00000233; Bits:10; Init:$00000000; FInit:$00000000; Inverse:true), // CRC_10 ATM/OAM Cell (Poly:$0000080F; Bits:12; Init:$00000000; FInit:$00000000; Inverse:true), // CRC_12 (Poly:$00008005; Bits:16; Init:$00000000; FInit:$00000000; Inverse:true), // CRC_16 ARC;IBM (Poly:$00001021; Bits:16; Init:$00001D0F; FInit:$00000000; Inverse:false), // CRC_16 CCITT ITU (Poly:$00008408; Bits:16; Init:$00000000; FInit:$00000000; Inverse:true), // CRC_16 XModem (Poly:$00864CFB; Bits:24; Init:$00B704CE; FInit:$00000000; Inverse:false), // CRC_24 (Poly:$9DB11213; Bits:32; Init:$FFFFFFFF; FInit:$FFFFFFFF; Inverse:true), // CRC_32 (Poly:$04C11DB7; Bits:32; Init:$FFFFFFFF; FInit:$FFFFFFFF; Inverse:true), // CRC_32CCITT (Poly:$04C11DB7; Bits:32; Init:$FFFFFFFF; FInit:$00000000; Inverse:true) // CRC_32ZModem ); 2) Alte Daten konnte ich nicht mehr einlesen, da die Identity geändert haben. Schuld war die geänderte Erzeugung der Indentiy nun ein widestring mit 512 Bytes und damals ein ansistring mit 256 Bytes. Klar das die dann unterschiedlich sein muss. Für mich habe ich das dann so geändert:
Code:
Da der Classname sicher ohne Fehler auf AnsiString abzubilden ist, wäre das kein Problem das so zu machen. Da aber die 5.2 mit widestring geht, sollte man dies mit einer Compilerdirektive in der Source machen. Dass man das sogar programmiertechnisch macht, um alte und neue Dateien zu lesen, ist wohl ein größere Aufwand.
class function TDECObject.Identity: LongWord;
var Signature: AnsiString; begin Signature := AnsiString(StringOfChar(#$5A, 256 - Length(Classname)) + UpperCase(ClassName)); Result := CRC32(IdentityBase, Signature[1], Length(Signature)); end; Gruß Thomas |
Re: Eure Anregungen für das DEC 5.3 gebraucht
Zitat:
Ich denke nicht, das es ein Identity Problem geben müsste. |
Re: Eure Anregungen für das DEC 5.3 gebraucht
@Findus: Ich wollte damit nur sagen: Wenn es bekannte Probleme oder Ideen zur Verbesserung gibt, wozu aber eine größere Änderung nötig wäre, dann wäre ein Versionswechsel zumindestens ein guter Zeitpunkt. :angel2:
PS: MD5 und GUID sind gleich groß, also falls die Identity geändert wird, dann könnte man schon das TGUID als Typ verwenden und wie die 128 Bit nun berechnet werden, daß ist ja erstmal egal. Aber 128 Bit böten einen größeren Spielraum, gegenüber den aktuellen 32 Bit (für Identity). |
Re: Eure Anregungen für das DEC 5.3 gebraucht
Zitat:
Das wurde von mir so angedacht aber niemals bis zu Ende implementiert. Und das hat auch einige Gründe. Kryptographisch gut wäre diese Lösung nämlich nicht. 100% vor cleveren Manipulationen wird sie auch nicht schützen. Deswegen CRC so belassen wie es war und die finalen Prüfungen nicht weiter implementiert. So bleibt wenigstens das Feature das man diese BSS-Konstanten, auf Grunde des Schreibschutzes des CRC Codes im Speicher, als echte schreibgeschützte Konstanten benutzt, und so unabsichitliche Änderungen dieser Konstanten verhindert. Gruß Hagen |
Re: Eure Anregungen für das DEC 5.3 gebraucht
Hallo Leute,
Erst mal vielen Dank für die tolle Arbeit an DEC. Ich nutze die Komponente schon lange und würde sie gerne weiter einsetzten. Ich weiß nicht ob das hier die richtige Stelle ist, aber ich hab da mal ne Frage zu einer Portierung von D2007 -> D2010. Ich habe bis D2007 die DEC Version 3.0 eingesetzt und bin mit der Portierung auf D2010 auf die DEC Version 5.2 umgestiegen. Ich habe nun ein Problem bei der Dekodierung von Dateien die mit der 3.0 Version Blowfish-Verschlüsselt wurden. Die letzten Bytes einer DEC 5.2 Verschlüsselung unterscheiden sich von der DEC 3.0 Verschlüsselung. Ich habe das Problem auf die folgenden Stellen im Quellcode zurückgeführt:
Delphi-Quellcode:
Ich habe DEC 3.0 und DEC 5.2 verglichen und mit der Modifikation "MyEncodeCFS8" funktioniert es wieder.
procedure EncodeCTSx(S,D: PByteArray; Size: Integer);
var I: Integer; begin Dec(Size, FBufferSize); I := 0; while I <= Size do begin XORBuffers(S[I], FFeedback[0], FBufferSize, D[I]); DoEncode(@D[I], @D[I], FBufferSize); XORBuffers(D[I], FFeedback[0], FBufferSize, FFeedback[0]); Inc(I, FBufferSize); end; Dec(Size, I - FBufferSize); if Size > 0 then begin // padding //EncodeCFS8(@S[I], @D[I], Size); -------original code MyEncodeCFS8(@S[I], @D[I], Size); //my modification FState := csPadded; end else FState := csEncode; end; procedure EncodeCFS8(S,D: PByteArray; Size: Integer); // CFS-8, CTS as CFB var I: Integer; begin I := 0; while I < Size do begin DoEncode(FFeedback, FBuffer, FBufferSize); D[I] := S[I] xor FBuffer[0]; Move(FFeedback[1], FFeedback[0], FBufferSize -1); FFeedback[FBufferSize -1] := FFeedback[FBufferSize -1] xor D[I]; Inc(I); end; FState := csEncode; end; procedure MyEncodeCFS8(S,D: PByteArray; Size: Integer); begin Move(FFeedback[0], FBuffer[0], FBufferSize); DoEncode(FBuffer,FBuffer,FBufferSize); XORBuffers(S[0], FBuffer[0], Size, D[0]); XORBuffers(FBuffer[0], FFeedback[0], FBufferSize, FFeedback[0]); FState := csEncode; end; Mein Problem ist das ich nicht wirklich verstehe warum das so ist. Kann mir da jemand weiter helfen? Gruß Malcolm |
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:59 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz