Eure Meinung zum Thema Verschlüsselung?

[Codehunter]

Hallo!

Zum Thema DEC 5.3 gab es die Tage schon einmal eine Diskussion zu dem Thema, nur dort etwas OT. Darum will ich hier mal eine separate Diskussion dazu aufmachen.

Grundsätzlich habe ich z.B. das Problem, dass ich von Verschlüsselung nicht allzu viel verstehe. Das heißt, ich kann zwar eine Crypto-Suite wie DEC integrieren. Jedoch kann ich beim besten Willen nicht einschätzen, wie gut eine Implementierung und meine Integration ist. Noch weniger könnte ich an solchen Suites mitentwickeln.

Wie mir scheint, ist die ganze Thematik zum Teil durchsetzt mit paranoiden oder verschwörungstheoretischen Ansichten. Compiler ersetzen beim Kompilieren starke Algorithmen durch schwache usw. Wenn dem so wäre, müßte sich dann das FBI mit Apple öffentlichkeitswirksam um die Entschlüsselung eines iPhones streiten? Nur mal so als Beispiel. Darauf will ich aber gar nicht hinaus.

Mir geht es mehr darum, wie wir das Thema Kryptografie in Zukunft besser angehen können. Native Algorithmen in Object Pascal sind dünn gesät. Fähige Programmierer wie Assarbad, Hagen Reddmann und Assertor sind rar bzw. wenden sich irgendwann "einträglicheren" Sprachen wie C++/# oder Java zu, mit denen man mehr Geld verdienen kann.

Wenn man mit seiner Software selbstständig Geld verdienen will, dann ist man ja umso mehr in der Pflicht, sich um die Qualität Gedanken zu machen bzw. der Schaden ist umso größer wenn man irgendwann mal mit einem seiner Produkte als Einfallstor für irgendeine Schadsoftware missbraucht wird.

Ich bin der Meinung, da fehlt etwas im großen Pool allgemein verfügbarer Delphi-Bibliotheken. Denn ich kenne keine Delphi-native Crypto-Lib, die auf der Höhe der Zeit ist. Beim DEC sehe ich viele Schwächen (z.B. 64 Bit, Unicode etc.) und das obwohl DEC immer noch als die Referenz in Delphi-Crypto angesehen wird.

Zweitens, wenn ich mal von mir selbst ausgehe, sind wir Delphi-Entwickler schwerpunktmäßig mit Datenbanken unterwegs. Kryptografie ist ein Thema für sich und da sehe ich einigen Nachholbedarf wenn es um das Verständnis der Technik geht. Das ist so ähnlich wie beim Blitzschutz: Halbe Verschlüsselung ist gar keine Verschlüsselung.

Wie seht ihr das?

Grüße
Cody

[Neutral General]

Es gibt ernsthaft Leute die glauben der Compiler würde Verschlüsselungsalgorithmen beim Compilieren durch schwächere Algorithmen ersetzen? :mrgreen:
Das ist schon irgendwie traurig. :roll:

Ansonsten ist mir nicht ganz klar was du hier genau fragst, bzw. welche Antworten du haben möchtest.

Dass es an einigen (aktuellen) Bibliotheken mangelt stimmt schon.
Und ich fände es eigentlich auch schön wenn die Mitglieder der Delphi-Praxis das ein oder andere zusammen entwickeln würden.

Dazu habe ich ja im Ansatz schon mal einen Thread erstellt vor ein paar Monaten:
http://www.delphipraxis.net/186962-v...rschlaege.html

Wir sind die größte (zumindest deutsche) Delphi Community mit einigen sehr fähigen Leuten und ich denke wir wären durchaus in der Lage unsere Träume was fehlende Bibliotheken/Komponenten/etc angeht selbst zu erfüllen :)

[Delphi-Laie]

Zitat:

Zitat von Codehunter (Beitrag 1331934)

Fähige Programmierer wie Assarbad, Hagen Reddmann und Assertor

Würde ich auf jeden Fall noch Sebastian Jänicke hinzuzählen, auch Michael Puff alias Luckie.

Zitat:

Zitat von Codehunter (Beitrag 1331934)

sind rar bzw. wenden sich irgendwann "einträglicheren" Sprachen wie C++/# oder Java zu, mit denen man mehr Geld verdienen kann.

Kann man das wirklich?

[Benedikt Magnus]

Zitat:

Zitat von Delphi-Laie

Zitat:

Zitat von Codehunter

Fähige Programmierer wie Assarbad, Hagen Reddmann und Assertor

