Krypto-Provider / Krypto-Engines - Kooperationsangebot

[himitsu]

Bei den öffentlichen Sachen kann jeder reinsehen und Schachstellen/Backdors entdecken, welche dann auch behoben werden können.

Für "geheime" Algorithmen kann man z.B. über statistische Analysen einige Grundschlüsse ziehen und dann kann man immernoch via Reverse Engineering (des Verschlüsselungsprogramms) die Sache knacken.


Siehe DEC: Der Hagen hat massig Ahnung, von der Materie, und selbst er hat da viel Zeit dran gessessen, an seinen Verbesserungen der verschiedensten Standards.

Es gibt bestimmte Dinge, die man beachten sollte und selbst wenn man "denkt", man habe etwas super Sicheres erfunden, dann kann man bei der Implementierung immernoch irgendwo "Mist" bauen, womit das dann am Ende doch wieder so unsicher wie Klartext ist.
Und wenn da kein Anderer da mal drübergucken kann, dann fällt das einem garnicht auf, bis es einer der "lieben" Hacker entdeckt und es bekannt macht.

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1273537)

Siehe DEC: Der Hagen hat massig Ahnung, von der Materie, und selbst er hat da viel Zeit dran gessessen, an seinen Verbesserungen der verschiedensten Standards.

Und selbst er hat die Algorithmen nicht erfunden sondern „nur“ implementiert.

[mkinzler]

Zitat:

Die Idee des Open Source schätze ich aus verschiedenen Gründen wirklich sehr, aber nicht aus Gründen der Sicherheit. Den OPEN-SSL Bug, der tatsächlich von Geheimdiensten und Kriminellen ausgiebig genutzt wurde, ist sicher bekannt (Safer Mail war da glücklicherweise nie betroffen, da ich die BUG-Versionen - zugegeben per Zufall - ausgelassen hatte).

Und den Fehler hätte man schneller gefunden, wenn der Entwickler den Quellcode geheimgehalten hätte?
Das war ein Problem, der mangelden Kontrolle innerhalb des OpenSSl-Projektes, welcher auch in einem Closed Source Produkt auftreten kann und es bestimmt auch tut.

Zitat:

Ich muss gestehen, dass ich da dezidiert anderer Meinung bin. Öffentlicher Source-Code kann mir einen Angriff vereinfachen, denn ich muss nicht zuerst alles dekompilieren oder Schutzmechanismen vor Dekomilierung umgehen. Sondern ich sehe sofort die Schwachstellen für potentielle Angriffe, bin immer auf dem Laufenden, bei Veränderungen, usw.

Und genau da besteht der Vorteil der Offenlegung. Algorithmen/Verfahren sind von unzähligen Spezialisten auf Herz- und Nieren geprüft worden und deshalb sind die offensichtlichen Schwachstellen bereinigt.

@nuclearping: Steinigt den Erfinder des Messers. ;)

[nuclearping]

Zitat:

Zitat von mkinzler (Beitrag 1273539)

@nuclearping: Steinigt den Erfinder des Messers. ;)

Der Erfinder des Feuers hätte es mehr verdient. Damit fing der ganze Mist ja erst an! :mrgreen:

(Edit)

... Obwohl, vorm Feuer haben wir uns mit Steinmessern bekriegt. Also ja, AUF IHN! ;)

[bernau]

Zitat:

Zitat von nuclearping (Beitrag 1273527)

Dafür die Mitverantwortung zu tragen, war uns zu krass. Nicht mal vom rechtlichen her, sondern vom menschlichen. Also haben wirs gelassen.

Wenn man so denken würde, dann dürfte man so vieles nicht entwickeln oder anfertigen. Früher hat man Videokassetten mit Kinderpornos per Post versendet. Man hat werder Videokassetten verboten, noch die Post eingestellt. Alles kann missbraucht werden. Ist aber noch lange kein Grund dies als Grund zu nehmen, Dinge nicht für Gutes zu entwickeln.

[cookie22]

Zitat:

Zitat von Harry Stahl (Beitrag 1273528)

Meine Überlegung ging ja dahin, dass die personalisierten Krypto-Engines nicht öffentlich werden. Wenn die Verschlüsselungsalgorhytmen gut, aber nicht bekannt sind, wie sollte man dann auf dieser Basis verschlüsselte Daten entschlüsseln können?

Derzeit ist doch eines der Probleme, dass man Programme oder DLL's dekompilieren kann und somit die Algorhytmen dadurch wieder bekannt werden können. Dann muss man "nur" noch das Passwort ermitteln, per Brute-Force und der heutigen Rechnerkompotenz keine allzu lange Frage der Zeit und man hat die Daten.

Aber was, wenn der Algorhytmus nicht bekannt ist? Wie da einen Brute Force reiten?

Was du vorhast nennt man "Security by Obscurity". Das ist der größte Fehler den man im Kryptobereich machen kann. Solch eine Software wird niemand freiwillig benutzen. Weil man nicht nachweisen kann, dass der verwendete Algorithmus sicher ist und der verwendete Algorithmus richtig und fehlerfrei implementiert wurde.

Zitat:

Zitat von Harry Stahl (Beitrag 1273528)

