Hi, heute bin ich in den Notices of the AMS (Vol. 61 #2) über folgenden
kleinen Artikel gestolpert, der eine (mögliche) Backdoor in von der NIST
empfohlenen Kryptosystemen / Algorithmen erklärt.
Aus dem Inhalt:
1
NIST (the National Institute for Standards and Technology) of the
2
U.S. Department of Commerce derives its mandate from the U.S.
3
Constitution through the congressional power [...]
4
Whatever NIST says about cryptography becomes implemented in
5
cryptographic applications throughout U.S. government agencies.
6
Its influence leads to the widespread use of its standards in
7
industry and the broad adoption of its standards internationally.
8
9
[...] The NIST standard gives a list of explicit mathematical
10
data (E, p, n, f, P, Q) to be used for pseudo-random number
11
generation. [...] No explanation is given of the particular
12
choices (E, p, n, f, P, Q). We are told to use these data and
13
not to question why.
14
15
[...] It is a matter of public fact that the NSA was tightly
16
involved in the writing of the standard. Indeed, NIST is required
17
by law to consult with the NSA in creating its standard.
Das ganze funktioniert dann folgendermaßen:
Für ein sicheres Crypto-System würde man P und Q (zwei Punkte auf der
elliptischen Kurve E) zufällig bestimmen. Bestimmt man jedoch Q und ein
geheim gehaltenes e so, daß P = e·Q ist, dann kann man mit diesem Wissen
bereits aus den beim öffentlichen Schlüsselaustausch nach
Diffie-Hellmann übermittelten Daten auf den internen Zustand der
Pseudozufalls-Generators der Gegenseite schließen. Und damit natürlich
auch auf die erzeugten Zufallszahlen und damit weiter auf Daten, die
üblicherweise beim Schlüsselaustausch privat bleiben müssen, falls der
Austausch wie angedacht (abhör)sicher funktionieren soll.
Ist man im Besitz dieser privaten Daten, kann man natürlich die ganze
folgende, chiffrierte Kommunikation mitlesen.
Übrigens besteht der Zusammenhand P = e·Q für alle nicht-trivialen
Punkte P und Q auf E. Aus P und Q jedoch e auszurechnen ist eine
Aufgabe, die bei der Größe der eingesetzten Kurven (p > 10^77) mit
heitigen technischen Mitteln kaum lösbar ist (Berechnung des diskreten
Logarithmus' auf einer elliptischen Kurve der Ordnung > 10^77).
Viel Spaß beim Lesen!
http://www.ams.org/notices/201402/rnoti-p190.pdf
Auf die (mögliche) Backdoor wurde übrigens bereits 2007 durch
Micosoft-Mitarbeiter aufmerksam gemacht.
https://en.wikipedia.org/wiki/Dual_Elliptic_Curve_Deterministic_Random_Bit_Generator
Die Firma "RSA Security" und deren Kunden haben nun ein "kleines"
Problem. Ob die 10 Mio, die RSA dafür kassiert haben soll, die Folgen
wohl kompensieren?
Mit dem RSA Verfahren selbst hat das nur indirekt zu tun, indem dies
nicht sicherer ist als der verwendete Zufallszahlengenerator. Und der
ist unabhängig vom Verfahren wählbar. So ist deshalb beispielsweise
OpenSSL nicht davon betroffen.
Johann L. schrieb:> eine (mögliche) Backdoor in von der NIST empfohlenen Kryptosystemen /> Algorithmen erklärt
Gab es das nicht schon mal in einem Thread?
A. K. schrieb:> Und der ist unabhängig vom Verfahren wählbar
War es da nicht sogar so das nur eines der Empfohlenen angreifbar und
eigentlich kaum verwendet wurde?
Läubi .. schrieb:> War es da nicht sogar so das nur eines der Empfohlenen angreifbar und> eigentlich kaum verwendet wurde?
Laut Wikpedia steckt das Dual_EC_DRBG Verfahren zwar auf Wunsch eines
Kunden im OpenSSL als eine von mehreren Optionen drin, war aber aufgrund
eines Bugs effektiv nicht verwendbar. Zweifel bestanden bereits als man
das einbaute.
Für betroffene Produkte kann man einerseits hier nach Dual_EC_DRBG
suchen: http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html
Andererseits sind Kunden von Libraries betroffen. Hauptsächlich wohl
jene, die RSA Securities BSAFE-Library einsetzen.
Mich würde interessieren, wie sicher die Verschlüsselung der Daten in
Clouds wirklich ist.
Hat aber vermutlich nur wenig bis nix mit Eurem Thema zu tun.
Danke für die Info. Interessant finde ich ja die Frage ob in den anderen
empfohlenen Verfahren auch so "magic-numbers" existieren und man es nur
noch nicht untersucht hat, oder ob diese tamper-proof sind.
Eventuell wird man in Zukunft seinen eigenen RNG Generator mit sich
rumtragen müssen der echten Zufall aus verschiedenen Umweltfaktoren
(Temp, Luftfeuchte, Bewegung, Atemfrequenz,...) gewinnt.
A. K. schrieb:> das Dual_EC_DRBG Verfahren zwar auf Wunsch eines> Kunden im OpenSSL als eine von mehreren Optionen drin, war aber aufgrund> eines Bugs effektiv nicht verwendbar
<VT>Und ich bin mir ziemlich sicher, dass dieser Bug eingebaut wurde,
weil ein Programmierer zwar wusste, dass der Algo korrumpiert war, aber
nicht gegen den Wunsch des "Kunden" vorgehen konnte. So wurde der Algo -
ups - halt stillgelegt.</VT>
Läubi .. schrieb:> Danke für die Info. Interessant finde ich ja die Frage ob in den anderen> empfohlenen Verfahren auch so "magic-numbers" existieren und man es nur> noch nicht untersucht hat, oder ob diese tamper-proof sind.
Die Abwesenheit einer Backdoor zu beweisen dürfte prinzipiell nicht
möglich sein, ebenso wie es nicht zu beweisen ist, daß jemand ein
bestimmtes Wissen nicht hat. Allerdings stellt sich Hales für die
o.g. Backdoor die Frage, wie leicht oder schwer diese zu entdecken war
und kommt zu einem für das NIST wenig schmeichelhaften Ergebnis:
1
Without prior knowledge of the back door, how difficult would it
2
be to rediscover the possible existence of a back door? An analysis
3
of the argument shows the required level of creativity is that of
4
an undergraduate homework problem.
Falls die NSA tatsächlich über diese Magic Number e verfügt, dann ist
eine interessante Frage, wie sie damit umgehen, d.h. einerseits die Zahl
zum Kompromottieren verhandener Kryprosysteme zu verwenden (und damit in
Software zumindest intern zu verteilen) und andererseis zu verhindern,
daß diese Zahl irgendwie in die Öffentlichkeit gelangt. Ihr Preis /
Wert in kriminellen Kreisen oder für andere Nationen dürfte auch nicht
gerade niedrig sein.
> Eventuell wird man in Zukunft seinen eigenen RNG Generator mit sich> rumtragen müssen der echten Zufall aus verschiedenen Umweltfaktoren> (Temp, Luftfeuchte, Bewegung, Atemfrequenz,...) gewinnt.
Die Frage ist, warum werden denn die Zufallsgeneratoren nur mit einem
zufälligen Wert initialisiert, danach aber nur noch deterministisch
weiter gerechnet, d.h. daruf basierende Pseuduzufallszahlen erzeugt?
Gut, man hat eine bessere Gleichverteilung der Folge, aber die würde
sich auch erreichen lassen, wenn man in jedem Schritt nochmals einen
echten Zufall reinfüttert.
Johann L. schrieb:> wenn man in jedem Schritt nochmals einen echten Zufall reinfüttert.
OpenSSL scheint normalerweise auch so zu arbeiten, wenn ich das hier
richtig verstanden habe:
http://wiki.openssl.org/index.php/Random_Numbers
Der Haken liegt hier in der Verfügbarkeit echten Zufalls, wenn das
Verfahren zertifiziert werden muss. Du kannst kein Verfahren
zertifizieren, das auf /dev/[u]random basiert, wenn dessen Verfahren
nicht Teil der Zertifizierung ist. Den Inhalt vom Bildschirmspeicher
hinein zu mischen dürfte auf der formalen Seite auch nicht weiterhelfen.
Hingegen sind algorithmische Verfahren nur vom ursprünglich
eingebrachten Zufall abhängig. Danach sind sie mathematischer Natur und
formal erfassbar. Somit leichter zertifizierbar. Was in beide Richtungen
ausschlägt. Man ist nicht mehr von Fehlern und möglicher
Manipulierbarkeit von /dev/random & Co betroffen (gabs ja auch schon),
aber dafür von Fehlern in ebendiesem Algorithmus.
Was OpenSSL angeht: Da wurde von dritter Seite auf der optionalen
Nutzbarkeit von Dual_EC_DRBG bestanden. Da kann man sich nun natürlich
seinen Teil dabei denken.
Johann L. schrieb:> warum werden denn die Zufallsgeneratoren nur mit einem> zufälligen Wert initialisiert, danach aber nur noch deterministisch> weiter gerechnet
Weil Du zum Ver- und Entschlüsseln dann jeweils die gleichen
Zufallsfolgen, zum Beispiel die gleichen Verläufe der elliptischen
Kurven, brauchst.
Deswegen ist ein "echter" Zufall z.B aus radioaktivem Zerfall oder
Mausrumeiern nur als Seed zu gebrauchen, aber nicht für die weiteren
Werte.
Wenn ich das richtig vestanden habe...
Das Problem aller Verschlüsselung ist:
Das die Wiederverwendung eines Schlüssels dessen Kompromitirung
wahrscheinlicher macht.
Gegenmaßnahmen währen
1. Einmalschlüssel
Vorteil: zeitlich begrenzt sehr sicher
Nachteil: Hoher logistischer Aufwand für sichere Schlüsselübergabe und
-verwaltung
2 Übergabe des Neuen schlüssels in einer Vorhergehenden Nachricht
Vorteil: Geringer logistischer Aufwand für sichere Schlüsselübergabe und
-verwaltung für Erstkontakte ist ein vis a vis nicht notwendig
Nachteil: nicht wesentlich Sicherer als die generelle Verwendung des
Selben schlüssels. Einmalige Komprommitierung Komprommitiert alle
weiteren Sendungen.
3. Schlüsselableitung aus vorhergehenden Schlüsseln
Vorteil: Geringer logistischer Aufwand für sichere Schlüsselübergabe und
-verwaltung einmalige Komprommitierung kann ohne Kenntniss des
Algorithmus nicht nicht fortgeschrieben werden
Nachteil: die Sicherheit hängt von der Komlexität des Algorithmus und
dessen Geheimhaltung ab.
4. Mehrschlüsselsysteme mit offenem Algorithnus
Vorteil: Geringer logistischer Aufwand für sichere Schlüsselübergabe.
die Sicherheit hängt nicht von der Komlexität des Algorithmus und dessen
geheimhaltung ab.
Nachteil: Der Aufwand der Schlüsselerstellung und verwaltun wächst. die
Sicherheit hängt von in 1 Linie von der Loyalität eines externen
Schlüsselverwalters/zertificators ab.
Eine rein deterministische Schlüsselerzeugung ist nur schwer
darzustellen und erfordert pro Bit ein nicht irgendwie mit anderen
herangezogenen Parametern verknüfptes Einzelerigniss, was kein kausaler
Generator vermag.
womit die unabhängige Schlüsselgenerierung an 2 verschiedenen Orten sich
nicht synchronisieren läßt.
Timm Thaler schrieb:> Weil Du zum Ver- und Entschlüsseln dann jeweils die gleichen> Zufallsfolgen, zum Beispiel die gleichen Verläufe der elliptischen> Kurven, brauchst.
Die Zufallsfolge ist üblicherweise nicht Teil der Verschlüsselung.
PGP beispielsweise verschlüsselt aus Effizienzgründen den Hauptinhalt
mit einem symmetrischen Verfahren wie AES und verwendet dazu einen
zufälligen Schlüssel. Nur dieser Schlüssel wird mit dem viel
aufwändigeren RSA Verfahren verschlüsselt.
Man kann in diesem (und anderen) Verfahren problemlos voneinander
unabhängige vollständig zufällig erzeugte AES-Schlüssel verwenden. Also
auch solche, die mit echtem Hardware-Zufall erzeugt werden.
> Wenn ich das richtig vestanden habe...
Was du hier skizzierst ist ein völlig anderes Verschlüsselungsverfahren
als jene, um die es in der Praxis geht. Es wäre schon deshalb
problematisch, weil CSPRNGs recht aufwendig sind und den Vorgang
empfindlich bremsen würden. Hingegen ist es sehr viel effizienter, per
CSPRNG den Schlüssel für AES zu generieren und dann mit AES CBC weiter
zu arbeiten.
CSPRNG = cryptographically secure pseudo-random number generator
https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator
Winfried J. schrieb:> Das die Wiederverwendung eines Schlüssels dessen Kompromitirung> wahrscheinlicher macht.
Richtig gemacht wird nicht immer der gleiche Schlüssel verwendet,
sondern jedes Mal ein anderer. Und der kann mit einem CSPRNG erzeugt
werden. Wobei CSPRNGs die Eigenschaft besitzen, dass auch ein offen
gelegter Zustand des CSPRNGs keinen Schluss auf vergangene Schlüssel
zulässt - das unterscheidet sie von normalen PRNGs wie rand().
SSL mit PFS stellt sicher, dass die erfolgreiche Ermittlung eines
Sitzungsschlüssels, beispielsweise durch einen aktiven Lauscher dank
korrumpierten Zertifikats, nicht dabei hilft, vergangene passiv
aufgezeichnete Sitzungen zu entschlüsseln. Sich in diesem Fall gegen
zukünftige passive Aufzeichnungen zu sichern erfordert es, dass der
CSPRNG nichtdeterministisch arbeitet, also zusätzliche Entropiequellen
nutzt.
Schlüsselübertragung bei online stattfindender bidirektionaler
Kommunikation kann mit dem Diffie-Hellman Verfahren stattfinden. Damit
können sich zwei Seiten auf einen jedes Mal völlig zufälligen
gemeinsamen Schlüssel einigen, ohne diesen irgendwie separat übertragen
oder speichern zu müssen, und ohne dass ein passiver Lauscher auf der
Leitung diesen Schlüssel ermitteln kann.
https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
Deine Liste ist also nicht mehr ganz auf dem neuesten Stand. Bei
Verwendung des DH-Verfahrens sind SSL Zertifikate nicht Teil der
Verschlüsselung, sondern dienen nur der Authentifizierung des
Gegenübers. Um sicherzustellen, dass am anderen Ende auch der sitzt, mit
dem man kommunizieren will, nicht ein aktiver Lauscher dazwischen sitzt
(man in the middle).
Entscheidend beim DH-Verfahren ist nur die darin enthaltene Annahme,
dass man aus den übertragenen Daten nicht auf den Schlüssel schliessen
kann. Nach derzeitigem Stand der Erkenntnis ist dies gesichert.
Johann L. schrieb:> Die Abwesenheit einer Backdoor zu beweisen dürfte prinzipiell nicht> möglich sein
Das ist klar, deswegen finde ich es immer wieder spannend wenn (ggf.
nach Jahren) eine mögliche Schwachstelle entdeckt wird. Es ist eben
nicht reine Schulmathematik welche dahinter steckt.
Johann L. schrieb:> An analysis of the argument shows the required level of> creativity is that of an undergraduate homework problem.
Naja das ist wie das "Ei-des-Columbus", wenn die Lösung vor einem liegt
ist vieles klar und offensichtlich. Also entweder hat sich wohl niemand
die Mühe gemacht sich das mal anzuschauen, oder es war halt doch nicht
gnaz so offensichtlich.
Johann L. schrieb:> Falls die NSA tatsächlich über diese Magic Number e verfügt, dann ist> eine interessante Frage, wie sie damit umgehen
Der Stoff aus dem die Filme sind ;-) Ich halte es ehrlich gesagt für
unwahrscheinlich, das irgendwer diese Zahl (noch) besitzt. Man würde
sich ja im Zweifel damit selbst angreifbar machen. Denn entweder müsste
allen "empfehlen" das Verfahren mit BackDoor zu nutzen, selber aber
ein ganz anderes nutzen (was ja durchaus Leute hellhörig machen würde),
oder halt in Kauf nehmen, dass im Zweifel auch die eigene Kommunikation
(Rückwirkend) kompromittiert wird.
Auch der Einsatz/die Geheimhaltung dieses einen "Generalschlüssels"
stelle ich mir wie du schon schriebst schwer vor. Aber vielleicht liegt
der einfach beim Präsidenten, gleich neben dem Schlüssel für die
Atomwaffen ;-)
A. K. schrieb:> https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
Da das Diffie–Hellman_key_exchange Verfahren lediglich auf der Anwendung
des Komutativgesestzes besteht kann es imho nicht wirklich als sicher
eingestuft werden. Es stellt also eine Kombination aus 3 und 4 dar
jedoch mit zu sätzlichen Nachteilen. Hierbei ist der spätere Schlüssel
die eigentliche Nachricht.
Wenn wir das Verfahren genau betrachten gibt es nur einen wirksamen
Schlüssel genannt common paint (CP)
Das System besteht aus genau 3 unabhängigen Unbekanten, und 2
unabhängigen Gleichungen. Nach Gaus genügt es eine eine der Unbekannten
extern zu lösen und das und common paint ist korumpiert. Da keine
weitere redundante Sicherung vorhanden ist, müssen alle für dahin aus
diesem CP errechneten Schlüssel ebenfalls als korrumpiert gelten, da mit
Kenntnis von CP und der beiden Publikzwischensummen alle Unbekannten
errechnet werden können.
Ein externer Bruch kann dabei eine Klartextnachricht sein welche nach
diesem Verfahren übermittelt wurde und welche dem Gegner nachvolziehbar
wurde.
Zum Bbeispiel durch nachträgliche Zusammenführung von Nachricht und
Ereignis.
D.h.: Kann der passive Lauscher auch nur eine Nachricht einem Ereignis
zuordnen und auf dieser Übereinstimmung einen Schlüssel nachträglich
überwinden, so kann er CP ermitteln und so er über vollständige
Zwischensummenpaare abfangen kann vermag er auch die resultierenden
Schlüssel zu bestimmen.
Das Verfahren lässt sich verbessern in dem CP aktualisiert wird
hier greifen wieder die selben Regeln wie oben beschrieben.
Gerade wenn der Gegner über hohe Rechen und Speicherkapazität sowie auch
sicheren Zugriff auf wichtige Nachrichtenknoten verfügt betrachte ich
das Verfahren als schwache Verschleierung nicht weniger, aber auch
nicht mehr.
MfG Winne
A. K. schrieb:> Laut Wikpedia steckt das Dual_EC_DRBG Verfahren zwar auf Wunsch eines> Kunden im OpenSSL als eine von mehreren Optionen drin, war aber aufgrund> eines Bugs effektiv nicht verwendbar.
Das richtig interessante ist aber: Das Dual_EC_DRBG im OpenSSL hat die
Zertifizierung des FIPS problemlos bestanden, die eigentliche
Implementierung versagt dann aber, so dass sich diese Verschlüsselung
gar nicht benutzen lässt. Das hat mit einem kleinen Programmierfehler zu
tun.
https://lwn.net/Articles/578375/> One other thing to possibly consider: did someone on the OpenSSL project> "backdoor" the Dual EC DRBG implementation such that it could never work,> but would pass the certification tests?Läubi .. schrieb:> Johann L. schrieb:>> Falls die NSA tatsächlich über diese Magic Number e verfügt, dann ist>> eine interessante Frage, wie sie damit umgehen>> Der Stoff aus dem die Filme sind ;-) Ich halte es ehrlich gesagt für> unwahrscheinlich, das irgendwer diese Zahl (noch) besitzt. Man würde> sich ja im Zweifel damit selbst angreifbar machen. Denn entweder müsste> allen "empfehlen" das Verfahren mit BackDoor zu nutzen, selber aber> ein ganz anderes nutzen (was ja durchaus Leute hellhörig machen würde),> oder halt in Kauf nehmen, dass im Zweifel auch die eigene Kommunikation> (Rückwirkend) kompromittiert wird.
Warum sollten sie diese Zahl e denn NICHT aufbewahren? Die Sicherheit
der Verschlüsselung wenn man sie selbst verwendet leidet nicht darunter,
solange man nur selbst das e kennt. (Was ja auch bei den meisten anderen
Verschlüsselungen so ist, dass man seinen (privaten) Schlüssel geheim
halten muss).
Grundsätzlich gilt wohl: Was möglich ist, wird auch gemacht.
Läubi .. schrieb:> Eventuell wird man in Zukunft seinen eigenen RNG Generator mit sich> rumtragen müssen der echten Zufall aus verschiedenen Umweltfaktoren> (Temp, Luftfeuchte, Bewegung, Atemfrequenz,...) gewinnt.
Sehr viel verwertbare Entropie sehe ich bei all diesen Quellen nicht.
Abgesehen davon sind Hardware-RNGs eher weniger vertrauenswürdig als ein
moderner CSPRNG in Software.
Läubi .. schrieb:> Ich halte es ehrlich gesagt für unwahrscheinlich, das irgendwer diese> Zahl (noch) besitzt.
Das ist eine sehr mutige Annahme, denn sie setzt voraus, daß die Leute
unbestechlich und unverletztlich sind.
Derlei Geheimnisse muß der Anwender einer Knack-Software nicht kennen
und rein technisch ist es möglich, diese Geheimnisse zu wahren.
Bleibt also der menschliche Faktor. Wie man den in den Griff bekommt,
dafür sind die Geheimdienste ausgewiesenermaßen DIE Experten und wenn
die Zielpersonen bekannt sind, dann haben die keine Chance, das
Geheimnis der Öffentlichkeit zu offenbaren, ohne mit schwersten
Nachteile für Leib und Leben rechnen zu müssen.
Auf der anderen Seite haben diese Zielpersonen ausgesorgt, wenn sie sich
im Sinne des Apparates verhalten.
Ein prominentes Beispiel ist Mordechai Vanunu.
Ironischerweise ist schon deine Annahme incl. deiner Begründungen ein
Beispiel dafür, wie solche Geheimnisse sehr häufig gewahrt werden: durch
Bestreiten ihrer Existenz.
A. K. schrieb:> PGP beispielsweise verschlüsselt aus Effizienzgründen den Hauptinhalt> mit einem symmetrischen Verfahren wie AES und verwendet dazu einen> zufälligen Schlüssel. Nur dieser Schlüssel wird mit dem viel> aufwändigeren RSA Verfahren verschlüsselt.
Dann brauchst Du trotzdem erstmal einen brechenbaren Zufall für das
RSA-Verfahren, z.B. die angreifbaren elliptischen Kurven.
> Man kann in diesem (und anderen) Verfahren problemlos voneinander> unabhängige vollständig zufällig erzeugte AES-Schlüssel verwenden. Also> auch solche, die mit echtem Hardware-Zufall erzeugt werden.
Die AES ist dann uninteressant, der Schlüssel dafür kann noch so
zufällig sein, wenn die RSA angreifbar ist, hast Du auch den Schlüssel
vorliegen. Da kannst Du dann auch 1-2-3-4-5 nehmen.
Läubi .. schrieb:> Ich halte es ehrlich gesagt für unwahrscheinlich, das irgendwer> diese Zahl (noch) besitzt. Man würde sich ja im Zweifel damit> selbst angreifbar machen.
Nö, man könnte die Daten sicher verschlüsseln. Und dann nochmals mit
dem NIST-Verfahren verschlüsseln um die Normen zu erfülle. Der
zusätzliche Aufwand dazu ist marginal, da üblicherweise asymmetrische
Verfahren nur zu Verschlüsselung symmetrischer Schlüssel verwendet
werden.
Winfried J. schrieb:> A. K. schrieb:>> https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange>>> Da das Diffie–Hellman_key_exchange Verfahren lediglich auf der Anwendung> des Komutativgesestzes besteht kann es imho nicht wirklich als sicher> eingestuft werden.
Na, etwas mehr als das Kommutativgesetz wird schon verwendet. Unter der
Voraussetzung, daß die privaten Daten wirklich privat bleiben. Wenn Q,
a*Q und b*Q (öffentlich) bekannt sind, ist es immer nocht nicht-trivial,
daraus a*b*Q zu bestimmen -- worüber die beiden Schlüsselaustauscher
verfügen.
> Das System besteht aus genau 3 unabhängigen Unbekanten, und 2> unabhängigen Gleichungen. Nach Gaus genügt es eine eine der Unbekannten> extern zu lösen...
Was aber nicht so einfach ist, d.h. man geht davon aus, daß es s.g.
Einweg-Funktionen gibt, die leicht zu berechnen aber schwer umzukehren
sind. Dabei bedeutet "leicht", "schnell auf einem normalen Rechner
berechenbar" und "schwer", "nach heutigem Stand der Technik nicht
möglich".
Beispiele sind Diskreter Logarithmus (auf einer entsprechend gewählten
Gruppe) oder Faktorisierung großer Zahlen.
Public-Key (also asymmetrische) Systeme sind auch so gestrickt, daß man
aus Wissen um Public Key + x verschlüsselte Texte + x zugehörige
Klartexte weder auf den Private Key noch auf den x+1-ten oder folgende
klartexte schließen kann.
Johannes O. schrieb:> Warum sollten sie diese Zahl e denn NICHT aufbewahren?
Man weiß ja nicht, ob irgendjemand diese Zahl überhaupt kennt. Wenn P
und Q zufällig bestimmt sind, hat man keine Ahnung von e. Und P und Q
sieht man es nicht an, ob sie zufällig sind oder eben gemäß P = e*Q mit
zufälligen e und Q.
Einiges spricht für Variante 2: Einerseits beschäftigt die NSA hunderte
fähiger Kryptologen, Mathematiker und Informatiker. Zudem Funktioniert
die Backdoor nur wenn das Verschlüsselungsverfahren im Tandem mit dem
Zufallsgenerator verwendet wird. Die NSA-Leute haben die verwendeten
Algorithmen sicherlich genauestens unter die Lupe genommen.
Die Algorithmen sind definitiv Design und nicht nach dem Muster "Bits
mal kräftig durchwirbeln und gut is".
Uhu hatte mich auf dieselben Aspekte hingewisen
danke für eure Hinweise. Ich habe sie ernst genug genommen meine These
ein weiteres mal zu prüfen, da ich zunächst nur wenig Zeit darauf
verwendet hatte das Grundprinzip auf Schwachstellen abzusuchen und mir
diese bei dem einfachen Algorithmus sofort ins Auge stach. Deshalb hatte
ich mir auch schon selbst überlegt wie man das Verfahren absichern
könnte und kam zu dem Schluss wie ich ihn beschrieben habe.
Was nun den konkreten mathematischen Algorithmus beziehungsweise dessen
Umkehrbarkeit angeht, so komme ich zu dem Schluss das Algorithmen deren
Umkehrung mehrdeutige Ergebnisse liefern den Aufwand auf der
Angreiferseite zwar asymmetrisch erhöhen, jedoch immer nur in einer
Größenordnung welche gegenüber dem zusätzlichen Aufwand der
autorisierten Seite nicht grundsätzlich unverhältnismäßig sein muss.
Es ist halt eine wie immer eine Frage der verfügbaren Ressourcen. Das
Verfahren ist trotz Allem direkt an das Komutativgesetz gebunden, sonst
würde es nicht funktionieren.
Deshalb kann ich dir leider nicht zustimmen. Bitte nimm es mir nicht
übel aber es ist wie immer. Wer in der Statistik an die Unmöglichkeit
glaubt wird schnell von der Realität der Wahrscheinlichkeit eingeholt.
Das ergibt sich bereits aus dem Verhältnis von Nutzinformation zu
übermittelten Informationsmenge. Weshalb es leichter ist eine kleine
Daten Menge wirksam in einer Großen zu verstecken, als die selbe sicher
zu verschlüsseln.
Da mag auch jeder seine Meinung haben. Ich sehe das aus rein
gesetzmäßiger Sicht so, ohne mich an den Konkreten Verfahren
aufzuarbeiten. Es ist ein wenig wie beim Lösen von Integralen,
hast du das richtige Hilfsintegral gefunden ist die Lösung ein
Spaziergang. Hinzu kommt das sich der Angreifer in aller Regel besser
mit der Materie auskennt als der Entwickler eines Verfahrens oder gar
dessen Anwender. Oft erkennt er auf Grund von Erfahrungen schneller das
angewandte Verfahren und deren Schwachstellen als der Entwickler selbst.
Auf der revers arbeitenden Seite finden sich immer die besseren
Analytiker und zu denen zähle ich mich beileibe jedenfalls nicht in der
Cryptologie.
Mein persönliches (reverses) Gebiet ist eher die logische Analyse von
Kausalketten elektronischer Schaltungen. Zu Beispiel in der berühmten
unbekannten Cermitschen Waspassiertdannnmaschine Fehler aufzuspüren und
sie zu reparieren, ohne deren konkrete Konstruktion kennen. Ja zur Not
ohne jedweden Plan alles selbst analysieren zu müssen inklusive der
bezweckten Funktionsweise einer defekten Black Box, nur an Hand des
Verstehens der Peripherie. Das ist mein Brot und mir Spass genug bei
Gerätschaften aus den letzen 70 Jahren, bis hin zu den Neuesten und
undokumentierten Steuerungen. Mein Vorteil gegenüber den Kryptologen ist
die Überschaubarkeit der Anforderungen und der Funktionalität eines
Aufzuges.
Gruß Winne
Thread beobachten
Seitenaufteilung abschalten