Hallo, vielleicht eine dumme Frage, aber nachdem ich etwas im Internet gesurft habe frage ich mich: Spricht eigentlich etwas dagegen, wenn man Software, die Dateien verschlüsselt, verbreitet? In vielen Länder scheint Verschlüsselung ja sogar verboten zu sein, und wenn nicht, dann ist es teilweise nur unter sehr strengen Auflagen erlaubt. Weiß jemand, wie das in Deutschland aussieht? Grüße, Bernd
Kannst in D soviel Verschlüsselungssoftware verbreiten wie du willst. Gibt auch nicht mehr viele Länder wo das verboten ist, macht in Zeiten des Internets auch eher wenig Sinn.
Soweit ich weiß gibt es sowas in D nicht. Du musst aber vermutl. bald bei Schäuble einen Master-key hinterlegen :-)
Ist eigentlich das reine Kombinieren von Daten (als Datei1 XOR Schlüsseldatei (1MB)) schon eine Verschlüsselung?
ja, sogar eine sehr sichere und wenn die Schlüsseldatei genau so lang ist wie die Datei ansich und schön verteilte Werte enthält sogar die sicherste Verschlüsselung die es gibt. Gruß Roland
Roland Praml wrote: > ja, sogar eine sehr sichere und wenn die Schlüsseldatei genau so lang > ist wie die Datei ansich und schön verteilte Werte enthält sogar die > sicherste Verschlüsselung die es gibt. Aber nur wenn der Schlüssel perfekt zufällig ist und nur ein einziges mal verwendet wird. Dann ist es die bisher einzig bekannte Verschlüsselung die außer Brute Force nicht zu brechen ist.
Das Verbot von Verschluesselungssoftware ist ein Auswuchs von sprachlich Unterbelichteten, sogenannten Einsprachlern. zB den Franzosen. Sprachlich Erfahrenere wissen, dass ein Dialekt so gut wie eine Verschluesselung sein kann. Hatten die Allierten in WW2 nicht Navaho Indianer zum Senden von geheimen Meldungen ? Der Stamm ist hinreichend klein und die Chance dass der Feind einen solchen hatte war Null.
3365 wrote: > Hatten die Allierten in WW2 nicht Navaho > Indianer zum Senden von geheimen Meldungen ? Der Stamm ist hinreichend > klein und die Chance dass der Feind einen solchen hatte war Null. Ich denke nicht das man sich heutzutage auf sowas verlassen würde. Erstens kann man vielleicht doch noch irgendwo jemanden finden der die Sprache spricht und zweitens muß sie komplex genug sein um nicht durch Analyse "erraten" zu werden.
Jurij G. wrote: > Roland Praml wrote: >> ja, sogar eine sehr sichere und wenn die Schlüsseldatei genau so lang >> ist wie die Datei ansich und schön verteilte Werte enthält sogar die >> sicherste Verschlüsselung die es gibt. > > Aber nur wenn der Schlüssel perfekt zufällig ist und nur ein einziges > mal verwendet wird. Dann ist es die bisher einzig bekannte > Verschlüsselung die außer Brute Force nicht zu brechen ist. Noch besser: Du kannst die Daten dann garnicht mehr entschlüsseln. Auch BruteForce funktioniert nicht, weil du aus den verschlüsselten Daten beliebige Daten erzeugen kannst. Du weist also nie, ob du den richtigen Schlüssel gerade gefunden hast. Verschlüsselung ist in Deutschland erlaubt. Hab meine ganze Datenpartition verschlüsselt (Twofish, 256Bit), unter Linux ist das schon länger transparent möglich. Für windows gibt's zB. Truecrypt.
Das ist richtig, soll nur den Unsinn eines Verschluesselungsverbotes zeigen. Man kanns immer so machen, dass der Mithoerer nichts versteht, auch ohne Verschluesselung.
keine sorge die eu wird uns schon noch zur rausgabe der schlüssel zwingen .... und ich kündige an der stelle schon an das ich da nicht mitmachen werde ... ich werde dann sofort auswandern .... bzw ich sehe nach galileo das nächste teure super projekt riesiege rechner systeme die auf das knacken von private key´s spezialisiert sind ... haltet ihr es für schizophren 16 MB ssh key´s zu verwenden .... ich tue das schon jetzt
>keine sorge die eu wird uns schon noch zur rausgabe der schlüssel >zwingen .... und ich kündige an der stelle schon an das ich da nicht >mitmachen werde ... ich werde dann sofort auswandern .... bzw ich sehe >nach galileo das nächste teure super projekt riesiege rechner systeme >die auf das knacken von private key´s spezialisiert sind ... haltet ihr >es für schizophren 16 MB ssh key´s zu verwenden .... ich tue das schon >jetzt Wie wollen das die deutschen Stasi-Spasten denn bitte machen wollen, wenn du den Key vergessen hast. Ausserdem kennst du das Copacobana Projekt? http://de.wikipedia.org/wiki/Copacobana Ein Haufen FPGA's für ne popelige 56Bit-Verschlüsselung, was sollen die dann nur bei 512Bit machen... :)
Schlüssel jenseits der 256 Bit (symmetrisch) sind auf absehbare Zeit nicht zu knacken.
Ich wrote: > Ausserdem kennst du das Copacobana Projekt? > http://de.wikipedia.org/wiki/Copacobana Aus dem Artikel: >Dabei sind die symmetrischen und asymmetrischen Chiffrierverfahren am >weitesten verbreitet, obwohl sie durch die Brute-Force-Methode, einem >Ausprobieren aller möglichen Schlüssel grundsätzlich zu brechen sind. Da kennt sich jemand ja richtig aus...
>Da kennt sich jemand ja richtig aus...
Stimmt mit dem Satz etwas nicht?
symmetrisches oder asymmetrisches Chiffrierverfahren.... Eine Klasse trifft doch zwingend immer zu, oder? (jetzt rein vom Sprachgefuehl her.)
>keine sorge die eu wird uns schon noch zur rausgabe der schlüssel >zwingen .... Aus der Treucrypt-Doku: Plausible Deniability In case an adversary forces you to reveal your password, TrueCrypt provides and supports two kinds of plausible deniability: 1. Hidden volumes (for more information, see the section Hidden Volume). 2. It is impossible to identify a TrueCrypt volume. Until decrypted, a TrueCrypt volume appears to consist of nothing more than random data (it does not contain any kind of "signature"). Therefore, it is impossible to prove that a file, a partition or a device is a TrueCrypt volume or that it has been encrypted. However, note that for system encryption, the first drive track contains the (unencrypted) TrueCrypt Boot Loader, which can be easily identified as such (for more information, see the chapter System Encryption). In such cases, plausible deniability can be achieved by creating a hidden operating system (see the section Hidden Operating System).
Ihr benutzt das Tool auch? :) Serpent-Twofish-AES und ein ziemlich langes und kompliziertes Passwort. Keine Ahnung ob dieser Schluessel was taugt, aber er klang so geheimnisvoll. :D
Krypton wrote: >>Da kennt sich jemand ja richtig aus... > Stimmt mit dem Satz etwas nicht? Naja das Verschlüsselungsverfahren die 2 aus 2 Klassen angehören am weitesten verbreitet sind liegt ja irgendwie auf der Hand, und das "obwohl sie" klingt als hätten sie einen ernsten Mangel, dabei ist gegen Brute Force nun mal nicht wirklich viel zu tun. Wenn 1000000 Affen 1000000 Jahre auf die Tastatur hacken kommt irgendwann auch mal ein Meisterwerk raus.
@WTF wegen den Hidden volumes so ganz einfach ist es leider nicht, verschlüsselte daten zu verstecken. Denn wie wahrscheinlich ist es dann das jemand auf seiner festplatte eine Bereich freiläst und sich in diesem Bereich zufällig daten sind die keine Muster aufweissen.
@Peter: Truecrypt schreibt grundsätzlich ein "Rauschen" auf die Platte - egal ob ein hidden volume angelegt wurde oder nicht. Dass es überhaupt eine Truecryptpartition gibt, ist natürlich leicht erkennbar. Es geht also lediglich um die Frage, ob in der Truecryptparition ein hidden volume steckt oder nicht.
@Gast und was hilft da? Wenn es eine Veschlüsselten bereich gibt dann weiss jeder das dort daten versteckt werden. Wenn man jetzt gezwungen wird die Schlüssel rauszugeben, dann kann man ja vergleichen ob noch ein "Rest" existiert wo noch daten sein müssen. Was ich mir vorstellen könnte ist das das Hidden volume als Datei vorhanden ist, aber dann kann man ja auch gleich eine normale Container datei verwenden.
Peter wrote: > @Gast > und was hilft da? Wenn es eine Veschlüsselten bereich gibt dann weiss > jeder das dort daten versteckt werden. Wenn man jetzt gezwungen wird die > Schlüssel rauszugeben, dann kann man ja vergleichen ob noch ein "Rest" > existiert wo noch daten sein müssen. > Was ich mir vorstellen könnte ist das das Hidden volume als Datei > vorhanden ist, aber dann kann man ja auch gleich eine normale Container > datei verwenden. Stell dir das so vor: <------Truecrypt Volumen-------Daten---------|----Zufallszahlen> Sprich ein ganzes Volume wird mit Zufallszahlen gefüllt, bis es voll ist. Es gibt also keinen "freien Platz". Nun kannst du in diesem "Rest" noch ein Truecrypt-Volumen anlegen, mit einem anderen Key verschlüsselt. Selbst wenn man das "obere" Volume z.B. per erpresstem Key entschlüsselt, hat man keine Möglichkeit festzustellen, ob in dem "freien Platz" noch ein weiteres Volume steckt oder nicht, außer man hat den richtigen Key zu dem "tieferen" Volumen. Nachteil ist das man dich generell foltern könnte da man ja immer vermutet das da ein zweites Volumen ist, auch wenns gar keins da ist ;)
warum sollte man das nicht feststellen können? ich schreibe der entschlüsselte" Festplatte voll und schau wie viele Daten drauf passen die differenz zu der Gesamten Partition ist die hidden partition.
@ Peter: Wenn du die "entschlüsselte Festplatte" vollschreibst überschriebst du so irgendwann die "Hidden Partition" und das wars. Der "hidden Part" liegt am Ende des eignetlichen Containers! Deshalb wird auch empfohlen den "vorzeige Teil" zuerst zu füllen und danach nicht mehr zu verändern...
Bernd wrote: > Ist eigentlich das reine Kombinieren von Daten (als Datei1 XOR > Schlüsseldatei (1MB)) schon eine Verschlüsselung? Siehe Vernam's Onetime Pad: http://de.wikipedia.org/wiki/One-Time-Pad
Tututack wrote: > Wenn du die "entschlüsselte Festplatte" vollschreibst überschriebst du > so irgendwann die "Hidden Partition" und das wars. Richtig! > Der "hidden Part" liegt am Ende des eigentlichen Containers! Nee, das Hidden Volumen ist eingestreut in den eigentlichen Container!
Ich bin mal gespannt ob ich noch die Entwicklung eines Quantenrechners miterlebe. Mit einem solchen Rechner lassen sich verschlüsselte Daten in Minuten knacken (für die herkömmliche Rechner Jahre brauchen).
Auch nicht. Quantenrechner sind zwar besser geeignet, aber wenn du dann Schlüssel mit tausenden Bits nimmst (zB. 4096) werden die nötigen Quantenrechner immer teurer und schließlich unbezahlbar.
dann erzeuge mal einen 4096bit schlüssel und dann merkt man schnell das auch eine aktuelle CPU gut damit beschäftigt ist - wenn ich dann einen Quadcore brauche nur um Onlinebanking zu machen ist das auch nicht so toll.
Wenn das einzig sichere Verfahren das One-Time-Pad Dingens ist, stellt sich doch wohl nur die Frage, wie erzeuge ich einen Schlüssel und transportiere diesen. Und wenn ich auch den schnellsten Computer habe, der alle Brute-Force Lösungen in Sekundenschnelle errechnet, woher weiß ich, ob der Text ursprünglich ein Bibeltext, Kuchenrezept oder Startcode für Atomraketen war; alles ist möglich. Oder habe ich was falsch verstanden?
Dein Onlinebanking wird mit asynchronen ciphern verschlüsselt, da sind Schlüssellängen jenseits der 1024Bit normal. Ich hab's mal durchgetestet, 1GB Container in eine Ramdisk und Zeit bis der mit 0en beschrieben wurde. Hab je 2 Messungen gemacht. twofish: 128 bit: 40MB/s (39.9, 40) 256 bit: 42MB/s (41.9, 42.6) leider kann die aktuelle twofish Implementierung nur bis 256bit :( blowfish: 256 bit: 34MB/s (33.9, 34) 448 bit: 34MB/s (33.8, 34.1) aes: 128 bit: 50MB/s (49.3, 50.5) 256 bit: 44MB/s (43.9, 44.1) Wirklich langsamer wir wie man sieht nur AES, twofish sogar schneller. Leider können die cipher im linux kernel im Moment nur max. 256 bzw. 448 Bit, das liegt aber nicht an der Machbarkeit, sondern daran, dass 128bit heute als sicher anzusehen sind. CPU war ein A64 X2 2*3.2GHz, Platte hatte Sendepause (6GB Ram).
Ein 128 Bit Schlüssel in Kombination mit einem Verschlüsselungssystem, das keine bekannten Schwachstellen hat (z.B. AES), ist unknackbar. Per BruteForce würde man 10^16 Jahre (Alter des Universums: ~10^10 Jahre) brauchen, wenn man annimmt, das ein Supercomputer 10^-15 Sekunden pro Versuch hat. (2^128*10^(-15)/60/60/24/365). Nur um mal die Dimensionen zu veranschaulichen, von denen wir hier reden.
Es ist aber zu bedenken, dass man unter Umständen bei der Brute-Force Attacke Glück hat und die Daten gleich beim ersten Versuch korrekt entschlüsselt werden können. Dann bräuchte es nicht 10^16 Jahre sondern lediglich einige Millisekunden. Aber ist natürlich schon recht unwahrscheinlich ;-)
Beim Banking wird beides verwendet (symmetrisches oder asymmetrisches ). Weil die Rechneleistung zur übertragung von daten für das Asymmetrisches viel zu hoche währe. Schau dir mal die zahlen aus dem Benchmark an, wie sich 1024 zu 4096 beim schlüsselaustausch verhält. http://botan.randombit.net/bmarks.html Es mag sein, das der Client-PC das dann noch schafft. Aber den Server wird damit wohl seine Probleme haben.
RSA verhält sich nunmal quadratisch, das ist doch keine neue Erkenntnis. Im Moment geht die ganze Rechnerindustrie in Richtung Multicore bzw. spezialisierte PUs, ein RSA Prozessor ist da kein großer Schritt. VIA baut ja schon eine ganze Weile eine AES Einheit in die CPUs, die - oh wunder - alle aktuellen CPUs verdammt alt aussehen lässt. Dabei ist die Einheit selbst garnet besonders aufwendig, ist halt das übliche Verhalten Hardware vs. Software. http://www.linuxjournal.com/article/8042 1.7GB/s ist schon verdammt flott. Oben stehen ja die Werte die ich erreicht habe, müssten 512 Byte Blocks gewesen sein. Gerade RSA eignet sich für Hardwareumsetzung. 1024bit div/mod/mul bringt da sicher richtig Geschwindigkeit.
Duh wrote: > Ein 128 Bit Schlüssel in Kombination mit einem Verschlüsselungssystem, > das keine bekannten Schwachstellen hat (z.B. AES), ist unknackbar. Per > BruteForce würde man 10^16 Jahre (Alter des Universums: ~10^10 Jahre) > brauchen, wenn man annimmt, das ein Supercomputer 10^-15 Sekunden pro > Versuch hat. (2^128*10^(-15)/60/60/24/365). > > Nur um mal die Dimensionen zu veranschaulichen, von denen wir hier > reden. Man braucht im Durchschnitt aber nur 1/2 So viele Versuche und das Jahr hat 365.25 Tage ;) Dann sinds "nur" 53914487622781590 Jahre :P
@Jonny >Ich bin mal gespannt ob ich noch die Entwicklung eines Quantenrechners >miterlebe. Mit einem solchen Rechner lassen sich verschlüsselte Daten in >Minuten knacken (für die herkömmliche Rechner Jahre brauchen). Für den Moment hättest du Recht. Aber wie es immer ist werden diese Rechner kurz darauf auch für den Ottonormalsterblichen nutzbar sein und dann ist der Vorsprung schnell wieder futsch da die Anwender ebenfalls aufgrund der Geschwindigkeit aufwändiger verschlüsseln können. War die Enigma damals noch unknackbar so würde man Heute mit einem normalen PC über diese Verschlüsselung nur müde lächeln. Es geht beim Verschlüsseln immer nur um den gewissen Vorsprung, mehr nicht. die Frage ist viel mehr ob man denn Daten hat die zu verschlüsseln sich lohnen ?
Enigma war nicht unknackbar, sondern hatte viele eklatante Schwachstellen. Daher war es überhaupt erst möglich den Funkverkehr zu entschlüsseln, und trotzdem brauchte es enormen Aufwand. Hätte man damals einige Details anders gelöst, wäre der Code nicht zu knacken gewesen.
>Enigma war nicht unknackbar, sondern hatte viele eklatante >Schwachstellen.....usw. Es spielt kein rolle ob sie Schwachstellen oder eklatante Schwachstellen hatte. Damals waren die Nachrichten nicht in brauchbarer Zeit zu entschlüsseln und genau darauf kam es an und kommt es immer noch. Es ist wie mit Tresore oder ganze Verschlussanlagen. Überwindbar sind sie alle ohne Ausnahme. Der Trick dabei ist den Einbrecher/Dieb solange aufzuhalten bis man ihn schnappen kann (Wachrunde usw.) bzw. den Aufwand derart in die höhe zu treiben das es sich nicht lohnt. Bei Verschlüsselungen ist es das Gleiche. Von groben Fehlern mal abgesehen ist es leicht Daten so zu verschlüsseln das der Aufwand für die Entschlüsselung in die Höhe schnellt. Folglich bestimmt der Wert der Daten den Aufwand für die Ver- und Entschlüsselung. Für die privaten Daten von dir und mir wird man kaum Ressourcen verschwenden. Bei schwereren Straftaten wird schon mehr eingesetzt. Und bei Top-Informationen entsprechend summen von denen wir beide bis zum Lebensende gut auskommen würden. Die Frage ob man denn überhaupt Daten hat deren Verschlüsselung sich lohnen würde habe ich deshalb mit Absicht ganz am Ende gestellt. ;)
>>Enigma war nicht unknackbar, sondern hatte viele eklatante >>Schwachstellen.....usw. > > Es spielt kein rolle ob sie Schwachstellen oder eklatante Schwachstellen > hatte. > Damals waren die Nachrichten nicht in brauchbarer Zeit zu entschlüsseln Etwas geschichtliches Grundwissen sollte man schon haben wenn man über Kryptographie reden will.
Ja und auch die Zeiträume und deren Möglichkeiten beachten über die gesprochen wird. Also zwischen Zivil und Militärische Variante sowie Zeitpunkt der Indienststellung und ersten Erfolgen bei der Deschiffrierung. Ebenso sollte man taktische Fehler ausklammern die nicht dem Gerät anzulasten sind (Dilletantische Fehler mit Modernen Verfahren führen zu ähnlichen Pannen). Das es dennoch Nachrichten gibt die man bis Heute nicht entschlüsselt hat kann man zb. hier...... http://de.wikipedia.org/wiki/Enigma_(Maschine) .....nachlesen.("Kryptographische Stärken" 3. Absatz) Richtig, etwas geschichtliches Grundwissen sollte man schon haben wenn man über Kryptographie reden will. ...Und ein Gefühl für Zeitliches ;)
Sind ja anscheinend viele da die sich einigermassen mit Kryptographie auskennen, darum eine Frage: Bei einer Brute-Force Attacke, wie findet man bei einem Versuch eigentlich raus, wann die Daten korrekt entschlüsselt worden sind? Da man die Daten ja nicht kennt, kann man nicht auf ein Muster prüfen.
meist am Inhalt, weil sich die Bits des Schlüssels auf die gesamte Datei Auswirken kann man entscheiden ob das ergebniss wahrscheinlicht richtig ist. Wenn man überhaupt keine Ahnung von den Entschlüsselten daten hat, geht es meines Wissens nicht. Ausser es ist jemand so dumm und schickt eine Prüfsumme der Entschlüsselten daten zur sicherheit mit.
Soweit ich weiß geht das bei den asymmetrischen Verfahren schon. Beim One Time Pad geht das natürlich nicht.
Aha, sofern der Verschlüsselungsalgorhythmus was taugt, wäre es dann praktisch unmöglich, mehrfach hintereinander verschlüsselte Daten mit einigermassen unbekanntem Inhalt per Brute-Force korrekt zu entschlüsseln. Sagen wir mal, wir hören einen Datenstrom von einem Kommunikationssateliten ab und versuchen ihn zu knacken, dann müsste man schon noch einige Informationen daüber haben, was ungefähr übermittelt wird. Ob es sich z.B. um eine Videokonferenz handelt, PDF Dateien, ZIP Dateien etc. um wenigstens eine Chance zu haben um mit bekannten Mustern (z.B. Header von solchen Dateien) zu erkennen, ob die per Brute-Force entschlüsselten Daten korrekt entschlüsselt worden sind.
Wenn du mit 2 Verfahren hintereinander verschlüsselst, mit dem selben key, und nicht 2mal die selben hintereinander, ist das so als wäre der key ein Bit länger. Wenn du auch 2mal gleich hintereinander zulässt so als wären es 2 Bit mehr.
> Aha, sofern der Verschlüsselungsalgorhythmus was taugt, wäre es dann > praktisch unmöglich, mehrfach hintereinander verschlüsselte Daten mit > einigermassen unbekanntem Inhalt per Brute-Force korrekt zu > entschlüsseln. leider nicht, dann eine verschlüsste datei auch auch ein merkmal, es ist ein gleichmäßiges Rauschen ohne struktur. Wenn also nach der 1. Entschlüsselung muster in der Datei sind, kann das nicht der richtige schlüssel sein. Wenn man eine Datei mit 3DES zwei mal hintereinander mit 2 verschieden Schlüsseln verschlüsselt, dann besteht die Möglichkeit das die Datei mit einem entschlüsselungsvorgang geöffnet werden kann - dann aber mit einen 3.Schlüssel. Wenn 2 Verschiedene Verfahren verwendet werden dann geht das nicht mehr.
Sehr interessant. Ist also ähnlich wie beim SETI @ Home projekt, wo man versucht, aus dem kosmischen Rauschen heraus Signale zu entdecken. In unserem Fall entschlüsselt man also die Daten, sieht es immernoch nach Rauschen aus, dann wechselt man den Schlüssel (Einfachverschlüsselung) oder versucht nochmals zu entschlüsseln (Mehrfachverschlüsselung).
Oh, Oh, Oh, so viel gefährliches Halbwissen! Man sllte den Thread besser schliessen. @ Johnny SETI wird ganz sicher nicht dazu benutzt um kosmisches Rauschen zu analysieren! (Wäre schade um die enorme Rechenkapazität)
Frank, wieso sollte man diesen Thread schliessen? Habe in diesem Thread gelernt, dass die Sicherheit im Schlüssel stecken muss und nicht im Verfahren selbst. Von da her kann man doch alles offen legen und muss keine Angst davor haben, dass nun alles geknackt wird. Zu SETI @ Home, was wird denn Deiner Meinung nach damit untersucht?
Glaube nicht, dass dies jemanden interessiert, was ich gestern telefoniert habe ;-)
Schäube interessiert's, aber seti rechnet nun wirklich nicht an deinen Telefonaten rum. Mal schauen wann's das erste distributed computing project von der BRD gibt...
Johnny wrote: > Aha, sofern der Verschlüsselungsalgorhythmus was taugt, wäre es dann > praktisch unmöglich, mehrfach hintereinander verschlüsselte Daten mit > einigermassen unbekanntem Inhalt per Brute-Force korrekt zu > entschlüsseln. Es wäre schon möglich. >>Peter (Gast) >> Wenn man überhaupt keine Ahnung von den Entschlüsselten daten hat, >> geht es meines Wissens nicht. >Alexander Schmidt (esko) > Soweit ich weiß geht das bei den asymmetrischen Verfahren schon. > Beim One Time Pad geht das natürlich nicht. Und jetzt hab ich mich nochmal genau informiert. Und bin mir auch ganz sicher. Das Verfahren ruht ja auf dem Multiplizieren von Primzahlen, und der Angriff besteht aus dem faktorisieren des Produkts. Somit ist es einfach zu erkennen ob der errechnete Schlüssel richtig ist. Die Überlegungen zum Rauschen sind leider falsch. Wenn man mit dem falschen Schlüssel entschlüsselt kann das Ergebnis regelmäßig oder auch ein rauschen sein. @Frank: Du solltest das Halbwissen hier verbessern statt nach dem Admin zu schreien. Und woran rechnet SETI denn deiner Meinung nach.
@ Alexander Schmidt
>Und woran rechnet SETI denn deiner Meinung nach.
Das verrate ich dir doch nicht! Wenn ich es dir sagen würde, würdest du
es bestimmt jedem weiter erzählen und dann wüsstte jeder, dass der Staat
damit lediglich die kommenden Lottozahlen ausrechnet - und darum sage
ich es dir nicht!
I_ H. wrote: > Enigma war nicht unknackbar, sondern hatte viele eklatante > Schwachstellen. Daher war es überhaupt erst möglich den Funkverkehr zu > entschlüsseln, und trotzdem brauchte es enormen Aufwand. > Hätte man damals einige Details anders gelöst, wäre der Code nicht zu > knacken gewesen. Das stimmt wohl so nicht. Angreifbar wurde sie, weil die Typen immer mit festen Floskeln an Anfang und Ende gearbeitet haben und es auch mit der Zufälligkeit der Tagesschlüssel nicht so genau genommen haben. Damit haben den Codeknackern wertvolle Hinweise zur Entschlüsselung gegeben. Zudem nahmen sie es mit der Rechtschreibung deutlich genauer, als das heute üblich ist. Das Problem war weniger das Prinzip der Enigma, als ihre Anwendung. Der eigentliche Sinn der Verschlüsselung ist nicht absolute Unknackbarkeit, sondern nur, das Mitlesen der Nachrichten so zeitaufwendig zu machen, daß man, wenn es glücklich geschafft ist, mit der entschlüsselten Nachricht nichts mehr anfangen kann.
Es gab für einige wenige Anwendungen eine Enigma mit einer zusätzlichen Rolle, die auch nie geknackt wurde, weil das für die damaligen Verhältnisse viel zu aufwendig geworden wäre.
@Alexander Schmidt stimmt das entschlüsseln mit beliebigen Schlüssel geht bloss bei den symmetrischen Verfahren. Ja Das mit den Rauschen ist bloss ein Anhaltspunkt - das ist bei der Cryptoanalyse aber schon etwas mehr als nichst.
@i_h Du meinst warscheinlich die Engima M4. Die wurde auch geknackt. Sie konnten nur eine Zeitlang nicht mehr mit lesen. Siehe Wikipedia http://de.wikipedia.org/wiki/ENIGMA-M4
Der Unterschied zu den anderen Enigmas besteht aber afair darin, dass man die M3 bzw. M4 erst mit den Codebüchern knacken konnte (wobei es imho schon an Dämlichkeit grenzt die nicht regelmäßig auszutauschen). Es waren einige Schwächen in den ersten Enigmas, und eben auch im System wie Codebücher etc. verteil wurden. Wenn ich mich richtig erinnere wurde auch einzigst deutsche Funksprüche entschlüsselt, bei den Alliierten oder Japanern dagegen nicht. EDIT: Ok, eine japanische wurde auch gecknackt. Auf alliierter Seite aber nix.
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? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.