Verschlüsselung ist keine Hürde mehr

[bugmenot]

Oh mann das Forum hier ist ml wieder voll von gefährlichem Halbwissen GPUs auf knacken von Passwörtern optimiert undso...Der nächste nennt in dem zusammenhang Cuda...

Keiner scheint mal auf die simple Idee zu kommen das mehrere Hundert Kerne/Units wesentlich bessere Ergebnisse liefern als ein Rechner mit 4x3Ghz auch wenn diese Units nur mit ~1000Mhz arbeiten. Selbst eine billig Karte (50€) bietet heutzutage zb. 256 Shaderprocessingunits ;)

Feuer Frei:
> Recovery speed on ATI HD 5970 peaks at 5600M/s MD5 hashes and 2300M/s SHA1 hashes.

> nVidia GTX 260 w/ 192 SP peaks at 560M/s MD5 & 175M/s SHA1.

> supports systems with multiple GPUs, so, for example, result for HD5770+HD4770+8600GT: Processed 42 228 252 672 passwords in 16s. Thus, 2 731 452 307 password(s) per second in average.

[GruenBlau]

Bin etwas erschreckt über den Tiefgang hier im Forum. Man braucht doch mal nur zu überlegen, dass z.B. eine ATI Radeon 6990 gut und gerne über 3000 Stream Prozessoren enthält. Dabei ist die Karte beim errechnen von z.B. Bitcoin-Hashes rund 13mal schneller als ein Core i7@4,6GHz. Das ist aber immer noch zu kurz gedacht, wenn man den Energieverbrauch beider Systeme einem simplen FPGA gegenüberstellt der noch rund 6mal flotter als der i7 arbeitet, aber bei 200MHz Takt nur einen Bruchteil der Leistungsaufnahme hat. Ausreichend Finanzmittel vorrausgesetzt, kann man damit spezialisierte Systeme bauen, die jeden Großrechner/Supercomputer blass aussehen lassen. Und was spricht dagegen, dass in echtes Silizium zu giessen?

Wobei ich mir auch nicht 100% sicher bin, ist ob es überhaupt hilft den eigenen PGP-Key mit einer größeren Schlüssellänge zu versehen. Ich ging immer davon aus, dass damit nur der eigentliche AES-Schlüssel (i.d.R. 256Bit) verschlüsselt wird. Anderenfalls würde ja eine Nachricht die an z.B. 5 verschiedene Adressaten geht, ja auch 5mal verschlüsselt werden. D.h. die Nachricht ja auch 5mal größer werden, was AFAIK nicht der Fall ist. Es dürfte also die eigentliche Nachricht mit einem zufälligen Schlüssel symmetrisch verschlüsselt werden und nur dieser Schlüssel wird asymmetrisch für jeden Empfänger verschlüsselt und der Nachricht beigefügt. Ergo ist der logische Angriffspunkt nicht das Public-Key Verfahren.

[MaxT]

Auch wenn Ampel im Prinzip nur Blödsinn erzählt, bitte seid auch nicht so naiv und geht immer von Millionen von Jahren aus, die man bräuchte um etwas zu knacken.

Alles was man über den Inhalt bereits weiß ist potentiell gefährlich. Und das könnte bei einem verschlüsselten Dateisystem z.B. der Header sein, zu dem zu allem Überfluss auch noch die Position im verschlüsselten Datenstrom bekannt ist.

Solches Wissen macht das Entschlüsseln erheblich einfacher. Okay okay ... Verfahren wie AES setzen nicht umsonst nicht auf ein einfaches XOR zwischen Inhalt und Schlüssel, daher ist auch das nicht die ganze Wahrheit. Ich sehe allerdings kein Problem, wenn ein modernes Verschlüsselungsverfahren selbst dann noch Attacken nötig macht, die über tausende von Jahren dauern.

[M.P.]

