Man verwendet beide: Asymmetrische und symmetrische.

Asymmetrische sind ziemlich sicher, aber im Vergleich schnarchlahm. Symmetrische sind flott, aber haben eben nur einen Schlüssel zum de- und enkodieren. Also generiert man eine Zufällige Zeichenfolge, benutzt ein symmetrisches Verfahren zur Verschlüsselung, und verschlüsselt den Schlüssel dann mit RSA. das Zeug kann man dann bedenkenlos verschicken, weil nur der richtige Empfänger (dank RSA) den Schlüssel wieder entschlüsseln kann. Hat er das getan, benutzt er den Schlüssel um die Nachricht zu entschlüsseln.

Anwender hat folgendes geschrieben :

[...]RSA? sowas lahmes. Du weißt schon, [...]

Martok hat folgendes geschrieben :

Frag mal user profile iconBenBE, wie lange es dauert

jfheins hat folgendes geschrieben :

... Asymmetrische sind ziemlich sicher, aber im Vergleich schnarchlahm. Symmetrische sind flott, ...

ist mir oben noch im Munde verdreht worden ...


krieg ich als Entschuldigung bitte auch ein DANKE, Matrok?


sicher sind OTPs sicher. Das bewiesen sicherste Verfahren.
Nur die hinreichenden Bedingungen dafür zu schaffen ...

Anwender hat folgendes geschrieben :

krieg ich als Entschuldigung bitte auch ein DANKE, Matrok?

Du sagst, RSA ist langsam. Ich sage, stimmt, BenBE kann das beweisen. jfheins sagt, es ist schnarchlangsam.
Wer muss sich wofür entschuldigen? Ich versteh grad nicht, worauf du hinaus willst

Anwender hat folgendes geschrieben :

sicher sind OTPs sicher. Das bewiesen sicherste Verfahren. Nur die hinreichenden Bedingungen dafür zu schaffen ...

Womit wir das Problem auf einen guten PRNG und IV-Ableitung für selbigen reduziert haben (ja man merkt dass ich in letzter Zeit ein paar Dinge zu Salsa gelesen hab...). Ist doch was

Martok hat folgendes geschrieben :

Anwender hat folgendes geschrieben : hhuuuhh ... fast 100 Punkte. Also wirklich, 6KDVB erkennt man doch. Das ist doch fast so bekannt wie FCKW damals war

Der hieß FCKGW ...

Martok hat folgendes geschrieben :

Anwender hat folgendes geschrieben : RSA? sowas lahmes. Du weißt schon, daß man dazu noch nen zweiten Schlüssel braucht? und je nach Schlüssellänge (unter mittlerweile 2048 Bit ist fast alles unsicher !!!) unsicherer als symmetrische Verschlüsselung mit gleicher Schlüssellänge. Frag mal BenBE, wie lange es dauert, eine 8k GPG-Key zu generieren Es hat schon einen Grund, dass man im Allgemeinen RSA zum Schlüsselaustausch verwendet und die eigentliche Arbeit dann von einem symmetrischen Verfahren (Blowfish, 3DES, AES, ...) machen lässt.

