• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Wie Passwörter sicher speichern?

Kugelfisch

Nerd

Registriert
12 Juli 2013
Beiträge
2.342
Ort
Im Ozean
Gewährleisten kann man momentan eh nichts, da die NIST-Kurven, auf denen heutzutage alles in der Kryptographie beruht, nicht mehr als sicher eingesuft werden.
Woher stammt diese Information, hast du dazu eine verlässliche Quelle? Zwar sind durchaus Probleme im Zusammenhang mit den vom NIST standardisierten elliptischen Kurven bekannt (z.B. http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf), dabei handelt es sich jedoch zum Grossteil schlicht um Implementierungsfehler, welche Seitenkanal-Angriffe ermöglichen - wobei die Referenzimplementierungen teilweise dieselben Probleme aufweisen und die Wahl ungünstiger Kurven die Problematik verschärft. Allerdings sind solche Angriffe in vielen Szenarien nicht durchführbar, insbesondere können sie nicht genutzt werden, um offline ein Chiffrat anzugreifen. Auch ist ECC keineswegs auf NIST-Kurven beschränkt.

Bei RSA ist das ganz einfach: Die zufallszahlen, welche faktisch natürlich Primzahlen sein müssen, werden in 99% der Fälle durch Elliptische Kurven herausgefunden.
Woher nimmst du diese Information, und selbst wenn dem so wäre: Wo wäre das Problem dabei? Mögliche Seitenkanal-Angriffe werden in diesem Fall schliesslich nicht durchführbar sein, da der Angreifer das Verhalten des ECC-Ciphers bei der Generierung des anzugreifenden Schlüsselpaars nicht überwachen kann.

AES.. Das hatte ich mir nie genauer angesehen, vermutete also nur das dies auch auf Primzahlen beruht.
Nein, das ist nicht korrekt. AES ist als symmetrischer Cipher nicht auf eine Schlüsselpaar angewiesen, dessen Schlüssel in einer bestimmten Beziehung stehen müssen (was die Nutzung von Primzahlen zur Generierung von RSA-Schlüsselpaaren bedingt). Der Schlüssel kann beliebig gewählt werden, der AES spezifiziert lediglich, dass er 128, 192 oder 256 Bit lang sein muss.
 

darksider3

NGBler