MaxT schrieb:
--------------------------------------------------------------------------------
> Solches Wissen macht das Entschlüsseln erheblich einfacher. Okay okay ...
> Verfahren wie AES setzen nicht umsonst nicht auf ein einfaches XOR zwischen
> Inhalt und Schlüssel,

Wenn die Schlüssellänge länger, oder gleich lang wie die Nachricht ist, und der Schlüssel wirklich zufällig erzeugt, kann man auch ein einfaches XOR benutzen, und ist völlig sicher.
Bei einem rollierend mehrfach verwendeten Schlüssel sollte man das nicht machen ;-)

[tunnelblick]

GruenBlau schrieb:
--------------------------------------------------------------------------------
> Bin etwas erschreckt über den Tiefgang hier im Forum. Man braucht doch mal
> nur zu überlegen, dass z.B. eine ATI Radeon 6990 gut und gerne über 3000
> Stream Prozessoren enthält. Dabei ist die Karte beim errechnen von z.B.
> Bitcoin-Hashes rund 13mal schneller als ein Core i7@4,6GHz. Das ist aber
> immer noch zu kurz gedacht, wenn man den Energieverbrauch beider Systeme
> einem simplen FPGA gegenüberstellt der noch rund 6mal flotter als der i7
> arbeitet, aber bei 200MHz Takt nur einen Bruchteil der Leistungsaufnahme
> hat. Ausreichend Finanzmittel vorrausgesetzt, kann man damit spezialisierte
> Systeme bauen, die jeden Großrechner/Supercomputer blass aussehen lassen.
> Und was spricht dagegen, dass in echtes Silizium zu giessen?

nichts. trotzdem ist massive rechenpower der falsche ansatz. es bringt weitaus mehr, sich diesem problem mathematisch zu lösen, anstatt einfach zu brute-forcen. insbesondere ist der fpga-entwicklungsaufwand auch alles andere als zu unterschätzen...

"we have computers, which can beat your computers"

[GruenBlau]

tunnelblick schrieb:
--------------------------------------------------------------------------------
> GruenBlau schrieb:
> ---------------------------------------------------------------------------
> > Und was spricht dagegen, dass in echtes Silizium zu giessen?
>
> nichts. trotzdem ist massive rechenpower der falsche ansatz. es bringt
> weitaus mehr, sich diesem problem mathematisch zu lösen, anstatt einfach zu
> brute-forcen. insbesondere ist der fpga-entwicklungsaufwand auch alles
> andere als zu unterschätzen...

Und dennoch haben ein paar Verrückte das für das Bitcoin-Mining erfolgreich betrieben. Wenn die das schaffen, dann auch eine Sicherheitsbehörde mit mehreren Millionen im IT-Haushalt.

Vermutlich wird das ganze eine Kombination aus verschiedenen Szenarien sein: Brute-Force, Schwachstellen bei der Zufallszahlengenerierung und der eingesetzten Verschlüsselungsverfahren. Oder am Ende stellt sich nur raus, dass die PGP-Emails entschlüsseln können, wenn die vorher einen Private-Key mit konventionellen Methoden abgegriffen haben.

[virsh]

M.P. schrieb:
--------------------------------------------------------------------------------
> MaxT schrieb:
> ---------------------------------------------------------------------------
> -----
> > Solches Wissen macht das Entschlüsseln erheblich einfacher. Okay okay
> ...
> > Verfahren wie AES setzen nicht umsonst nicht auf ein einfaches XOR
> zwischen
> > Inhalt und Schlüssel,
>
> Wenn die Schlüssellänge länger, oder gleich lang wie die Nachricht ist, und
> der Schlüssel wirklich zufällig erzeugt, kann man auch ein einfaches XOR
> benutzen, und ist völlig sicher.
> Bei einem rollierend mehrfach verwendeten Schlüssel sollte man das nicht
> machen ;-)

Der Vollständigkeit halber:
Nennt sich One-Time-Pad und ist meines Wissens nach das einzig (bewiesene) informationstheoretisch sichere Verschlüsselungsverfahren.