Der 8192er ist in wenigen Sekunden erstellt (Das geht mit passendem Entropie-Daemon mal nebenbei. Was gedauert hat, waren die beiden 31337er Schlüssel (einmal RSA und einmal DSA). Musste nur vorher ein wenig die Software patchen, weil die da irgendwelche Limits hatten.

Martok hat folgendes geschrieben :

Wobei natürlich die Meisten Verfahren in irgend einer Form vom Protokoll (SSL-Handshake, ...) angesagt werden - die Gegenstelle muss ja wissen, was da jetzt kommt. Das macht Angriffe auf schwache Verfahren natürlich einfach - und genau deswegen sollte man da die Finger von lassen und lieber Zeug nehmen, was aus bestimmten beweisbaren Gründen schwierig zu knacken ist.

Irgendwie müssen sich die beiden Kommunikationspartner ja einigen können. Außerdem darf das Verfahren ja durchaus offen angesagt werden, da davon die Sicherheit ja nicht abhängt.

IhopeonlyReader hat folgendes geschrieben :

das gilt vorallem für Xor! Denn 2x Xor ist wiederum 0xXor und somit komplett unentlschüsselt. Wenn der Endbenutzer nicht weiß, was "orginale" Buchstaben sind und was nicht, wie bei Doppel-Caesar mit verschiedenen Schlüsselwörtern oder sonst was, dann ist es meiner Meinung nach vollkommen egal, ob einige Buchstaben "orginale" sind oder nicht. Da man weniger damit rechnet (geheim gehaltenes Verfahren ), dann ist es durch sogar sicherer.

Das Problem hier sind sogenannte Derived Key Attacks, die bei doppelter Anwendung eines Verfahrens X u.U. dazu führen, dass der Cipher-Text identisch zu dem ist, den man mittels des Klartexts und Verschlüsslung eines dritten Schlüssels erhalten würde. In diesem Fall steigert die zweite Verschlüsslung die Sicherheit nicht; schadet aber auch nicht primär. Viele Stream-Cipher sind hier anfällig, aber auch Caesar gehört hier hinein.

jaenicke hat folgendes geschrieben :

IhopeonlyReader hat folgendes geschrieben : Da man weniger damit rechnet (geheim gehaltenes Verfahren ), dann ist es durch sogar sicherer. Das Problem dabei ist nur, dass es genügt, wenn jemand das Programm in die Finger bekommt. Wenn die Verschlüsselung dann nur sicher ist, weil man nicht weiß wie sie funktioniert, wären dann alle jemals damit verschlüsselten Daten knackbar.

Ich suche noch "KRYPTO 4.0/2013 Professional"; wer da also helfen kann ...

jaenicke hat folgendes geschrieben :

Wenn die Verschlüsselung hingegen wegen des verwendeten Verfahrens sicher ist, dann kann der Angreifer alles haben, und wird trotzdem ohne den Schlüssel nur schlecht an die Daten kommen. Und wenn er dann eins geknackt hat, hat er damit bei den anderen trotzdem keinen Vorteil.

Und deshalb ist KRYPTO 4.0/2013 sicher!

IhopeonlyReader hat folgendes geschrieben :

naja es ging mir um die Aussage: "2x verschlüsseln sein unsicherer als 1x, da man teilweise das original dadurch wiederherstellen würde"

2mal Rot13 ist gegen diesen Angriff immun!

Oliver Maas hat folgendes geschrieben :

Soweit ich das nun verstanden habe, ist der One-Time-Pad (sofern er die Voraussetzungen korrekt einhält) informationstheoretisch sicher. Die zweimalige Anwendung kann ihn also nicht "sicherer" machen (er ist bereits sicher).

Jain. One-Time-Pads sind gegen Derived Keys anfällig. Man kann zwei Keys nehmen und daraus einen dritten, gleichbedeutenden ableiten.

Ansonsten bitte mal Kryptographie-Literatur aus der Praxis studieren ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Nur interessehalber, Du schreibst

BenBE hat folgendes geschrieben:

Der 8192er ist in wenigen Sekunden erstellt (Das geht mit passendem Entropie-Daemon mal nebenbei.)

Ich nehmen mal an, der Entropie-Daemon liefert nur die Randombits, und Du must (bei Standard-RSA) mindestens zwei Pseudo-Primzahltests für 4096-Bit-Primzahlen machen. Was benutzt Du da, wenn man mal annimmt das wenige Sekunden so ca 10-20 sind?

BenBE hat folgendes geschrieben :

Jain. One-Time-Pads sind gegen Derived Keys anfällig. Man kann zwei Keys nehmen und daraus einen dritten, gleichbedeutenden ableiten.

wobei wie ich schon erwähnte Strings den Bytewert 0 nicht annehmen. bei doppelverschlüsselung ist dieser wert enthalten, hierdurch hat man 256 anstatt 255 "varianten" zur verfügung und somit ist es ca. 0,4% sicherer !

IhopeonlyReader hat folgendes geschrieben :

BenBE hat folgendes geschrieben : Jain. One-Time-Pads sind gegen Derived Keys anfällig. Man kann zwei Keys nehmen und daraus einen dritten, gleichbedeutenden ableiten. wobei wie ich schon erwähnte Strings den Bytewert 0 nicht annehmen. bei doppelverschlüsselung ist dieser wert enthalten, hierdurch hat man 256 anstatt 255 "varianten" zur verfügung und somit ist es ca. 0,4% sicherer !

Andersrum: wenn du aus irgendwelchen Implementationsgründen nullterminierte Strings statt ByteArrays verwendest, schränkst du deinen Schlüsselraum ein. Es wird nicht besser, sondern nur weniger schlecht.

Gammatester hat folgendes geschrieben :

Nur interessehalber, Du schreibst BenBE hat folgendes geschrieben: Der 8192er ist in wenigen Sekunden erstellt (Das geht mit passendem Entropie-Daemon mal nebenbei.) Ich nehmen mal an, der Entropie-Daemon liefert nur die Randombits, und Du must (bei Standard-RSA) mindestens zwei Pseudo-Primzahltests für 4096-Bit-Primzahlen machen. Was benutzt Du da, wenn man mal annimmt das wenige Sekunden so ca 10-20 sind?

XCA auf nem Intel Core i7-2860QM

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Das ist ein sehr interessantes Thema. Mich würde interessieren, ob ein Angreifer wenn er genügend verschlüsselte und unverschlüsselte Daten hat und das Cryptoverfahren kennt Rückschlüsse auf den verwendeten Schlüssel ziehen kann?
Als konkretes Beispiel könnten wir das Programm Boxcryptor nehmen (kennen sicher einige): Verwendet AES 256, salt ist dem Angreifer bekannt.
Wenn ich nun eine Öffentlich zugängliche Datei (z.B. ein YouTube Video) verschlüssele und die Dateinamenverschlüsselung aus ist, kann der Angreifer ja anhand des Dateinamens herausfinden worum es dich handelt. Nun hat er die unverschlüsselte Datei (Youtube) und die verschlüsselte. Kann er jetzt den Schlüssel herausfinden und damit den Rest meiner Dateien entschlüsseln?

Siehe en.wikipedia.org/wik...own-plaintext_attack

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.