Hilfe, die Verschlüsselungs Algorithmen spielen mit mir...

[Kedariodakon]

So habe jetzt mal ein kleines Problem... :freak:

Habe mit dem Delphi Encryption Compendium & mit der DCPcrypt Cryptographic Component Library v2 Beta 3 gearbeitet und habe Texte mit verschiedenen Algorithmen decryptiert und enryptiert... :coder:
Aber bei den, die ich getestet hab, kommen andere Ergebnisse raus, sprich Sie sind untereinander nicht kompatiebel... :gruebel:

Aber müsten die doch oder?
Sie nutzen doch alle den selben Algorithmus und bei gleichem Key = gleiches Ergebniss... :nerd:
Aber irgendwie nicht...

Dann hab ich mit "CrypTool" Datein verschlüsselt, aber der bekommt trotz gleichem Schlüssel wieder was ganz anderes raus... :wall:

Nu bin ich am verzweifeln... :pale:

Kennt Noch wer Tools, Libarys, Komponenten oder Verschlüsselungs Programme, wo ich direkt den Schlüssel eingeben kann, ohne Hashen des Schlüssels & Co? :roll:

Verschlüsselungsverfahren: Twofish, Rijndael (AES), RC2- RC6, IDEA, Blowfish, Cast-128 & Cast 256... :warn:


Bye

[jim_raynor]

:wiejetzt:

Unterschiedliche Verschlüsselungen bedeuten unterschiedliche Ergebnisse bei gleichem Schlüssel.

Wenn alle zum gleichen Ergebnis führen würden, braucht man doch nicht verschiedene Algorithmen :gruebel:

[Kedariodakon]

:wiejetzt:

Wenn ich mit Hilfe von 2 Quellen und einem Tool eine Datei mit dem Twofish-Algorithmus mit einem (einzigen & gleichem :zwinker: ) 256Bit Key decryptiere, müsste 3 mal das selbe rauskommen und jedes müsste das vom anderem wieder Encryptieren können :warn:

Tuts aber net...
Rauskommt bei Jedem was anderes... :gruebel:

Allein unter sich selbst decoden & encoden sie ja richtig, nur gemischt machen sie es nicht und das ist ja das Problem... :hi:



Bye

[Nuclear-Ping]

Zur Verständnisverbesserung:

• Du hast Tool A und Tool B
• Tool A verwendet Twofish und Tool B ebenfalls
• Wenn du mit Tool A Daten ver- und entschlüsselst, stimmen die Ergebnisse
• Ebenfalls stimmen die Ergebnisse, wenn du mit Tool B Daten ver- und entschlüsselst
• Allerdings stimmt es nicht mehr, wenn du mit Tool B Daten entschlüsselst, die du vorher mit Tool A verschlüsselt hast
• Und umgekehrt stimmt es ebenfalls nicht mehr, wenn du mit Tool A Daten entschlüsselst, die du vorher mit Tool B verschlüsselt hast

Korrekt?

Grüße,
Mario

[Kedariodakon]

:coder2: GENAU

Aber zu Tool A & Tool B kommt noch Tool C..

Dec&Enc mit Tool A geht, Dec&Enc mit Tool B geht und Dec&Enc mit Tool C geht...

Aber untereinander gehen sie nicht... :coder: ---> :freak:


Tool A und Tool B habe ich selber gebaut:
- Tool A mit der Delphi Encryption Compendium http://www.luckie-online.de/Delphi/I...gen%20Reddmann
- Tool B DCPcrypt Cryptographic Component Library v2 Beta 3 http://www.cityinthesky.co.uk

Tool C (CrypTool) hab ich herruntergeladen http://www.cryptool.de

Alle nutzen den selben Schlüssel & den selben Algorithmus (oder sollten zumindest :zwinker: )


Bye

[Sharky]

Hai,

es wäre ja möglich das die Komponente für "Tool B" und das Programm "Tool C" noch ein hardcodiertes Passwort mit dem von dir eingegebenen kombinieren.

