DEC 5.1 wie benutzen?

[Luckie]

Eventuell solltet ihr eure Slang-Diskussion im Offtopic-Bereich führen, weil es nicht ganz uninteressant ist oder doch per PN. Nur so viel von meiner Seite, im Internet hat man nicht allzuviele Möglichkeiten, Höflichkeit gegenüber anderen zu zeigen, deswegen finde ich sollte man doch auf seine Grammatik und Rechtschreibung achten, denn das ist eine Form von Höflicheit. Letztendlich sollte einem auch bewusst sein, dass man hier Bittsteller ist und von anderen etwas will und wenn ich mir erst wein Postinmg drei mal durchlesen muss, weil es ohne Punkt und Komma geschrieben wurde, dann sag ich mir auch, "Ich habe besseres zu tun als deine Postings zu entziffern und wenn du dir noch nicht mal die Mühe machst etwas auf die Rechtschreibung und Grammatik zu achten, warum sollte ich mir die Mühe machen zu anworten?"

[negaH]

Zitat:

Kurze Frage:
Sind die DEC Units closed source und nur für Freeware-Programme? Wie kam es denn dazu?
Welche Delphiversionen können die DEC verwenden?

DEC Part I ist OpenSource, einzigste Einschränkung ist das man die Courage hat und eventuell an einer dunkeln Stelle seiner Aboutbox oder Hilfedatei oder Readme.txt auf die Verwendung des DECs hinweist. Ich weiß das das viel verlangt ist und manchesmal nur sehr kompliziert umzusetzen geht

Alle anderen Teile des DECs sind genau betrachtet garnicht existent ausserhalb meines Datenspeichers
Ich habe speziell für die DP hier mal par prekompilierte Blibliotheken gepostet und diese hostet nun Luckie für mich. Nochmals danke.

Das DEC Part II nun closed Source ist hat ganz verschiedene Gründe. Als erstes mal das ich die Erfahrung machen musste das man DEC Part I unter dem eigenen Namen als eigene Leistung darstellte. Es gibt aber auch gegenteiliges zu berichten. Zum zweiten weil auf Grund meiner "Supportanfragen", und ich erhielt zweitweise bis zu 100 Mails pro Tag !!, ich feststellen musste das heutzutage Support heist "der kann doch für mich meine Probleme lösen, warum dann noch mal selber in den Sourcecode schauen". Und mit fast 98% Wahrscheinlichkeit war es dann so das garnichtmal der Fehler im DEC lag. Nee es ist sogar so das ich die EMails die ich erhalten habe, die sich auch wirklich auf Fehler im DEC bezogen, an einer Hand abzählen kann. Die Frage ist also: wenn ich meine Hobbyarbeiten veröffentliche was kommt dann auf mich zu ? Fast immer nur Zeitverbrauch, Arbeit und wenig hilfreiches Feadback. Nungut, es ist aber nun auch so das das Thema Kryptographie nicht jedermans Sache ist, das muß ich berücksichtigen.
Zum dritten: DEC ist eine Phase in meiner Entwicklung Hört sich abgehoben an, meint aber das ich mich mit dem Thema Kryptographie nur so ca. 3-4 Jahre befasst habe und dann wusste ich eigentlich alles was ich wissen wollte und der Spaß war vorbei. Mein Interesse am Thema ist also gesättigt und es gibt Neues.
Zum Vierten: DEC sollte aus drei Teilen bestehen. Part I kennt ihr und enthält die symmetrischen Verfahren. Part II wäre nur eine Bibliothek gewesen um die nötigen mathematischen Primitive zu entwickeln. Also das Rechnen mit supergroßen Zahlen, Modulararithmetik, Elliptische Kurven usw. usw. Also alles was eher im Arithmetischen Sektor anzusiedeln wäre. Zusätzlich wären noch Supportfunktionen enthalten um später die verschiedenen asymmetrischen Verfahren wie RSA, EC, ElGamal, Diffie Hellman uvm. zu vereinfachen. Part III nun würde auf beide Teile aufsetzten und Standardprotokolle wie PKCS, PGP, IEEE usw. zu implementieren.
Also ziemlich viel Arbeit ohne das ich jemals damit mein Brot verdienen könnte. Denn vor par Jahren hatten nur wenige Experten überhaupt ein Bedürfnis nach Kryptographie. Und gerade bei der Implemntierung von solchen Protokolen wie PKCS oder PGP würde ich eine Arbeit machen die mir im Grunde widerstrebt. Warum sollte ich mit nicht kommerziellem Interesse solche kommerziell durchsetzten Protokolle implementieren von deren Umsetzung ich noch nichtmal überzeugt bin ? Besonders PKCS ist so ein Fall, aufgebläht, unsicher und verkompliziert.
DEC part II ist auch deshalb closed Source weil ich darin einige von mir entwickelte Optimierungen und Algorithmenverbesserungen implementiert habe. Es steckt viel Knowhow drinnen und einige implementierte Verfahren dürften auch durch Patente geschützt sein. Bei dieser Art der Kryptographie, speziell Elliptische Kurven usw. kann man sehr schnell unabsichtlich in Patentfallen geraten. Dieser "Markt" ist da sehr aggressiv und es gibt so einige Patente auf mathematisch absolut offensichtliche Verfahren/Verbesserungen auf die jeder auch mit par Minuten Nachdenken von selber kommt. Die Wahrscheinlichkeit ist also hoch das auch ich mir einige offensichtliche Optimierungen einfallen lassen habe die patentiert sein könnten. Ergo: closed Source, nur private Benutzung etc.pp.

