Sichere Anwendung - OpenSource-Fähigkeit

[qwert_zuiopue]

Halllo ,

ich möchte gerne eine OpenSource-Software schreiben, die Daten verschlüsselt in eine Datenbank eintragen kann. Dazu verwende ich HttpPost in Verbindung mit PHP und SQL. Nun möchte ich aber die Schnittstelle für die Datenbank nicht herausgeben, ansonsten wäre für jegliche Angriffe Tür und Tor geöffnet.
Ich denke darüber schon länger nach aber mir fällt dazu leider nichts brauchbares ein. Deswegen möchte ich hier fragen, ob es eine Möglichkeit gibt, die Software komplett open source zu haben und dennoch die Schnittstelle für die Datenbank geheim zu halten.

Vielen Dank für eine Antwort !

 

[Kiwi++Soft]

Eine Anwendung wird durch 'Nichtoffenlegen' der Datenbankschnittstelle nicht sicher, das Prinzip 'Security by Obscurity' funktioniert im allgemeinen nicht gut.

Du solltest Dir dabei über eine Sache im klaren sein: Alles, was eine Maschine ohne Hilfe eines Menschen auslesen kann, kann niemals sicher sein. Sicher wären Daten nur, wenn sie verschlüsselt sind, und der Schlüssel von dem Menschen eingegeben wird, und nicht auf dem Maschine gespeichert wird.

Werden Daten mit irgendeinem Verfahren verschlüsselt, aber die Maschine kann ohne Schlüsseleingabe die Daten lesen, so spricht man nur noch von verschleiert.

Daher hast Du folgende Möglichkeiten:

• Du bleibst bei Deinem Konzept, und lieferst das 'Zugriffsmodul' als fertig kompilierte Bibliothek aus. Dann kann man es neben den Opensource Teil als fertige Komponente mit in Projekt einbinden.
• Du baust einen Mechanismus, der einen zufälligen Schlüssel generiert in die Software mit ein, der Schlüssel wird genutzt, um die Daten beim Speichern zu verschlüsseln, und beim Lesen zu entschlüsseln, der Schlüssel wird auf dem Gerät gespeichert.
• Du lässt den Benutzer einen Schlüssel (Passwort) eingeben, den Du zum verschlüsseln nutzt und zum Entschlüsseln. Der Schlüssel muss jedesmal vom Nutzer neu eingegeben werden.

 

[qwert_zuiopue]

Ich glaube, du hast nicht ganz auf meine Frage geantwortet , oder meine Frage war nicht gut genug gestellt.

Die Software arbeitet so, dass der Benutzer beim Start der App ein Kennwort eingibt. Dieses wird verwendet um den verschlüsselten privaten Schlüssel einer RSA-Verschlüsselung zu entschlüsseln - der unverschlüsselte private Schlüssel liegt also nur im Arbeitsspeicher. Im Prinzip also das, was du als 3. Methode beschrieben hast.
Meine Frage ist nun, wie ich es anstelle, dass der Nutzer nachprüfen kann, dass sein privater Schlüssel niemals in die Datenbank eingetragen wird. Mein Ansatz dazu war, den Code vollständig offen zu legen. Dann kann der Nutzer aber unkontrolliert Daten in die Datenbank eintragen und auslesen.
Gibt es vielleicht andere Möglichkeiten?

 

[Kiwi++Soft]

Mein Ansatz dazu war, den Code vollständig offen zu legen. Dann kann der Nutzer aber unkontrolliert Daten in die Datenbank eintragen und auslesen.
Gibt es vielleicht andere Möglichkeiten?

Entweder ist das Problem noch immer unklar, oder ich habe es falsch verstanden.

Ich habe den Eindruck, wir sind, wenn auch auf anderer Ebene, in der gleichen Situation:

Wenn die Sicherheit davor, dass der User keine Daten in die Datenbank unkontrolliert ein- und ausgibt nur in der Unkenntnis des Zugriffscodes liegt, ist das eine schwache Sicherheit.

 

[qwert_zuiopue]

Ja, das stimmt. Das ist auch eine Schwachstelle.
Dann muss ich das Zugriffsskript also auch mit einem Passwort versehen bzw. das Passwort für die Datenbank dem Skript mit übergeben. Doch dann habe ich wieder das Problem, dass ich nicht weiß, wohin mit dem Passwort.

 