[Kedariodakon]

Zitat:

Zitat von Sharky

Hai,

es wäre ja möglich das die Komponente für "Tool B" und das Programm "Tool C" noch ein hardcodiertes Passwort mit dem von dir eingegebenen kombinieren.

Würde ich aber bei Verschlüsselungs Libarys für unsinnig deklarieren, denn die sollen ja nach dem verschlüsseln was ich den sage und nicht noch eigennen Mist mit einbauen...

Aber nichtsdesto trotz schau ich schon danach...

Aber Tool C macht das nicht...
Selbstgeschriebenes Programm A auch nicht ( Soweit ich das verfolgen konnte... )

Bei B bin ich mir nicht sicher, analysiere noch :coder:
Ich glaub Hagen Reddmanns Routinen hashen den Key standardmäßig, wenn nichts angegeben nochmal mit RipeMD256 und nehmen dann den gehashten Wert als Key (bei Twofish zumindest)...

Aber wenn ich das Mit Programm A simmuliere, stimmt das Ergebniss trotzdem nicht...

Also geht die Suche weiter...
Ich glaub wenn ich gar nicht mehr weiter weiss, schreib ich die Authoren mal an um Infos zu bekommen, aber da bekommt man selten eine Antwort... :roll:


Bye

[mirage228]

Hi,

vielleicht hilft Dir mein Twofish Verschlüsselungsprogramm weiter => http://www.delphipraxis.net/internal...ect.php?t=6648. Das verwendet auch 256 Bit Keys und die TwoFish Komponente von http://www.crypto-central.com/index.html.

Vielleicht findest Du damit Gemeinsamkeiten / Unterschiede bei der Verarbeitung.

mfG
mirage228

[sakura]

Zitat:

Zitat von Kedariodakon

Ich glaub wenn ich gar nicht mehr weiter weiss, schreib ich die Authoren mal an um Infos zu bekommen, aber da bekommt man selten eine Antwort... :roll:

Warte mal ab, eventuell schaut Hagen Reddmann aka negaH noch heute hier vorbei und hilft Dir ;-)

...:cat:...

[Kedariodakon]

@mirage228
Das sieht ganz interessant aus, ich werd mir das nachher mal anschauen :thumb:

@sakura
Ich denke mal von ihm würde ich schon Fragen beantwortet bekommen, aber bei den anderen Komponenten sieht das schwieriger aus...

Bye

[negaH]

Du benutzt beim DEC die Methode .InitKey() zum Schlüsselsetup. Wird das Password mit dieser Methode oder direkt im Contructor .Create() des Ciphers übergeben so wird intern mit Hilfe einer Hashfunktion ein SessionKey berechnet. Dies ist sicherer aber eben auch inkompatibel. Das Schlüsselsetup als solches ist in diesen Punkten nicht Standardisiert.

Damit nun mit dem DEC absolut Standard konforme Verschlüsselungen möglich sind musst du
1.) den Cipher Mode -> Property Cipher.Mode, auf einen Standard Modus wie cmCBC, cmECB, cmCFB oder cmOFB setzen.
2.) Methode .Init() zum Setzen des Passwortes benutzen
3.) eventuell bei .Init() auch einen InitVector mit übergeben.

Nur wenn ALLE drei Punkte in jedem Tool identische Verfahren und Daten benutzen ist sichergestellt das sie auch identische Werte liefern müssen.

Ich persönlich habe DEC auch mit DCPCrypt verglichen und auf Kompatibilität getestet.

Ein spezielles Problem bleibt aber bestehen: Twofich in der offizielle DEC Part 3 Version hat einen klitzekleinen Bug im KeySetup.

DEC benutzt standardmäßig dem Cipher.Mode := cmCTS. cmCTS ist eine Entwicklung von mir, die sicherer als der Standard cmCBC ist. Ein fast identisches Verfahren wie mein CTS wurde in der AES Ausschreibung von Belgischen Cryptoexperten als Ersatz für CBC vorgeschlagen. Da aber CTS kein offizieller Standard ist (wobei es eigentlich bis heute überhaupt keinen offiziellen Standard gibt ;)) kann DCPCrypt oder andere Tools garnicht kompatibel zum DEC sein.