Bei dem Beispiel mit MD5 stimmt es zwar, dass es kein Verschlüsselungsverfahren ist, dennoch passt der Vergleich in den Kontext. Es reicht nämlich aus, zu veranschaulichen, dass bei einer Rechnung Informationen verloren gehen können. Bei einer Abbildung kann ich nicht zwingend aus dem Bild wieder das Urbild berechnen, genau da ist der Witz an der ganzen Sache. Anwendung findet sowas, wenn auch in sehr kleinem Rahmen und sehr sehr simpel (da gibt es tollere Dinge, Stichwort One Way Functions - Einwegfunktionen), als Beispiel sollte es aber genügen, bei RSA. Es werden für den Modulus zwei große Primzahlen multipliziert und deren Ergebnis kann veröffentlicht werden. Ein Angreifer kennt die Primzahlen nicht und kann aus dem Ergebnis nur seeeehr schwer auf die ursprünglichen Zahlen zurückrechnen. Funktioniert aber auch nur deshalb, weil man annimmt, dass Faktorisieren ein schweres (NP-vollständig?) Problem ist, bewiesen ist das nicht.
Angemerkt sei auch noch, dass ich für das Entschlüsseln nicht zwingend eine Umkehrfunktion der Verschlüsselungsfunktion benötige. Am Beispiel von Blockschiffren wie dem CBC kann man sich das anschauen.
Wenn ich mich nicht täusche, macht das der DES genauso.

Zu den mathematischen Formeln, die bekannt sind oder auch nicht:
Kerkhoffs Prinzip besagt, dass die Sicherheit eines Verfahrens nur vom Schlüssel abhängen darf, nie vom Verfahren selbst. Stell dir mal vor, eine Firma wie IBM benutzt ein Verschlüsselungsverfahren, einer findet den Code raus und sie dürfen sich ein neues Verfahren ausdenken. Demnach sind selbstverständlich alle anerkannten Verschlüsselungsverfahren (und sonstige kryptografische Leckerheiten wie Hashen, Signaturen, ...) frei verfügbar.

Zum Abschluss:
Die ganzen Rechnungen um die Dauer von Brute-Force-Attacken lassen meiner Meinung nach eines unter den Tisch fallen, zumindest wird es nicht erwähnt: Das ist immer nur die absolut maximale Dauer, d.h. wenn der allerletzte Schlüssel der richtige ist. Im Allgemeinen sollte ich aber mit einer BF-Attacke weitaus früher erfolgreich sein (was mir zumindest ein paar Jahre ersparen wird ;))

[Replay]

Ich dachte, daß die Pfingstferien noch nicht begonnen haben o.O

Die Stimmen außerhalb meines Kopfes irritieren mich am meisten...

[just a other random guy]

Ampel schrieb:
--------------------------------------------------------------------------------
> Noch nicht aber wenn Maschinen solche Verfahren selbst erstellen könne so
> das der Mensch das nicht mehr Nachvollziehen kann ( oder Erschwert) dann
> sieht es anders aus

Security by Obscurity?! Ja, bitte. Die Meisten dieser Varianten haben auf kurz oder lang versagt (GSM, DVD, die meisten Spielkonsolen...).

> Nur wie du sicherlich weist zu jeder Berechnung (egal wie) gibts auch eine
> Gegenrechnung , egal wie aufwendig sie ist und wieviele Unbekannte da mit
> einfließen. Es zeigt letztendlich das jede Verschlüsselung die von
> menschenhand erschaffen wurde Knackbar ist. Unabhängig wie lange sie
> braucht um geknackt zu werden !.

Dann bitte eine Lösungsformel für: y= ∑a(n)*x^n für n > 4