Registriert
18 Sep. 2013
Beiträge
393
Ort
/dev/sda
Woher stammt diese Information, hast du dazu eine verlässliche Quelle? Zwar sind durchaus Probleme im Zusammenhang mit den vom NIST standardisierten elliptischen Kurven bekannt (z.B. http://www.hyperelliptic.org/tanja/vortraege/20130531.pdf), dabei handelt es sich jedoch zum Grossteil schlicht um Implementierungsfehler, welche Seitenkanal-Angriffe ermöglichen - wobei die Referenzimplementierungen teilweise dieselben Probleme aufweisen und die Wahl ungünstiger Kurven die Problematik verschärft. Allerdings sind solche Angriffe in vielen Szenarien nicht durchführbar, insbesondere können sie nicht genutzt werden, um offline ein Chiffrat anzugreifen. Auch ist ECC keineswegs auf NIST-Kurven beschränkt.


Woher nimmst du diese Information, und selbst wenn dem so wäre: Wo wäre das Problem dabei? Mögliche Seitenkanal-Angriffe werden in diesem Fall schliesslich nicht durchführbar sein, da der Angreifer das Verhalten des ECC-Ciphers bei der Generierung des anzugreifenden Schlüsselpaars nicht überwachen kann.
.

Hast Du dir jemals die Algorithmen zur erzeugung von RSA-Schlüsseln angesehen? Wenn Du es getan hättest, wüsstest Du, dass diese auf Primzahlen beruhen. Diese werden sehr oft(99% ist gefühlt - da gibt's nur mich als Quelle) durch NIST-Kurven erzeugt.
NIST-Kurven beruhen(wie sollte es bei Kurven auch anders sein) auf einer Statischen Zahl, welche mir gerade spontan nicht einfällt(Ist auch etwas länger).
Diese wurde, das geht aus dem NIST-Standard hervor(Und sogar die NSA gibt das Freiwillig heraus: http://www.nsa.gov/ia/_files/nist-routines.pdf ) auf Zahlen der NSA. Leider ist es, aufgrund der Rechnenstärke von denen, momentan nicht möglich herauszufinden, wieso diese Zahl gewählt wurde. Entweder beruht es auf Willkür(Hoffnung stirbt zuletzt) oder auf einer Zahl, mit der man leichter eine eigene Kurve erstellen kann, wo man die Schwächste Stelle heraussucht.

"Diese Informationen" kann man sich im ganzen Internet zusammenlesen - Heise.de golem.de usw. (Und wie schon erwähnt http://www.nsa.gov/ia/_files/nist-routines.pdf ).

Ich sagte ja, dass ich keinerlei Praxis/Theorie mit AES habe. Bei RSA ist jedenfalls fakt, das Primzahlen genutzt werden müssen. Damit diese (meiner Meinung nach Pseudo-)Zufällig sind, wird aufgrund einer Elliptischen Kurve und möglichst vielen Zufallsvariablen eine Primzahl errechnet, die nur in diesem Moment auftauchen kann(Theorie, wurde nie bestätigt/Widerlegt)... Obwohl immer wieder Gerüchte auftauchen, dass dies mittlerweile auch nicht mehr korrekt ist.
--
Wollte nicht unhöflich wirken(Tu ich aber wahrscheinlich, nutze ja nichtmal irgendeine Höflichkeitsform :D ).
(Einmal vorgerechnet: )
(Quelle: Simon Singh/Abgekürzt mit Wikipedia.de/wiki/RSA-Kryptosystem)
q=11 und p=13, für die beiden Primzahlen
Der RSA-Modul ist N=p*q=143
EUL(143)=120
Da die Zahl e zu dem Schlüssel 120 Teilerfremd sein muss:e=23
e=23 und N=143 sind der Öffentliche Schlüssel
(Weiter kann ich leider nicht ausführen, soweit ich weiß ist hier auch kein MathML möglich, also verweise ich weiter auf https://de.wikipedia.org/wiki/RSA-Kryptosystem )

BTW Mit dem Primzahlen sollte das nun reichen ^^
MfG :)
 
Zuletzt bearbeitet:

Mr_J

Neu angemeldet

Registriert
14 Juli 2013
Beiträge
991
Hast Du dir jemals die Algorithmen zur erzeugung von RSA-Schlüsseln angesehen? Wenn Du es getan hättest, wüsstest Du, dass diese auf Primzahlen beruhen. Diese werden sehr oft(99% ist gefühlt - da gibt's nur mich als Quelle) durch NIST-Kurven erzeugt.

Das Paper von Rivest, Shamir und Adleman gibt an wie die Primzahlen gefunden werden:
To find a 100-digit "random" prime number, generate (odd) 100-digit random
numbers until a prime number is found. By the prime number theorem [7], about
(ln 10^100) / 2 = 115 numbers will be tested before a prime is found.

Ich gehe mal davon aus, dass du das Paper nicht gelesen hast. Die Annahme das grundsätzlich ein Zusammenhang zwischen RSA und ECC besteht, dürfte falsch sein.

MfG
Mr. J
 
Zuletzt bearbeitet:

Skipjack

Neu angemeldet

Registriert
17 Juli 2013
Beiträge
213
Hast Du dir jemals die Algorithmen zur erzeugung von RSA-Schlüsseln angesehen? Wenn Du es getan hättest, wüsstest Du, dass diese auf Primzahlen beruhen. Diese werden sehr oft(99% ist gefühlt - da gibt's nur mich als Quelle) durch NIST-Kurven erzeugt.
"gefühlt" ist ja eine colle Argumentation - die Quelle kannst Du dann wohl abharken.
Primzahlenerzeugung für kryptographische Anwendungen hat absolut nichts nichts mit elliptischen Kurven zu tun. Dafür braucht man einen guten Zufallszahlengenerator.
Im Prinzip läuft es einfach so:
1) Würfele eine Zufallszahl in der gewünschten Grösse. Wenn diese gerade ist, decrementiere sie.
2) Teste, ob diese prim ist.
3) Wenn ja, fertig, wenn nein, decrementiere sie und zurück zu 2.
Der letzte Schritt wird konfigurierbar oft gemacht (nicht zu selten, weil Zufallszahlen Rechenzeit kosten, nicht zu oft, weil sonst die Zufälligkeit leidet).

NIST-Kurven beruhen(wie sollte es bei Kurven auch anders sein) auf einer Statischen Zahl, welche mir gerade spontan nicht einfällt(Ist auch etwas länger).
Diese wurde, das geht aus dem NIST-Standard hervor(Und sogar die NSA gibt das Freiwillig heraus: http://www.nsa.gov/ia/_files/nist-routines.pdf ) auf Zahlen der NSA. Leider ist es, aufgrund der Rechnenstärke von denen, momentan nicht möglich herauszufinden, wieso diese Zahl gewählt wurde. Entweder beruht es auf Willkür(Hoffnung stirbt zuletzt) oder auf einer Zahl, mit der man leichter eine eigene Kurve erstellen kann, wo man die Schwächste Stelle heraussucht.
Also ehrlich, so ein Quatsch.
Natürlich "besteht" die Kurve (besser "sie wird definiert") durch einen Satz Zahlen. Aus der Theorie von ECC geht auch hervor, welche Ansprüche an eine "gute" Kurve gestellt werden müssen. Aus genau diesem Grund werden nämlich Standard-Kurven definiert und verwendet. Und wenn Du den Kurven des NIST nicht traust (das diese tatsächlich eine Schwäche haben, die z.Zt. nur der NSA bekannt ist, würde ich jetzt auch nicht mehr ausschliessen wollen), gibt es auch noch andere, die hinreichend untersucht wurden. Das ist noch kein Grund, generell gegen ECC zu sein.

"Diese Informationen" kann man sich im ganzen Internet zusammenlesen - Heise.de golem.de usw. (Und wie schon erwähnt http://www.nsa.gov/ia/_files/nist-routines.pdf ).
Bis auf Dich als Quelle (die oben schon nicht gut war - SCNR) hast Du jetzt aber noch keine genannt, die mit ernsthaften Indizien die NIST Kurven anzweifelt.

Bei RSA ist jedenfalls fakt, das Primzahlen genutzt werden müssen. Damit diese (meiner Meinung nach Pseudo-)Zufällig sind, wird aufgrund einer Elliptischen Kurve und möglichst vielen Zufallsvariablen eine Primzahl errechnet, die nur in diesem Moment auftauchen kann(Theorie, wurde nie bestätigt/Widerlegt)... Obwohl immer wieder Gerüchte auftauchen, dass dies mittlerweile auch nicht mehr korrekt ist.
Gerüchte, wo?
Natürlich könnte eine einmal verwendete Primzahl noch einmal auftauchen, d.h. wieder generiert und verwendet werden.
Deshalb nimmt man ja u.a. entsprechend grosse. Damit die Wahrscheinlichkeit dafür entsprechend klein - faktisch Null - ist.
Und nix mit Pseudo-Zufällig (PRNG). Für wirklich wichtige RSA-Schlüssel (oder auch alle anderen kryptographischen Schlüssel, egal ob symmetrisch oder asymmetrisch) nimmt man echte Zufallszahlen (TRNG).

Und bitte nicht mehr diese "Gerüchte", "gefühlt" oder "kann man überall nachlesen" - Butter bei die Fische.

--- [2013-09-19 09:09 CEST] Automatisch zusammengeführter Beitrag ---

Von sowas kann man keine 1:1-Kopien erstellen? Davon ging ich recht selbstverständlich aus.
Nur von einer Speicherkarte, nicht von einer Prozessorkarte.

Aber sonst: Wenn doch ein Kartenleser das Ding lesen kann, dann kann man es sicher auch kopieren. Er muß ja nicht das Betriebssystem starten. Ich fand auch keinen Hinweis in den Artikeln zu SIM-Karte und Chipkarte, daß man sowas nicht auslesen könnte. Ist doch auch nur ein Speicher.
Eben nicht. Eine Prozessorkarte ist ein kleiner Computer (Proz, flüchtiger und nicht-flüchtiger Speicher und I/O). Über die Kontakte kommst Du mit dem I/O System in Verbindung, welches vom Prozessor kontrolliert wird. Dieser holt seine SW aus dem ROM und wenn darin (im übertragenen Sinne) steht, Du darfst den Speicherinhalt nicht auslesen (kopieren), dann wird der Prozessor Dir diesen auch nicht über den I/O zur Verfügung stellen - also nichts mit kopieren.
Du darfst die Karte nicht mit Deiner Festplatte (die Du - irgendwo angschlossen - kopieren könntest) vergleichen, sondern mit Deinem Rechner, mit dem Du nur über die Schnittstellen (Keyboard, Monitor, Netzwerk, USB ...) kommunizieren kannst. Und wenn Dein Rechner so konfiguriert/programmiert ist, dass er den Festplatteninhalt über diese Schnittstellen nicht rausgibt, dann kommst Du da auch nicht ran - ohne den Rechner zu hacken.

Im Bezug auf EC-Karten und ähnlichem wird selbst im TV immer wieder mal davor gewarnt, daß sich die Inhalte solcher Chips extrem leicht klonen lassen und daß sich viele Kriminelle darauf spezialisiert haben. Warum soll das dann hier nicht gehen?
Nein ganz bestimmt nicht. Wobei ich nicht ausschliessen möchte, dass dies in den Medien immer richtig dargestellt wird.
Was sich klonen lässt - und auch getan wird - ist der Magnetstreifen (Stichwort Skimming).
 

MSX

Retro-Nerd-Hippie

Registriert
14 Juli 2013
Beiträge
15.092
Ort
v01d
Danke für die Info! So klingt das immerhin ein gutes Stück weit nachvollziehbarer. - Wegen der EC-Karten guck ich nochmal.

Falls euch das in eurer Debatte was bringt, weil mir gerade "NIST" ins Gesicht sprang als aktuelle Meldung im Feed-Reader: http://seclists.org/isn/2013/Sep/63
Mir ist das zu hoch. :o)
 

Skipjack

Neu angemeldet

Registriert
17 Juli 2013
Beiträge
213
Falls euch das in eurer Debatte was bringt, weil mir gerade "NIST" ins Gesicht sprang als aktuelle Meldung im Feed-Reader: http://seclists.org/isn/2013/Sep/63
Mir ist das zu hoch. :o)
Die Sache ist Kryptographen schon seit 2007 aufgefallen http://www.wired.com/politics/security/commentary/securitymatters/2007/11/securitymatters_1115, aber vor dem Hintergrund der Enthüllungen der letzten Monate, wird dem endlich mehr Gewicht gegeben. Seit 2 Wochen ist das jetzt wieder in Diskussion.

Allerdings geht es hier nicht um die Sicherheit von ECC oder den NIST Kurven, sondern eines Algorithmus zur Erzeugung von Zufallszahlen auf Basis von ECC.
Hiermit erzeugte Zufallszahlen bzw. die daraus abgeleiteten Schlüssel "könnten" für die NSA vielleicht doch nicht so zufällig - und damit reproduzierbar - sein.
Das ist der Hintergrund.

Verwendet man echte Zufallszahlen, dann gibt es momentan keinen Anlass an ECC zu zweifeln.

Aber - wie Kugelfisch schon schrieb - häufig (oder meistens) steckt der Teufel im Detail. Und wenn die Implementierung fehlerhaft ist, hilft auch der beste Algorithmus nichts. Aktuelles Beispiel bei Zufallszahlen: http://www.heise.de/security/meldung/RSA-Schluessel-zertifizierter-Smartcards-geknackt-1959704.html
 

darksider3

NGBler

Registriert
18 Sep. 2013
Beiträge
393
Ort
/dev/sda
@Skipjack: Der zweite Absatz mit dem Anfang "Also ehrlich, so ein Quatsch" gibt mir eigentlich auch schon wieder recht :D
@Mr_J nopes hab ich nicht, bin aber grad dabei :T

Der Teufel im Detail... ECC hab ich niemals anzweifeln wollen, ich rede ja die ganze Zeit explizit von NIST. Echte Zufallszahlen, soweit mir bekannt ist, sind mom. doch eigentlich nur bei Atomen möglich??
 

Kugelfisch

Nerd

Registriert
12 Juli 2013
Beiträge
2.342
Ort
Im Ozean
Mir wird aus deinen Beiträgen nach wie vor nicht klar, ob du nun die vom NIST standardisierten Kurven im allgemeinen anzweifelst (wovon ich nach deinem ersten Beitrag ausging) oder die Verwendung von Dual_EC_DRBG(?) zur Erzeugung von kryptografischen Schlüsseln für andere Verfahren.

Bei ECC im Allgemeinen, auch unter Verwendung der NIST-Kurven, sind mir wie erwähnt nur potentielle Seitenkanal-Angriffe bekannt, welche in dem in diesem Thread beschriebenen Szenario - einem Offline-Angriff auf eine verschlüsselte Passwort-Datei - nicht anwendbar wären. Die Verwendung von Dual_EC_DRBG ist hingegen, wie bereits länger bekannt ist, sehr problematisch, da die Möglichkeit besteht, durch Kenntnis eines bestimmten Satzes von Zahlen und vergleichsweise sehr wenigen Bytes der Ausgabe den PRNG-Zustand zu rekonstruieren und damit weitere Zufallszahlen vorherzusagen. Allerdings bezweifle ich, dass in den von dir erwähnten 99% der Fälle Dual_EC_DRBG zum Einsatz kommt, um kryptografisches Schlüsselmaterial für RSA zu erzeugen. Die bekannte Angreifbarkeit betrifft auch nur spezifisch Dual_EC_DRBG, nicht etwa ECC-basierte PRNGs im Allgemeinen.
 

darksider3

NGBler

Registriert
18 Sep. 2013
Beiträge
393
Ort
/dev/sda
Mir wird aus deinen Beiträgen nach wie vor nicht klar, ob du nun die vom NIST standardisierten Kurven im allgemeinen anzweifelst (wovon ich nach deinem ersten Beitrag ausging) oder die Verwendung von Dual_EC_DRBG(?) zur Erzeugung von kryptografischen Schlüsseln für andere Verfahren.

Bei ECC im Allgemeinen, auch unter Verwendung der NIST-Kurven, sind mir wie erwähnt nur potentielle Seitenkanal-Angriffe bekannt, welche in dem in diesem Thread beschriebenen Szenario - einem Offline-Angriff auf eine verschlüsselte Passwort-Datei - nicht anwendbar wären. Die Verwendung von Dual_EC_DRBG ist hingegen, wie bereits länger bekannt ist, sehr problematisch, da die Möglichkeit besteht, durch Kenntnis eines bestimmten Satzes von Zahlen und vergleichsweise sehr wenigen Bytes der Ausgabe den PRNG-Zustand zu rekonstruieren und damit weitere Zufallszahlen vorherzusagen. Allerdings bezweifle ich, dass in den von dir erwähnten 99% der Fälle Dual_EC_DRBG zum Einsatz kommt, um kryptografisches Schlüsselmaterial für RSA zu erzeugen. Die bekannte Angreifbarkeit betrifft nach aktuellem Kenntnisstand auch nur Dual_EC_DRBG, nicht ECC-basierte PRNGs im Allgemeinen.

Ich sagte ja, und deswegen vergessen wir mal mein Überschwängliches gelaber, noch nicht wirklich was ich Anzweifle: Sowohl als auch..
Also die Berechnung unter Dual_EC_DRBG und die NIST-Kurven, wobei ich ECC Allgemein für vollkommen in Ordnung halte.
Dual_EC_DRBG, ist soweit mir bekannt, zumindest __mal__(vielleicht auch nicht mehr) irgendwann unter anderem in OpenGP vorhanden gewesen. Also streichen wir mein Gelaber :D

Um es nochmal klar hinzustellen:
ECC im Allgemeinen also=>Gut, Dual_EC_DRBG=>Schlecht, NIST=>Schlecht.. :)
 

Pleitgengeier

offizielles GEZ-Haustier

Registriert
14 Juli 2013
Beiträge
7.375
Ort
127.0.0.1
Viele Systeme beschränken - das finde ich zwar auch dämlich, ist aber leider nicht selten Realität - Passwörter in ihrer maximalen länge.
Ja, das ist immer das Beste: max (zB) 16 Zeichen, dafür müssen Groß-/Kleinbuchstaben, Ziffern und Sonderzeichen darin vorkommen :m

Das gilt für reine Brute Force-Angriffe, nicht jedoch, wenn man die Angriffe modifiziert und stattdessen mit Wörterbüchern arbeitet, die mehrere Wörter - durch Satz- und Leerzeichen getrennt - miteinander verknüpfen. Zwar ist angesichts des großen Wortschatzes der deutschen Sprache ein Satz mit wenigen Wörtern schon relativ sicher, doch ist nach wie vor ein rein zufälliges (oder im Falle der Anfangsbuchstaben der Wörter ein ausreichend zufällig wirkendes) Kennwort die bessere Wahl.
Da reicht ein einziges Sonderzeichen als Salt und schon braucht der Angreifer wieder Bruteforce.
Abgesehen davon gehst du davon aus dass der Angreiffer weiß, dass es ein Satz ist.
 

darksider3

NGBler

Registriert
18 Sep. 2013
Beiträge
393
Ort
/dev/sda
Dictionary-Attack ist eig. das erste, was man mit Bruteforce versucht... Danach kommt Zufalls/Counter-Bruteforce(Hochzählen, Alles Ausprobieren)
--Jedenfalls kenne ich das so. Direkt mit Bruteforce lohnt nicht - Wenn doch auch ein Dictionary reicht?
(Bruteforce kann ja Tage/Wochen dauern)
 

accC

gesperrt

Registriert
14 Juli 2013
Beiträge
5.250
Atomarer Zerfall, atmosphärisches Rauschen, Bewegungen in Lavalampen und eventuell Bierschaumzerfall sind eigentlich gute Zufallszahlengeneratoren..

Wobei das natürlich kein Zufall ist, sondern wahrscheinlich auch irgendwie berechenbar wäre, wenn man hinreichend viele Variablen und Zusammenhänge wüsste, was aber zur Zeit einfach nicht der Fall ist, daher nehmen wir etwa Radioaktiven Zerfall als Zufall an.
 

Kugelfisch

Nerd

Registriert
12 Juli 2013
Beiträge
2.342
Ort
Im Ozean
aber auch ein Pseudozufallszahlengenerator liefert brauchbare Zahlen wenn man einen vernünftigen Seed wählt, wie z.B. die aktuelle Systemzeit.
Das hängt davon ab, wozu man die Zufallszahlen benötigt. Für kryptografische Anwendungen ist die aktuelle Systemzeit (in der realistisch erreichbaren Auflösung von Mikro- oder ggf. sogar Nanosekunden) als Seed wenig geeignet, da sie nur sehr wenig Entropie erhält. Ein Angreifer kann den Zeitraum der Erstellung des Schlüsselmaterials leicht einschränken und muss dann nicht einmal alle möglichen PRNG-Seeds testen. Ausserdem muss der Seed an sich ausreichend lang sein, um einen Brute-Force-Angriff darauf ausschliessen zu können - schliesslich ist der Seed in diesem Fall die einzige Entropiequelle.

Deshalb wählt man für kryptografische Anwendungen in der Regel RNGs, welche `echte` Entropie aus Benutzereingaben, Festplatten-Zugriffszeiten u.ä. sammeln (z.B. Linux' /dev/random) und nur solange Zufallszahlen liefern, wie ausrechend neue Entropie verfügbar ist. Damit erhält man theoretisch (sofern die Einschätzung der Entropie korrekt und der RNG sicher ist) `echte` Zufallszahlen.

Wobei das natürlich kein Zufall ist, sondern wahrscheinlich auch irgendwie berechenbar wäre, wenn man hinreichend viele Variablen und Zusammenhänge wüsste, was aber zur Zeit einfach nicht der Fall ist, daher nehmen wir etwa Radioaktiven Zerfall als Zufall an.
Das ist (in Bezug auf den radioaktiven Zerfall) nach aktuellem Kenntnisstand nicht korrekt. Da sich physikalisch bedingt nicht alle Observablen gleichzeitig messen lassen, ohne das System mit jeder einzelnen Messung zu verändern, handelt es sich beim Kernzerfall um echt zufällige (nicht-deterministische) Ereignisse. Lediglich die Wahrscheinlichkeit, dass dies in einem bestimmten Zeitraum geschieht, lässt sich (näherungsweise) berechnen - siehe z.B. https://de.wikipedia.org/wiki/Fermis_Goldene_Regel. Gemäss dem Gesetz der grossen Zahl ist das Ergebnis übrigens mit der Umwandlungsrate (bei Betrachtung einer ausreichend grossen Anzahl von Kernen verknüpft.
 

accC

gesperrt

Registriert
14 Juli 2013
Beiträge
5.250
Ach Kugelfisch, hör mal auf so viel zu wissen. Wenn ich ein Thema finde, über das ich hinreichend kompetent sprechen kann, von dem du keine Ahnung hast, feiere ich eine Party und es gibt Koks und Nutten fürs gesamte NGB. ;)


Allerdings hängt das, wie du selbst sagst, doch nur mit unseren Messmethoden zusammen, oder?!
Vielleicht gibt es da draußen ja irgendwelche tollen Alientechnologien, die andere Messverfahren ermöglichen. ;)
Eventuell wäre damit der Atomzerfall ausreichend genau berechenbar.
 

Kugelfisch

Nerd

Registriert
12 Juli 2013
Beiträge
2.342
Ort
Im Ozean
Allerdings hängt das, wie du selbst sagst, doch nur mit unseren Messmethoden zusammen, oder?!
Nein, bestimmte Grössen gleichzeitig genau zu messen, ist physikalisch unmöglich. Spezifisch sind zwei Observablen nur dann gleichzeitig genau messbar, wenn die zugehörigen Operatoren kommutieren und damit gemeinsame Eigenvektoren aufweisen. Als klassisches Beispiel lassen sich für das Wasserstoffatom z.B. die Energie, der Gesamtdrehimpuls und dessen z-Projektion gleichzeitig bestimmen (sie bilden sogar eine Basis, wenn man Spins und Schwerpunktbewegung ausser Acht lässt, d.h. die zugehörigen Eigenwerte spezifizieren den Zustand des Systems). Hat man diese drei Observablen gemessen, befindet sich aber z.B. der Impuls in einer Überlagerung mehrere Eigenzustände - versucht man, ihn zu messen, wird man (nach einer bestimmten Wahrscheinlichkeitsverteilung) einen der zugehörigen Eigenwerte messen und dabei das System in den zugehörigen Eigenzustand versetzen - jede weitere Messung wird immer genau diesen Eigenwert liefern. Das hat allerdings zur Folge, dass es daraufhin nicht mehr im vorherigen Energie-/Drehimpuls-Eigenzustand ist (da die beiden zugehörigen Operatoren nicht kommutieren), bei einer folgenden Messung der Energie oder des Drehimpulses wird man also einen anderen Wert messen (und dabei das System erneut verändern, da man es durch die Messung wieder in einen bestimmten Energie- bzw. Drehimpuls-Eigenzustand zwingt). Eine Folge davon ist die heisenbergsche Unschärferelation.

Es ist natürlich denkbar, dass sich die Quantenmechanik in der bekannten Form als falsch herausstellt und untergeordnet deterministische Prozesse existieren, die nur nach Aussen zufällig erscheinen. Das ist jedoch ein physikalisches, kein technisches Problem.
 

Skipjack

Neu angemeldet

Registriert
17 Juli 2013
Beiträge
213
@Skipjack: Der zweite Absatz mit dem Anfang "Also ehrlich, so ein Quatsch" gibt mir eigentlich auch schon wieder recht :D
Ist es eigentlich möglich, dass Du Deine Aussagen auch mal mit Tatsachen oder wenigstens einer nachvollziehbaren Argumentation versiehst?

Echte Zufallszahlen, soweit mir bekannt ist, sind mom. doch eigentlich nur bei Atomen möglich??
Echte Zufallszahlen lassen sich "relativ" leicht (und umweltfreundlich ;)) mittels Rauschgeneratoren, die "weisses" Rauschen erzeugen herstellen. Solche Rauschgeneratoren können ganz ganz stark vereinfacht aus einem Schwingkreis bestehen, der so justiert ist, dass er sich nicht auf eine Resonanzfrequenz einstellen kann. Das entstehende Rauschen liefert eine kontinuierliche Folge von (Zufalls)bits, die durch eine nachfolgende Logik statistisch überprüft werden müssen, ob die entsprechenden Kriterien für "Zufälligkeit" eingehalten werden.
Solche TRNG (true random generator) befinden sich z.B. als "entropy source" auf TPM. HSM (Hardware Sicherheitsmodule) haben auch immer einen TRNG an Bord, um kryptographische Schlüssel zu erzeugen, oder zumindest als Seed für einen nachgeschalteten PRNG. Also nichts Exotisches und mit einem TPM auch für wenige Euro für jedermann erhältlich.
 

musv

Bekannter NGBler

Registriert
15 Juli 2013
Beiträge
3.454
Ort
/dev/null
Ich schreib die Passwörter immer auf einen Memozettel und kleb den an den Bildschirm.
 
Oben