Wie gesagt, eine einfache Aussage wie "alle nutzen Twofish" also müssen sie gleiche Resultate erzielen ist falsch. Es gibt zu viele weitere Einstellungen die unterschiedlich sein könnten.

Ein weiteres Problem entsteht bei vielen Cipher die unterschiedliche Schlüssellängen und Rundenanzahlen unterstützen. Twofisch ist so ein Kandidat. Um also kompatibel zu werden müssen folgende Punkte abgeklärt werden:
1.) Schlüssellänge
2.) Rundenanzahl oder andere Ciphrspezifische Einstellungen
3.) Cipher Block Modus
4.) Cipher Block Size
5.) Schlüssel Preprocessing
6.) Padding Schemata
7.) Init Vector
8.) Daten Formatierung vor & nachher

Gruß Hagen

[Kedariodakon]

Zitat:

Zitat von negaH

1.) den Cipher Mode -> Property Cipher.Mode, auf einen Standard Modus wie cmCBC, cmECB, cmCFB oder cmOFB setzen.

Ok das war mein Erster Fehler...
Da waren Unterschiedliche Modis drin...

Zitat:

Zitat von negaH

2.) Methode .Init() zum Setzen des Passwortes benutzen

Hab den übergebenen Hash Key direkt per Debugger im Speicher geändert
Wuste mir da keine andere Lösung ohne Viel Arbeit :wink:

Zitat:

Zitat von negaH

3.) eventuell bei .Init() auch einen InitVector mit übergeben.

Ka für was das ding gut ist...
hatte bei beidem Nil übergeben ^^

Zitat:

Zitat von negaH

Ich persönlich habe DEC auch mit DCPCrypt verglichen und auf Kompatibilität getestet.

Lass mich raten es war kompatibel? :zwinker:

Zitat:

Zitat von negaH

Ein spezielles Problem bleibt aber bestehen: Twofich in der offizielle DEC Part 3 Version hat einen klitzekleinen Bug im KeySetup.

Das heißt?

Zitat:

Zitat von negaH

DEC benutzt standardmäßig dem Cipher.Mode := cmCTS. cmCTS ist eine Entwicklung von mir, die sicherer als der Standard cmCBC ist. Ein fast identisches Verfahren wie mein CTS wurde in der AES Ausschreibung von Belgischen Cryptoexperten als Ersatz für CBC vorgeschlagen. Da aber CTS kein offizieller Standard ist (wobei es eigentlich bis heute überhaupt keinen offiziellen Standard gibt ;)) kann DCPCrypt oder andere Tools garnicht kompatibel zum DEC sein.

Ohne die Umstellung des Modus? Oder generell nicht?

Zitat:

Zitat von negaH

Wie gesagt, eine einfache Aussage wie "alle nutzen Twofish" also müssen sie gleiche Resultate erzielen ist falsch. Es gibt zu viele weitere Einstellungen die unterschiedlich sein könnten.

Hmm für mich galt Gleicher ( Algorithmus + Gleicher Key ) * Gleicher Inhalt = Gleiches Result :drunken:

Zitat:

Zitat von negaH

Ein weiteres Problem entsteht bei vielen Cipher die unterschiedliche Schlüssellängen und Rundenanzahlen unterstützen. Twofisch ist so ein Kandidat. Um also kompatibel zu werden müssen folgende Punkte abgeklärt werden:
1.) Schlüssellänge
2.) Rundenanzahl oder andere Ciphrspezifische Einstellungen
3.) Cipher Block Modus
4.) Cipher Block Size
5.) Schlüssel Preprocessing
6.) Padding Schemata
7.) Init Vector
8.) Daten Formatierung vor & nachher.

:nerd:


1. Sollte bei Twofish 256bit sein oder nicht? :roll:
8. Von Stream zu Stream gibts keine Formatierung oder doch? :duck:

2-7 Kann ich nix sagen, beschäftige mich erst seit paar Tagen mit der gazen Matherie, dachte das wär alles Standard (Rundenanzahl, Cipher Block Modus, Cipher Block Size, Schlüssel Preprocessing) :gruebel:

Was bewirkt die Änderung des Modis überhaupt?

Init Vector, Padding Schemata z.b. Sagt mir rein gar nix, für was soll das beides gut sein :?:


JaJa da besteht noch eine Menge Nachholbedarf bei mir zu dem Thema :)


Und danke für die Antwort :cheers:
Vielleicht kannst du ein Buch empfehlen, so als quasi Crypto-Experte :angel:
Möglichst Deutsch :lol:

Bye

[mirage228]

Hi,

als Kryptographie-Einsteigerbuch kann ich dir "Angewandte Kryptographie" von Bruce Schneier empfehlen.
Gibts für ca 50€ bei Amzaon in Deutsch :)

mfG
mirage228

[negaH]

Hi

InitVector kannst nil übergeben. Allerdings wird dann intern dieser als $FFFFFFF...FFFFF angenommen. Dies kann sich von Tool zu Tool unterscheiden. Es ist also besser bei beiden Tools den gleichen IV explizit zu übergeben.

DCPCrypt und DEC sind soweit kompatibel, wenn man in beiden Tools auch die gleichen Daten, Initialisierungen, Modis usw. benutzt.

Zitat:

Ein spezielles Problem bleibt aber bestehen: Twofich in der offizielle DEC Part 3 Version hat einen klitzekleinen Bug im KeySetup.
Das heißt?

Das der Twofish im DEC ein anderes KeySetup besitzt und somit immer anders arbeitet ;)

Überschreibe im KeySetup die Funktion F32() mit nachfolgender:

Delphi-Quellcode:

    function F32(X: Integer; K: array of Integer): Integer;
    var
      A, B, C, D: LongWord;
    begin
      A := X        and $FF;
      B := X shr  8 and $FF;
      C := X shr 16 and $FF;
      D := X shr 24;
      if Size = 32 then
      begin
        A := Twofish_8x8[1, A] xor K[3]        and $FF;
        B := Twofish_8x8[0, B] xor K[3] shr  8 and $FF;
        C := Twofish_8x8[0, C] xor K[3] shr 16 and $FF;
        D := Twofish_8x8[1, D] xor K[3] shr 24;
      end;
      if Size >= 24 then
      begin
        A := Twofish_8x8[1, A] xor K[2]        and $FF;
        B := Twofish_8x8[1, B] xor K[2] shr  8 and $FF;
        C := Twofish_8x8[0, C] xor K[2] shr 16 and $FF;
        D := Twofish_8x8[0, D] xor K[2] shr 24;
      end;
      A := Twofish_8x8[0, A] xor K[1]        and $FF;
      B := Twofish_8x8[1, B] xor K[1] shr  8 and $FF;
      C := Twofish_8x8[0, C] xor K[1] shr 16 and $FF;
      D := Twofish_8x8[1, D] xor K[1] shr 24;

      A := Twofish_8x8[0, A] xor K[0]        and $FF;
      B := Twofish_8x8[0, B] xor K[0] shr  8 and $FF;
      C := Twofish_8x8[1, C] xor K[0] shr 16 and $FF;
      D := Twofish_8x8[1, D] xor K[0] shr 24;

      Result := Twofish_Data[0, A] xor Twofish_Data[1, B] xor
                Twofish_Data[2, C] xor Twofish_Data[3, D];
    end;

  var
    I,J,A,B: Integer;
    E,O: array[0..3] of Integer;
    K: array[0..7] of Integer;
  begin
    FillChar(K, SizeOf(K), 0);
    Move(Key, K, Size);
    if Size <= 16 then Size := 16 else
      if Size <= 24 then Size := 24
        else Size := 32;
    J := Size shr 3 - 1;
    for I := 0 to J do
    begin
      E[I] := K[I shl 1];
      O[I] := K[I shl 1 + 1];
      BoxKey[J].L := Encode(E[I], O[I]);
      Dec(J);
    end;
    J := 0;
    for I := 0 to 19 do
    begin
      A := F32(J, E);
      B := F32(J + $01010101, O);
      B := B shl 8 or B shr 24;
      SubKey[I shl 1] := A + B;
      B := A + B shl 1;     // here buggy instead shr 1 it is correct shl 1
      SubKey[I shl 1 + 1] := B shl 9 or B shr 23;
      Inc(J, $02020202);
    end;
  end;

