Eure Anregungen für das DEC 5.3 gebraucht

[gammatester]

Vielleicht solltest Du einmal hier ein Beispiel geben. Ich weiß nur, daß meine alten DEC-Tests nicht mehr compilierbar sind, zB

Delphi-Quellcode:

var
  AES: TCipher_Rijndael;

var
  key128 : array[0..15] of byte = ($2b,$7e,$15,$16,$28,$ae,$d2,$a6,
                                   $ab,$f7,$15,$88,$09,$cf,$4f,$3c);

      IV : array[0..15] of byte = ($00,$01,$02,$03,$04,$05,$06,$07,
                                   $08,$09,$0a,$0b,$0c,$0d,$0e,$0f);

  plain  : array[0..63] of byte = ($6b,$c1,$be,$e2,$2e,$40,$9f,$96,
                                   $e9,$3d,$7e,$11,$73,$93,$17,$2a,
                                   $ae,$2d,$8a,$57,$1e,$03,$ac,$9c,
                                   $9e,$b7,$6f,$ac,$45,$af,$8e,$51,
                                   $30,$c8,$1c,$46,$a3,$5c,$e4,$11,
                                   $e5,$fb,$c1,$19,$1a,$0a,$52,$ef,
                                   $f6,$9f,$24,$45,$df,$4f,$9b,$17,
                                   $ad,$2b,$41,$7b,$e6,$6c,$37,$10);

  ct_cbc : array[0..63] of byte = ($76,$49,$ab,$ac,$81,$19,$b2,$46,
                                   $ce,$e9,$8e,$9b,$12,$e9,$19,$7d,
                                   $50,$86,$cb,$9b,$50,$72,$19,$ee,
                                   $95,$db,$11,$3a,$91,$76,$78,$b2,
                                   $73,$be,$d6,$b8,$e3,$c1,$74,$3b,
                                   $71,$16,$e6,$9e,$22,$22,$95,$16,
                                   $3f,$f1,$ca,$a1,$68,$1f,$ac,$09,
                                   $12,$0e,$ca,$30,$75,$86,$e1,$a7);

var
  ct: array[0..63] of byte;

procedure TestCBC;
begin
   AES.Mode := cmCBC;
   AES.Init(key128,16,@IV);
   AES.EncodeBuffer(plain,ct,sizeof(plain));
end;

Es scheint keinen CBC-Modus mehr zu geben, der IV kann nicht mehr in die Initialisierung einfließen, EncodeBuffer ist unbekannt.

Wirklich nicht sehr ermutigend.

Eigentlich dachte ich, daß die neue Version kompatibel sein sollte.

Weiter: Es scheint (bisher?) nur das Altbekannte umgeschrieben zu sein, das war mal aktuell vor 15 Jahren: Dutzende Chiffren/Hashes die mM nicht mehr benutzt werden. Dafür fehlen wichtige standardisierte Neuerungen: Betriebsmodi GCM, CTR, EAX etc, Stromchiffren wie Salsa/Chacha, SHA3, Blake, Poly1305.

Sinnvoll wäre auch einige Umbenennungen bzw. Alias zB TCipher_Q128 -> TCipher_Camellia.

[Codehunter]

Jaja, Fordern ist immer einfach, Fördern hält sich in engen Grenzen. Für das Problem ist nicht nur ein gewisses deutsches Amt/Agentur bekannt 8-)

Mir fehlt es leider an Zeit und dem angemessenen Knowhow um mich zu beteiligen. Allgemein denke ich, dass man wann immer möglich Standardbibliotheken wie OpenSSL nutzen sollte. Die native Delphi-Implementierung mag zwar sportliche Ambitionen haben. Jedoch haben wir heute ganz andere Anforderungen an Verschlüsselung wie vor 15 Jahren. Da wird ein solches Projekt doch schnell zum Fass ohne Boden.

Wie viele Entwickler hier können wirklich sichere Verschlüsselungen implementieren bzw. die Sicherheit beurteilen? Die meisten stückeln sich ihre Implementierungen doch meist per Copy&Paste aus Tutorials zusammen. Ich selbst habe einen großen Respekt vor Entwicklern, die sich mit Projekten wie OpenSSL und DEC befassen.

[TurboMagic]

Zitat:

Zitat von gammatester (Beitrag 1396485)

Vielleicht solltest Du einmal hier ein Beispiel geben. Ich weiß nur, daß meine alten DEC-Tests nicht mehr compilierbar sind, zB

Delphi-Quellcode:

var
  AES: TCipher_Rijndael;