[rihntrha]

Fangen wir mal ganz von vorne an. Warum möchtest du die Schnittstelle nicht Offenlegen?

Willst du das, damit niemand anders Software schreiben kann die deine Schnittstelle nutzt? Das wäre der einzig sinnvolle Grund. Allerdings funktioniert das nicht wirklich, es erschwert die Sache nur.

Oder willst du die Schnittstelle geheim halten um die Sicherheit des Systems zu erhöhen? Das wäre Blödsinn, dadurch das man etwas geheim hält erhöht sich die Sicherheit nicht im geringsten.


Alles in allem macht es grundsätzlich keinen Sinn irgendeine Schnittstelle geheim zu halten.

Beschreib mal konkret was du vor hast, ich denke dein Ansatz ist schon grundlegend falsch.

cu

 

[qwert_zuiopue]

Ok.

Es geht um einen Messanger über den geheime Nachrichten ausgetauscht werden. Nun soll jeder Nutzer nachprüfen können, dass ich als Eigentümer der Datenbank und Programmierer der App nicht auf die privaten Schlüssel zugreifen kann und somit die Daten auch für mich nicht lesbar sind.

Meine Überlegungen gehen davon aus, dass etwas geheim gehalten werden muss, denn sonst hätte jeder Nutzer uneingeschränkten Zugriff auf die Datenbank und könnte dadurch Nachrichten entfernen.

Ja, das rot unterstrichene ist das einzige Ziel. Meine bisherigen Ansätze waren Mittel zum Zweck, wenn es andere Ansätze gibt, dann her damit .

 

[rihntrha]

Wenn jeder Nutzer (der die Schnittstelle kennt) uneingeschränkten Zugriff auf die Datenbank hat, dann ist die Schnittstelle Mist ;-)

Der User muss sich der Schnittstelle gegenüber irgendwie Identifizieren/Authentifizieren. Und dann erlaubt ihm die Schnittstelle natürlich nur Sachen die für ihn vorgesehen sind (z.B. Nachrichten abrufen die für ihn bestimmt sind).

D.h. die Schnittstelle bestimmt, was derjenige der sie gerade anspricht darf und nicht darf.

Das was du offenbar vorhast ist die Schnittstelle offen zu lassen wie ein Scheunentor. Und dann die App so zu programmieren das schon nix falsches genutzt wird.
Das klappt aber nur so lange wie deine App genutzt wird. Spricht jemand die Schnittstelle direkt an (und das ist einfach, auch wenn du die Beschreibung geheim hältst) dann darf er alles. Das ist also ein extrem unsicheres Konzept.

cu

 

[qwert_zuiopue]

Das was du offenbar vorhast ist die Schnittstelle offen zu lassen wie ein Scheunentor. Und dann die App so zu programmieren das schon nix falsches genutzt wird.
Das klappt aber nur so lange wie deine App genutzt wird. Spricht jemand die Schnittstelle direkt an (und das ist einfach, auch wenn du die Beschreibung geheim hältst) dann darf er alles. Das ist also ein extrem unsicheres Konzept.

Das ist richtig, genau so hab ich es momentan umgesetzt .

Was schlägst du konkret zur Lösung vor?
Du sagst, der Nutzer müsse sich authentifizieren. Wie setze ich sowas konkret um? (Meine PHP-Kenntnisse sind momentan auf Copy&Paste beschränkt ) Und wenn ich aber bestimmten Nutzern nur bestimmte Sichten auf meine Datenbank erlaube, wer garantiert dann, dass ich nicht in meiner nur für mich sichtbaren globalen Datenbank die privaten Schlüssel abspeichere?

 

[rihntrha]

Was schlägst du konkret zur Lösung vor?

PHP üben und einfach anfangen

Für den Anfang wäre es IMHO vernünftig auf altbewährtes zu setzen auch wenn es mittlerweile beseres gibt. Es schadet nie erstmal die Grundlagen zu lernen.

Also, REST API mittels json/xml. Dein Server akzeptiert nur https Verbindungen. Du erstellst selbst ein https Zertifikat (muss nicht signiert werden) und lieferst den öffentlichen Teil in deiner App mit. Dann legst du bei https Verbindungen mit deinem API Server fest das nur dieses Zertifikat genutzt wird.