> Wer nichts zu verheimlichen hat muss auch nichts verschlüsseln !.
> Und wer etwas Sicherheit aben will sollte nicht auf zu lange Keys setzten
> denn wenn jemand die Erfahrung hat und weis wie es geht die Verschlüsselung
> zu knacken für den ist auch jede Verschlüsselung kein Hindernis . Im
> Zweifelsfall alles auf enie SSD und sich das tool holen für die
> selbstzerstörung . Wenn da wer vor der Tür steht hat man immer noch die
> Chance den Roten Knopf zu drücken. Lieber Daten futsch als das sie in
> andere Hände fallen (falls wer das braucht)

Aus meinen Augen einen eindeutige Disqualifikation. Tool man schwingt ein solches "Totschlagargument" alle die Verschlüsselung anwenden sind Böse...

> und du hast keine Ahnung wieviele Zugriffe und Berechnungen ein z.B:
> Großrechner in einer Sekunde schafft.....

64 Bit ist veraltet sind immer noch 18'446'744'073'709'551'616 Möglichkeiten. Als ich in einem Kurs vor 3-4 Jahren eine DES - die eigentlich nur 56 Bit ist - Verschlüsselung mit normaler HW knacken sollten (mit einem billigen Programm) hätte es genügend lange gedauerte (~ 1 Jahr). Selbst wenn die heutigen Maschinen viel schneller sind, dürfte des doch noch ein paar Minuten brauchen um geknackt zu werden.

Heute wird mehr als 128 Bit als sicher angesehen. Das nicht doppelt so viele Möglichkeiten, sonder es sind genau (2^64)^2 Möglichkeiten. Sollte für ein paar Jährchen wieder reichen...

Der Punkt ist, wie viele schon bemerkt haben, dass eine Verschlüsselung eine (eindeutige) Umkehrfunktion haben muss. Also ist jede Verschlüsselung auch knack bar (Und sei es, wenn man den richtigen Holzstock für den Lederstreifen hat...).

Die Frage war und ist immer: WIE LANGE?
Wie viel Zeit und Geld will jemand in das knacken der Verschlüsselung investieren?
Oder anders gesagt, wie wertvoll ist die Information für denjenigen, welcher sie haben will.

> Im Privaten ist jeder schon mit >64 bit Keys hoffnungslos überfordert.
> Keiner merkt sich die Dinger und werden oft in weniger gesicherten Dateien
> abgespeichert .Meistens auf einem USB Stick oder anderen Medium.Im Profi
> Bereich wird es ähnlich gemacht denn keiner hat lust z.B: 4096 Zeichen
> abzutippen. Bei den meisten Menschen ist es ausserdem so das bei 10 Stellen
> sich zu merken es schon Probleme gibt. Nur durch Regelmäßiges Braintraining
> kriegt man es hin sich mehr stellen zu merken . Die mesten machen es aber
> nicht ,Sie generieren oder lassen sich einen Key generieren , und mit C &
> P wird der benutzt. wehe wenn man versucht dann den vergessenen Key wieder
> zu kriegen , viel Spaß dabei !.

Also deine Bankkarte (ev. auch Kreditkarte) braucht nur ein die bis zu 6 Zeichen deines Pins, für die Verschlüsselung?!? Nur 10'000'000 Möglichkeiten?! Dann würde ich nur noch Bargeld brauchen....

Grundlegendes über Verschlüsselung (und Feinheiten lass ich weg): Du hast eine Maschinen die eine Schlüssel braucht der, wesentlich kürzer ist, als der Datenstrom, mit dem du die Maschine fütterst. Jeder, beim Grossteil der Verfahren, weiss, wie die Maschine aussieht. Rein kommt Key + Plaintext und raus kommt Ciphertext und Bob und Alice sind zufrieden....

Den Schlüssel dafür wird irgendwo (meistens) abgespeichert, wo auch immer. IdR jedoch nicht ungesichert, du schützt, denn Key mit einer kurzen, merkbaren, aber nicht erratenen Passphrase. (Key != Passphrase!!!)
In einem intakten, guten aufgebautem System wird dir der Zugriff zum Key gesperrt, wenn du zu viele Falscheingaben in zu kurzer Zeit hast (probieren kann man dies an jedem Bankomat...)