Ich muss gestehen, dass ich da dezidiert anderer Meinung bin. Öffentlicher Source-Code kann mir einen Angriff vereinfachen, denn ich muss nicht zuerst alles dekompilieren oder Schutzmechanismen vor Dekomilierung umgehen. Sondern ich sehe sofort die Schwachstellen für potentielle Angriffe, bin immer auf dem Laufenden, bei Veränderungen, usw.

Das ist ein typischer Fehler, den "Krypto-Anfänger" machen. Kryptosoftware die nicht Open-Source ist, ist wertlos.

Man kann auch Open-Source Software vermarkten, denke nicht, dass man damit kein Geld machen kann.


Benutze lieber gut untersuchte Algorithmen, es gibt da ganz tolle Implementierungen für Delphi die sogar Crossplatform fähig sind. Schau mal hier.

http://www.wolfgang-ehrhardt.de/crypt_en.html

[mensch72]

Nehmen wir mal ein schönes Beispiel:
- wir erzeugen für "RndWord=Encode(RealWord)" uns ein zufälliges WordArray aus 65536(2^16) Werten im Bereich von 0..65535(0..2^16-1) per "http://www.random.org"
- wir erzeugen temporär ein 2. "inverses" WordArray aus 65536(2^16) Werten im Bereich von 0..65535(0..2^16-1) um "RealWord=Decode(RndWord)" zu bekommen
- das entspräche einer Keylänge von 128KByte = !1048576Bits! = !1MBit! Keylänge...
- das ganze ist nur solange sicher, wie die 128KB Keytable "geheim" bleibt
- wir packen die 128KB Table in den internen Flash eines MicroControlers nd schützen den auf Hardwarelevel als "ReadProtected+ExecuteOnly"
- wir ergänzen noch einen Hash-Algo über den Key, sodass nur wenn der "PublicHash" stimmt die interne Logik anläuft... also der "Hashwert" identifiziert die verwendete 128KB-KeyTable
- beim Sender ergäbe der "PlainText" und dann als "PublicOutput" den "PublicHash"+"CryptText"(der Hashwert vom KeyTable im Hardwareflash wird von/in der Hardware berechnet)
- beim Empfänger ergäbe "PublicHash"+"CryptText" als "PublicInput" dann den wieder den "PlainText" (wenn die zum Hashwert passende KeyTable im Hardwareflash existiert)

Wenn die Plaindaten stets BZIP gepackt sind, dann ist das Verfahren so sicher wie die Geheimhaltung der Hardwaremodule wo der 1MBit-Key drin ist.
Das Verfahren ist "offen", nur die 1MBit KeyFiles mit z.B. von "Random.org" oder woher auch immer gefütterten Zufallssequenzen sind innerhalb der Kommunikationspartner(-gruppen) geheim.
Der Anbieter/Erzeuger des Providers hat ohne passende KeyTable keinen Zugriff auf die Daten der Nutzer. Konzeptionell ähnlich mit ClientToClient Verschlüsselung arbeitet "Mega", der aktuelle FileSharer von KimSchmitz.


In wie fern Anbieter von Diensten/Programmen mit "starker" ClientToClient Verschlüsselung gemäß Gesetz in der EU doch eine Hintertür für den "ManInTheMiddle" einbauen müssen, das will ich gerade gar nicht wissen.


Ob ich mir das gerade ausgedacht habe, oder sowas eventuell schon existiert, das habe ich gerade vergessen.

!!!Und wer erkennbar verschlüsselte Daten verschickt, erweckt nur der Spiel-/Jagdtrieb bestimmter Leute. Sowas muss dann mindestens im Alphachannel oder besser im YUV Offest eines schönen Fotos im Anhang einer netten Grußkarten-Mail "verschwinden"!!!

[cookie22]

Zitat:

Zitat von mensch72 (Beitrag 1273556)

In wie fern Anbieter von Diensten/Programmen mit "starker" ClientToClient Verschlüsselung gemäß Gesetz in der EU doch eine Hintertür für den "ManInTheMiddle" einbauen müssen, das will ich gerade gar nicht wissen.

Da muss keiner was einbauen. ;)
Soweit ist es noch nicht.

[Puke]

Die Idee finde ich richtig gut! :thumb::thumb::thumb: Natürlich müssen die Algorithmen veröffentlicht sein, ABER man kann erstens NSA & Co. mit mehreren verschiedenen Verfahren austricksen (muss ja kein Public-Key-Verfahren sein ...), weiterhin kann man verschiedene Verschlüsselungsverfahren kombinieren.

Und wenn man Hagens DEC-Varianten schon einbauen würde (ich weiß jetzt nicht, ob das Lizenzrechtlich geht und ob Hagen das möchte), hätte man schon eine ordentliche Variation an Algorithmen.

Gruß Puke

PS: Vielleicht könnte man ja ein Steganografie-Verfahren später noch einbauen :-D

[Harry Stahl]

Vielen Dank erst mal für Eure Antworten.

Ich bin immer offen für Argumente. Ich hätte auch keine Probleme damit, wenn ein Krypto-Provider eine Krypto-Engine auf der Basis von starken und "sicheren" Open Source Algorhytmen entwickelt.

Man kann hier ja durchaus auch mehrgleisig fahren. Die "bessere" Variante setzt sich dann am Ende eben durch.