DEC Part I sollte ab Delphi 4 compilierbar sein, einfach weil overloads und default Parameter benutzt werden. Nach oben wird die Grenze durch Borland bestimmt. Solange die sich an ihre Schnittstelle halten und abwärtskompatibel belieben sollte Part I ohne einen Fehler/Warnung kompilierbar sein.

DEC Part II kann von 2-3 Leuten vollständig kompiliert werden Für Part II gibts prekompilierte Versionen für Delphi 5,6,7 und 2006/2007. Allerdings werde ich für 2006/2007 keine Distributation verteilen da ich diese Delphi Versionen nicht lizensiert habe.
Aber kompilierbar dürfte auch dieser Teil unter allen Delphi Version ab Delphi 5 sein.

Nach einiger Zeit habe ich mich dann entschlossen Part I und Part II zusammenzupacken und auf Luckie's Rechner abzulegen. Hintergrund war das immer wieder nach einer Bibliothek gefragt wurde mit der man möglichst effizient supergroße Zahlen rechnen kann. In den meisten Fällen ging es dabei wirklich nur um private Ambitionen, also einfach mal reinschnuppern, mal par Konstanten berechnen, mal RSA ausprobieren usw. Dabei geht es auch nicht darum ob man Part II als vollständigen Source vorsich hat, Mathematik geht auch ohne den Source zu haben.

Von Zeit zu Zeit beschäftige ich mich noch mit diesem Thema, meistens wenn es ganz neue Entwicklungen gibt oder auf Grund von Nachfragen zb. hier in der DP. Tja, das wars mit der Historie vom DEC

Gruß Hagen

PS: achso ein weiteres Problem war es kompatible Mitstreiter zu finden. Fast alle "Experten" auf diesem Sektor sind hm sagen wir mal verknöchert/verbohrt und starke Individualisten, sowas wie ich halt

[Dezipaitor]

Das mit den Mitstreitern kenne ich von JWSCL. Ich glaube aber, dass es ein Delphi Problem ist. In C++ tummeln sich einfach mehr Experten, die Zeit haben.
Ich hab deshalb auch vor die JWSCL in COM (ActiveX) zu implementieren. Sie kann dann auch in VB und C++ einfach verwendet werden.

[jorgos]

Hallo zusammen,
ich habe mir das jetzt mal alles angetan, weil ich auch eine Möglichkeit suchte, Dateien zu verschlüsseln.
Vorab auch mal ein Lob und ein "Hut ziehen2" an Hagen.
Da kann einem schwindelig werden.

So jetzt mal ganz kurz.
Kann ich irgendwie prüfen, ob eine Datei bereits verschlüsselt ist, um interaktiv zu verschlüsseln,
wenn ich möchte (z.B. bei einem ganzen Verzeichnis)?