Ich behaupte, dass die wenigsten, mit aktuellen, "sicheren" Verschlüsselungsmechanismen (kein rot13...) gesicherten Daten mit simpler Brute-Force geknackt werden. (Entweder hat der "Depp" mal wieder das erste Wort aus dem Duden genommen oder sie haben ihn "bearbeitet", dass er es ihnen sagt oder sonst den Key abgefangen....)



1 mal bearbeitet, zuletzt am 24.05.12 15:47 durch just a other random guy.

[rangnar]

Ich weiss, dass ich nichts weiss. Und ich weiss, das Ampel noch weniger weiss.

Ja. Richtig. Man kann jeden verschlüsselten Text knacken. Denn die Texte sind endlich und wir haben unendlich Zeit. Wie können jede Kombination der Schlüssel mit jedem bekannten und unbekannten Verschlüsselungs-Algorythmus durchprobieren, irgendwann kommt man zum Ergebnis. Wenn man bis dahin nicht vergessen hat, was die Frage war. Die Antwort könnte 42 sein.

Gerade bei unsymetrischer rät man lieber. Denn wenn du durch 10 Teilst und 4 übrig bleibt, weißt du eben nicht, ob das vorher 4, 14, 24, 34, ... 132.244.398.123.004, ... war

So, kommen wir zurück zu Schlüssellänge. Die war mal, im Zeitalter von dx66 256 bit. dann 1024. Inzwischen 4096. Wie hängt die notwendige Rechenzeit von der Schlüssellänge ab? Jedes Bit mehr verdoppelt die Rechenzeit. Also 1025 war doppelt so lange wie 1024. 1026 ist doppelt so lange wie 1025 und damit vier mal so lang wie 1024. ...

Also, wie gesagt, grundsätzlich kann man jede Verschlüsselung entschlüsseln. Am einfachsten, erfolgreichsten und effektiv, in kürzester Zeit, entschlüsselt die Polizei wie folgt: Den Verdächtigen, der das Passwort und den Algorithmus kennt, einsperren, ohne Wasser und Brot. Das Problem ist in der Regel nach 3 Tagen gelöst. Wenn die zu rechnen anfangen würden, ... haben Sie schon verloren ;-)

Mal zum nachdenken. Es gibt ein Projekt den Schlüssel für ein Motorola-Handy zu knacken, um dort einen beliebigen Bootloader zu installieren. Wenn es so einfach wäre, wie Ampel meint, bräuchte man dafür mit seinem PC 15 Minuten ... nun rechnen einige tausend PCs schon Jahre daran. Aber sie werden gewinnen. Sie haben unendlich Zeit und der Schlüssel war nur endlich.

[tunnelblick]

GruenBlau schrieb:
--------------------------------------------------------------------------------
> tunnelblick schrieb:
> ---------------------------------------------------------------------------
> -----
> > GruenBlau schrieb:
> >
> ---------------------------------------------------------------------------
>
> > > Und was spricht dagegen, dass in echtes Silizium zu giessen?
> >
> > nichts. trotzdem ist massive rechenpower der falsche ansatz. es bringt
> > weitaus mehr, sich diesem problem mathematisch zu lösen, anstatt einfach
> zu
> > brute-forcen. insbesondere ist der fpga-entwicklungsaufwand auch alles
> > andere als zu unterschätzen...
>
> Und dennoch haben ein paar Verrückte das für das Bitcoin-Mining erfolgreich
> betrieben. Wenn die das schaffen, dann auch eine Sicherheitsbehörde mit
> mehreren Millionen im IT-Haushalt.

nanana, die haben sich an einem bestehenden core bei opencores bedient, von daher... das "porten" ist dann noch das leichteste, was aber auch nicht trivial ist. so einen core selber zu entwickeln, ist allerdings noch mal eine *ganz* andere hürde.

"we have computers, which can beat your computers"

[just a other random guy]

