Hallo Ihr, ich weiß, Sicher geht nicht, aber das ist auch nicht Sinn und zweck der Übung. Hier geht es um die Bewertung von Verschlüsselungs und Signatur Algorithmen, insbesondere um sha256WithRSAEncryption und RSASSA-PSS gibt es irgendwo Informationen z.B. ein Ranking für solche Algorithmen? Punkte wie momentan Knackbar, ggf. erfolgreiche knack Versuche in Vergangenheit oder die Chance die Nachricht zu errechnen wäre Interessant einsehen zu können. ich weiß, viele denken sich jetzt ob jetzt 2000 Jahre oder 3000 Jahre (mit heutiger Technologie) ist doch egal... aber in der Tat definiert es den Algorithmus welcher 3000 Jahre bedarf <- in diesen Punkt besser. Vielen Dank für jeden Tipp PS. Bei diesem Thema geht es um Verschlüsselung relevanter Marktdaten wir werden hier auch in den nächsten Monaten einen Verschlüsselungs Experten mit an den Tisch holen... trotzdem ist es FÜR MICH (als aktiver Gesprächspartner) enorm wichtig, diverse Basics zu diesem Thema zu verstehen. Wie die ganzen Verschlüsselungen arbeiten bin ich auch gerade am lernen... aber das macht die unterschiedlichen Methoden für mich noch nicht gleich "Vergleichbar"
:
Verschoben durch User
Vom BSI gibt es regelmäßig aktualisierte Empfehlungen für aktuell als sicher angesehene Algorithmen und Schlüssellängen. https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html RSASSA-PSS gilt aktuell als sicher sofern die Schlüssellänge mindestens 2048 Bit beträgt. Wenn ich mich recht erinnere basiert sha256WithRSAEncryption auf RSASSA-PKCS-V1_5, das sollte man bei Neuentwicklungen nicht mehr verwenden.
https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Ob du denen traust musst du selber wissen. Das BSI ist die ehemalige Zentralstelle für das Chiffrierwesen des Bundesnachrichtendienstes, alte Kumpels der Amerikaner. Vom amerikanischen NIST gibt es ähnliche Empfehlungen. Von denen ist bekannt, dass die NSA ihnen in SP 800-90A einen schwachen Zufallsgenerator "untergeschoben" hat. Was der NSA einmal gelingt gelingt ihr auch zweimal. FIPS hat sicher auch etwas, vermutlich mit Verweis auf NIST. Einfach suchen.
Hi, erstmal danke für die Konstruktive und Hilfreiche Diskussion :) ja, BSI ist gut... hier geht es eher um Standards und Haftbarkeit <- eigen Beurteilungen sind eben auch IMMER gewagt. => vertrauen (Privat) eher fraglich. In einem Großunternehmen, vermutlich nicht anders möglich. Dennoch will ich mich nicht nur auf deren Aussage verlassen sondern eben mir selbst BASIS-Wissen aneignen (ich bin gerade "nebenbei" dabei mich mit Bouncy-Castle auseinander zu setzen... aber es ist einfacher zu verschlüsseln und entschlüsseln als es zu verstehen ^^) Aber gibt es denn noch weitere Anlaufstellen. Hier kann man sich ja nur "weiterbilden" indem man mehr und mehr liest... => was mich wundert ist, dass die Standardisierungsprozesse bei welchen die Kryptografien "durchnummeriert" werden, den sha256WithRSAEncryption, später einstufen als den RSASSA-PSS: http://oid-info.com/get/1.2.840.113549.1.1.11 <- hier die Endnummer 11 http://oid-info.com/get/1.2.840.113549.1.1.10 <- hier die Endnummer 10 ich weiß, dass neuere Entwicklungen nicht immer besser sind, aber hier wundert es mich doch sehr <- oder verstehe ich hier etwas nicht "ganz richtig"... von: http://oid-info.com/get/1.2.840.113549.1.1.5 weiß ich z.B. sicher, dass es geknackt ist...
Anton schrieb: > ja, BSI ist gut... hier geht es eher um Standards und Haftbarkeit <- Daniel H. schrieb: > RSASSA-PSS gilt aktuell als sicher sofern die Schlüssellänge mindestens > 2048 Bit beträgt. 2048 bit ist gleichzusetzen mit einem Text von 256 Zeichen. Ein einfaches XOR mit 32 beliebigen Zeichen über Sourcetext und den so gewonnenen Text noch einmal mit 32 beliebigen Zeichen XOR-en - das schafft kein Computer in Tausend Jahren. Und wenn das zweite XOR nicht von Position 0 anfängt, sondern um eine gewisse Anzahl Zeichen verschoben wird - unknackbar für immer. Wahrscheinlich ginge es auch mit 16 Zeichen, was einer Schlüssellänge von insgesammt 256 bit entspricht. Aber komplizierte Algorithmen mit komplizierten Namen - das hört sich schon mal nach unknackbar, auch wenn es nicht so ist...
:
Bearbeitet durch User
Marc V. schrieb: > 2048 bit ist gleichzusetzen mit einem Text von 256 Zeichen. Ein > einfaches XOR mit 32 beliebigen Zeichen über Sourcetext und den so > gewonnenen Text noch einmal mit 32 beliebigen Zeichen XOR-en - das > schafft kein Computer in Tausend Jahren. Das ist mit verlaub, totaler Blödsinn: wenn Du c = p ^ k1 ^ k2 nimmst, dann ist das identisch zu c = p ^ (k1 ^ k2) = p ^ kx. Es wird also durch den zweiten Lauf nicht sicherer. Und wenn Du an irgend einer Stelle einen Anhaltspunkt dafür gibst, wie der plaintext aussieht, dann hast Du sofort den Schlüssel: kx = p ^ c. Und selbst, wenn Du keine plain text Attacken zuläßt, ist so eine Verschlüsselung extrem einfach zu knacken. Mach doch mal ein einfaches Text-Beispiel, mit z.B. 2000 Zeichen. Das knackt Dir hier jeder Informatik-Student in einer halben Stunde. > Aber komplizierte Algorithmen mit komplizierten Namen - das hört sich > schon mal nach unknackbar, auch wenn es nicht so ist... Bei Cryptographie, ist es wie mit der Juristerei: wenn man davon keine Ahnung hat, sollte man sich lieber Experten-Hilfe suchen, sonst wird es teuer. Zum Glück bekommen wir die als SW-Entwickler in Form von bereits vorhandenen und bewärten Algorithmen bereits geschenkt. mfg Torsten
:
Bearbeitet durch User
Torsten R. schrieb: > Das ist mit verlaub, totaler Blödsinn: wenn Du c = p ^ k1 ^ k2 nimmst, > dann ist das identisch zu c = p ^ (k1 ^ k2) = p ^ kx. Es wird also durch > den zweiten Lauf nicht sicherer. LOL. Ich habe nur als Beispiel gleiche Schlüssellängen angegeben. Wenn aber k1 192 bit lang ist und k2 320 bit lang ist, wobei beide Schlüssel beliebige Längen zwischen 64 und 448 bit haben können (als Beispiel) - was dann ? Und k2 kann in zuerst verschlüsseltem Text zwischen 0 und 1023 bit verschoben sein (als Beispiel) ? Torsten R. schrieb: > Und selbst, wenn Du keine plain text Attacken zuläßt, ist so eine > Verschlüsselung extrem einfach zu knacken. Mach doch mal ein einfaches > Text-Beispiel, mit z.B. 2000 Zeichen. Das knackt Dir hier jeder > Informatik-Student in einer halben Stunde. LOL.
Marc V. schrieb: > Torsten R. schrieb: >> Das ist mit verlaub, totaler Blödsinn: wenn Du c = p ^ k1 ^ k2 nimmst, >> dann ist das identisch zu c = p ^ (k1 ^ k2) = p ^ kx. Es wird also durch >> den zweiten Lauf nicht sicherer. > > LOL. > Ich habe nur als Beispiel gleiche Schlüssellängen angegeben. Wenn aber > k1 192 bit lang ist und k2 320 bit lang ist, wobei beide Schlüssel > beliebige Längen zwischen 64 und 448 bit haben können (als Beispiel) > - was dann ? Dann kommst Du immer noch extrem einfach vom plain text und dem cypter text auf die beiden Schlüssel. Gibt es Dir nicht zu bedenken, dass noch kein Security-Experte (ausser Dir) auf diese Idee gekommen ist?
Marc V. schrieb: > Torsten R. schrieb: >> Und selbst, wenn Du keine plain text Attacken zuläßt, ist so eine >> Verschlüsselung extrem einfach zu knacken. Mach doch mal ein einfaches >> Text-Beispiel, mit z.B. 2000 Zeichen. Das knackt Dir hier jeder >> Informatik-Student in einer halben Stunde. > > LOL. Korrekt. Er benötigt hierzu einen Text der Länge r*k1*k2 wobei r eine hinreichend große, rationale Zahl ist (für r>100 wird es trivial) Den Rest kann man an einem Tag mit Matlab und einfachen Grundkentnissen in Stochastik zusammenfrickeln. Tipp: In einem Text kommt nicht jeder Buchstabe gleich oft vor. Man muss nur zählen können...
Torsten R. schrieb: > Dann kommst Du immer noch extrem einfach vom plain text und dem cypter > text auf die beiden Schlüssel. Erstens ist das nicht extrem einfach und zweitens: Wenn du dir plain text besorgen kannst, warum überhaupt nach Schlüssel suchen ?
Schreiber schrieb: > Tipp: In einem Text kommt nicht jeder Buchstabe gleich oft vor. Man muss > nur zählen können... LOL. Ja. Deswegen wird zweites XOR bitweise verschoben.
:
Bearbeitet durch User
Üblicherweise ist zwar beim gleichen Verfahren der längere Key sicherer. Aber beim Vergleich verschiedener Verfahren funktioniert das nicht mehr. So ist der "Sicherheitswert" eines Bits bei RSA in keiner Weise vergleichbar mit beispielsweise ECDH oder gar AES. Da können die bei RSA genannten 2048 Bits in anderen Verfahren 224 oder 112 Bits entsprechen. Ein Vergleich von 2048 Bits bei RSA mit einem zufälligen Text aus 256 Zeichen führt schon deshalb in die Irre.
:
Bearbeitet durch User
Marc V. schrieb: > Erstens ist das nicht extrem einfach und zweitens: Doch, dein Verschieben der Schlüssel führt nur dazu, dass Du einen Gesammt-Schlüssellänge hast, die maximal dem kleinsten gemeinsamen Vielfachen beider Schlüssellängen entspricht. Die beiden Einzelschlüssel brauchst Du überhaupt nicht mehr, um andere, verschlüsselte Texte zu entschlüsseln. > Wenn du dir plain text besorgen kannst, *warum überhaupt nach* > Schlüssel suchen ? Je nach dem, wo das Verschlüsselungsverfahren eingesetzt wird, gibt es Möglichkeiten, als Angreifer, entweder Teile dessen, was übertragen wird zu kennen (HTTP Header, C-Quellcode fängt meistens mit "#include" an, etc) oder es dem Verschlüsseler unter zu jubeln. Wenn es mir gelingt, Dir zu sagen, was Du verschlüsseln sollst und mir dann den verschlüsselten Text gibst, hast Du mir auch den Schlüssel gegeben. Das ist eine sehr große Schwäche in einem Verschlüsselungsverfahren und keiner würde ohne große Not so etwas einsetzen. Details kannst Du Dir hier nachlesen: https://en.wikipedia.org/wiki/Known-plaintext_attack Nochmal: Warum glaubst Du, dass Du schlauer bist, als alle anderen Kryptoexperten zusammen? Wenn Dein Verfahren keine Schwächen hätte, würde es verwendet werden.
Anton schrieb: > => was mich wundert ist, dass die Standardisierungsprozesse bei welchen > die Kryptografien "durchnummeriert" werden, den sha256WithRSAEncryption, > später einstufen als den RSASSA-PSS: Ulkiges Kriterium. Die Geheimnisse der Nummerierung von Algorithmen sagt sehr wenig aus über deren Qualität. Patente bewertet man ja auch nicht nach der Nummer.
Torsten R. schrieb: > Dir zu sagen, was Du verschlüsseln sollst und mir dann den > verschlüsselten Text gibst, hast Du mir auch den Schlüssel gegeben. Verschlüsselungsverfahren sind in sehr unterschiedlichem Mass empfindlich gegenüber einer known plaintext attack. Während die Kenntnis bereits von Teilen des Klartextes bei der ollen Enigma sehr nützlich war, ist es bei AES für die Katz. Wie auch in dem von dir verlinkten Artikel steht.
A. K. schrieb: > Torsten R. schrieb: >> Dir zu sagen, was Du verschlüsseln sollst und mir dann den >> verschlüsselten Text gibst, hast Du mir auch den Schlüssel gegeben. > > Verschlüsselungsverfahren sind in sehr unterschiedlichem Mass > empfindlich gegenüber einer known plaintext attack. Während die Kenntnis > bereits von Teilen des Klartextes bei der ollen Enigma sehr nützlich > war, ist es bei AES für die Katz. Wie auch in dem von dir verlinkten > Artikel steht. Richtig und der "Vesely Park" Algorithmus ist sehr anfällig für known plaintext attack.
Anton schrieb: > gibt es irgendwo Informationen z.B. ein Ranking für solche Algorithmen? Neben den Algorithmen selbst kann auch die Implementierung der Algorithmen eine wesentliche Rolle spielen. Und damit meine ich nicht Implementierungsfehler sondern side channel attacks: Die Möglichkeit, korrekt implementierte Algorithmen zu knacken, in dem man irgendwelche Nebeneffekte wie Details beim Stromverbrauch oder Zeitverhalten nutzt, um sich den Zugang zum Schlüssel zu erleichtern. Da kann der exakte innere Ablauf von Befehlssequenzen in modernen Prozessoren einem Nachbarprozess mehr Information vermitteln, als dem Anwender lieb ist. https://en.wikipedia.org/wiki/Side-channel_attack
Hallo Marc, Marc V. schrieb: > 2048 bit ist gleichzusetzen mit einem Text von 256 Zeichen. Ein > einfaches XOR mit 32 beliebigen Zeichen über Sourcetext und den so > gewonnenen Text noch einmal mit 32 beliebigen Zeichen XOR-en - das > schafft kein Computer in Tausend Jahren. > Und wenn das zweite XOR nicht von Position 0 anfängt, sondern um eine > gewisse Anzahl Zeichen verschoben wird - unknackbar für immer. > Wahrscheinlich ginge es auch mit 16 Zeichen, was einer Schlüssellänge > von insgesammt 256 bit entspricht. > > Aber komplizierte Algorithmen mit komplizierten Namen - das hört sich > schon mal nach unknackbar, auch wenn es nicht so ist... das von Dir vorgeschlagene Verfahren nutzt einen unsicheren Modus: https://de.wikipedia.org/wiki/Electronic_Code_Book_Mode
Torsten R. schrieb: > Richtig und der "Vesely Park" Algorithmus ist sehr anfällig für known > plaintext attack. > Möglichkeiten, als Angreifer, entweder Teile dessen, was übertragen wird > zu kennen (HTTP Header, C-Quellcode fängt meistens mit "#include" an, > etc) oder es dem Verschlüsseler unter zu jubeln. Manomanoman. Du verwechselt ständig einen Schlüssel mit fester Länge mit zwei Schlüsseln mit variabler Länge, wovon der zweite Schlüssel noch um etliche Stellen verschoben in schon einmal verschlüsseltem Text begint. Wieviele Versuche brauchst du für einen einzigen Schlüssel mit 512 bit Länge ? Wieviele Versuche für 2 Schlüssel wenn jeder zwischen 64 und 448 bit lang sein kann ? Und wieviele Versuche wenn das alles noch um 1023 (Beispiel) bits verschoben werden kann ? Es gibt nicht mehr nur Blocks mit fester Länge und es gibt auch keine Regelmässigkeiten mehr, noch dazu ist alles ist um eine unbekannte Anzahl der bits verschoben. Somit gibt es auch keine häufigsten Buchstaben bzw. Buchstabengruppen mehr.
:
Bearbeitet durch User
Marc V. schrieb: > Du verwechselt ständig einen Schlüssel mit fester Länge mit zwei > Schlüsseln mit variabler Länge, wovon der zweite Schlüssel noch um > etliche Stellen verschoben in schon einmal verschlüsseltem Text begint. Nein, Du übersiehst den Punkt, dass deine zwei Schlüssel, durch einen, längeren Schlüssel ersetzt werden können: Nehmen wir der Einfachheit halber mal zwei Schlüssel, der eine k1 2 Byte lang und der zweite k2 3 Byte lang (das gleiche Phänomen hast Du auch, wenn ein Schlüssel 8 Byte und der andere 56 Byte lang ist). Dann verschlüsselst Du jedes Byte plaintext (px) mit den einzelnen Bytes der Schlüssel (k10-k11 und k20-k22):
1 | p0 p1 p2 p3 p4 p5 p6 |
2 | xor xor xor xor xor xor xor |
3 | k10 k11 k10 k11 k10 k11 k10 |
4 | xor xor xor xor xor xor xor |
5 | k20 k21 k22 k20 k21 k22 k20 |
6 | = = = = = = = |
7 | c0 c1 c2 c3 c4 c5 c6 |
richtig? Dann wird Dir auffallen, dass ab p6 deine Schlüssel-Bytes wieder gemeinsam anfangen. Hier können wir aus k10 xor k20 bis k11 xor k22 einfach einen Schlüssel ks generieren, der genau so gut funktioniert, aber etwas länger erscheint:
1 | p0 p1 p2 p3 p4 p5 p6 |
2 | xor xor xor xor xor xor xor |
3 | k10 k11 k10 k11 k10 k11 k10 |
4 | xor xor xor xor xor xor xor |
5 | k20 k21 k22 k20 k21 k22 k20 |
6 | = = = = = = = |
7 | p0 p1 p2 p3 p4 p5 p6 |
8 | xor xor xor xor xor xor xor |
9 | ks0 ks1 ks2 ks3 ks4 ks5 ks0 |
10 | = = = = = = = |
11 | c0 c1 c2 c3 c4 c5 c6 |
Der gemeinsame Schlüssel, ist also maximal so lang, wie das kleinste gemeinsame Vielfache der Längen deiner beiden Schlüssel. Im Fall von 64 und 448 wären es sogar nur 448. Jetzt machst Du also nichts anderes als ein one time pad, bei dem Du alle 448 bits den Schlüssel wieder verwendest. > Wieviele Versuche brauchst du für einen einzigen Schlüssel mit 512 > bit Länge ? Wenn ich ein 512 bit langes plaintext / cypthertext Paar habe, dann brauche ich genau einen Versuch. Du verwechselst xor mit einem funktionierenden Verschlüsselungsalgorithmus, wie AES. Wenn ich einen kürzeres plaintext / cypthertext Paar habe, kann ich daraus immer noch einen Teil des Schlüssels extrahieren. Wenn ich weder plaintext habe, noch cypthertext habe und der plaintext von der Länge her <= 512 bits ist, dann ist ein one time pad nicht knackbar. > Wieviele Versuche für 2 Schlüssel wenn jeder zwischen 64 und 448 bit > lang sein kann ? Wenn ich z.B. annehmen kann, dass der plaintext, Text in deutscher Sprache ist und ich genügend cypher text habe, dann gehe ich in Schritten von der Gesamtschlüssellänge von 448 bit durch den cypher text und gucke mir die Verteilung an und vergleiche die ermittelte Verteilung mit der, der deutschen Sprache: Bei gleicher Verteilung habe ich mit hoher Wahrscheinlichkeit, das entsprechende plaintext byte gefunden und damit dann das entsprechende Byte im Schlüssel. Dass ganze wiederhole ich 448/8 mal. > Und wieviele Versuche wenn das alles noch um 1023 (Beispiel) bits > verschoben werden kann ? Das änderst überhaupt nichts: die ersten 1023 bits werden halt mit einem one time pad verschlüsselt, bei dem sich der Schlüssel entsprechend der ersten Schlüssellänge wiederholt. Ich werfe die ersten 1023 bit cypher text weg und gehen, wie oben beschrieben vor. Die ersten 1023 bit entschlüsselt dann das erste Semester ;-) Auch wenn Du zwei Schlüssellängen wählst, die als KGV das Produkt aus beiden Längen hat: der gesamte Schlüssel ist nicht mehr Zufällig und Du hast eine direkte Zuordnung von jedem bit des plaintext, über ein bit des Schlüssels zu exakt einem bit im cypher text. > Es gibt nicht mehr nur Blocks mit fester Länge und es gibt auch keine > Regelmässigkeiten mehr, noch dazu ist alles ist um eine unbekannte > Anzahl der bits verschoben. Wie sollte das gehen? Die Schlüssel wiederholen sich irgend wann und damit werden sie auch immer eine gemeinsame Periode haben. Wenn es keine Regelmässigkeit gäbe, wäre auch der Empfänger nicht in der Lage, den cypher text zu entschlüsseln. Vorschlag zur Güte. Du scheinst Dir ja sehr sicher zu sein, den Stein der Weisen gefunden zu haben: Implementiere Deinen Algorithmus doch mal in python, javascript oder ruby etc. Dann veröffentlichst Du das Skript und gibst einem Admin hier die beiden Schlüssel. Der Admin prüft dann, dass man aus den beiden Schlüsseln nur mit der Kenntnis des Algorithmus und des cyphertexts auf den plaintext kommt und veröffentlicht einen 100kByte Text-Datei in deutscher Sprache und den cyphertext dazu. Wenn es innerhalb einer Woche keiner schafft, den cypher text zu entschlüsseln, dann spende ich 100€ für einen guten Zweck. Wenn es einer schafft, dann spendest Du die 100€ für einen guten Zweck. Do we have deal mister Vesely?
Ich gehe davon aus, dass du (Marc 4) folgendes meinst: 2 feste Schlüssel, gegebener aber unterschiedlicher Länge. Dann ist die gefühlte Schlüssellänge tatsächlich größer, aber auch nur der KGV von den beiden Schlüssellängen. Wenn beide teilerfremd sind (z.B. Prim), multipliziert sich die gefühlte Schlüssellänge. Weils so schön ist, hab ich das mal schnell in Javascript umgesetzt. https://jsfiddle.net/wkf4e56p/4/ Es wird ein zufälliger "text" generiert, ist jetzt kein Text, hat aber ordentlich Bias (Zufallszahlen zwischen 0 und 64). Es werden 2 Keys unterschiedlicher Länge produziert. Dann wird alles ordentlich zusammen geXort. Der Graph ist die Häufigkeitsverteilung des Ciphertextes. Der Bias ist immernoch heftig, auch wenn ich relativ lange und sehr teilerfremde Keys voreingestellt habe. Schwächend kommt leider hinzu, dass ich nur Byte-lange Keys erlaube, weil ich zu Faul war das auf Bitebene zu implementieren. Dafür sind die Keys deutlich länger als vorgeschlagen. Das verschieben des zweiten Keys bringt nicht wirklich was. Im besten Fall werden die ersten n Bits mit nem eigenen Key verschlüsselt, weil da der zweite noch nicht greift. Wenn der zweite einfach um n-Bits geshiftet wird, dann bringt das genau 0. In der realen Anwendung sieht man den Bias längst nicht so schön, wie hier, weil sich realer Text eben deutlich anders verhält als meine Zufallszahlen. Aber dennoch braucht man kein Bruteforce, sondern nur genug Ciphertext und eine Vermutung, wie der Bias aussieht.
Anton schrieb: > ich weiß, Sicher geht nicht Das Stimmt nicht. OTP ist sicher. Aber nur, wenn: 1) die Schluessellaenge mindestens der Klartextlaenge entspricht 2) der Schluessel nur ein einziges mal verwendet wird Ist Punkt 1 nicht erfuellt, fuehrt das automatisch dazu, das der Schluessel mehrfach verwendet wird. Dann sogar innerhalb derselben Nachricht. Damit ist Punkt 2 auch nicht mehr einzuhalten. Das aber nur als Anmerkung zu "Sicher geht nicht". Wenn ihr qualifizierte Aussagen zu der Sicherheit von Verschluesselungsalgorithmen haben wollt, dann wendet euch einfach an Prof. Christof Paar, von der Ruhr-Universitaet Bochum. https://www.emsec.rub.de/chair/_staff/christof-paar/
Kaj G. schrieb: > Anton schrieb: >> ich weiß, Sicher geht nicht > Das Stimmt nicht. OTP ist sicher. Und Quantenverschlüsselung ebenfalls. Zumindest solange die Heisenbergsche Unschärferelation nicht widerlegt ist.
jz23 schrieb: > Und Quantenverschlüsselung ebenfalls. Zumindest solange die > Heisenbergsche Unschärferelation nicht widerlegt ist. Und damit moechtest du was sagen?
Wirklich sicher war nur KRYPTO mit der Vollbitverschlüsselung vom Kryptochef. Das war so sicher, dass er seine Webseite auf Druck von Geheimdiensten vom Netz nehmen musste. Anschließend ist er untergetaucht. Die Geheimdienste suchen ihn immer noch (oder haben ihn schon?).
Kaj G. schrieb: >> Und Quantenverschlüsselung ebenfalls. Zumindest solange die >> Heisenbergsche Unschärferelation nicht widerlegt ist. > Und damit moechtest du was sagen? Gleich kommt Kurt. ;-)
Anton schrieb: > http://oid-info.com/get/1.2.840.113549.1.1.11 <- hier die Endnummer 11 > http://oid-info.com/get/1.2.840.113549.1.1.10 <- hier die Endnummer 10 Das sind lediglich nach PKCS#1 (nichts anderes steckt hinter 1.2.840.113549.1.1) standardisierte IDs. Warum die so gewählt wurden, musst du die RSA Laboratories fragen. Die "Höhe" der OID gibt jedoch keinerlei Auskunft darüber, wie sicher der dahinter stehende Algorithmus ist. Marc V. schrieb: > 2048 bit ist gleichzusetzen mit einem Text von 256 Zeichen. Ein > einfaches XOR mit 32 beliebigen Zeichen über Sourcetext und den so > gewonnenen Text noch einmal mit 32 beliebigen Zeichen XOR-en - das > schafft kein Computer in Tausend Jahren. Nein, das ist falsch. Bei den beschriebenen RSA-basierten Verfahren sind 2048 Bit eher mit einem symmetrischen 112 Bit Schlüssel (= 14 Zeichen) gleichzusetzen. Hintergrund ist, dass der Schlüssel (oder genauer: das Schlüsselpaar) nur aus Primzahlen gebildet werden kann, was den gesamten Schlüsselraum stark einschränkt, deswegen müssen RSA-Schlüssel deutlich länger sein. Was du beschreibst ist zweifacher OTP mit zwei verschiedenen, symmetrischen 2048 Bit Schlüsseln. Dieses System bietet dir aber keine der Eigenschaften, die dir ein asymmetrisches Verfahren bietet. Da Empfänger und Sender den gleichen Schlüssel benötigen, kann z.B. der Empfänger auch Nachrichten im Namen des Senders fälschen. Schließlich bleibt das Problem der Schlüsselverwaltung, da OTP nur als sicher zu betrachten ist, wenn ein einmal verwendeter Schlüssel nicht wiederverwendet wird. Willst du also Datenmenge N verschlüsseln, dann musst du auch die gleiche Menge an zufälligem Schlüsselmaterial erzeugen und a) sicher zwischen Empfänger und Sender austauschen und b) speichern. Im von dir vorgeschlagenen Verfahren musst du sogar die doppelte Menge an Schlüsselmaterial vorhalten, ohne dass dir die zweite OTP-Rund irgendeine zusätzliche Sicherheit bietet. Im Gegenteil, es könnte sogar sein, dass du durch die zweite Runde die Sicherheit sogar schwächst. > Und wenn das zweite XOR nicht von Position 0 anfängt, sondern um eine > gewisse Anzahl Zeichen verschoben wird - unknackbar für immer. > Wahrscheinlich ginge es auch mit 16 Zeichen, was einer Schlüssellänge > von insgesammt 256 bit entspricht. Vollkommen unerheblich, aufgrund des Aufwandes für das Schlüsselmanagement ist der Ansatz im täglichen Leben nicht praktikabel. Du kannst gerne auch noch 20 mal verschieben und XORen, du gewinnst nichts, musst aber immer mehr Rechenzeit investieren. > Aber komplizierte Algorithmen mit komplizierten Namen - das hört sich > schon mal nach unknackbar, auch wenn es nicht so ist... Das ist dann ein Problem aufseiten des Lesers/Zuhörers, insbesondere wenn er sich nicht weiter informiert bzw. nicht weiter informieren will (oder der Meinung ist, dass sein selbst ausgedachtes System viel besser ist). Als unknackbar wird in der Kryptographie nichts betrachtet. Es gibt lediglich Verfahren, die nach aktuellem Wissensstand kryptographisch sicher sind, sich also mit vertretbarem Aufwand nicht in absehbarer Zeit brechen lassen. Ein Verfahren, das heute noch als sicher gilt, kann morgen schon gebrochen sein. Beispiele dafür gibt es zur Genüge, z.B. MD5, SHA-1, DES, viele weitere High-Level-Protokolle wie z.B. WEP, WPA2, A5/1, A5/2, SS7 etc.
:
Bearbeitet durch User
Kaj G. schrieb: > jz23 schrieb: >> Und Quantenverschlüsselung ebenfalls. Zumindest solange die >> Heisenbergsche Unschärferelation nicht widerlegt ist. > Und damit moechtest du was sagen? Der TO fragte oben nach Verschlüsselungsalgorithmen und wie sicher die sind. Quantenkryptographie ist zwar nicht direkt ein Algorithmus aber trotzdem eine Verschlüsselung und zwar eine aktuell unknackbare.
Horst schrieb: > Wirklich sicher war nur KRYPTO mit der Vollbitverschlüsselung vom > Kryptochef. Mir fehlten die Worte, Kryptochef!!!
ist ja spannend geworden :)
anbei für die entschlüsselungsexporten :)
RSA Verschlüsselt
> ;212170374;196004503;394095273;623762517;120405286;372248707;310428316
gesucht ist ein WORT mit 7 Buchstaben :) <- muss ja GAAAAANZ EINFACH
SEIN ;=)
so, jetzt zurück zum "ernsten" Thema.
@A.K. ja, das war mir auch klar, dass die "Nummer" nicht was über die
Qualität aussage,... aber es könnte ja sein, dass man davon ausgehen
kann, dass das (Fiktive Zahlen) 2015ner verfahren BESSER ist als das
2006er verfahren!?
<- aber während hier viele versuchen meinen Schlüssel zu knacken waren
auch ein paar Konstruktive Inhalte dabei...
noch ein paar Fragen... hat mein Verschlüsselungsalgorithmus bzw. mein
Signaturalgorithmus was mit dem Zertifikat zu tun?
=> okay soweit ich weiß ist die Schlüssellänge im Zertifikat ... d.h.
wenn ich ein Zertifikat mit 2048 Bit Schlüssellänge habe kann ich nicht
mit einer Schlüssellänge von 4096 Verschlüsseln...
Aber ob ich nun RSA oder AES oder PSS, Elyptisch oder sonst wie
Verschlüssle definiert mein Program <- oder gibt es Einschränkungen wo
man sagt, mit dem Zertifikat kann man nur "Kacke" verschlüsseln!?
=> PS. wir und viele Marktpartner verwenden die BouncyCastle Library
@jz23 <- nun gut, es sollte Realisierbar sein... wir Sprechen hier von
einen Markt mit ein paar tausend Marktparntern, teilweise Großkonzerne,
teilweise 3 Mann-Firmen d.h. ich geh davon aus dass etliche sich auf
eine Simple Dienstleistung von einem Provider einlassen...
Quantenkryptografie ist jetzt noch ein wenig schwer herzubekommen und
noch schwerer handzuhaben :) <- aber lustige Idee
Grundsätzlich gehts hier auch nur um die Bewertung der Verschlüsselung
für den Übertragungsweg, wie sicher die Systeme am ende sind kann und
will ich hier nicht beurteilen <- Frech gesagt geht das an meiner
Aufgabe vorbei :P (Aber ja, richtig, es bringt nix, die geilste
Alarmanlage zu haben, wenn das Cabrio dann offen herumsteht)
1000 Dank erstmal an alle :)
Anton schrieb: > aber es könnte ja sein, dass man davon ausgehen > kann, dass das (Fiktive Zahlen) 2015ner verfahren BESSER ist als das > 2006er verfahren!? Andersrum: Ein altes Verfahren, das den Test der Zeit überlebt hat und heute immer noch als sicher gilt, würde ich einem taufrischen und wenig erprobten Verfahren vorziehen. Nur würde ich bei der Altersbestimmung nicht nach der Nummerierung des Verfahrens gehen, sondern nach der Nummerierung des Jahres der Veröffentlichung. Das muss sich nicht decken.
:
Bearbeitet durch User
A. K. schrieb: > Kaj G. schrieb: >>> Und Quantenverschlüsselung ebenfalls. Zumindest solange die >>> Heisenbergsche Unschärferelation nicht widerlegt ist. >> Und damit moechtest du was sagen? > > Gleich kommt Kurt. ;-) Ohne Helm und ohne Gurt? :P
Anton schrieb: > noch ein paar Fragen... hat mein Verschlüsselungsalgorithmus bzw. mein > Signaturalgorithmus was mit dem Zertifikat zu tun? > => okay soweit ich weiß ist die Schlüssellänge im Zertifikat ... d.h. > wenn ich ein Zertifikat mit 2048 Bit Schlüssellänge habe kann ich nicht > mit einer Schlüssellänge von 4096 Verschlüsseln... Natürlich geht das. Wobei erst mal die Frage ist, um was es eigentlich genau geht? Sicherstellen, dass die Daten vom Urheber kommen und unverändert sind und/oder ob sie auch sicher verschlüsselt von A nach B kommen. Zurück zur Schlüssellänge: Beispiel: PGP, Sender erzeugt zufälligen Key, verschlüsselt (bspw. RSA 4096) diesen mit dem öffentlichen Schlüssel des Empfängers, verschlüsselt die Nachricht (bspw. AES-256) mit dem zufälligen Key und (erzeugt aus den unverschlüsselten Daten eine Signatur) und schickt alles an den Empfänger. jz23 schrieb: > Kaj G. schrieb: >> Anton schrieb: >>> ich weiß, Sicher geht nicht >> Das Stimmt nicht. OTP ist sicher. > > Und Quantenverschlüsselung ebenfalls. Zumindest solange die > Heisenbergsche Unschärferelation nicht widerlegt ist. OTP = One Time Pad = das einzige Verfahren, das beweisbar sicher ist und dessen Sicherheit nicht auf Vermutungen basiert wie RSA = Faktorisierung von Primzahlen ist schwer (bis es Quantencomputer gibt) oder z.B. ECC = Eliptic Curve Cryptography = Diskreter Logarithmus ist schwer zu finden (bis es Quantencomputer gibt) oder Quantenverschlüsselung (No-Cloning Theorem). Problem bei OTP: Schlüssel darf nur ein einziges Mal verwendet werden 1), Schlüssellänge >= Nachrichtenlänge, muss absolut zufällig sein und dann auch noch sicher zu allen Empfängern kommen... da würde dann ein Quantenschlüsselaustauschverfahren helfen... 1) schönes Beispiel mit Bildern: https://crypto.stackexchange.com/questions/59/taking-advantage-of-one-time-pad-key-reuse
Arc N. schrieb: > 1), Schlüssellänge >= Nachrichtenlänge, muss absolut zufällig sein und > dann auch noch sicher zu allen Empfängern kommen... da würde dann ein > Quantenschlüsselaustauschverfahren helfen... Wenn du schon eine sichere Übertragungsstrecke für einen Schlüssel baust, der mindestens so lang ist wie die zu übertragenen Daten, kannst du da auch gleich die Daten übertragen an Stelle des Schlüssels. ;-) Abgesehen davon, dass es nicht immer ganz einfach ist, an einen völlig zufälligen OTP Schlüssel zu kommen, und das beweisbar dauerhaft. Das ist nämlich der Knackpunkt bei diesem ach so beweisbar sicheren Verfahren.
A. K. schrieb: > Arc N. schrieb: >> 1), Schlüssellänge >= Nachrichtenlänge, muss absolut zufällig sein und >> dann auch noch sicher zu allen Empfängern kommen... da würde dann ein >> Quantenschlüsselaustauschverfahren helfen... > > Wenn du schon eine sichere Übertragungsstrecke für einen Schlüssel > baust, der mindestens so lang ist wie die zu übertragenen Daten, kannst > du da auch gleich die Daten übertragen an Stelle des Schlüssels. ;-) https://en.wikipedia.org/wiki/Quantum_key_distribution > Abgesehen davon, dass es nicht immer ganz einfach ist, an einen völlig > zufälligen OTP Schlüssel zu kommen, und das beweisbar dauerhaft. Das ist > nämlich der Knackpunkt bei diesem ach so beweisbar sicheren Verfahren. Naja, dass ist das übliche Problem bei allen Verfahren: Theoretisch sicher heißt nicht automatisch, dass auch die Implementierungen sicher sind. Gab's oben schon mal mit RSA, PKCS und dem Bleichenbacher-Angriff http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf Und von den div. Seitenkanälen haben wir noch gar nicht angefangen ;)
Daniel H. schrieb: > speichern. Im von dir vorgeschlagenen Verfahren musst du sogar die > doppelte Menge an Schlüsselmaterial vorhalten, Menge an Schlüsselmaterial ist unerheblich - ob 64 Zeichen oder 256 Zeichen, macht ja keinen Unterschied - man muss es sich nicht merken und ob Klartext einmal oder zweimal verschlüsselt wird, macht kaum einen merkbaren Unterschied - es kann sich nicht einmal um ms handeln. > ohne dass dir die zweite > OTP-Rund irgendeine zusätzliche Sicherheit bietet. Im Gegenteil, es > könnte sogar sein, dass du durch die zweite Runde die Sicherheit sogar > schwächst. Die Zweite Runde dient dazu, um zu verhindern, dass durch ausprobieren gleich Klartext rauskommt (Brute-Force-Attack). Durch variable Länge der beiden Schlüssel wird zusätzliche Sicherheit geboten. > Du kannst gerne auch noch 20 mal verschieben und XORen, du gewinnst > nichts, musst aber immer mehr Rechenzeit investieren. Verschieben ist dazu da, um Blöcke mit Schlüssellänge zu verhindern oder zumindest die erkennung von diesen zu erschweren. Und Rechenzeit ist kein Argument - 2 Mal XOR-en, 1 Mal verschieben... Daniel H. schrieb: > Das ist dann ein Problem aufseiten des Lesers/Zuhörers, insbesondere > wenn er sich nicht weiter informiert bzw. nicht weiter informieren will > (oder der Meinung ist, dass sein selbst ausgedachtes System viel besser > ist). Selbstverständlich bin ich nicht der Meinung, dass das viel besser ist. Es war nur eine Idee und da ich kein Experte in Kryptographie bin, kann ich dies nicht einmal mathematisch belegen. Die ganzen aufgeführten Probleme mit Schlüsseln sind natürlich wahr. Aber das gilt für alle Schlüssel. P.S. Und ich glaube immer noch, dass ein Text der auf diese Art verschlüsselt wird, in absehbarer Zeit nicht zu knacken ist.
:
Bearbeitet durch User
> Wobei erst mal die Frage ist, um was es eigentlich genau geht?
SORRY,... mein Fehler.
Es geht um praktikable Emailübertragung von "undefinierten" Systemen
(wobei natürlich Systeme [z.B. mangels unterstützung] ausgeschlossen
werden können). Die Emails sind in 99% aller Fälle Automatisch
generierte Emails in welcher Maschinenlesbare Daten enthalten sind
(Stichwort EDIFACT <- hier aber erstmal egal).
Selbstverständlich MUSS dabei der Content verschlüsselt werden UND die
Signatur validierbar sein. Das heißt, den Inhalt vor Veränderung
schützen UND den Sender zu Identifizieren <- den Inhalt davor zu
Schützen, dass er von anderen "lesbar" ist, ist in diesem fall sogar
eher "Sekundär" (aber ich geh davon aus, wenn man den Inhalt lesen kann,
kann man ihn auch verändern)...
Anton schrieb: > (aber ich geh davon aus, wenn man den Inhalt lesen kann, > kann man ihn auch verändern)... PKI Signaturverfahren haben genau den einen Sinn, Veränderungen lesbarer Mails erkennbar zu machen.
Marc V. schrieb: > Die ganzen aufgeführten Probleme mit Schlüsseln sind natürlich wahr. > Aber das gilt für alle Schlüssel. Grundfalsch! Scheinbar kennst du nicht den Unterschied zwischen symmetrischen und asymmetrischen Schlüsseln?
Anton schrieb: > Es geht um praktikable Emailübertragung von "undefinierten" Systemen Was spricht aus deiner Sicht gegen die bereits verbreiteten Verfahren für verschlüsselte Mails? Also PGP und S/MIME? Ebenso ist es problemlos möglich, die übliche Technik zur Mailübertragung (SMTP) mit Verschlüsselung der Übertragung und strenger Verifikation von Zertifikaten zu betreiben. Die Technik ist längst da, wird aber im üblichen Internet-Mailverkehr tolerant gegenüber beliebigen Zertifikaten betrieben.
:
Bearbeitet durch User
A. K. schrieb: > Wenn du schon eine sichere Übertragungsstrecke für einen Schlüssel > baust, der mindestens so lang ist wie die zu übertragenen Daten, kannst > du da auch gleich die Daten übertragen an Stelle des Schlüssels. ;-) Nein, man kann auch unterschiedliche Übertragungswege nutzen. Etwa einen Kurier für den Schlüsseln und das Telefon für die verschlüsselte Nachricht > Abgesehen davon, dass es nicht immer ganz einfach ist, an einen völlig > zufälligen OTP Schlüssel zu kommen, und das beweisbar dauerhaft. Das ist > nämlich der Knackpunkt bei diesem ach so beweisbar sicheren Verfahren. Da gabs früher schon passende Lösungen für. Etwa einen Geigerzählerzusatz für den Lochstreifenlocher... Die beiden Schlüssellochstreifen mussten sofort nach Verwendung verbrannt werden.
@Marc Vesely Ich würde sagen, deine Konstruktion ist nicht sooo schlecht, wie hier geschrieben. Sie ist auf keinen Fall sicher in irgendeinem Cryptographischen Sinne, aber so für Crypte eines Laien schon nicht schlecht. Auf jeden Fall besser, als einiges was ich gesehen habe, womit Geschäftsgeheimnisse geschützt werden. Dennoch: Ich würde nie behaupten, das ist ein sicheres Verfahren. Alles was man braucht, ist hinreichend viele verschlüsselte Daten. Aber es wird auch immer der gleiche Keystream gebildet, das heißt gleiche Nachrichten verschlüsseln zum gleichen Crypto text. Kann man auch wieder irgendwie umgehen, klar, abe4r wirklich sicher wird sowas nie werden. @Anton Wenn es nicht gute Gründe dagegen gibt, dann auf jeden Fall GPG oder S/MIME nutzen. Wie schon geschrieben, es gibt auch nur signiert ohne Verschlüsselung. Die Nachricht kann dann natürlich verändert werden, aber dann stimmt die Signatur nicht mehr. S/Mime hat nen Vorteil, wenn du öfters mal Maschinen hinzufügst und du nicht allen den neuen Key mitteilen willst. Bei S/MIME kann man die Keys in einer Hierarchie aufbauen. Der Root Key signiert deine Client Keys. Jeder der den Root PubKey vertraut, vertraut auch allen Client Keys. Dann muss man nicht allen Clients alle nötigen Keys mitgeben, dennoch weiß jeder genau wem er vertrauen kann. Zertifikate kann man von anerkannten CAs signieren lassen, für dich wäre aber wohl sinnvoller deine eigen CA zu erstellen und allen anderen das Vertrauen zu entziehen. PGP/GPG ist dagegen für kleinere oder statische Setups vielleicht einfacher aufzubauen. Jeder Teilnehmer bekommt einfach alle relevanten Keys mit ausgeliefert und dann muss man sich nicht ums Zertifikate Signieren kümmern.
@A. K. Per Quanten Key-Exchange lassen sich witzigerweise keine Nachrichten übertragen. Es braucht selbst für den Key-Exchange noch einen klassischen (unsicheren) Kanal. @Schreiber (Gast) Ein Kurier ist aber kein Beweisbar sicherer Übertragungsweg, damit ist die Beweisbare Sicherheit des OTPs total dahin. Dann lieber klassische Pubkey Krypto. Auch wenn die ihre eigenen Probleme hat, siehe Infineon gerade.
Mathias schrieb: > @Marc Vesely > Ich würde sagen, deine Konstruktion ist nicht sooo schlecht, wie hier > geschrieben. Sie ist auf keinen Fall sicher in irgendeinem > Cryptographischen Sinne, aber so für Crypte eines Laien schon nicht > schlecht. Auf jeden Fall besser, als einiges was ich gesehen habe, womit > Geschäftsgeheimnisse geschützt werden. Dennoch: Ich würde nie behaupten, > das ist ein sicheres Verfahren. Alles was man braucht, ist hinreichend > viele verschlüsselte Daten. Aber es wird auch immer der gleiche > Keystream gebildet, das heißt gleiche Nachrichten verschlüsseln zum > gleichen Crypto text. Kann man auch wieder irgendwie umgehen, klar, > abe4r wirklich sicher wird sowas nie werden. Die Idee von oben war "2048 bit ist gleichzusetzen mit einem Text von 256 Zeichen. Ein einfaches XOR mit 32 beliebigen Zeichen über Sourcetext und den so gewonnenen Text noch einmal mit 32 beliebigen Zeichen XOR-en - das schafft kein Computer in Tausend Jahren. Und wenn das zweite XOR nicht von Position 0 anfängt, sondern um eine gewisse Anzahl Zeichen verschoben wird - unknackbar für immer. Wahrscheinlich ginge es auch mit 16 Zeichen, was einer Schlüssellänge von insgesammt 256 bit entspricht." Als Beispiel mit der Annahme, dass ein Angreifender c1 und c2 (s.u.) abfangen/mitlesen kann
1 | k1 = Key 1, k2 = Key 2 |
2 | p1 = plain text 1, p2 = plain text 2 |
3 | c1 = cipher text 1, c2 = cipher text 2 |
4 | |
5 | |k1] = |k2| = 4 |
6 | |p1| = |p2| = 16 |
7 | offset = 2 |
8 | |
9 | c1[0] = p1[0] ^ k1[0] |
10 | c1[1] = p1[1] ^ k1[1] |
11 | c1[2] = p1[2] ^ k1[2] ^ k2[0] |
12 | c1[3] = p1[3] ^ k1[3] ^ k2[1] |
13 | c1[4] = p1[4] ^ k1[0] ^ k2[2] |
14 | c1[5] = p1[5] ^ k1[1] ^ k2[3] |
15 | c1[6] = p1[6] ^ k1[2] ^ k2[0] |
16 | c1[7] = p1[7] ^ k1[3] ^ k2[1] |
17 | c1[8] = p1[8] ^ k1[0] ^ k2[2] |
18 | c1[9] = p1[9] ^ k1[1] ^ k2[3] |
19 | c1[a] = p1[a] ^ k1[2] ^ k2[0] |
20 | c1[b] = p1[b] ^ k1[3] ^ k2[1] |
21 | c1[c] = p1[c] ^ k1[0] ^ k2[2] |
22 | c1[d] = p1[d] ^ k1[1] ^ k2[3] |
23 | c1[e] = p1[e] ^ k1[2] ^ k2[0] |
24 | c1[f] = p1[f] ^ k1[3] ^ k2[1] |
25 | |
26 | c2[0] = p2[0] ^ k1[0] |
27 | c2[1] = p2[1] ^ k1[1] |
28 | c2[2] = p2[2] ^ k1[2] ^ k2[0] |
29 | c2[3] = p2[3] ^ k1[3] ^ k2[1] |
30 | c2[4] = p2[4] ^ k1[0] ^ k2[2] |
31 | c2[5] = p2[5] ^ k1[1] ^ k2[3] |
32 | c2[6] = p2[6] ^ k1[2] ^ k2[0] |
33 | c2[7] = p2[7] ^ k1[3] ^ k2[1] |
34 | c2[8] = p2[8] ^ k1[0] ^ k2[2] |
35 | c2[9] = p2[9] ^ k1[1] ^ k2[3] |
36 | c2[a] = p2[a] ^ k1[2] ^ k2[0] |
37 | c2[b] = p2[b] ^ k1[3] ^ k2[1] |
38 | c2[c] = p2[c] ^ k1[0] ^ k2[2] |
39 | c2[d] = p2[d] ^ k1[1] ^ k2[3] |
40 | c2[e] = p2[e] ^ k1[2] ^ k2[0] |
41 | c2[f] = p2[f] ^ k1[3] ^ k2[1] |
42 | |
43 | OTP Key Reuse first step: |
44 | n[0] = c1[0] ^ c2[0] = p1[0] ^ k1[0] ^ p2[0] ^ k1[0] = p1[0] ^ p2[0] |
45 | n[1] = c1[1] ^ c2[1] = p1[1] ^ k1[1] ^ p2[1] ^ k1[1] = p1[1] ^ p2[1] |
46 | n[2] = c1[2] ^ c2[2] = p1[2] ^ k1[2] ^ k2[0] ^ p2[2] ^ k1[2] ^ k2[0] = p1[2] ^ p2[2] |
47 | n[3] = c1[3] ^ c2[3] = p1[3] ^ k1[3] ^ k2[1] ^ p2[3] ^ k1[3] ^ k2[1] = p1[3] ^ p2[3] |
48 | n[4] = c1[4] ^ c2[4] = p1[4] ^ k1[0] ^ k2[2] ^ p2[4] ^ k1[0] ^ k2[2] = p1[4] ^ p2[4] |
49 | n[5] = c1[5] ^ c2[5] = p1[5] ^ k1[1] ^ k2[3] ^ p2[5] ^ k1[1] ^ k2[3] = p1[5] ^ p2[5] |
Was man schön sehen kann, ist, dass sich 1. ein Schlüssel wiederholt
1 | k1[2] ^ k2[0] |
2 | k1[3] ^ k2[1] |
3 | k1[0] ^ k2[2] |
4 | k1[1] ^ k2[3] |
und 2. mit derselben Schlüssellänge wie im Fall ohne zusätzliche "Runde" und, mit etwas genauerem Hinschauen, dass man bei genügend großer verschlüsselter Nachricht nur eine Nachricht braucht für das was folgt: https://crypto.stackexchange.com/questions/2249/how-does-one-attack-a-two-time-pad-i-e-one-time-pad-with-key-reuse und https://crypto.stackexchange.com/questions/33376/what-to-do-when-crib-dragging-does-not-work-in-otp-one-time-pad-ciphers
Mathias schrieb: > Ein Kurier ist aber kein Beweisbar sicherer Übertragungsweg, damit ist > die Beweisbare Sicherheit des OTPs total dahin. Sorry, aber das ist unfug! Denn nach deiner Logik ist auch AES total unsicher, weil man den Schluessel ja erstmal sicher uebertragen muss. Hier muss unterschieden werden zwischen: - Verschluesselung - Schluesselaustausch Das sind naemlich 2 verschiedene paar Schuhe. OTP ist sicher. Warum das so ist, da kommt man sehr leicht von alleine drauf, wenn man sich OTP laenger als 2 Minuten anschaut. Den Schluessel sicher zu uebertragen ist ein voellig anderes Problem und schwaecht die Sicherheit von OTP in keinster Weise. https://de.wikipedia.org/wiki/One-Time-Pad#Sicherheit Natuerlich muss der Schluessel geheim bleiben, wie bei allen anderen Verfahren auch. Auch Public-Key-Verfahren sind nur solange sicher, wie der private Schluessel geheim bleibt. Und um einen Schluessel sicher zu uebertragen gibt es den DHKE: https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch Einige hier anwesenden sollten doch mal in einem Hoersaal der RUB Platz nehmen und die Krypto-Vorlesungen besuchen. Wem das zu aufwaendig ist, die Vorlesungen gibt es auch auf Youtube: https://youtu.be/AELVJL0axRs https://youtu.be/aeOzBCbwxUo https://youtu.be/IGqrbM52wtg https://youtu.be/DiLPn_ldAAQ
:
Bearbeitet durch User
Kaj G. schrieb: > Und um einen Schluessel sicher zu uebertragen gibt es den DHKE: > https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch Der aber wiederum, strikt nach Lehrbuch implementiert, anfällig für Man-in-the-Middle-Angriffe ist, wodurch eine weitere Autentifizierungsschicht benötigt wird. Egal wie man es dreht und wendet, am Ende kommt man immer an dem Punkt aus, dass initial ein vertraulicher Datenaustausch zwischen zwei Kommunikationspartner stattfinden muss.
:
Bearbeitet durch User
Arc N. schrieb: > |k1] = |k2| = 4 > |p1| = |p2| = 16 > offset = 2 Nicht ganz. Bei gleicher Länge und Offset aber mit Schlüssel: k1 = 7 k2 = 11
1 | c1[0] = p1[0] ^ k1[0] ^ k2[3] |
2 | c1[1] = p1[1] ^ k1[1] ^ k2[4] |
3 | c1[2] = p1[2] ^ k1[2] ^ k2[0] |
4 | c1[3] = p1[3] ^ k1[3] ^ k2[1] |
5 | c1[4] = p1[4] ^ k1[4] ^ k2[2] |
6 | c1[5] = p1[5] ^ k1[5] ^ k2[3] |
7 | c1[6] = p1[6] ^ k1[6] ^ k2[4] |
8 | c1[7] = p1[7] ^ k1[0] ^ k2[5] |
9 | c1[8] = p1[8] ^ k1[1] ^ k2[6] |
10 | c1[9] = p1[9] ^ k1[2] ^ k2[7] |
11 | c1[a] = p1[a] ^ k1[3] ^ k2[8] |
12 | c1[b] = p1[b] ^ k1[4] ^ k2[9] |
13 | c1[c] = p1[c] ^ k1[5] ^ k2[10] |
14 | c1[d] = p1[d] ^ k1[6] ^ k2[0] |
15 | c1[e] = p1[e] ^ k1[0] ^ k2[1] |
16 | c1[f] = p1[f] ^ k1[1] ^ k2[2] |
Sieht das ein bißchen anders aus, oder ?.
Hi Und/Oder man verwendet zwei/mehrere Verbindungen, Die nur zusammen 'ein Bild' ergeben. Dann müssen schon zwei 'Man in the middle' drin sein und Die müssen auch noch 'miteinander wollen'. MfG
Marc V. schrieb: > Arc N. schrieb: >> |k1] = |k2| = 4 >> |p1| = |p2| = 16 >> offset = 2 > > Nicht ganz. > Bei gleicher Länge und Offset aber mit Schlüssel: > k1 = 7 > k2 = 11 > ... > Sieht das ein bißchen anders aus, oder ?. Sieht anders aus, ja. Es wiederholt sich erst nach kgv(7,11) = 77... Ändert aber am Prinzip nichts: Sind zwei Nachrichten abgefangen/mitgehört ist c1[x] ^ c2[x] = p1[x] ^ p2[x] bzw. bei einer Nachricht c1[x] ^ c1[x + 77] = p1[x] ^ p1[x + 77]. Der/die Schlüssel fällt/fallen raus
Arc N. schrieb: > Sieht anders aus, ja. Es wiederholt sich erst nach kgv(7,11) = 77... Im Prinzip war das aber auch schon seine Aussage: Wenn man zwei Schlüssel unterschiedlicher Länge nimmt, dann erhöht sich die Sicherheit. 2x mit 256 Bit Schlüssel Xoren bringt nix zusätzlich. Aber 1x mit 255 und 1x mit 257 macht die Sache schon schwieriger. Klar ist immernoch einfaches Xor und ich behaupte mal, wenn man sich das genauer anguckt ist die resultierende Schlüsselkomplexität nicht 65535 bit(255*257) sondern eher in der Nähe der Summe. Aber ich glaube nicht, das der besagte Informatik Student das mit 100kb Text knacken kann. Kaj G. schrieb: > Hier muss unterschieden werden zwischen: > - Verschluesselung > - Schluesselaustausch Muss man? Ich guck mir immer das Gesamtpaket an. Klar ist ein OTP sicher, wenn man den Schlüsseltausch ignoriert. Dafür ist der Schlüsseltausch alles andere als Trivial. Nen ECC-Key kann man sich vorlesen oder per QR code Scannen. Der Private Key landet im Hardware Keystore und schwirrt nie im Ram rum, wo er geklaut werden kann. Mir ist klar, das auch solche Module Fehler/Backdoors haben können. Das sind dennoch Vorteile, die in realen Situationen deutlich wichtiger sind als der Theoretische Vorteil der OTPs. Ich stell mir gerade vor, Estland verteilt an ihre Bürger Ausweise mit 16GB OTP, weil alles andere ja nicht sicher ist... Mir fallen wenige Anwendungen ein, wo der Schlüsselaustausch per Kurier praktikabel ist.
Arc N. schrieb: > Sieht anders aus, ja. Es wiederholt sich erst nach kgv(7,11) = 77... > Ändert aber am Prinzip nichts: Sind zwei Nachrichten > abgefangen/mitgehört ist c1[x] ^ c2[x] = p1[x] ^ p2[x] bzw. bei einer LOL. Ganz so einfach ist es nicht. Verschlüsselte Nachricht abfangen/ mithören ist nicht gleichzusetzen mit ursprünglicher Nachricht in Klartext abfangen/mithören/besitzen. > Nachricht c1[x] ^ c1[x + 77] = p1[x] ^ p1[x + 77]. Der/die Schlüssel > fällt/fallen raus Es wiederholt sich immer nach len(k1) * len(k2) nur - wer weiss wie lang k1 und wie lang k2 ist ?
:
Bearbeitet durch User
Marc V. schrieb: > Arc N. schrieb: >> Sieht anders aus, ja. Es wiederholt sich erst nach kgv(7,11) = 77... >> Ändert aber am Prinzip nichts: Sind zwei Nachrichten >> abgefangen/mitgehört ist c1[x] ^ c2[x] = p1[x] ^ p2[x] bzw. bei einer > > LOL. > Ganz so einfach ist es nicht. Verschlüsselte Nachricht abfangen/ > mithören ist nicht gleichzusetzen mit ursprünglicher Nachricht in > Klartext abfangen/mithören/besitzen. Oben sind ein paar Links zu Stackoverflow... Hier nur noch mal der mit dem schönen graphischen Beispiel und wie man bei verschlüsselten Texten weiter vorgehen würde https://crypto.stackexchange.com/questions/59/taking-advantage-of-one-time-pad-key-reuse >> Nachricht c1[x] ^ c1[x + 77] = p1[x] ^ p1[x + 77]. Der/die Schlüssel >> fällt/fallen raus > > Es wiederholt sich immer nach len(k1) * len(k2) nur - wer weiss wie > lang k1 und wie lang k2 ist ? Security by obscurity? Auch keine gute Idee. Es ist egal wie lang k1 oder k2 sind, ob |k1| und |k2| Primzahlen sind und damit die Periode bis sich das wiederholt verlängern. Es ändert nichts.
> Was spricht aus deiner Sicht gegen die bereits verbreiteten Verfahren
für verschlüsselte Mails? Also PGP und S/MIME?
PGP unterstützt OAEP und RSAPSS-SSA nicht... Aber selbstverständlich
lehnen wir uns an "Standards" ...
In meiner ersten Frage ging es ja auch nicht darum zu sagen wir wollen
was anderes machen <- andernfalls müssten wir Tunnel bauen und die
Datenübertragung tunneln (würde mir eh viel mehr gefallen).
und an alle anderen... ich finde es sehr spannend und lese aufmerksam
mit... ABER es geht natürlich um "Praktikabilität" und Interoperabilität
1. muss das System auch Kleinstunternehmen zutraubar sein. Sich jetzt
extra ein System für tausende € zu kaufen geht nicht.
2. muss es Marktalternativen geben, d.h. ich darf keine Software bereit
stellen oder diese Verkaufen wenn es nicht die selben Funktionalität
durch andere Anbieter gibt (Marktregulierung).
3. Natürlich wird ein asymmetrisches Verfahren mit privaten und
öffentlichen Schlüsseln angepeilt. Die Schlüssel haben eine
Maximalgültigkeit von 3 Jahren (gleichzeitig sollen die Schlüssel aber
auch nicht wesentlich kürzer geltend sein). Der Schlüsselaustausch
selbst ist meist "unsicher" z.B. über einer Homepage.
4. Es wird weder Root noch CA vorgeschrieben, dennoch können diverse CAs
nicht vertraut werden. Die CA muss das Zertifikat selbst mit einem
gewissen und gleichzeitig relativ sicheren Standard Signieren.
Ich weiß, dass viele "privat Personen" sich die Hände über den Kopf
zerschlagen weil das ganze viel einfacher, und besser geht, aber uns
sind die Hände gebunden...
Es geht hier hauptsächlich um die Standards welche OAEP, RSASSA-PSS,
sha256WithRSAEncryption, sha512WithRSAEncryption und Co.
das mit OTP klingt z.B. Spannend, aber 1. lässt sich das nicht so
einfach integrieren und 2. ist der Schlüsselaustausch eine echte
Herausforderung <- vermutlich mehr als der Austausch der Nachricht
selbst. Das funktioniert wenn 2 Großunternehmen genug Geld haben und
Ihre Daten schützen wollen,... Aber auf einem Markt mit zig
Marktpartnern funktioniert das leider nicht... <- aber ich durfte etwas
dabei lernen, daher finde ich diese Kommentare sogar sehr gut.
Anton, hier in Hannover bekämst Du eine kostenpflichtige Auskunft zu Deiner Frage von Ciphron. Ich arbeite nicht für diese Firma, habe deren Mitarbeiter aber kennengelernt.
Anton schrieb: > das mit OTP klingt z.B. Spannend, aber 1. lässt sich das nicht so > einfach integrieren Das stimmt nicht, im Gegenteil. > und 2. ist der Schlüsselaustausch eine echte > Herausforderung <- vermutlich mehr als der Austausch der Nachricht > selbst. Das funktioniert wenn 2 Großunternehmen genug Geld haben und > Ihre Daten schützen wollen,... Aber auf einem Markt mit zig > Marktpartnern funktioniert das leider nicht... Das stimmt aber 100% (leider). Obwohl, Zentrale <=> Marktpartnern ginge ohne Probleme - jeder Partner kriegt seinen eigenen Gesammtschlüssel (gk) von, sagen wir mal 2KB Länge sowie eine Codetabelle. Jede Nachricht wird Random verschlüsselt, Partner kriegt Nachricht mit z.B. COD1234 zugesendet. Bedeutet (Beispiel) Schlüssel 1 ist 103 Zeichen lang, beginnt um 7 Zeichen versetzt in gk, ergibt c1. Schlüssel 2 ist 71 Zeichen lang, beginnt um 19 Zeichen versetzt in gk, startet bei Zeichen 23 in c1. Wie gesagt, ich kenne mich nicht genügend aus, aber irgendwie habe ich das Gefühl, dass ohne Tabelle dieses Verfahren nicht zu knacken ist, lasse mich aber gerne eines Besseren belehren. Das Problem mit versenden und sicherem Aufbewahren der Codetabelle bleibt natürlich bestehen.
Arc N. schrieb: > Security by obscurity? Auch keine gute Idee. > Es ist egal wie lang k1 oder k2 sind, ob |k1| und |k2| Primzahlen sind > und damit die Periode bis sich das wiederholt verlängern. Es ändert > nichts. Es ändert doch, weil sich die Schlüssellänge, Schlüssel selbst und die Position jedesmal ändern (siehe obige Post) - es sind praktisch jedesmal ganz andere Schlüssel.
:
Bearbeitet durch User
Mathias schrieb: > Muss man? Ja, muss man. Denn das eine hat nichts mit dem anderen zu tun. Mathias schrieb: > Ich guck mir immer das Gesamtpaket an. Kannst du machen, dann hast du aber elementare Dinge nicht verstanden. Wie der Schluessel sicher von Alice zu Bob kommt, spielt bei der Betrachtung eines Kryptoverfahrens (OTP, DES, AES, Serpent, etc) keine Geige. Was du offenbar nicht verstehen willst: OTP ist beweisbar sicher. Alle anderen Algorithmen basieren auf der Annahme, das sie nach aktuellem Wissens- und Technikstand nicht knackbar sind. Das ist ein erheblicher Unterschied, der sich von heute auf morgen bei allen Algorithmen aendern kann, ausser bei OTP. Um die Unterschiede zwischen OTP und allem anderen noch deutlicher zu machen:
1 | Definition Informationstheoretische Sicherheit |
2 | |
3 | Ein Kryptoverfahren ist informationstheoretisch oder beweisbar sicher, |
4 | wenn es auch dann nicht gebrochen werden kann, wenn dem Angreifer |
5 | beliebige(!) Rechenleistung zur verfuegung steht. |
" beliebige Rechenleistung " ist hierbei der Knackpunkt. Nimm einen OTP-Schluessel mit 10.000 Bit. Auch mit 2^10.000 Rechnern (beliebige Rechenleistung) die parallel arbeiten (jeder Rechner braucht nur einen einzigen Schluessel probieren) kann dieses OTP nicht gebrochen werden. Das es schlicht unmoeglich ist solch eine Rechenkapazitaet zu bauen, ist dabei egal (Anzahl der Atome im Universum ca. 2^266). Die Betrachtung geht aber von beliebiger Rechenleistung aus. Alle anderen Kryptoverfahren beruhen aber auf berechenbarkeitstheoretischer Sicherheit:
1 | |
2 | Definition berechenbarkeitstheoretische Sicherheit |
3 | |
4 | Ein Kryptosystem ist berechenbarkeitstheoretisch sicher, wenn fuer |
5 | alle probabilistischen Polynominalzeitalgorithmen gilt, dass sie das |
6 | System nur mit einer vernachlaessigbar kleinen Wahrscheinlichkeit |
7 | brechen koennen. |
Diese Definition sagt, dass eine Chiffre berechenbarkeitstheoretisch sicher ist, wenn kein Algorithmus bekannt ist, der die Chiffre effizient brechen kann. Effizient bedeutet in diesem zusammenhang, dass kein Angriffsalgorithmus mit polynominaler Laufzeit existiert. Der Unterschied sollte jetzt klar sein: "auch mit beliebiger Rechneleistung nicht zu brechen" gegen "nur mit einer vernachlaessigbar kleinen Wahrscheinlichkeit zu brechen". Bei OTP muss der Schluessel nichtmal von Alice zu Bob uebertragen werden. Das Uebertragen des Startwertes fuer einen CSPRNG wuerde reichen. Dann muessen nur noch Alice und Bob den gleichen CSPRNG verwenden. Bei einer entsprechenden Datenmenge dauert aber das erzeugen des Schluessels... bei einigen uC bekommt man z.B. alle paar Takte nur 1 oder 2 Bit vom TRNG. OTP ist nicht praktikabel, ich hab aber auch nie etwas anderes behauptet. Deswegen wird OTP ja auch praktisch nicht verwendet. Mir ging es um die Aussage > Sicher geht nicht Doch, geht, bringt aber neue Probleme mit sich, wie man an OTP sieht. Mathias schrieb: > Ich stell mir gerade vor, Estland verteilt an ihre Bürger Ausweise mit > 16GB OTP Das verstoesst ja schon wieder gegen die Anforderungen an den OTP-Schluessel. Mathias schrieb: > weil alles andere ja nicht sicher ist... Du kannst noch so sehr mit den Faeusten auf den Boden trommeln und versuchen die Sache mit unsinnigen Beispielen ins laecherliche zu ziehen, das aendert nichts an der Tatsache, dass ausser OTP kein anderes (bekanntes) Verfahren beweisbar sicher ist. Anton schrieb: > aber ich durfte etwas > dabei lernen, daher finde ich diese Kommentare sogar sehr gut. Freut mich. :)
Noch was zum Thema "mehrfach verschluesseln": Hier muss man hoellisch aufpassen! Das beste Beispiel ist DES: DES hat eine Sicherheit von 2^56. Wendet man DES 2x an erhaelt man aber gerade mal eine Sicherheit von 2^57. Der dazu passende Angriff nennt sich "MitM - Meet in the Middle". Erst bei dreimaliger Anwendung von DES (Tripple DES) erhaelt man eine Sicherheit von 2^112. Solange sowas nicht untersucht wurde, und man keine Ahnung hat was man da macht, waere ich mit solchen Vorschlaegen sehr vorsichtig.
Daniel H. schrieb: > Kaj G. schrieb: >> Und um einen Schluessel sicher zu uebertragen gibt es den DHKE: >> https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%C3%BCsselaustausch > > Der aber wiederum, strikt nach Lehrbuch implementiert, anfällig für > Man-in-the-Middle-Angriffe ist, wodurch eine weitere > Autentifizierungsschicht benötigt wird. Ja. RSA ist ohne modifizierung aber auch angreifbar, wenn man es auf reinen Text anwendet. Deswegen wird es in der Regel in verbindung mit hybrider Verschluesslung eingesetzt. Ganz ohne irgendeine Modifizierung geht es an vielen Stellen eben nicht, egal ob beim DHKE, RSA oder anderen Verfahren.
:
Bearbeitet durch User
Kaj G. schrieb: > Mathias schrieb: >> Ich guck mir immer das Gesamtpaket an. > Kannst du machen, dann hast du aber elementare Dinge nicht verstanden. Ich weiß sehr wohl, das OTPs beweißbar sicher sind, aber wenn du nicht das Gesamtpaket betrachten willst, hast du aber elementare Dinge nicht verstanden. Kommst wohl gerade von der Uni oder? Hast du schon irgendwo mal OTPs ausgerollt? Klar gibt es Anwendungen, wo das Praktikabel ist, ich höre mir gerne deine Anwendungen an. und @Marc Vesely Bitte höre auf, dein Verfahren als sicher zu bezeichnen. Für einen Cryptolaien ist das Verfahren nicht schlecht und ich denke auch nicht von jedem Studenten mit 100kb verschlüsseltem Text zu knacken, aber das wars. Cryptologen lachen über sowas. Wer keinen wirklichen Anspruch an Verschlüsselung hat, der kann sowas einsetzen. Wenn es entfernt wichtig ist, dass etwas nicht unbefugt entschlüsselt werden kann, dann ist das absolut untauglich.
Marc V. schrieb: > Wie gesagt, ich kenne mich nicht genügend aus, aber irgendwie habe > ich das Gefühl, dass ohne Tabelle dieses Verfahren nicht zu knacken > ist, lasse mich aber gerne eines Besseren belehren. Jeder, absolut jeder Mensch auf dieser Welt kann sich ein Verschlüsselungsschema ausdenken, das er selbst nicht knacken kann.
Ex-Crypto-Mann schrieb: > absolut jeder Mensch auf dieser Welt kann sich ein > Verschlüsselungsschema ausdenken, das er selbst nicht knacken kann. Klar, je dümmer desto einfach. Georg
Mathias schrieb: > und @Marc Vesely > Bitte höre auf, dein Verfahren als sicher zu bezeichnen. Ex-Crypto-Mann schrieb: > Jeder, absolut jeder Mensch auf dieser Welt kann sich ein > Verschlüsselungsschema ausdenken, das er selbst nicht knacken kann. Das mag ich - einfach behaupten, etwas ist knackbar. Alles ist knackbar, nur ist nicht alles zu Lebzeiten knackbar. Marc V. schrieb: > Es ändert doch, weil sich die Schlüssellänge, Schlüssel selbst und > die Position jedesmal ändern (siehe obige Post) - es sind praktisch > jedesmal ganz andere Schlüssel. Und das ist ganz einfach nicht knackbar - und selbst wenn du eine Nachricht zufällig entschlüssellt hast, nützt dir das bei der nächsten überhaupt nichts - du fängst bei der nächsten wieder ganz von vorne an. Aber es ist leichter ganz einfach zu schreiben, dass etwas knackbar ist, als dies zu beweisen (oder zumindest versuchen diese Behauptung zu belegen). Und deswegen behaupte ich, dass schon Plaintext XOR-ed with Random Bytes nicht knackbar ist. Es kann nur durch ausprobieren geknackt werden. Mathias schrieb: > wars. Cryptologen lachen über sowas. Nein, Laien und möchtegern Cryptologen lachen über sowas.
:
Bearbeitet durch User
Marc V. schrieb: > Und deswegen behaupte ich, dass schon Plaintext XOR-ed with Random > Bytes nicht knackbar ist. Es kann nur durch ausprobieren geknackt > werden. Also erst behauptest du, dass es nicht knackbar ist, nur um im nächsten Satz zu sagen, dass es doch knackbar ist? Was denn jetzt? Insgesamt ist dein Verfahren nicht falsch, nur gibt es genau dafür moderne und beweisbar sichere Verfahren. Denn was in deinem Verfahren bisher komplett unter den Tisch fällt ist, wie Sender und Empfänger an die gleichen zufälligen Bytes für Ver- und Entschlüsselung kommen. Ein deutlich einfaches Verfahren dazu ist z.B. AES im CFB- oder CTR-Modus. Hier wird zunächst aus einem zufällig generierten Nonce (das im Klartext übertragen werden kann) und einem geheimen Schlüssel mittels AES ein kryptographisch sicherer, pseudozufälliger Byte-String erzeugt, der anschließend mit dem Plaintext XORed wird. Der Vorteil ist, dass man lediglich einmalig den geheimen Schlüssel sicher verteilen muss, und dann "beliebig" viele Nachrichten verschlüsseln kann, ohne jedesmal austauschen zu müssen, was denn nun der aktuelle Schlüssel ist. Auch hier aber wieder das Problem, wie man den Schlüssel sicher verteilen kann. Und da kommen wir wieder, zumindest bei großen, verteilten System mit möglicherweise tausenden Teilnehmern, bei der asymmetrischen Kryptographie vorbei, mit der man solche symmetrischen Schlüssel einfach austauschen kann ohne dass sie von anderen Teilnehmern beobachtet werden können. Und nochmal, der TO möchte explizit asymmetrische Kryptographie nutzen, da hilft ihm ein, wie auch immer geartetes, XOR mit Zufallswerten genau gar nicht.
Daniel H. schrieb: > Also erst behauptest du, dass es nicht knackbar ist, nur um im nächsten > Satz zu sagen, dass es doch knackbar ist? Was denn jetzt? Alles ist knackbar, fragt sich nur in welcher Zeit. Für dieses Verfahren gibt es kein Algorithmus, es muss ausprobiert werden, eins nach dem anderen und wenn der Schlüssel lang genug ist, ist es praktisch unknackbar. Eine Entschlüsselung nach 50 Jahren ist nutzlos. Daniel H. schrieb: > Insgesamt ist dein Verfahren nicht falsch, nur gibt es genau dafür > moderne und beweisbar sichere Verfahren. Denn was in deinem Verfahren > bisher komplett unter den Tisch fällt ist, wie Sender und Empfänger an > die gleichen zufälligen Bytes für Ver- und Entschlüsselung kommen. So: Marc V. schrieb: > Obwohl, Zentrale <=> Marktpartnern ginge ohne Probleme - jeder Partner > kriegt seinen eigenen Gesammtschlüssel (gk) von, sagen wir mal 2KB > Länge sowie eine Codetabelle. > Jede Nachricht wird Random verschlüsselt, Partner kriegt Nachricht mit > z.B. COD1234 zugesendet. > > Bedeutet (Beispiel) > Schlüssel 1 ist 103 Zeichen lang, beginnt um 7 Zeichen versetzt in gk, > ergibt c1. > Schlüssel 2 ist 71 Zeichen lang, beginnt um 19 Zeichen versetzt in gk, > startet bei Zeichen 23 in c1.
Und wenn die Zentrale erfolgreich angegriffen wird sind sämtliche (gk) aller Partner auf einmal kompromittiert. Das kann mit einem geeigneten, auf asymmetrischen Algorithmen basierenden Protokoll nicht passieren, da wäre dann "nur" der private Schlüssel der Zentrale kompromittiert. Den zu tauschen wäre deutlich leichter, als alle (gk) auszutauschen. Üblicherweise nimmt man heute Verfahren zur Schlüsselvereinbarung/-austausche, welche über asymmetrische Verfahren abgesichert werden. Diese sind gut erforscht, bei korrekter Anwendung sicher und in der Praxis gut anzuwenden. Allein aus Haftungsgründen würde ich im kommerziellen Umfeld niemals ein selbstgestrickten Verfahren einsetzen.
Meine Daumenregel: Ohne wirklich fundierte Kenntnisse sind eigene realistisch nutzbare Verfahren allenfalls so lange als sicher zu betrachten, wie sich kein Schwein wirklich ernsthaft dafür interessiert, was transportiert wird. Was für viele Anwendungen ein nicht ganz unrealistisches Szenario sein könnte.
:
Bearbeitet durch User
> Und deswegen behaupte ich, dass schon Plaintext XOR-ed with Random > Bytes nicht knackbar ist. Das stimmt nur, wenn deine "random Bytes" auch wirklich zufällig sind. Sonst kannst du die Verschlüsselung über den RNG angreifen.
MaWin schrieb: >> Und deswegen behaupte ich, dass schon Plaintext XOR-ed with Random >> Bytes nicht knackbar ist. > > Das stimmt nur, wenn deine "random Bytes" auch wirklich zufällig sind. > Sonst kannst du die Verschlüsselung über den RNG angreifen. Mikrofon in der Innenstadt oder im Einkaufszentrum, ADC Werte nehmen.
Marc V. schrieb: > Mikrofon in der Innenstadt oder im Einkaufszentrum, ADC Werte nehmen. Sicher, dass das reicht? Die Geräusche der Motoren von Ventilation, Aufzügen, Rolltreppen sind nicht sonderlich zufällig.
Marc V. schrieb: > Mikrofon in der Innenstadt oder im Einkaufszentrum, ADC Werte nehmen. Ich glaube du unterschätzt enorm, wie schwer es ist richtigen Zufall zu generieren und auch aufzunehmen. Wenn nur wenige Bits deines RNG-Stroms mit einer geringen Wahrscheinlichkeit vorhersagbar sind, dann ist dein OTP angreifbar.
Marc V. schrieb: > Daniel H. schrieb: >> Also erst behauptest du, dass es nicht knackbar ist, nur um im nächsten >> Satz zu sagen, dass es doch knackbar ist? Was denn jetzt? > > Alles ist knackbar, fragt sich nur in welcher Zeit. Nein, es ist nicht alles knackbar. Wenn du alle Möglichkeiten durchprobierst (z.B. beim OneTime-Pad), dann hast du zwar unter den Millionen Lösungen auch irgendwo die richtige dabei, aber du hast auch eben noch die Millionen anderer Lösungen, die genauso möglich wären.
jz23 schrieb: > Millionen Lösungen auch irgendwo die richtige dabei, aber du hast auch > eben noch die Millionen anderer Lösungen, die genauso möglich wären. Vorsichtige Leute bauen deshalb in ihre Rohdaten CRCs oder andere Signaturen ein. Das macht die Erkennung deutlich einfacher. ;-)
MaWin schrieb: > Ich glaube du unterschätzt enorm, wie schwer es ist richtigen Zufall zu > generieren und auch aufzunehmen. Ach was. Alle Kryptographen und Mathematiker dieser Welt sind einfach nur zu dumm oder zu faul... [/ironie]
MaWin schrieb: > Wenn nur wenige Bits deines RNG-Stroms mit einer geringen > Wahrscheinlichkeit vorhersagbar sind, dann ist dein OTP angreifbar. Angreifbar ist alles - ist aber nicht gleichzusetzen mit knackbar. > Ich glaube du unterschätzt enorm, wie schwer es ist richtigen Zufall zu > generieren und auch aufzunehmen. Und ich glaube du überschätzt enorm die Angriffsmöglichkeiten. Es muss gewisse Regelmässigkeiten geben und diese müssen sich auch in festen Intervalen wiederholen. Strassenverkehr in der Innenstadt ist mit Sicherheit absolut zufällig, zumindest für eine gewisse Zeit, die wiederum mehr als ausreichend ist.
A. K. schrieb: > jz23 schrieb: >> Millionen Lösungen auch irgendwo die richtige dabei, aber du hast auch >> eben noch die Millionen anderer Lösungen, die genauso möglich wären. > > Vorsichtige Leute bauen deshalb in ihre Rohdaten CRCs oder andere > Signaturen ein. Das macht die Erkennung deutlich einfacher. ;-) Ja, nur bekommst du zu jeder beliebigen Nachricht mit falschem CRC als Lösung auch die Nachricht mit richtigem CRC. Es grenzt die möglichen Lösungen ein, aber unter denen hast du keine Möglichkeit, die richtige rauszufinden.
A. K. schrieb: > Sicher, dass das reicht? Die Geräusche der Motoren von Ventilation, > Aufzügen, Rolltreppen sind nicht sonderlich zufällig. Stimmt, aber diese sind auch nicht sonderlich laut und werden von anderen (zufälligen) Geräuschen überlagert. Und einzig Ventilation kann als einigermassen regelmässig bezeichnet werden - Aufzug is es bestimmt nicht und Rolltreppe dürfte je nach Belastung verschiedene Geräusche produzieren. Aber wie gesagt, das sind relativ leise Geräusche und werden Samstags um 12 Uhr kaum wahrzunehmen sein - diese können vielleicht raus- gefiltert werden, aber das nützt kaum bei der Entschlüsselung.
jz23 schrieb: > Nein, es ist nicht alles knackbar. Doch, alles ist knackbar, nur ist eine Entschlüsselung nach 2000 Jahren sinnlos.
Marc V. schrieb: > Stimmt, aber diese sind auch nicht sonderlich laut und werden von > anderen (zufälligen) Geräuschen überlagert. Weshalb eine gängige Strategie, vorsichtshalber nur die unteren Bits zu verwenden, damit man nicht sofort raushört, ob das Einkaufszentrum in Dresden oder Stuttgart steht, genau jene überlagerten Geräusche enthält, die du selbst nicht wahrnimmst. Das macht es nicht gleich deterministisch, aber auch nicht rein zufällig.
:
Bearbeitet durch User
Marc V. schrieb: > Doch, alles ist knackbar, nur ist eine Entschlüsselung nach > 2000 Jahren sinnlos. Hast du meinen Beitrag gelesen? Offensichtlich nicht, aber ich wiederhole es gerne noch einmal: Du hast eine riesige Anzahl an Lösungen, die bei der Entschlüsselung eine OTP auftauchen, die sind alle sinnvoll. Und trotzdem ist nur eine dieser Lösungen richtig - es ist unmöglich zu sagen, welche, außer du bist im Besitz des OTP. Und deswegen ist das eben unknackbar.
Marc V. schrieb: > Es muss gewisse Regelmässigkeiten geben Und eben diese sind vorhanden, wenn du makroskopische Ereignisse aufnimmst. > und diese müssen sich auch in festen Intervalen wiederholen. Nein. Es muss nur mit einer geringen Wahrscheinlichkeit teilweise vorhersagbar sein. > Strassenverkehr in der Innenstadt ist mit Sicherheit absolut zufällig, Worauf stützt du diese Aussage?
MaWin schrieb: >> Strassenverkehr in der Innenstadt ist mit Sicherheit absolut zufällig, > > Worauf stützt du diese Aussage? Ich halte es für Sarkasmus!
Marc H. schrieb: > MaWin schrieb: >>> Strassenverkehr in der Innenstadt ist mit Sicherheit absolut zufällig, >> >> Worauf stützt du diese Aussage? > > Ich halte es für Sarkasmus! Warum ? Welche Regelmässigkeiten gibt es in einem 10 sec. Zeitraum von, z.B. 7:44:28 bis 7:44:38, für sich alleine betrachtet ? P.S. Selbst mit 8bit und 20KHz ergibt das fast 200KByt.
:
Bearbeitet durch User
Marc V. schrieb: > Welche Regelmässigkeiten gibt es in einem 10 sec. Zeitraum von, > z.B. 7:44:28 bis 7:44:38, für sich alleine betrachtet ? Motorengeräusche sind von sich aus schon sehr regelmäßig. Sonst würde der Motor nicht laufen. Der Verkehr wird von Ampeln geregelt, die hoffentlich äußerst regelmäßig funktionieren. Sprach- und Tiergeräusche sind äußerst regelmäßig, sonst würden sie zur Kommunikation nicht taugen. Und hier willst du beweisbaren Zufall erzeugen? Jede auch noch so geringe Regelmäßigkeit kann im Ciphertext sichtbar sein und damit ist dein Verfahren schon praktisch als gebrochen anzusehen.
Angehängte Dateien:
-
zufall.png
42 KB
Auch die oft getätigte Aussage, dass Regelmäßigkeiten verschwinden, indem man Zufall addiert, ist natürlich falsch. Unterschiedliche Schallwellen addieren sich auf (grob gesagt). Wenn da eine Regelmäßigkeit dabei ist, nutzt es kaum, wenn auch noch 100 zufällige Schallquellen vorhanden sind. Das kann jeder selbst durch nachdenken oder in seiner Tabellenkalkulation herausfinden.
MaWin schrieb: > Motorengeräusche sind von sich aus schon sehr regelmäßig. Sonst würde > der Motor nicht laufen. > Der Verkehr wird von Ampeln geregelt, die hoffentlich äußerst regelmäßig > funktionieren. > Sprach- und Tiergeräusche sind äußerst regelmäßig, sonst würden sie zur > Kommunikation nicht taugen. > > Und hier willst du beweisbaren Zufall erzeugen? Ja.
Marc V. schrieb: >> Und hier willst du beweisbaren Zufall erzeugen? > > Ja. Dann bin ich ja mal gespannt.
MaWin schrieb: > Und hier willst du beweisbaren Zufall erzeugen? Kann man das überhaupt beweisen? Oder gibts hier nur Negativbeweise - es gibt Verfahren dafür - und was die allesamt überlebt gilt vorläufig als zufällig?
:
Bearbeitet durch User
A. K. schrieb: >> Und hier willst du beweisbaren Zufall erzeugen? > > Kann man das überhaupt beweisen? Ok, das war etwas schlecht ausgedrückt. Ich wollte sagen: Und hier willst du Zufall erzeugen, den man nicht mit gängigen Verfahren als nicht-zufällig entlarven kann? Einen Crypto-Hash wie SHA drüberlegen zählt übrigens nicht, denn dann ist es keine OTP-Verschlüsselung mehr, sondern ein ganz "normaler" Verschlüsselungsalgorithmus.
Ich finde das Thema sehr spannend und habe auch schon Einiges gelernt. Ohne jetzt auf Details einzugehen, aber diese Frage: MaWin schrieb: > Das kann jeder selbst durch nachdenken oder in seiner > Tabellenkalkulation herausfinden. Was willst Du damit zeigen? Dass der Zufall sich nicht zu Null addiert erfordert eine Integration der Zufallswerte. Was macht dabei der Sinus? Und: Sind die Zufallszwerte in Excel wirklich gute Zufallswerte?
MaWin schrieb: > Auch die oft getätigte Aussage, dass Regelmäßigkeiten verschwinden, > indem man Zufall addiert, ist natürlich falsch. Die Addition vieler nicht zufälliger Geräusche erzeugt etwas, das subjektiv zufällig wirken kann. Beispielsweise die Schritte von Menschen. Die Schrittfrequenz variiert etwas zwischen den Individuen. Beim Individuum selbst variiert sie hauptsächlich in Abhängigkeit von der Umwelt, ist sonst aber ziemlich regelmässig. Die Summe vieler Schritte mag dann sehr chaotisch klingen, ist aber als Quelle von Zufall völlig ungeeignet.
Hi-Tech-Progger S. schrieb: > Was willst Du damit zeigen? Das Regelmäßigkeiten nicht durch Addition von echtem Zufall verschwinden. Selbst wenn der Mensch dann die Regelmäßigkeit nicht mehr unmittelbar erkennen kann, z.B. durch seine Ohren. Das ist in vielen Bereichen relevant. Wie z.B. hier bei der Addition von Schallwellen. Oder z.B. bei TCP-Paketen im TOR-Netzwerk. Dort kann man auch die Anonymität nicht erhöhen, wenn man die Pakete zufällig verzögert. >Und: Sind die Zufallszwerte in Excel wirklich gute Zufallswerte? Das spielt zur Demonstration kaum eine Rolle.
A. K. schrieb: > Die Summe vieler Schritte mag dann sehr chaotisch klingen, Gemeint ist hier die Summe der Schritte vieler Menschen.
Trotzdem verstehe Ich nicht, was der Sinus da soll. Umgekehrt wäre es aussagefähiger: Zufall addieren und eine Kurve rausbekommen. Das ist es nämlich was passiert.
Hi-Tech-Progger S. schrieb: > Umgekehrt wäre es aussagefähiger: Zufall addieren und eine Kurve > rausbekommen. Der umgekehrte Fall ist interessanter: Eine beliebig kompliziert aussehende Kurve haben, und feststellen, ob es sich dabei um Zufall handelt.
Angehängte Dateien:
-
zufall2.png
160 KB
Hi-Tech-Progger S. schrieb: > Trotzdem verstehe Ich nicht, was der Sinus da soll. Der Sinus ist ein Beispiel für eine regelmäßige Quelle. >Umgekehrt wäre es aussagefähiger: Zufall addieren und eine Kurve rausbekommen. > Das ist es nämlich was passiert. Nein. Wie soll das gehen?
Hi-Tech-Progger S. schrieb: > Trotzdem verstehe Ich nicht, was der Sinus da soll. Auch wenn man auf den (regelmäßigen) Sinus zufällige Werte addiert, bleibt der regelmäßige Sinus im Ergebnis nachweisbar (wenn auch nicht direkt erkennbar).
Bei Zufallszahlen ist auch Vorsicht geboten. Beispiel: Ein CSPRNG liefert 16 bit Zufallszahlen. Braucht man aber eine 32 bit Zufallszahl, und verbindet einfach 2 16 bit Zahlen (x = (z[0] << 16) | z[1]) so ist es mit der kryptographischen Sicherheit und auch mit dem Zufall ganz schnell vorbei. Das aber nur als kleine Randnotiz.
Kaj G. schrieb: > Braucht man aber eine 32 bit Zufallszahl, und verbindet einfach 2 16 bit > Zahlen (x = (z[0] << 16) | z[1]) so ist es mit der kryptographischen > Sicherheit und auch mit dem Zufall ganz schnell vorbei. Das hört sich interessant an. Könntest du genauer erklären, warum das so ist?
Erzähl mehr! Wenn dem so wäre, dann müßtest du den CSPRNG ja von einer Zufallsfolge unterscheiden können, und dann wäre es kein ernstzunehmender CSPRNG.
Dussel schrieb: > Hi-Tech-Progger S. schrieb: >> Trotzdem verstehe Ich nicht, was der Sinus da soll. > Auch wenn man auf den (regelmäßigen) Sinus zufällige Werte addiert, > bleibt der regelmäßige Sinus im Ergebnis nachweisbar (wenn auch nicht > direkt erkennbar). Das ist unbestritten, erklärt aber nicht die Grundaussage, dass Zufallszahlen sich über die Zeit nicht zu völligem Zufall addieren. Das war ja die Aussage. Im Gegenteil: Man muss ja annehmen, dass es weitgehend klappt, sonst könnte man den Nichtzufall, den Sinus ja nicht daraus extrahieren.
Hi-Tech-Progger S. schrieb: > dass > Zufallszahlen sich über die Zeit nicht zu völligem Zufall addieren. Das > war ja die Aussage. Nein, das war nicht die Aussage.
MaWin schrieb: > Marc V. schrieb: >>> Und hier willst du beweisbaren Zufall erzeugen? >> >> Ja. > > Dann bin ich ja mal gespannt. Ich verstehe deine Einwände nicht, es ist für mich ganz einfach Sturheit. Es wird nicht im Studio aufgenommen, wo nur ein Motor 75 cm entfernt links von Mikrofon läuft, ein Moped 2,5m rechts, ein Vogel zwitschert 20cm entfernt und alles bleibt schön statisch, regelmässig und mit gleicher Lautstärke. Und selbst wenn - ob es Regelmässigkeiten gibt oder nicht, ist vorerst uninteressant, beim Entschlüsseln weisst du das ganz einfach nicht. Und ob etwas mit Werten von 0 bis 255 verschlüsselt wird oder nur mit Werten von 121 bis 225 ist vorerst auch uninteressant - man muss alle Werte durchgehen. Erst wenn (falls überhaupt) durch Ausprobieren etwas sinnvolles rauskommt, kann man versuchen, gewisse Regelmässigkeiten rauszufinden. Es genügt aber nur, dass jemand kurz hupt und schon ist deine Regel- mässigkeit hinüber. Auspuff knallt, jemand pfeift einem Mädchen hinterher, ein Extremist jagt sich in die Luft - es mag für sich alleine regelmässig sein aber es wird durch einen anderen (regelmässigen oder nicht) Geräusch zu einem unbekannten und nicht vorhersehbaren Zeitpunkt unterbrochen. Und schon ist deine Regelmässigkeit hinüber. Und selbst dein Beispiel mit Sinus + Zufall steht nicht - es sind immer noch zufällige Werte - multipliziere die Werte mit 100 und dann siehst du das auch. Und mehr als einen Trend erkennen kann man in deinem Beispiel nicht. Einen Trend erkennen hat aber mit entschlüsseln genau nichts zu tun. Selbst die aufeinanderfolgenden Werte schwanken teilweise um mehr als 50% - das hat nicht einmal R von Regelmässigkeit.
MaWin diskutiert an einem völlig anderen Ende der Wurst, wie mir scheint.
Marc V. schrieb: > ob es Regelmässigkeiten gibt > oder nicht, ist vorerst uninteressant, beim Entschlüsseln weisst du > das ganz einfach nicht. Wenn du mit OTP encryption ein leeres Signal überträgst, dann liegt der RNG blank vor und kann auf Schwächen analysiert werden. Generell ist OTP mit schwachem Zufallsgenerator empfindlich für known plaintext attacks.
Angehängte Dateien:
-
zufall3.png
100 KB
Marc V. schrieb: > Ich verstehe deine Einwände nicht, es ist für mich ganz einfach Sturheit. Nur weil du etwas nicht verstehst, musst du nicht gleich beleidigen. > beim Entschlüsseln weisst du das ganz einfach nicht. Doch. Regelmäßigkeiten im Ciphertext lassen sich mit statistischen Methoden recht einfach erkennen. Solche Regelmäßigkeiten können nur von Regelmäßigkeiten im RNG kommen. > Und ob etwas mit Werten von 0 bis 255 verschlüsselt wird oder nur mit Werten von 121 bis 225 ist vorerst auch uninteressant Nein das ist sehr wohl sehr sehr sehr interessant. Ein derartiger Fehler führt zum sofortigen Zusammenbruch der Verschlüsselung. Mit statistischen Methoden lässt sich aus dem Ciphertext der Klartext rekonstruieren, wenn der Schlüsselstrom nicht regelmäßig ist. Als beispiel sei RC4 und WEP genannt. > Es genügt aber nur, dass jemand kurz hupt und schon ist deine Regelmässigkeit hinüber. Nein eben nicht. Genau das habe ich oben versucht zu erklären. > Und selbst dein Beispiel mit Sinus + Zufall steht nicht - es sind immer noch zufällige Werte Nein. Der Sinus ist ganz klar für jeden nach der Addition noch erkennbar. > multipliziere die Werte mit 100 und dann siehst du das auch. Warum sollte sich durch eine Skalierung etwas ändern? > Einen Trend erkennen hat aber mit entschlüsseln genau nichts zu tun. Doch hat es. Ein guter Ciphertext ist von Zufall nicht unterscheidbar. Wenn der Ciphertext eine Regelmäßigkeit aufweist, dann kann man auf Schwächen im RNG und damit auf den Klartext schließen. > Selbst die aufeinanderfolgenden Werte schwanken teilweise um mehr als 50% - das hat nicht einmal R von Regelmässigkeit. Dann filtern wir es doch mal mit einem simplen gleitenden Mittelwert und verschieben es um einen konstanten Wert auf der Y-Achse. Plötzlich ist der "Zufall" kaum mehr von einem Sinus zu unterscheiden. Und damit fütterst du dein OTP.
Martin, es ging Anton um dies hier: #5179083: > Hier geht es um die Bewertung von Verschlüsselungs und Signatur > Algorithmen, insbesondere um sha256WithRSAEncryption und RSASSA-PSS D.h. du müsstest Deinen Sinus so verschlüsseln, dass er nicht mehr erkennbar ist, aber wieder zu rekonstruieren. Mit nur "Rauschen drauf" braucht man nur ein RC-Glied, um den Sinus zu sehen.
MaWin schrieb: > wenn der Schlüsselstrom nicht regelmäßig ist. wenn der Schlüsselstrom nicht zufällig ist. natürlich :)
MaWin schrieb: > MaWin schrieb: >> wenn der Schlüsselstrom nicht regelmäßig ist. > > wenn der Schlüsselstrom nicht zufällig ist. Um das jetzt zu einem Abschluss zu bringen vielleicht mal Folgendes: Wir hatten in meiner Ex-Firma vor einigen Jahren ein Projekt im Umfeld der Verschlüsselung des Bundeswehrfunks im Feld. D.h. es geht um den Digitalfunk - im Großen und Ganzen handelt es sich um ähnliche Themen, wie bei dem Polizeifunk. Zur Anwendung kamen Algorithmen, die von Mitarbeitern einer ehemaligen Stelle der Stasi in der DDR (kein Witz!) entwickelt wurden und die heute in einer westdeutschen Firma eingegliedert ist - angeblich, um sie nach der Wende davon abzuhalten, zu den Russen zu wechseln. Diese Stelle sitzt heute in Berlin (oder sie saß damals in Berlin) und produziert mit Mathematikern und Physikern spezielle Codierverfahren und Schlüssel, um sie in Rechnersysteme übernehmen zu können. Diese Verfahren bestehen aus Algorithmen zur Chiffrierung und Dechiffrierung sowie eben den Schlüsseln, die getauscht werden können und flossen in die Funkgeräteentwicklung und auch die Flugleitentwicklung, wenn es um das Bestimmen von Aufenthaltsorten von Flugkörpern geht, oder wenn ihnen per SDR Daten zugesendet werden sollen. Diese Informationen werden so verschlüsselt, dass es praktisch ein Rauschsignal ist, welches so homogen und unauffällig ist, dass man es im normalen Rauschen verstecken kann. Das "normale" Rauschen ist an der Stelle aber ein bekanntes Rauschen, d.h. wenn man es empfängt, kann man es erkennen, einrasten und abziehen. Übrig bleibt dann das Zufallsrauschen aus der Atmospähre und der Elektronik sowie der scheinbar rauschende Code. Den muss man dann eben nochmal durch die Algorithmen jagen. Dies soweit.
Hi-Tech-Progger S. schrieb: > Diese Informationen werden so verschlüsselt, dass es praktisch ein > Rauschsignal ist, Das ist bei jeder beliebigen sicheren Verschlüsselung der Fall.
MaWin schrieb: >> Rauschsignal ist, > > Das ist bei jeder beliebigen sicheren Verschlüsselung der Fall. Sein Beitrag riecht danach, als ob sowohl Verschlüsselung als auch Funkmodulation gemeint sind. Es also auch darum geht, das HF-Signal selbst zu verstecken, nicht nur den Inhalt.
:
Bearbeitet durch User
MaWin schrieb: > Marc V. schrieb: >> Ich verstehe deine Einwände nicht, es ist für mich ganz einfach Sturheit. > > Nur weil du etwas nicht verstehst, musst du nicht gleich beleidigen. Ich habe dich nicht beleidigt oder zumindest nicht mit Absicht. Aber Floskel wie diese: MaWin schrieb: > Ein derartiger Fehler führt zum sofortigen Zusammenbruch der > Verschlüsselung. > Mit statistischen Methoden lässt sich aus dem Ciphertext der Klartext > rekonstruieren, wenn der Schlüsselstrom nicht regelmäßig ist. MaWin schrieb: > Regelmäßigkeiten im Ciphertext lassen sich mit statistischen Methoden > recht einfach erkennen. Solche Regelmäßigkeiten können nur von > Regelmäßigkeiten im RNG kommen. MaWin schrieb: > > Dann filtern wir es doch mal mit einem simplen gleitenden Mittelwert und > verschieben es um einen konstanten Wert auf der Y-Achse. > Plötzlich ist der "Zufall" kaum mehr von einem Sinus zu unterscheiden. > Und damit fütterst du dein OTP. Was, womit und warum soll ich irgendetwas füttern ? Mit Sinus bestimmt nicht. Das sind abgeschriebene Floskeln und haben mit der Realität nichts zu tun. Und diese ganze Schreiberei über statistische Methoden, filtern und verschieben ist ganz einfach Blödsinn. Und Regelmässigkeiten in Ciphertext kannst du erst nach Entschlüsseln erkennen. P.S. Irgendwie habe ich das Gefühl, dass du dieses Verfahren ganz einfach nicht verstanden hast. Das einzige Problem bei dieser Methode ist das Versenden und sicheres Aufbewahren der Gesammtschlüssel und der Codetabelle. Knackbar ist es nicht, das steht mit Sicherheit fest.
:
Bearbeitet durch User
Marc V. schrieb: > Das sind abgeschriebene Floskeln und haben mit der Realität nichts > zu tun. Ich habe mit RC4/WEP sogar Beispiele genannt. > Und diese ganze Schreiberei über statistische Methoden, filtern und > verschieben ist ganz einfach Blödsinn. Nicht alles, was man nicht versteht, ist Blödsinn. > Und Regelmässigkeiten in Ciphertext kannst du erst nach Entschlüsseln > erkennen. Du trollst doch.
Marc V. schrieb: > Das einzige Problem bei dieser Methode ist das Versenden und sicheres > Aufbewahren der Gesammtschlüssel und der Codetabelle. > Knackbar ist es nicht, das steht mit Sicherheit fest. Das trifft nur zu, wenn dein Schlüssel 100% und ausnahmslos zufällig ist. Und das trifft auf deine Innenstadtaufnahmen ganz einfach nicht zu. Sobald dein Schlüssel auch nur die geringsten Regelmäßigkeiten hat, wird dein Verfahren angreifbar. Aber was rede ich; das habe ich schon mehrfach geschrieben.
MaWin schrieb: > Sobald dein Schlüssel auch nur die geringsten Regelmäßigkeiten hat, wird > dein Verfahren angreifbar. Ja, fragt sich nur wie du die Regelmässigkeiten erkennen willst. Und wie gesagt, angreifen und entschlüsseln ist nicht dasselbe. Und wie gesagt, eine Entschlüsselung nach 2000 Jahren ist nutzlos.
Marc V. schrieb: > Ja, fragt sich nur wie du die Regelmässigkeiten erkennen willst. Es gibt viele Verfahren, um Zahlenfolgen von Zufallszahlenfolgen zu unterscheiden. z.B. https://en.wikipedia.org/wiki/Diehard_tests > Und wie gesagt, angreifen und entschlüsseln ist nicht dasselbe. Das ist richtig. Ein nicht 100%ig funktionierender RNG ist aber gerade für OTP eine enorme Lücke. Siehe z.B. Plaintext-Angriff. Gegen diesen bietet OTP keinerlei Schutz. Deshalb wird aus einem Angriff gerade hier sehr schnell eine praktisch nutzbare Entschlüsselung. > Und wie gesagt, eine Entschlüsselung nach 2000 Jahren ist nutzlos. Es ist heute ohne weiteres für kleines Geld möglich, die Leistung von vielen tausend Bürorechnern per Click zu mieten. (z.B. Amazon). Da werden aus deinen 2000 Jahren ganz schnell 2000 Sekunden.
Kaj G. schrieb: > Bei Zufallszahlen ist auch Vorsicht geboten. > > Beispiel: > Ein CSPRNG liefert 16 bit Zufallszahlen. > Braucht man aber eine 32 bit Zufallszahl, und verbindet einfach 2 16 bit > Zahlen (x = (z[0] << 16) | z[1]) so ist es mit der kryptographischen > Sicherheit und auch mit dem Zufall ganz schnell vorbei. > > Das aber nur als kleine Randnotiz. Asche auf mein Haupt, da hab ich mist erzaehlt. :( Wie bin ich auf den Mist gekommen: Ein ehemaliger Kollege, der mal bei Rohde & Schwarz SIT gearbeitet hat, hatte mir mal erzaehlt, dass dem so waere. Ist aber auch schon wieder ein paar Jahre her. Moeglicherweise hab ich da was durcheinander gebracht. Ich hab jetzt aber mal Prof. Paar von der RUB gefragt, mit dem Beispiel von 2 4bit Zahlen. Seine Antwort:
1 | Wenn jedes Nibble (4 Bit) echt zufällig ist, dh. gleichverteilt aus |
2 | der Menge 0...15 gezogen wird, ist das Gesamt-Byte auch gleichverteilt |
3 | im Bereich 0...255. Man muss die Wahrscheinlichkeiten hier |
4 | Multiplizieren: Um eine bestimmte (beliebige) 8Bitzahl zu bekommen, hat |
5 | man eine Wahrscheinlichkeit von 1/16 für das MSB Nibble und noch einmal |
6 | 1/16 für das LSB Nibble, d.h. die Gesamtwahrscheinleichkeit für eine |
7 | beliebige 8Bitzahl ist 1/16 x 1/16 = 1/256. |
Nochmal sorry fuer diesen Muell. :'(
Kaj G. schrieb: > Ein ehemaliger Kollege, der mal bei Rohde & Schwarz SIT gearbeitet hat, > hatte mir mal erzaehlt, dass dem so waere. Kann es sein, dass Dein Kollege von SIT genau so denkt und er deshalb dort nicht mehr arbeitet? Der Abteilungsleiter dort, Herr Bat.....lag, ist ja dafür bekannt, daß er "hohe Anforderungen" hat. Zumindest kommuniziert er das so.
Schreiber schrieb: > Der Abteilungsleiter dort, Herr Bat.....lag, ist ja dafür bekannt, daß > er "hohe Anforderungen" hat. Zumindest kommuniziert er das so. Der von Dir mutmaßlich genannte Mitarbeiter war kein Mitarbeiter der R&S SIT, sondern des R&S Stammunternehmens, allerdings an demselben Standort in Stuttgart Weilimdorf.
Marc V. schrieb: > Ja, fragt sich nur wie du die Regelmässigkeiten erkennen willst. Eine FFT wäre eine Möglichkeit.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.