Wäre für eine Antwort dankbar

Viel Grüße
Jorgos

[Luckie]

Nein, es sei denn du markierst die Datei irgendwie selber, sei es durch eine Dateiendung oder durch eine Bytefolge am Anfang der Datei.

[negaH]

Wenn du deine Dateien mit einer eigenen Software verschlüsselst dann geht das sicherlich. So wie es Luckie schon andeutete.
Wenn du aber damit meinst das du erkennen möchtest ob eine beliebige Datei mit unbekannten Format verschlüsselt ist dann geht dies nur sehr eingeschränkt. Man kann verschlüsselte Dateien erkennen im Vergleich zu vielen anderen Dateiformaten. Aber zb. gepackte Dateien, Dateien mit fast zufälligen Inhalt, viele Binäreformate usw. würde man ebenfalls als potentiell verschlüsselte Dateien identifizieren. Ich selber habe schonmal versucht so ein System zu konstruieren das selbstständig diese Differenzierung erlernenen kann, Stichwort Neuronale Netze zb. Das klappte auch schon, allerdings wirft es eben solche Ausnahmen wie genannt immer in einen Topf.

Gruß Hagen

[gammatester]

Zitat von Luckie:

Nein, es sei denn du markierst die Datei irgendwie selber, sei es durch eine Dateiendung oder durch eine Bytefolge am Anfang der Datei.

In der Regel gibt es allerdings starke Hinweise, daß eine Datei verschlüsselt ist: Wenn Du zB eine .TXT verschlüsselst und keine andere Extension vergibts, wird man (wenn nicht gerade der ECB-Modus verwendet wird) ziemlich stutzig, wenn nur Schrott drin steht. Wenn der Algorithmus/Modus (Wieso wird eigentlich in Deiner Unit defaultmäßig der proprietäre cmCFS8-Modus verwendet?) gut ist, ist die Datei auch praktisch nicht komprimierbar.

Wenn allerdings Zufall/"Schrott" o.ä. verschlüsselt wird, hast Du ein anderes Problem: Die entschlüsselte Datei ist auch mehr oder weniger zufällig, und Manipulationen sind nicht oder nicht sofort ersichtlich. Deshalb sollte man Dateiverschlüsselung in der Regel zusammen mit Authentizitäts-"Prüfsumme" und Entschlüsselung mit der entsprechenden Verifikation verwendet. Leider kennt DEC weder EAX noch HMAC, die für diese Zwecke eingesetzt werden. Und wie es aussieht, hat Hagen auch keine Absicht diese einzubauen.

Gruß Gammatester

[negaH]

wenn man den CipherMode cmCTSx/cmCTS8 benutzt kann man am Ende eine CMAC errechnen und abspeichern. Das ist vergleichbar mit den sich gerade in Standardisierung befindelichen Ciphermodis bei AES. cmCTSx/cmCTS8 sind prohibitär das ist richtig. Im Grunde sind es doppelt arbeitende CBC Modis auf Blockgröße oder Bytegröße Feedback. Sie arbeiten wie CBC indem sie die Daten mit dem Feedbackregister vor der Verschlüsselung des Blocks XOR verknüpfen. Nach der Verschlüsselung wird aber nun zusätzlich auch der verschlüsselte Datenblock mit dem Feedback Register XOR verknüpft. So entsteht eine Verknüpfung der Datenblöcke untereinander die 1. von Feedbackregister Startwert abhängt, 2. vom Passwort und dem daraus erzeugten Schlüsselstrom und 3. von den Daten der Nachricht selber da man ja das Verschlüsselungprodukt noch zusätzlich XOR Verknüpft. cmCTS? ist also fast eine Alles oder Nichts Verschlüsselung ohne Selbstsynchronsation. Ändert sich 1 Datenbit mitten in den verschlüsselten Daten so sind alle nachfolgenden Datenblöcke inklusive des aktuellen Datenblockes vernichtet, eg. nicht korrekt entschlüsselbar. Am Ende einer Verschlüselung/Entschlüsselung kann man mit Cipher.CalcMAC eine sogenannte Cipher-MAC errechnen und somit auf Datenintegrität testen. Wie oben angedeutet wird sich die so errechnet CMAC komplett unterscheiden wenn nur 1 Datenbit falsch übertragenm wurde. Ok, da die meisten Cipher mit zb. 8 Bytes Feedbackregster arbeiten ist diese CMAC auch meistens nur 64 Bit groß. Das Kollisionsrisiko im Vergleich zu eienr guten Hash-MAC ist also viel größer. Nutzt man aber zb. einen 16 Bytes Blockcipher so ist das identisch mit einer zb. MD5-HMAC. Aber mit dem Unterschied das diese CMAC Berechnung Performancetechnisch schon inklusive ist.