Kleinen Anmerkung: Bei Verschlüsselungen basierend auf Primzahlen nimmt die Zahl der Möglichkeiten nicht so schnell zu, wie die Grösse des Schlüssels.

Primzahlen 1-10: 2, 3, 5, 7 = 4 Stück
Primzahlen 11-20: 11, 13, 17, 19 = 4 Stück
Primzahlen 21-30: 23, 29 = 2 Stück
....

Das Verhältnis Nicht Primzahlen : Primzahlen nimmt tendenziell ab, je Grösse die Zahlen sind, welche man anschaut. Deshalb steigt bei GPG die Zahl der, für die Verschlüsselung relevanten Möglichkeiten, nicht, so schnell an, wie die Schlüssellänge einem suggeriert.

[MaxT]

virsh schrieb:
--------------------------------------------------------------------------------
> M.P. schrieb:
> ---------------------------------------------------------------------------
> -----
> > MaxT schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > Solches Wissen macht das Entschlüsseln erheblich einfacher. Okay okay
> > ...
> > > Verfahren wie AES setzen nicht umsonst nicht auf ein einfaches XOR
> > zwischen
> > > Inhalt und Schlüssel,
> >
> > Wenn die Schlüssellänge länger, oder gleich lang wie die Nachricht ist,
> und
> > der Schlüssel wirklich zufällig erzeugt, kann man auch ein einfaches XOR
> > benutzen, und ist völlig sicher.
> > Bei einem rollierend mehrfach verwendeten Schlüssel sollte man das nicht
> > machen ;-)
>
> Der Vollständigkeit halber:
> Nennt sich One-Time-Pad und ist meines Wissens nach das einzig (bewiesene)
> informationstheoretisch sichere Verschlüsselungsverfahren.
>
> Bei dem Beispiel mit MD5 stimmt es zwar, dass es kein
> Verschlüsselungsverfahren ist, dennoch passt der Vergleich in den Kontext.
> Es reicht nämlich aus, zu veranschaulichen, dass bei einer Rechnung
> Informationen verloren gehen können. Bei einer Abbildung kann ich nicht
> zwingend aus dem Bild wieder das Urbild berechnen, genau da ist der Witz an
> der ganzen Sache. Anwendung findet sowas, wenn auch in sehr kleinem Rahmen
> und sehr sehr simpel (da gibt es tollere Dinge, Stichwort One Way Functions
> - Einwegfunktionen), als Beispiel sollte es aber genügen, bei RSA. Es
> werden für den Modulus zwei große Primzahlen multipliziert und deren
> Ergebnis kann veröffentlicht werden. Ein Angreifer kennt die Primzahlen
> nicht und kann aus dem Ergebnis nur seeeehr schwer auf die ursprünglichen
> Zahlen zurückrechnen. Funktioniert aber auch nur deshalb, weil man annimmt,
> dass Faktorisieren ein schweres (NP-vollständig?) Problem ist, bewiesen ist
> das nicht.
> Angemerkt sei auch noch, dass ich für das Entschlüsseln nicht zwingend eine
> Umkehrfunktion der Verschlüsselungsfunktion benötige. Am Beispiel von
> Blockschiffren wie dem CBC kann man sich das anschauen.
> Wenn ich mich nicht täusche, macht das der DES genauso.
>
> Zu den mathematischen Formeln, die bekannt sind oder auch nicht:
> Kerkhoffs Prinzip besagt, dass die Sicherheit eines Verfahrens nur vom
> Schlüssel abhängen darf, nie vom Verfahren selbst. Stell dir mal vor, eine
> Firma wie IBM benutzt ein Verschlüsselungsverfahren, einer findet den Code
> raus und sie dürfen sich ein neues Verfahren ausdenken. Demnach sind
> selbstverständlich alle anerkannten Verschlüsselungsverfahren (und sonstige
> kryptografische Leckerheiten wie Hashen, Signaturen, ...) frei verfügbar.
>
> Zum Abschluss:
> Die ganzen Rechnungen um die Dauer von Brute-Force-Attacken lassen meiner
> Meinung nach eines unter den Tisch fallen, zumindest wird es nicht erwähnt:
> Das ist immer nur die absolut maximale Dauer, d.h. wenn der allerletzte
> Schlüssel der richtige ist. Im Allgemeinen sollte ich aber mit einer
> BF-Attacke weitaus früher erfolgreich sein (was mir zumindest ein paar
> Jahre ersparen wird ;))