var
  key128 : array[0..15] of byte = ($2b,$7e,$15,$16,$28,$ae,$d2,$a6,
                                   $ab,$f7,$15,$88,$09,$cf,$4f,$3c);

      IV : array[0..15] of byte = ($00,$01,$02,$03,$04,$05,$06,$07,
                                   $08,$09,$0a,$0b,$0c,$0d,$0e,$0f);

  plain  : array[0..63] of byte = ($6b,$c1,$be,$e2,$2e,$40,$9f,$96,
                                   $e9,$3d,$7e,$11,$73,$93,$17,$2a,
                                   $ae,$2d,$8a,$57,$1e,$03,$ac,$9c,
                                   $9e,$b7,$6f,$ac,$45,$af,$8e,$51,
                                   $30,$c8,$1c,$46,$a3,$5c,$e4,$11,
                                   $e5,$fb,$c1,$19,$1a,$0a,$52,$ef,
                                   $f6,$9f,$24,$45,$df,$4f,$9b,$17,
                                   $ad,$2b,$41,$7b,$e6,$6c,$37,$10);

  ct_cbc : array[0..63] of byte = ($76,$49,$ab,$ac,$81,$19,$b2,$46,
                                   $ce,$e9,$8e,$9b,$12,$e9,$19,$7d,
                                   $50,$86,$cb,$9b,$50,$72,$19,$ee,
                                   $95,$db,$11,$3a,$91,$76,$78,$b2,
                                   $73,$be,$d6,$b8,$e3,$c1,$74,$3b,
                                   $71,$16,$e6,$9e,$22,$22,$95,$16,
                                   $3f,$f1,$ca,$a1,$68,$1f,$ac,$09,
                                   $12,$0e,$ca,$30,$75,$86,$e1,$a7);

var
  ct: array[0..63] of byte;

procedure TestCBC;
begin
   AES.Mode := cmCBC;
   AES.Init(key128,16,@IV);
   AES.EncodeBuffer(plain,ct,sizeof(plain));
end;

Es scheint keinen CBC-Modus mehr zu geben, der IV kann nicht mehr in die Initialisierung einfließen, EncodeBuffer ist unbekannt.

Wirklich nicht sehr ermutigend.

Eigentlich dachte ich, daß die neue Version kompatibel sein sollte.

Weiter: Es scheint (bisher?) nur das Altbekannte umgeschrieben zu sein, das war mal aktuell vor 15 Jahren: Dutzende Chiffren/Hashes die mM nicht mehr benutzt werden. Dafür fehlen wichtige standardisierte Neuerungen: Betriebsmodi GCM, CTR, EAX etc, Stromchiffren wie Salsa/Chacha, SHA3, Blake, Poly1305.

Sinnvoll wäre auch einige Umbenennungen bzw. Alias zB TCipher_Q128 -> TCipher_Camellia.

1. Etwaige Kompatibilitätsprobleme müssen natürlich während des betastadiums untersucht werden. Du darfst dich da gerne einbringen. Auch Testdaten sind uns willkommen.
2. CBC sollte es denke ich weiterhin geben. Bin mir auswendig aber nicht sicher wo das steckt. Diese Paddings wurden in eine eigene Zwischenklasse ausgelagert, Zwecks Modularisierung.
3. Ja, derzeit ist der Fokus erstmal das altbekannte in besserer Modularisierung und Cross-Plattform kompatibler Form zu bieten. Das ist für eine erste fassung noch genügend Arbeit.
4. Wenn 3. mal erledigt ist sollte selbstverständlich versucht werden der Reihe nach die Lücken zu füllen. Auch hier darf man sich ruhig beteiligen! Da wird es genügend Möglichkeiten geben.
5. Ach ja: nur weil wir es aufarbeiten heißt es auch nicht, dass die Aufrufschnittstelle 100,0% gleich sein muss wie bei der alten version. Wir versuchen das zwar soweit es uns sinnvoll erscheint. Tipp: wer mit einsteigt kann mehr beeinflussen!!! ;-)

Grüße

TurboMagic

[KodeZwerg]

Hallo DEC Entwickler-Team,
ich bin etwas verwirrt wer denn nun hier das Sagen hat,
es wurde nach alten Delphi und Tests damit gefragt.
Ich habe noch ein nacktes (keine non-borland addons/components etc) Delphi 7 hier und kann damit etwas testen/compilieren falls erwünscht, allerdings vorweg: Ich habe mich noch nie mit dUnit beschäftigt und bräuchte bestimmt eine kleine Anleitung/Einweisung damit das Resultat das ist was euch voran bringen kann.

ps: https://github.com/winkelsdorf/Delph...tionCompendium enthält keinen code, nur .wiki dateien?

[TurboMagic]

Zitat:

Zitat von Codehunter (Beitrag 1396499)

Jaja, Fordern ist immer einfach, Fördern hält sich in engen Grenzen.

Wie viele Entwickler hier können wirklich sichere Verschlüsselungen implementieren bzw. die Sicherheit beurteilen? Die meisten stückeln sich ihre Implementierungen doch meist per Copy&Paste aus Tutorials zusammen. Ich selbst habe einen großen Respekt vor Entwicklern, die sich mit Projekten wie OpenSSL und DEC befassen.

Naja, DEC sollte es ermöglichen eine sichere Verschlüsselung zu bieten, für die richtige Anwendung ist aber immer noch der DEC benutzende Entwickler zuständig! DEC ist nicht als Kryptographie Tutorial ausgelegt, auch wenn man via DEC (wie ich auch) einiges darüber lernen kann.

[TurboMagic]

Hallo,

danke für das Angebot, nur haben Assertor und ich beschlossen, dass wir mit dem neuen Release mindestens D2009 voraussetzen.