Zitat:

negaH hat folgendes geschrieben:
DEC benutzt standardmäßig dem Cipher.Mode := cmCTS. cmCTS ist eine Entwicklung von mir, die sicherer als der Standard cmCBC ist. Ein fast identisches Verfahren wie mein CTS wurde in der AES Ausschreibung von Belgischen Cryptoexperten als Ersatz für CBC vorgeschlagen. Da aber CTS kein offizieller Standard ist (wobei es eigentlich bis heute überhaupt keinen offiziellen Standard gibt ) kann DCPCrypt oder andere Tools garnicht kompatibel zum DEC sein.

Ohne die Umstellung des Modus? Oder generell nicht?

Ohne Umstellung dieses Modis, ansonsten kompatibel.

Zitat:

1. Sollte bei Twofish 256bit sein oder nicht?
8. Von Stream zu Stream gibts keine Formatierung oder doch?

Twofish kann verschiedene Schlüssellängen benutzen. 128, 192 und 256 Bit. DEC nimmt abhängig von der übergebenen Schlüssellänge den entsprechenden Modus.

Zitat:

Was bewirkt die Änderung des Modis überhaupt?
Init Vector, Padding Schemata z.b. Sagt mir rein gar nix, für was soll das beides gut sein

Hmmmm, die meisten Cipher sind Block-verschlüsselungen. D.h. die Nachricht wird in einzelne kurze Datenblöcke zerlegt, zb. 8,16,32 oder 64 Bytes. Dann wird die Verschlüsselungsfunktion auf diese Blöcke angewendet. Nun der Cipher Modus bestimmt wie die einzelnen Blöcke vor und nach der Verschlüsselung untereinander verknüpft werden. Der ECB Mode zb. verknüpft diese Blöcke überhaupt nicht untereinander, deshalb sollte man diesen Modus nicht in real benutzen. Die meisten anderen Modis benutzen ein zusätzliches Feedback Register. Der Anfangswert in diesem Register wird durch den IV=InitVector bestimmt und sollte zufällig sein. Natürlich muß man dann aber auch dieses Zufallsmuster mit in die Daten speichern damit man korrekt entschlüsseln kann.

Es gibt aber nun Nachrichten die nicht ein Vielfaches der Blockgröße in der Länge sind. Bei solchen Nachrichten wird also der letzte Block unvollständig und somit falsch verschlüsselt. Denn damit der Verschl. Algo. arbeiten kann benötig er ja einen kompletten Datenblock mit 6,16,32 oder 64 Bytes. In diesem Moment kommt das Padding zum Tragen, also das Auffüllen der fehldenen Bytes nach einem bestimmten Muster. Dieses Paddingist nichtwirklich standardisiert.

DEC benutzt zudem ein ganz spezielles "Padding", den Cipher Text Stealing. Dabei wird der letzte Block so verschlüsselt das er eben NICHT gepaddet werden muß, und somit die Länge der verschlüsselten Daten identisch zu der Länge der unverschlüsselten Nachricht ist.

Zitat:

Vielleicht kannst du ein Buch empfehlen, so als quasi Crypto-Experte möglichst Deutsch

siehe vorheriges Posting, schließe mich dieser Empfehlung voll und ganz an.