Das One-Time-Pad ist intuitiv (nein, ich habe darüber nicht recherchiert und meditiert) das einzige Verfahren, dass wirklich sicher sein kann. Wurde hier in der Diskussion ja schon öfter erwähnt, nur nicht unter diesem Namen. Der eigentliche Witz am One-Time-Pad ist ja, dass, nehmen wir mal an es wird nur XOR benutzt, man aus jedem verschlüsselten Text jeden unverschlüsselten Text machen kann. Sollte man also zur herausgabe des Schlüssels gezwungen werden, sollte man immer einen gefälschten Schlüssel besitzen, der statt der eigentlichen Information nur Kuchenrezepte produziert :)

[Weltverbesserer]

Linguist schrieb:
--------------------------------------------------------------------------------
> In deinem Umfeld wird du bestimmt als Computerexperte angesehen und um Rat
> gefragt :)

Made my day! :D

[Weltverbesserer]

Ampel schrieb:
--------------------------------------------------------------------------------
> lala1 schrieb:
> ---------------------------------------------------------------------------
> -----
> > Das du keine Ahnung hast merkt man an ganz schnell an solchen Aussagen
> > "Rechenkern mit 4 X 3.0 Ghz" ... wenn du schlau wärst hättest du
> wenigstens
> > GPU-Kern oder sowas gefaselt aber das disqualifiziert noch schneller LOL
>
> Das zeigt auch wieder einmal was für einen Unqalifizierten Müll du ablässt
>
> Englisch Graphics Processing Unit – GPU
>
> de.wikipedia.org
>
> Was hat eine GPU bitteschön mit einer Quad CPU (Beispiel) zu tun ?

Spätestens dieser Post disqualifiziert ihn als Troll.
Mal abgesehen von seinem penetranten ".!".

[klischeepunk]

Weil es übrigens thematisch so schön passt möcht ich für die ganzen Pfosten die Verschlüsselung nicht verstehen und gestern Pi s letzte Stelle berechnet haben folgenden Link hinterlassen:
http://www.schneierfacts.com/

Für all die Cryptonerds, diejenigen die wissen, was mit Rechnern möglich ist und die verstanden haben, dass die Meldung original gar nichts aussagt, hab ich auch nen Link:
http://www.schneierfacts.com/

Und für alle die an die glauben die böse böse Regierung hackt sich nun in unsere EMails weil sie so durchtrieben und hinterlistig sind:
http://xkcd.com/538/

(die hacken nicht, die lesen halt oder verhaften euch aus anderen gründen, ist ja nicht so dass die einen brauchen. Empfehle Udo Vetter beim 23C3 ;) )

Cheers

[skeptiker0815]

Mal zur Auflockerung :-)

mfeldt schrieb:

> Löse er mal bitte folgende Gleichung nach X auf:
>
> Y = -3*1.1^x - 3*0.7^x + 2
>

Mache ich doch glatt ;-).
Erstmal definiere ich mir eine Funktion G(a,b,c) folgendermaßen:
Der Funktionswert von G(a,b,c) sei derjenige Wert s für den gilt
0=e^(as)-e^(bs)+c.

Wie man leicht sieht gilt dann:
x=G( ln(1,1), ln(0.7), (Y-2)/3 ).
fertsch ;-),

Jetzt muss ich mir nur noch einen Algorithmus überlegen, der G(a,b,c) auch wirklich ausrechnet. Das dieser (nicht bei diesem Beispiel) extrem Aufwendig sein kann, ist der Punkt bei dem Ampel so tut als würde er es nicht verstehen.