Würde ich auf jeden Fall noch Sebastian Jänicke hinzuzählen, auch Michael Puff alias Luckie.

Und noch sehr viele mehr.

Zitat:

Zitat von Neutral General

Dass es an einigen (aktuellen) Bibliotheken mangelt stimmt schon.

Da kann ich nur bedingt zustimmen. Ich habe mich seeehr lange mit Verschlüsselung rumgeschlagen, ohne große Erfolge verzeichnen zu können. Aber seitdem ich mit CodeTyphon arbeite (wegen Linux) habe ich da eine Menge gefunden.
Symmetrisch kann man, auch was Hashing angeht, einiges mit Hilfe der Komponenten von DCPcrypt anfangen (und noch weiteren). (Originalseite und zwei Weiterführungen: Hier und hier.
Was Authentifikation/asymm. Verschlüsselung angeht, bin ich mittlerwiele vollkommen auf TLS umgestiegen. Besonders bequem geht das über die IOHandler der Indys, alternativ kann man auch die (sehr gut dokumentierten) SSL-Bibliotheken selbst verwenden. Auch gibt es da noch ein paar Komponenten, die SSL/TLS unterstützen.

[Neutral General]

Die Aussage mit den Bibliotheken war nicht nur auf Verschlüsselung bezogen sondern allgemein.
Mir z.B. hat DEC bisher immer noch gereicht, auch ohne Unicode und 64-Bit Unterstützung.
Das hängt halt immer vom Projekt oder/und den (eigenen) Anforderungen ab.

[4dk2]

Zitat:

Zitat von Codehunter (Beitrag 1331934)

Hallo!
Ich bin der Meinung, da fehlt etwas im großen Pool allgemein verfügbarer Delphi-Bibliotheken. Denn ich kenne keine Delphi-native Crypto-Lib, die auf der Höhe der Zeit ist. Beim DEC sehe ich viele Schwächen (z.B. 64 Bit, Unicode etc.) und das obwohl DEC immer noch als die Referenz in Delphi-Crypto angesehen wird.

Wie kommst du darauf, dass die Schwächen bei 64 bit und Unicode liegen?
Ich mein, die Algorithmen in DEC verschlüsseln ja auf Byte Ebene. Da ist es ja egal, ob das nun Unicode String oder Ansi ist.
Klar man muss bei der Handhabung darauf achten ( Die String-Länge bei Unicode ist halt nicht die Binär-Länge).

Und 64 Bit spielt glaube ich auch keine Rolle.

Das die Algorithmen wie z.b. AES im allgemeinen schwächen aufweisen, ist ja was anderes. Bei andern Programmiersprachen ist es aber genauso.

Wenn du dich nicht an geforderte Standards halten musst, kannst du ja auch mehrere Verschlüsselungen Kombinieren.
Jag die Daten erst durch A mit KeyA und dann durch B mit KeyB.

[Neutral General]

Zitat:

Zitat von 4dk2 (Beitrag 1331965)

Und 64 Bit spielt glaube ich auch keine Rolle.

64-Bit spielt eine große Rolle, denn ein Großteil des DEC ist in (32-Bit)Assembler geschrieben und läuft dementsprechend nicht in einem 64-Bit Prozess.

[4dk2]

Zitat:

Zitat von Neutral General (Beitrag 1331966)

64-Bit spielt eine große Rolle, denn ein Großteil des DEC ist in (32-Bit)Assembler geschrieben und läuft dementsprechend nicht in einem 64-Bit Prozess.

OK hast recht.

Google(auch Delphi-Praixs) ist voll mit 64 bit umsetzungen für die ASM routinen.
Leider hab ich auch auf die Schnelle keine veröffentlichte gefunden.

[Namenloser]

Zitat:

Zitat von Codehunter (Beitrag 1331934)

Wie mir scheint, ist die ganze Thematik zum Teil durchsetzt mit paranoiden oder verschwörungstheoretischen Ansichten. Compiler ersetzen beim Kompilieren starke Algorithmen durch schwache usw.

Bei dem Thema paranoid zu sein ist doch berechtigt. Die Geschichte der Verschlüsselung ist eine einzige von Sabotage und Verschwörungen, vor allem in der jüngsten Zeit. Guck dir doch mal an, wie die NSA Verschlüsselungsstandards sabotiert hat.

Zitat:

Zitat von Neutral General (Beitrag 1331952)

Es gibt ernsthaft Leute die glauben der Compiler würde Verschlüsselungsalgorithmen beim Compilieren durch schwächere Algorithmen ersetzen? :mrgreen:
Das ist schon irgendwie traurig. :roll:

Wirklich glauben wohl eher nicht. Ich habe das aber auch schon als theoretisches Konstrukt gehört. Weil jeder Compiler letztlich irgendwann mal von einer anderen Binary kompiliert werden musste, könnte es theoretisch Backdoors im Compiler geben, die im Source Code des Compilers nicht mal vorhanden sind. Diese Backdoor würde sich bei jeder Kompilierung wie ein Virus immer weiter in neuere Versionen des Compilers fortpflanzen und natürlich auch in jede andere kompilierte Software. Das wäre sehr schwer festzustellen.

Ist ein interessanter Gedanke, wenn auch nicht unbedingt realistisch, vor allem angesichts der Tatsache, dass man die Hardware selbst wesentlich einfacher, effektiver und zuverlässiger manipulieren kann.

Zitat:

Zitat von Codehunter (Beitrag 1331934)

Wenn dem so wäre, müßte sich dann das FBI mit Apple öffentlichkeitswirksam um die Entschlüsselung eines iPhones streiten? Nur mal so als Beispiel.

Weil es unterschiedliche Geheimdienste gibt. Bloß weil z.B. die NSA etwas kann, heißt das nicht, dass das FBI es auch kann. Es wäre zudem dumm, für irgendwelche Bagatellfälle Hintertüren zu „verbrennen“. Man will ja möglichst, dass sie nicht bekannt werden. Außerdem, warum die Mühe machen, wenn man Apple auch einfach freundlich nach den Daten zu fragen kann. Dazu ist die ganze Geschichte eh eine Farce:

Zitat:

Zitat von http://www.nytimes.com/2016/02/19/technology/how-tim-cook-became-a-bulwark-for-digital-privacy.html

Apple had asked the F.B.I. to issue its application for the tool under seal. But the government made it public, prompting Mr. Cook to go into bunker mode to draft a response, according to people privy to the discussions, who spoke on condition of anonymity. The result was the letter that Mr. Cook signed on Tuesday, where he argued that it set a “dangerous precedent” for a company to be forced to build tools for the government that weaken security.

Das heißt, wenn das FBI den Antrag nur nicht öffentlich gemacht hätte, was sie hätten tun können, dann hätte Apple die Daten ohne einen Mucks rausgegeben. Apple wollte bloß keine schlechte PR. Das FBI hat es aber öffentlich gemacht und so hat Apple den Spieß dann umgedreht und daraus positive PR für sich gemacht.
Außerdem sagt Edward Snowden, dass das FBI auch ohne Hilfe von Apple Zugriff auf den Inhalt des iPhones bekommen könnte:
https://twitter.com/snowden/status/700823383961792512

Also ist nicht ganz klar, was genau da hinter den Kulissen abgeht.

Sorry, wenn zu sehr Off-Topic. Mir ist nicht ganz klar, wo du mit dem Thread hin willst.

[Neutral General]

Zitat:

Zitat von Namenloser (Beitrag 1332001)

Wirklich glauben wohl eher nicht. Ich habe das aber auch schon als theoretisches Konstrukt gehört. Weil jeder Compiler letztlich irgendwann mal von einer anderen Binary kompiliert werden musste, könnte es theoretisch Backdoors im Compiler geben, die im Source Code des Compilers nicht mal vorhanden sind. Diese Backdoor würde sich bei jeder Kompilierung wie ein Virus immer weiter in neuere Versionen des Compilers fortpflanzen und natürlich auch in jede andere kompilierte Software. Das wäre sehr schwer festzustellen.

Ist ein interessanter Gedanke, wenn auch nicht unbedingt realistisch, vor allem angesichts der Tatsache, dass man die Hardware selbst wesentlich einfacher, effektiver und zuverlässiger manipulieren kann.

Eine Hintertür halte ich noch für halbwegs realistisch aber wenn der Compiler ganze Algorithmen bei der Compilierung austauschen soll, ohne dass das auffällt dann ist das in meinen Augen eine ganz andere Liga.
Der Compiler müsste ja den Quelltext analysieren und bestimmte Algorithmen anhand des Codes erkennen und diesen dann so umbauen, dass der Code immernoch funktioniert. Das halte ich für mehr als unwahrscheinlich.

Und ich denke dass irgendwem eine Backdoor wie von dir beschrieben aufgefallen wäre. Sollte ja relativ einfach mit einem Debugger/Disassembler und einer minimalen exe nachzuprüfen sein.