Gruß hagen

[Kedariodakon]

Ich habe immer noch Probleme...
Es geht noch nix...

Was habe ich getan?

Habe das KeySetup wie du gesagt hattest überschrieben...
Habe im TCipherManager = class(TComponent) im public Teil die Procedure:

Delphi-Quellcode:

Procedure TCipherManager.Init(const Key; Size: Integer; IVector: Pointer);
Begin
  Cipher.Init( Key, Size, IVector );
End;

hinzugefügt...

Zitat:

Zitat von negaH

DCPCrypt und DEC sind soweit kompatibel, wenn man in beiden Tools auch die gleichen Daten, Initialisierungen, Modis usw. benutzt.

Beide arbeiten im cmCBC
Beide arbeiten mit Twofish
Beide bekommen den selben 256bit Key ( 32x $88 )

Aber beide bekommen Nil als IVector...

Du sagtest aber mal:

Zitat:

Zitat von negaH

InitVector kannst nil übergeben. Allerdings wird dann intern dieser als $FFFFFFF...FFFFF angenommen. Dies kann sich von Tool zu Tool unterscheiden. Es ist also besser bei beiden Tools den gleichen IV explizit zu übergeben.

Ich habe keine Ahnung was die da als Pointer übergeben bekommen sollen, oder für was das gut ist...
Vielleicht kannst du mir das ja sagen, was ich dennen da geben soll... :zwinker:

Der IV is das einzigste noch, was da falsch sein könnte... :wall:


Bye

[Kedariodakon]

Ok es lag 100% am IV, habe ihm mal den Pointer vom Key gegeben, da du ja nur 16 byte von brauchst, konnte da ja nix schlimmes passieren...

Das hab ich bei beiden gemacht und siehe da, ich kann das eine Entschlüsseln, was ich mit dem anderen verschlüsselt hab...

Was der aber genau macht, weiß ich noch nicht.


Bye

[negaH]

Zerlege deine Nachricht in 16 Bytes Blöcke, und nummeriere diese von 1. bis x. durch. Setzt nun den IV als 0.Block vor diese Nachricht. Nun arbeitet der Cipher so das er Block für Block verschlüsselt, aber vorher den Nachtichten Block mit dem verschlüsselten Vorgängerblock verknüpft. Bei dieser Verknüpfung handelt es sich um den Feedback.Deshalb sind Modis wie CTS,CBC,CFB,OFB alles Feedback Modis. Sie sollen eine Abhängigkeit der einzelnen Nachrichtenblöcke untereinander schaffen und so die komplette Verschlüsselung überhaupt sicherer machen gegen viele Angriffe die zB. beim ECB Modus möglich wären.

Beispiel: du hast einen Überweisungsauftrag an deine Bank. Dieser besteht als 16 Bytes Absender und 16 Bytes Empfängerkonto und Summe. Nun verschlüsselst du diese 32 Bytes mit Twofish, einem 16 Bytes Blockcipher, in ECB. ECB verschlüsselt jeden Block unabhängig vom den anderen. D.h. der Block mit deinem Absender wird separat zum Block mit dem Empfänger+Summe verschlüsselt. Ich als Angreifer weis dies und habe dich irgendwan einmal gebeten mir 1 Million Euro zu überweisen, es war ein Geschäft zwischen uns. Nun, fange ich deine neueste Überweisung ab, schneide den letzten Block mit dem Empfänger raus und ersetze diesen mit dem Empfängerblock der Überweisung an mich. Schwups, überweist die Bank erneut 1 Million Euro auf mein Konto. Und ich konnte dies machen OHNE dein Passwort zu kennen.

Es gibt noch sehr viele solcher Angriffsmöglichkeiten. Der IV als Zufallswert und der Feedback Modus des Ciphers verhindern nun solche Angriffe, da
1.) über das Feedback Register die Blöcke informationstechnisch miteinander verknüpft wurden
2.) der 0. Block des Feedback Registers -> IV -> eben zufällig gewählt wurde und sich somit von Überweisung zu Überweisung ständig verändert