Dann ist das Reden mit dem API Server schon mal brauchbar abgesichert (wichtig damit z.B. niemand dein Passwort mitschnüffeln kann oder die Anfragen unterwegs manipulieren).

Dann, für den Anfang die Identifizierung mittels Benutzername/Password dürchführen (bei jeder Anfrage mitschicken. Dann weiss die API von wem die Anfrage kommt und kann entschieden ob die Anfrage rechtmässig ist).

Und wenn ich aber bestimmten Nutzern nur bestimmte Sichten auf meine Datenbank erlaube, wer garantiert dann, dass ich nicht in meiner nur für mich sichtbaren globalen Datenbank die privaten Schlüssel abspeichere?

Wenn das Projekt Open Souce ist und du netterweise noch eine saubere Beschreibung der Schnittstelle mitlieferst, dann kann das jeder nachvollziehen.


Und so als Tipp, das Thema "sicherer Messenger" ist noch weitaus komplexer. Das hier ist nur der Anfang. Soll das wirklich richtig sicher sein dann brauchst du erstmal viel solides Grundlagenwissen zum Thema Verschlüsselung (nein, ich bin auch weit davon entfernt das zu haben). Man kann bei der Sache so unglaublich viel falsch machen.

Das oben zkizierte Konzept ist nur das absolute Minimum.

cu

 

[qwert_zuiopue]

Ok. Vielen Dank für deine Erläuterung .

Ich hatte eben einen anderen Einfall:
- Ich schreibe eine App, die im Hintergrund läuft und die Datenbank synchronisiert auf dem Smartphone speichert und umgekehrt
- Eine weitere App - die eigentliche Messanger-App, die den privaten und öffentlichen Schlüssel generiert und den privaten Schlüssel verschlüsselt abspeichert, kann dann vollkommen transparent geschrieben werden, denn dann hat meine App offensichtlich niemals Zugriff auf den privaten Schlüssel, der lediglich im Arbeitsspeicher des Smartphones unverschlüsselt vorliegt
- Durch Offenlegung und Dokumentation der Schnittstellen kann jeder selbst eine derartige Messanger-App basteln
- Und selbstverständlich muss dann - wie du geschrieben hast - die Hintergrund-App über https kommunizieren

Das sollte für den Anfang reichen, oder?

Ich interessiere mich sehr für das Thema und möchte mit diesem Projekt vor allem auch etwas dazu lernen. Auf Anhieb fällt mir jetzt nichts ein, wie ein Angreifer dann noch an die Daten kommen soll oder meine Datenbank manipulieren kann. Wenn es noch was gibt - und wenn es nur Stichworte sind - wäre ich für weitere Sicherheitsmängel-Hinweise sehr dankbar .

 

[Kiwi++Soft]

Ich würde folgenden Vorschlag machen:

Es gibt eine Client- und eine Server-Anwendung.

Ein Client benötigt folgende Daten:

• Ein Username/Passwort, um an der ganzen Geschichte teilnehmen zu können.
• Ein Public/Private Key, der auf dem Client generiert wird und in einem Passwort geschützten Keystore auf dem Client liegt.
• Einen Public Key des Servers

Der Server bekommt folgende Daten:

• Den public Key des User
• Einen mit einem Secure Hash erzeugten Hash des Passworts des Users (* Siehe wichtige Anmerkung unten))
• Den Public/Private Key des Servers

Einloggen des Client am Server:

• Der Client schickt den Benutzer-Namen, mit dem Public Key des Servers verschlüsselt.
• Der Server antwortet mit einem kurzen zufälligen Byte-Paket, der sog. Challange, verschlüsselt mit dem private Key des Servers
• Der Client antwortet damit, dass er die Challange mit dem hash seines Passworts verschlüsselt, dann die Antwort mit dem Public Key des Servers verschlüsseln.

Nachrichten an andere User versenden:

• Nachricht mit dem eigenen Private Key signieren
• Addressliste der Empfänger an den Server senden (verschlüsselt mit dem Public Key des Servers
• Public Keys der Empfänger vom Server an den Client, mit dem private Key des Servers
• Nachrichten mit den Public Keys des Empfängers verschlüsseln, verschlüsselt mit den Public Key des Servers an den Server senden.

Nachricht vom Server empfangen:

• Nachricht verschlüsselt mit dem eigenen Public und dem Private Key des Servers empfangen und entpacken.
• Public Key des Senders, verschlüsselt mit dem Private Key des Servers empfangen.
• Signatur der Nachricht prüfen.

Das sollte relativ sicher sein.

(*) Es ist üblich, nicht nur das Passwort des Users zu hashen, sondern noch ein 'Secure Random' Zufalszahl dazu zu nehmen, damit nicht zwei User mit dem zufällig gleiche Passwort den gleichen 'Hash' haben.


GGF nochmal nachdenken, wo eine Lücke sein könnte, die ich übersehen habe

 

[asagk1963]

Ad hoc fällt mir dazu ein, daß langzeit Angriffe eines 'man in the middle' ohne OTP bei der beschriebenen Vorgehensweise nicht grundsätzlich auszuschließen sind, da die verwendeten Schlüssel stets wiedholend auf einem beschränkten Zeichenvorrat Anwendung finden, und somit mit statistischen Werkzeugen der Kryptoanalyse recht gute Angriffspunkte liefern.
Andererseits ist die zur Verfügungstellung 'starker' Kryptographie, wenn ich mich recht entsinne, in Deutschland strafbewährt. Ein Messenger, der dritten zur Verwendung angeboten wird und 'starke' Kryptographie beinhaltet, sprich von Geheimdiensten nicht 'mitgelesen' werden kann, dessen Verbreitung wäre dann möglicherweise ein Rechtsverstoß. Doch ich hab' da gerade auch nicht die entsprechende Gesetzesvorlage zur Hand.
Um sicher zu gehen, am besten mal nach googlen (keywords: Kryptographie, Gesetzeslage, etc. pp.).

 

[qwert_zuiopue]

Danke, an den rechtlichen Teil hab ich nicht gedacht. Muss ich mich noch informieren.

 

[TheDarkRose]

Andererseits ist die zur Verfügungstellung 'starker' Kryptographie, wenn ich mich recht entsinne, in Deutschland strafbewährt. Ein Messenger, der dritten zur Verwendung angeboten wird und 'starke' Kryptographie beinhaltet, sprich von Geheimdiensten nicht 'mitgelesen' werden kann, dessen Verbreitung wäre dann möglicherweise ein Rechtsverstoß.

Wo hast den das aufgeschnappt? Klar gibt es Länder bei denen Kryptographie verboten ist, aber definitiv nicht hier. Dann wäre die Verwendung von SSH oder sogar HTTPS auch illegal.

 

[asagk1963]

siehe: http://www.selflinux.org/selflinux/html/gpg_handbuch_kapitel_502.html
unter Punkt 3.

" Das sogenannte en Wassenaar Abkommenstuft starke Kryptographie als Kriegswaffe ein und sieht vor, dass seine 33 Mitgliedsstaaten (zu denen auch die Bundesrepublik Deutschland gehört) die Ausfuhr von kryptographischen Produkten mit einer Schlüssellänge von mehr als 64 Bit kontrollieren. [1] Der Export kryptographischer und kryptanalytischer Technologien unterliegt zwar prinzipiell nach §§ 7 Abs. 1, 5 Abs. 1 AWG einem Genehmigungsvorbehalt, aber kryptographische Produkte, die frei auf dem Massenmarkt erhältlich sind, können gegenwärtig ohne Genehmigung aus der Bundesrepublik ausgeführt werden. "

Nun ist RSA zwar per se ohnehin keine 'starke' Kryptographie, da diese mit einer Hintertür entwikelt wurde, und deshalb für Geheimdienste recht gut lesbar ist, doch die Anmerkung war auch ehr allgemein angedacht. 'Starke' Kryptographie hingegen, welche auch militärischen/geheimdienstlichen Zwecken dienen könnte, ist per Gesetz regelmentiert und die Ausfuhr eingeschränkt.

Eine Veröffentlich auf GooglePlay käme möglicherweise einer Ausfuhr gleich, je nach verwendetem kryptographischen Algorithmus & Schlüssellänge.

Deshalb auch der Hinweis, sich doch da vorher mal schlau zu machen. In den USA sind Schlüsselgrößen ab 128+ bit aufwärts streng relementiert, ähnlich wie auch Kiregswaffen. Das gilt im übrigen auch für viele andere Länder der Welt, in denen Kryptographie durch Privatpersonen teilweise sogar gänzlich untersagt ist. Da drängt sich dann doch die Frage auf, welches die Zielgruppe und Verteilungsmechanismus für die geplante APP sein sollen. Eventuell ist Play-Google nicht der richtige Platz für einen solchen Messenger, je nach verwendeter Verschlüsselung und Schlüsselgröße.
Unter Umständen wäre der "Export" zudem auch in der BRD melde- und genehmigungspflichtig, was jedoch RSA sicherlich nicht betrifft, da bekanntermaßen schwach, und deshalb auch auf dem Massenmarkt frei erhältlich.

Der ursprüngliche Beitrag von 21:31 Uhr wurde um 21:48 Uhr ergänzt:

ps.: Was HTTPS/TLS und SSH angeht, diese sind im Zusammenspiel mit den öffentlich verfügbaren Kryptomodulen (DES, 3DES, RSA, AES, IDEA, Blowfish, etc.) deshalb frei zugänglich, weil sie eben schwach sind bzw. für die öffentliche Verwendung abgeschwächt wurden; sprich zwar dem Privatnutzer vor anderen Privatnutzern gewissen Schutz bieten, jedoch gleichzeitig von den Geheimdiensten gut lesbar sind. Ansonsten wären diese nämlich nicht frei zugänglich.

Der ursprüngliche Beitrag von 21:48 Uhr wurde um 21:59 Uhr ergänzt:

pps.: Zum Vergleich, eigene Kryptographie, mittels linear rückgekoppelter Schieberegister (LFSR), wie auch vom Militär u.a. in der Satellitentechnik (Key-Hole-Satelliten usw.) verwendet, wäre sicherlich genehmigungsbedürftig, da potentiell stark, sofern die Schieberegistergröße ausreichend groß und die Rückkopplung entsprechend ausgelegt ist. Da wäre auch der Bereich, da auch in Deutschland deutliche Restriktionen durch Gesetze und internationale Verträge vorgesehen sind.

 

[Kiwi++Soft]

Es bleiben meinerseits noch weitere Fragen offen:

Erstens:

Nach meinem Verständnis basieren HTTPS und SSL auch wenn Client und Server über RSA Public/Private Keys verfügen, nicht auf diesen Keys, sondern im Höchstfall werden diese dazu verwendet, einen 'Transfer-Key' auszutauschen, und dieser ist meines Wissens nach auf 56 Bytes beschränkt.

Ebenso wird die Nachricht in der 'AS1/AS2/AS3' Kommunikation nicht mit den Public/Private Keys von Sender/Empfänger verschlüsselt, sondern nur mit einem Transfer-Key, und nur der Transfer-Key selbst wird mit dem Public Key des Empfängers verschlüsselt.

Damit ist auch hier Verschlüsselungs-Stärke auf die Schlüssellänge des Transfer-Keys abgeschwächt.

Liegt die 'Angreifbarkeit' dieser Protokolle damit in der Schwäche der Transfer-Keys begründet, oder im RSA-Key selbst?

Denn die 'Mathematische Grundlage' des RSA-Keys ist ja eigentlich soweit sicher, dass eine Angreifbarkeit des RSA-Algorythmus nicht System-Immanent sein muss.

Oder liegt es daran dass die erzeugten Public Keys immer mit dem Exponent 65537 erzeugt werden (ich habe mich schon lange gefragt, wieso die alle den gleichen Exponenten haben...), was ja eine prinzipielle Einschränkung der 'Erzeugenden Primzahlen' p und q bedeutet, da (p-1) * (q-1) teilerfremd zu 65537 sein muss.

BTW:

Nun ist RSA zwar per se ohnehin keine 'starke' Kryptographie, da diese mit einer Hintertür entwikelt wurde, und deshalb für Geheimdienste recht gut lesbar ist...

Hast Du evtl eine Quelle zu dieser Aussage?

Zweitens:

Wenn man sich Standart-Java auf dem PC installiert, ist das zunächst mal mit Einschränkungen in der Schlüsselstärke versehen, jedoch kann man sich von oracle.sun.com die 'Java Cryptography Extension (JCE) Unlimited Strength' runterladen und installieren.

Ich vermute, dass die 'Cryptography Strength' von Android auch limitiert ist. Kann man sich hier auch einen 'Unlimitierte Stärke' Extension runterladen und installieren?

Der ursprüngliche Beitrag von 02:00 Uhr wurde um 03:13 Uhr ergänzt:

GGF nochmal nachdenken, wo eine Lücke sein könnte, die ich übersehen habe

Ad hoc fällt mir dazu ein, daß langzeit Angriffe eines 'man in the middle' ohne OTP bei der beschriebenen Vorgehensweise nicht grundsätzlich auszuschließen sind, da die verwendeten Schlüssel stets wiedholend auf einem beschränkten Zeichenvorrat Anwendung finden, und somit mit statistischen Werkzeugen der Kryptoanalyse recht gute Angriffspunkte liefern.

Das ist übrigens ein sehr guter Hinweis!

Den hier aufgezeigten Schwachpunkt könnte man dadurch umgehen, dass man den Public/Private Key nicht zum unmittelbaren Verschlüsseln verwendet, sondern nur zum Verschlüsseln einer Secure Random Zahl, die man dann ihrerseits als Transport-Key verwendet.

Das hätte auch den entscheidenden Vorteil, dass man bei einer Nachricht an mehrere Empfänger die Nachricht nur einmal verschlüsselt übertragen müsste, und nur jedem Empfänger den mit seinem Public Key verschlüsselten Transport Key. Das würde allerdings eine hinreichende Länge des Transport Keys erfordern, um hier eine notwendige Sicherheit zu erreichen.

Die 'Login-Challange' vom Server dagegen sollte, da sie selbst eine Secure Random Zahl ist, keine statistischen Angriffsmöglichkeit bieten (wenn mein Verständnis der 'Statistischen Kryptoanalyse' korrekt ist...)

 

[qwert_zuiopue]

Also die Sache mit der eventuellen Ausfuhrbeschränkung kann ich entschärfen, weil derartiges nicht geplant ist. Die App wird lediglich von einem eingeschränkten und ausgewählten Personenkreis verwendet.

 

[asagk1963]

Hallo u.k-f!

Ich vermute, Du hast dich ein wenig mit der Thematik beschäftigt und bist dir darüber im klaren, daß im Gegensatz zur Verschlüsselung mit einem 'echt zufälligen' Schlüsselstrom (auch in der Theorie sicher), alle Krypto-Algorithmen lediglich einen beschränkten Schlüsselraum erzeugen, der gewisse Anomalien im erzeugten Schlüsselraum aufweist.
Diese Anomalien, muss man annehmen, sind auf Vorgabe der Geheimdienste hin, z.B. bei RSA, so beschaffen, daß diese vermutlich Angriffe mittels spezieller Hardware (FPGA-/ASIC-Accelerator) erlauben, die zunächst mittels 'generischer Rechenleistung' nicht mit 'vertretbarem Aufwand' lösbar erscheinen.
Genau das ist jedoch der Knackpunkt dabei... 'vertretbarer Aufwand' heißt nämlich das Stichwort. Abgesehen von der XOR-Verknüpfung mit einem 'echt zufälligen Schlüsselstrom' ist keine Methode sicher, sondern bestenfalls lediglich 'stark', da mutmaßlich nicht mittels 'vertretbarem Aufwand' lösbar!

Ich hab das gerade nicht parat, doch ich erinnere mich sehr gut an den Skandal um die systematische Schwäche im Design von DES. Der eigentlich Skandal war jedoch nicht die Schwäche von DES, sondern vielmehr darin, daß die amerikanischen Geheimdienste diese Schwäche gewissermaßen bei den Urhebern von DES 'bestellt' hatten, oder genauer gesagt diesen 'vorgeschrieben' hatte diese Schwäche einzubauen.


Was die Fermat-/Primzahl 65537 und ihre Alternativen/Drawbacks von möglichen Alternativen angeht, hier ein Link dazu:
http://crypto.stackexchange.com/questions/3110/impacts-of-not-using-rsa-exponent-of-65537

Wie bereits erwähnt, ist die einzige theoretisch sichere Verschlüsselung die, bei der ein 'echt zufälliger' Datenstrom mit einem gegebenen, zu verschlüsselnden Datenstrom XOR verknüpft wird, wobei der Schlüsselstrom (Geheimnis) wenigstens so lang sein muss, wie der zu verschlüsselnde Datenstrom (Text).

Wenn Du also nun wissen möchtest, wie sicher ein Schlüsselraumgenerator ist, z.B. RSA, so kannst Du diesen einfach mal einen größeren Schlüsselstrom von RSA erzeugen lassen, und diese auf die Güte ihrer Zufälligkeit, Verteilung etc., sprich auf ihren tatsächlichen genutzten Schlüsselraum und die dabei entstandenen Anomalien hin untersuchen. Dazu gibt es einiges an Tools, siehe folgende Links:

Webseite, die sich mit Zufallszahlen, deren Generierung (Radiowellen/Rauschen) und Güte verschrieben hat:
http://www.random.org/analysis/

NIST (Software & Documentation) über Zufalls- und Pseudo-Zufallszahlen:
http://csrc.nist.gov/groups/ST/toolkit/rng/index.html
http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html
csrc.nist.gov/publications/nistpubs/800-22-rev1a/SP800-22rev1a.pdf

Auch wenn die der asymetrischen Kryptographie zugrunde liegenden mathematischen Probleme, als 'nicht mit vertretbarem Aufwand' lösbar zu sein scheinen, zeigen Analysen über Größe und Nutzung des generierbaren Schlüsselraums ganz gut auf, wo mögliche Ansätze und Schwächen der jeweiligen Algorithmen liegen könnten.
Heutzutage gelten zwar rein statistische Ansätze als kaum noch vielversprechend, doch die Schwächen der Algorithmen müssen auch gar nicht durch statistische Ansätze aufdeckbar sein. Es reicht völlig aus, die Anomalien einer generierten Schlüsselmenge, im Verhältnis zur potentiell möglichen Größe und Verteilung des theoretischen möglichen Schlüsselvorrats eines gegebenen Generators zu betrachten, um absehen zu können, daß ganz andere Ansätze möglich sein könnten, die mittels spezieller Hardwareunterstützung vermutlich auch in 'vertretbarer Zeit' bewältigt werden können, ohne daß dabei das eigentliche mathematische Problem zu lösen sein muss.
Es reicht eben auch völlig aus, wenn man den Schlüsselraum auf eine Untermenge reduzieren kann, in dem der verbleibende Rechenaufwand dann plötzlich 'vertretbar' wird! Und genau an dieser Stelle eröffnet sich Raum für mögliche Abschwächungen beim Design eines Krypto-Algorithmus, die nämlich in der Erzeugung von Schlüsselräumen angesiedelt liegt, die spezielle, durchaus 'lösbare' Anomalien beinhalten.

Im Vergleich dazu sind diese brute-force-Projekte zum 'knacken' von verschlüsselten Texten pure Augenwischerei, da diese eine vermeintliche Sicherheit suggerieren, die tatsächlich in dieser Form lediglich für den reinen brute-force-Angriff selbst gelten kann.

Was diese Bibliotheken mit 'erweiterter' Sicherheit (Schlüssellänge) angeht, es steigt sicherlich der Aufwand, den man betreiben müßte, um Angriffe zu bewerkstelligen, und somit der Bedarf an Rechenleistung für die Geheimdienste dies auch tatsächlich zu bewerkstelligen. Was vermutlich auch der Grund ist, weshalb diese die Verwendung 'erweiterter Sicherheit' gar nicht so sehr gerne sehen.
Nur ändert das eben nichts an dem zugrunde liegenden Algorithmus, und dem, was dieser in der Lage ist an Schlüsselraum zu generieren, bzw. auch nicht zu generieren --- vermutlich auch gar nicht generieren können soll? (das wäre zumindest eine mögliche Vermutung dazu)

Zumindest wäre das so in etwa das, was mir spontan zu diesem Thema so einfällt. Am Rande bemerkt, Zufallszahlen sind ein ziemlich interessantes Gebiet!

 

[markus.tullius]

Zumindest wäre das so in etwa das, was mir spontan zu diesem Thema so einfällt. Am Rande bemerkt, Zufallszahlen sind ein ziemlich interessantes Gebiet!

Insbesondere da man schnell vergisst, dass es immer möglich ist, den Schlüssel zu knacken. Egal wie lange der Schlüssel ist.
Es gibt immer die Chance, das der erste eingegebene Schlüssel, der richtige sein kann.
Ist nur nicht sehr wahrscheinlich.

Besonders böse wird es, wenn das Passwort für die Schlüsselgenerierung benutzt wird.