[HomerSimpson]

So, ich hab mir jetzt nicht alles durchgelesen, aber ich muss doch mal die Ampel auf rot schalten, weil, sorry, aber du hast es glaube ich echt nicht verstanden.

@Ampel
1. In deiner "Maschinen programmieren Algorithmen" ist ein kleiner Denkfehler. Man müsste voraussetzen, dass diese Maschinen auf neue mathematische oder irgendwelche anderen physikalischen Eigenschaften kommen müssten, die wir Menschen nicht kennen. Ansonsten ist die Maschine nur so gut wie der Programmierer...

2. Warum sollte ich mir einen 4096 BIT!!! Schlüssel merken?! Diesen müsste ich nicht mal eingeben. Schon mal was von Smartcards gehört? Es gibt z. B. welche, bei denen man ein Kennwort eingeben muss um an diesen Schlüssel zu kommen. Wenn dieses Kennwort nach sagen wir 10 mal nicht richtig eingegeben wurde, ZERSTÖRT sich die Karte selbst und man hat keine Möglichkeit mehr an den Inhalt zu kommen... Und ich kann mir auch aus einem 4GB File einen 4096 Bit Schlüssel generieren nur so zur Info...

3. Das einfachste wird sein den Schlüssel durch Erpressung bzw. durch Folter zu bekommen - das braucht vermutlich nur ein paar Minuten/Stunden/Tage.

4. Mit einem FLOP ist noch nix berechnet...

5. Man muss erst einmal herausbekommen mit welchem Algorithmus verschlüsselt wurde...

6. Eine XOR Verschlüsselung ist NICHT knackbar! (One-Time-Pad)

7. Theoretisch könnte es natürlich passieren, dass der Schlüssel schon nach ein paar Durchläufen rausfällt... Deswegen One-Time-Pad ;)

@rangnar:
> Ja. Richtig. Man kann jeden verschlüsselten Text knacken. Denn die Texte sind endlich und wir haben unendlich Zeit. Wie können jede Kombination der Schlüssel mit jedem bekannten und unbekannten Verschlüsselungs-Algorythmus durchprobieren, irgendwann kommt man zum Ergebnis. Wenn man bis dahin nicht vergessen hat, was die Frage war. Die Antwort könnte 42 sein.

Nein eben nicht! Bei einer XOR Verknüpfung von Daten erhalte ich aus einem sagen wir 4GB verschlüsselten File ALLES! Um es etwas zu verdeutlichen: Ich erhalte quasi jeden Film der jemals gedreht wurde mit unterschiedlicher besetzung in den unterschiedlichsten Formen. Aber wer sagt dir jetzt, welchen Inhalt ich zuvor verschlüsselt habe?! Vielleicht war es ja nur ein privates Urlaubsvideo welches ich gedreht habe...



2 mal bearbeitet, zuletzt am 24.05.12 18:07 durch HomerSimpson.

[defaulx]

MaxT schrieb:
> Alles was man über den Inhalt bereits weiß ist potentiell gefährlich. Und
> das könnte bei einem verschlüsselten Dateisystem z.B. der Header sein, zu
> dem zu allem Überfluss auch noch die Position im verschlüsselten Datenstrom
> bekannt ist.
>

Daher gibt es ja moderne block encryption modes wie CBC oder besser noch XTS.

[el3ktro]

Ja, One-Time-Pads sind absolut sicher, solange sie die gleiche Länge haben wie die Nachricht und solange sie wirklich zufällig sind, also keine Muster (Wiederholungen) haben.

Nur muss man eben das One-Time-Pad sicher zum Empfänger übertragen können. Wenn man aber das One-Time-Pad sicher übertragen kann, kann man eigentlich auch gleich die eigentliche Nachricht sicher übertragen, denn beide haben ja die gleiche Länge ...