Stört man sich nicht daran das cmCTS? prohibitär ist und nicht selbstsynchronisierend so dürfte das eine gute Wahl sein, sowohl aus Sicherhsitsaspekten betrachtet wie auch aus Sicht der Performance. Aus kryptrographischer Sicht dürfte somit cmCTS? identisch zu den neueren Ciphermodis sein, eben nur mit dem Unterschied das DEC diesen Mode schon seit Jahren anbietet und AES sich noch in der Findungsphase befindet. (ich weiß das du, Gammatester, da eine andere Meinung vertrittst )

Ein weiterer Unterschied, prohibitär natürlich, besteht im Padding. Das neuste DEC wechselt wenn es padden muß vom Blockorientierten Modus zum Byteorientierten Modus. Ich erachte dies für die sicherste Paddingmethode. Den Byteorientierten Modus, wie zb. cmCBC8,cmCTS8 usw. benutzt man schon seit langer Zeit um sehr kurze und hochsensible Daten zu verschlüsseln, sie sind also anerkannte Verfahren. Sie sind aber bei langen Nachrichten ineffizienter das sie ja zb. bei Blockgröße 16 einen Datenblock insgesamt 16 mal verschlüsseln. Nimt man nun einen anerkannten Blockmodus wie CBC und verschlüsselt den letzten zu kurz geratenen Datenblock im dazu vergleichbaren Byteorientierten Ciphermode so hat man eine gute Methode für ein Padding. Neben viele anderen Vorteilen ergibt sich der Vorteil das man Daten die kürzer sind als die Blockgröße des Ciphers autom. immer im 8Bit Feedbackmodus verschlsüselt, da dieser 1. Datenblock ja auch gleichzetig der zu paddende Datenblock ist. Somit benutzt dieses Paddingschemata auch bei sehr kurzen Datenmengen den sichersten Modus. In keinem der Fälle kommt es zu einer Datenexpansion bei der Verschlüsselung, was enorm von Vorteil ist. Zudem braucht man dann auch nicht mehr spezielle und komplexere Chiphermodis zu impolenetieren das das System meistens immer einen Blockorientierten und Byteorientierten Feedbackmodus anbieten kann.

Also, das was ich im DEC implementiert habe hat meiner Meinung nach sehr wohl ein kryptographisch sauberes Fundament, nur mit dem Unterschied das DEC sowas schon seit längerer Zeit anbietet und die neueren Standards längst noch nicht in der Praxis angekommen sind. Verfolgt man den AES Zertifizierungsablauf bei den Ciphermodis über längere teit so wird man feststellen das von den vielen vorgeschlagenen Ciphermodis sehr viele in kürzester Zeit als unsicher bewiesen wurden. Das Komen und Gehen in diesem Sektor ist nach meinem Gefühl viel stärker als bei der Auswahl geeigneter Verschlüsselungsalgorithmen, also beim AES Rijndael. Das suggeriert wenig Vertrauen.

Ich werde diese Modis noch einbauen, mit Sichereit, aber erst wenn diese neuen Modis in der Praxis auf breite Akzeptanz gestoßen sind. Das heist ganz im Besondern das ich eben nicht EAX einbauen werde solang nur spezielle Produkte diesen unterstützen, womöglich nur diejenigen Produkte die den EAX entwickelt und vorgeschlagen haben.

Gruß Hagen

[jorgos]