Zum Thema DUnit: das ist gar kein Problem. Wir haben schon für viele Dinge Unit Tests programmiert (sicher noch nicht 100% Testabdeckung, aber doch schon so einiges) und diese sind alle in einem Projekt zusammengefasst. Man muss nur dieses Projekt aktivieren, F9 drücken und es erscheint ein schöner GUI. Dort wieder F9 drücken um mal alle Tests auszuführen und sich dann die Ausgabe anschauen. Ist die "grün" waren alle Tests erfolgreich. Sonst gibt's eine Liste der Fehler und auch das Compilieren dieses DUnit Projektes ist schon eine Aussage, nämlich dass wir keinen Code drin haben, der unter D2009 nicht geht.

Für Cross Plattform Entwicklung würden wir übrigens Delphi 10.1 Berlin oder neuer voraussetzen.

Grüße

TurboMagick

[KodeZwerg]

Ok, wenn es denn mal erforderlich und für Euch hilfreich sein könnte, ein (total Component verseuchtes) D2010 hab ich auch noch und für aktuelle Version müsste ja die Starter-Edition vielleicht ausreichen?

[Zacherl]

Zitat:

Zitat von TurboMagic (Beitrag 1396482)

Zitat:

Zitat von Zacherl (Beitrag 1396467)

Könntest du den Link zum richtigen GitHub Repo mal posten? Bin nicht sicher, was hier das "Offizielle" ist.

Gerne:
https://github.com/winkelsdorf/Delph...tionCompendium

Mal gespannt, ob du entdeckst was es zu entdecken gibt und ob du dich dann vielleicht als Freiwilliger meldest? ;-)

Das sieht doch schon sehr vielversprechend aus :thumb: Mit Unit Tests unter alten Delphis kann ich leider nicht wirklich dienen, aber falls z.B. noch ein paar Assembler Blöcke nach Pascal portiert werden müssen, kann ich sicherlich aushelfen.

[TurboMagic]

Zitat:

Zitat von Zacherl (Beitrag 1396523)

Das sieht doch schon sehr vielversprechend aus :thumb: Mit Unit Tests unter alten Delphis kann ich leider nicht wirklich dienen, aber falls z.B. noch ein paar Assembler Blöcke nach Pascal portiert werden müssen, kann ich sicherlich aushelfen.

Naja, das ASM Zeugs haben wir eigentlich alles auch schon als Pure Pascal Variante forliegen (es gibt einen Compilerschalter um zwischen beiden fassungen umschalten zu können. Allerdings gibt es derzeit noch einen heftigen Absturz, wenn man auf die ASM variante schaltet. Es kracht zwischen einem Methodenaufruf und der ersten Zeile in der Methode. :(

[TurboMagic]

Zitat:

Zitat von blackdrake (Beitrag 1144245)

Ein sehr großer Wunsch von mir war ja immer die Asynchrone Verschlüsselung zu Implementieren. Ich bin deswegen sogar von Delphi abgedriftet, da es für OpenSource Projekte keine PKI Implementierungen gibt. In Java kann man mit 5 Quelltextzeilen eine asynchrone Verschlüsselung hinbekommen.

Einen Bug, den ich damals fand war, dass der Shark Cipher nicht funktioniert. Beim Ver- und Entschlüsseln kommen unterschiedliche Ergebnisse raus.

Gruß
blackdrake

Hallo,

könntest du dieses Shark Cipher Problem mal bitte hier erfassen:
https://github.com/winkelsdorf/Delph...pendium/issues

Dann hat's nämlich eine Chance untersucht und behoben zu werden.
Falls du den Thread noch liest hast du ja wohl inzwischen mitbekommen, dass DEC nicht tot ist...

Grüße

TurboMagic

[TurboMagic]

Zitat:

Zitat von Schorschi5566 (Beitrag 1104779)

Sehe gerade, dass DEC 5.3 in Arbeit ist.

Ich schlage mich gerade damit rum DEC 5.2 nach Lazarus zu portieren. Könnte man das nicht auch gleich für die neue Version berücksichtigen?

Bin gerade erst bei der DECUtils und weiß nicht, was noch alles zu ändern ist aber wäre bestimmt besser, wenn das jemand macht, der sich mit dem Paket gut auskennt. ;)

Nur so als Vorschlag...


Grüße,
Uwe

Hallo,

falls noch grundsätzlich interessant könntest du uns evtl. mit Lazarus/FPC Kompatibilität helfen sobald wir in einer vernünftigen Beta Phase von DEC 6.0 sind. Es gibt bei uns jetzt nämlich auch einen "Pure Pascal" Modus. Also, wie sieht's aus? :wink:

Grüße

TurboMagic

[Zacherl]

Zitat:

Zitat von TurboMagic (Beitrag 1396529)

Allerdings gibt es derzeit noch einen heftigen Absturz, wenn man auf die ASM variante schaltet. Es kracht zwischen einem Methodenaufruf und der ersten Zeile in der Methode. :(

Gibt es dazu ein Testprojekt? Dann schaue ich mir das mal an bei Gelegenheit :)