Forum: Offtopic The NSA Back Door to NIST


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Läubi .. (laeubi) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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?

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Xyz X. (Firma: xyz) (khmweb)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Erstens ist das wirklich ziemlich themenfremd. Zweitens lässt sich dazu 
keine allgemeine Aussage treffen.

von Xyz X. (Firma: xyz) (khmweb)


Bewertung
0 lesenswert
nicht lesenswert
schade.

: Bearbeitet durch User
von Läubi .. (laeubi) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Timm T. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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>

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Läubi .. schrieb:
> 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.

Da werden Sie geholfen:
https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator

: Bearbeitet durch User
von Timm T. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Läubi .. (laeubi) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Johannes O. (jojo_2)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Stefan R. (srand)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Uhu U. (uhu)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Timm T. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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".

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.