Zitat von Luckie:

Nein, es sei denn du markierst die Datei irgendwie selber, sei es durch eine Dateiendung oder durch eine Bytefolge am Anfang der Datei.

Hallo zusammen,

erstmal Vielen Dank für die schnellen Antworten.

Ich habe mir den Source der DLL "MyCrypt" kopiert.

Ich meine bei diesem Verfahren.
Nicht, wenn eine Datei mit anderen Systemen verschlüsselt ist.

Wie kann ich denn

Zitat:

eine Bytefolge am Anfang der Datei

einbauen.
Hat da jemand eine Idee ?
Mit Sicherheit.

Kann mir jemand einen Tipp geben.

Wäre sehr Dankbar.

Viele Grüße
Jorgos

[negaH]

Zitat:

n der Regel gibt es allerdings starke Hinweise, daß eine Datei verschlüsselt ist: Wenn Du zB eine .TXT verschlüsselst und keine andere Extension vergibts, wird man (wenn nicht gerade der ECB-Modus verwendet wird) ziemlich stutzig, wenn nur Schrott drin steht. Wenn der Algorithmus/Modus (Wieso wird eigentlich in Deiner Unit defaultmäßig der proprietäre cmCFS8-Modus verwendet?) gut ist, ist die Datei auch praktisch nicht komprimierbar.

Wird cmCTS? im Zusammenhang mit einem randomisierten InitVector oder besser noch mit einer randomisierten KDF, wie oben im Bespiel gezeigt benutzt, dann trifft deine Aussage zu. Die Daten verhalten sich wie unkomprimierbarer Zufall.

Solche Daten lassen sich fats garnicht von Zufallsdaten oder komprimierten Daten unterscheiden. Dazu müsste man auf die Header komprimierter Dateien testen. Nun entsteht logisch betrachtet eine Argumentationskette wenn man sagt

1.) es gibt verschlüsselte Daten die vorher komprimeirt wurden
2.) es gibt komprimierte Daten die vorher verschlüsserlt wurden

Solche Daten kann man nicht differenzieren. Eine verschlüsselte Datei kann komprimiert sein und eine komprimierte Datei mit ZIP Header kann auch verschlüsselt sein. Wie soll man das dann unterscheiden können ?

Man könnte auch sagen, es gibt Dateien mit teilweise verschlüsselten Daten. Diese besitzen durchaus Header etc.pp. die in einer Mustererkennung auf Gesamt-Dateibasis identifizierbar sind. Damit würden diese Dateien eben nicht mehr als verschlüsselte Daten erkannt.

Man kann Verschlüsselung also nur im Rahmen eines bekannten Kontextes erkennen und dafür gibt es vielzuviele Dateiformate bzw. verschiedene Verschlüsselungen.

Das gesamte Problem lässt sich bis auf einen Punkt reduzeren -> Wenn man Daten unterhalb einer informationstheoretischen Rauschgrenze verstecken kann dann kann es kein Verfahren geben das Daten nach verschlüsselt und unverschlüsselt differenzieren kann wenn nicht alle Rahmenbedingungen bekannt sind, dazu gehört im Besondenen das Paswort. Und exakt sowas gibt es, nennt sich Steganographie. Deshalb erachte ich die Wissenschaft der Steganographie, das Verstecken von Daten unterhalb der informationstheoretischen Rauschgrenze, auch als eine Wissenschaft der Kryptographie.
Dh. ohne das benutzte Passwort für den steganographsichen Algortihmus kann man die Daten nicht mehr aus der informationstheoretischen Rauschgrenze extrahieren, das ist ja der Sinn der Steganographie. Ergo kann mna auch nicht erkennen ob bei diesen Daten eine Verschlüsselung angewendet wurde.

Fazit: man kann verschlüsselte Daten nicht identifizieren, das geht nicht da wir die informationstheoretische Rauschgrenze nicht durchbrechen können ohne das Passwort zu kennen, das hat Heisenberg schon mit seiner Unschärferelation bewiesen.

OffTopic: dieser "Beweis" zeigt wie dämlich die politischen Forderungen eines Überwachungsstaates sind.

Gruß Hagen