Gruß Hagen

[Kedariodakon]

Ah Gut und verständlich erklärt :thumb:

Bye

[Kedariodakon]

Hmm vielleicht hat der CipherManager im DEC nen Bug... :gruebel:

Follgende Algos nimmt er net an, auch wenn ich sie im ObjectInspector auswähle schaltet er immer auf Blowfish um ( z.b. wenn man den Algo mit Algorithm ausliest...)

Code:

Cast 128
Cast 256
DES Single 8byte
DES Double 8byte
DES Double 16byte
DES Triple 8byte
DES Triple 16byte
DES Triple 24byte
DESX
Diamond II
Diamond II Lite
FROG
Mars
Misty 1
NewDES
RC2
RC4
RC5
RC6
Rijndael
Sapphire II
Skipjack

Getestet hab ich das einfach indem ich die Algos zur Entwicklungszeit eingestellt habe und zur laufzeit mit:

Delphi-Quellcode:

procedure TfrmMain.cmdGetClick(Sender: TObject);
begin
   txtAlgo.Text := Cipher.Algorithm;
end;

ausgelesen hab...
Und wie gesagt alle bis auf die da oben nimmt er...

Liegt das schon wieder an irgendeiner einstellung bei mir? Oder hat es wirklich ein Bug?


Bye

Edit: HCMngr.pas -> Version: 3.0, Part I from Delphi Encryption Compendium

[Kedariodakon]

hmm in der Uses-Clausel des: HCMngr.pas war keine Cipher1.pas drin...
Habs hinzugefügt und schon gib es...
Zumindest das die ausgewählt wurden...

Aber ich hab es da bestimmt nicht rausgemacht...
Hab das DEC nochmal geladen und siehe da, dort war es auch nicht vorhanden...
hmm doch nen kleiner Bug? :roll:

Bye

[negaH]

Kein Bug, es liegt am Delhpi 7, du benutzt es ganz sicher. In D7 wurde einiges an dem DesignTimeInterface der Komponenten geändert.
Zudem, suche hier im Forum, warum ich die Verwendung der beiden Komponenten im DEC als prinzipiell schlecht empfinde.

Gruß hagen

[Kedariodakon]

Zitat:

Zitat von negaH

Kein Bug, es liegt am Delhpi 7, du benutzt es ganz sicher. In D7 wurde einiges an dem DesignTimeInterface der Komponenten geändert.

Jup Nutze Delphi 7 :roll:

Zitat:

Zitat von negaH

Zudem, suche hier im Forum, warum ich die Verwendung der beiden Komponenten im DEC als prinzipiell schlecht empfinde.

Welche beiden Komponenten im DEC :gruebel:

Bye

[fkerber]

Hi!

TCiphermanager und ?? (vergessen :oops: )


Ciao Frederic

[Kedariodakon]

Hmm wenn du sie so als so schlecht empfindest, warum nutzt du sie dann?
Soweit ich mich erinnern kann, sind sie doch von dir... :gruebel:


Bye

[negaH]

Richtig, ich habe sie aber nur entwickelt um sie für die DEMO zu benutzen. Und davon abgesehen macht jeder mal Fehler. Als ich DEC entwickelt habe bin ich mit DEC groß geworden. Um so mehr DEC wuchs um so größer wurde mein Wissen über die Kryptographie. Im nachhinein waren diese beiden Komponenten ein Fehler den ich auf Grund eines Wunsches eines DEC Anwenders gemacht habe. Damals wurde ich eben gefragt ob es nicht möglich wäre Komponenten ins DEC zu integrieren.

Kourioser weise ist die simple Verwendung der DEC Klassen viel einfacher verständlich, kryptographisch sicher und nicht so expensiv wie die Komponenten.

Ich kann dir aber versichern das ich diese beiden Komponenten ausser in der DEMO sonst nie wieder benutzt habe.

Gruß Hagen