Andere Ideen?

Und was bringt es dem Angreifer, wenn er den Public-Key kennt? Nichts. (Zumindest wenn die Schlüsselgröße groß genug ist ;))

Problematisch ist eher ein Man-in-the-middle-Angriff auf das Protokoll, wenn die Übertragung des Public-Keys Bestandteil des Protokolls ist!

Andere Ideen?

Ja: Beschäftige Dich mal mit einschlägiger Literatur zu dem Thema (siehe Diffie-Hellmann etc).

Äh, was soll das mit dem zufälligen Bitmuster bringen? Jemand der dein Protokoll angreifen will, kann die Bitmuster doch auch auslesen. Security-with-Obscurity ist keine gute Idee!

Na diese Bits sind natürlich auch verschlüsselt. Es gibt also keinen festen Punkt an dem man sagen kann, dass hier immer x stehen muss und deshalb dieser Teil des Schlüssels Y sein muss.

byto schrieb:

dsf46g.fg1tb-(43534<&l schrieb:

Andere Ideen?

Ja: Beschäftige Dich mal mit einschlägiger Literatur zu dem Thema (siehe Diffie-Hellmann etc).

Bücher lesen ist langweilig. Selber denken macht viel mehr Spass, als nur die Ideen anderer nachzumachen.

rüdiger schrieb:

Äh, was soll das mit dem zufälligen Bitmuster bringen? Jemand der dein Protokoll angreifen will, kann die Bitmuster doch auch auslesen. Security-with-Obscurity ist keine gute Idee!

Na diese Bits sind natürlich auch verschlüsselt. Es gibt also keinen festen Punkt an dem man sagen kann, dass hier immer x stehen muss und deshalb dieser Teil des Schlüssels Y sein muss.

Wie werden die Bits "entschlüsselt"?

dsf46g.fg1tb-(43534<&a schrieb:

byto schrieb:

dsf46g.fg1tb-(43534<&l schrieb:

Andere Ideen?

Ja: Beschäftige Dich mal mit einschlägiger Literatur zu dem Thema (siehe Diffie-Hellmann etc).

Bücher lesen ist langweilig. Selber denken macht viel mehr Spass, als nur die Ideen anderer nachzumachen.

Um zu solchen Themen etwas neues beitragen zu können, braucht man gewisse Grundlagen, um nicht längst bekannte Fehler zu wiederholen.

dsf46g.fg1tb-(43534<&a schrieb:

rüdiger schrieb:

Äh, was soll das mit dem zufälligen Bitmuster bringen? Jemand der dein Protokoll angreifen will, kann die Bitmuster doch auch auslesen. Security-with-Obscurity ist keine gute Idee!

Na diese Bits sind natürlich auch verschlüsselt. Es gibt also keinen festen Punkt an dem man sagen kann, dass hier immer x stehen muss und deshalb dieser Teil des Schlüssels Y sein muss.

Wie werden die Bits "entschlüsselt"?

Ganz normal mit dem private Key.

Christoph schrieb:

dsf46g.fg1tb-(43534<&a schrieb:

rüdiger schrieb:

Äh, was soll das mit dem zufälligen Bitmuster bringen? Jemand der dein Protokoll angreifen will, kann die Bitmuster doch auch auslesen. Security-with-Obscurity ist keine gute Idee!

Na diese Bits sind natürlich auch verschlüsselt. Es gibt also keinen festen Punkt an dem man sagen kann, dass hier immer x stehen muss und deshalb dieser Teil des Schlüssels Y sein muss.

Wie werden die Bits "entschlüsselt"?

Ganz normal mit dem private Key.

Dann ist es doch eine gewöhnliche private/public-key-Verschlüsselung, und kein "zufällig generierter Header" oder gar so etwas willkürliches wie

dsf46g.fg1tb-(43534<&l schrieb:

In den Bytes 4-17 steht z.B. eine Zufallszahl, die angibt wo es weitere Header Informationen gibt, dort steht dann ein Teil und weitere Zufallszahlen, mit denen man weiter kommt.

Beides. Ist meine Schrift oben so undeutlich?

Ah, nun weiß ich was du willst. Was du meinst nennt man glaube ich Plaintext-Attack (oh man, ist lange her, das ich mich mit Kryptographie befasst habe ). So weit ich weiß ist RSA dagegen nicht anfällig.

Da asymmetrische Verfahren aber sehr langsam zu implementieren sind, benutzt man asymmetrische Verfahren in der Regel nur dazu um einen temporären Schlüssel eines symmetrischen Verfahrens auszutauschen (zB AES) und damit die Daten dann zu verschlüsseln.

Ob es bei heutigen Verfahren sinnvoll ist eine große Entropie bei den Daten zu erzeugen, wage ich mal zu bezweifeln.

dsf46g.fg1tb-(43534<&a schrieb:

Beides. Ist meine Schrift oben so undeutlich?

Ah, nun weiß ich was du willst. Was du meinst nennt man glaube ich Plaintext-Attack (oh man, ist lange her, das ich mich mit Kryptographie befasst habe ). So weit ich weiß ist RSA dagegen nicht anfällig.

Da asymmetrische Verfahren aber sehr langsam zu implementieren sind, benutzt man asymmetrische Verfahren in der Regel nur dazu um einen temporären Schlüssel eines symmetrischen Verfahrens auszutauschen (zB AES) und damit die Daten dann zu verschlüsseln....

100% ACK

rüdiger schrieb:

...
Ob es bei heutigen Verfahren sinnvoll ist eine große Entropie bei den Daten zu erzeugen, wage ich mal zu bezweifeln.

Wird allerdings schon gemacht. Gerade wenn man (wie beim obigen Verfahren) mit relativ "kurzen Klardaten" (hier: Schlüssel mit Länge <= 256 Bit) mit einem deutlich längeren "Kryptogramm" verarbeitet (z.B. RSA Modulus mit Länge 2048 Bits) arbeitet man schon mit "Redundanzverfahren" (z.B. ISO9796-2), weil das Verfahren oftmals eben doch empfindlich gegenüber dieser Konstellation ist.

Gruß,

Simon2.

http://de.wikipedia.org/wiki/One-Time-Pad

wenn man vorher eh beiden per cd den key geben will, dann reicht als key auch ein seed in einem radom-number-generator. dann einfach immer xor der aktuellen daten mit den fortlaufenden random numbers und diese verschluesselung ist bewiesener massen unknackbar (sofern die random numbers wirklich random sind).

http://de.wikipedia.org/wiki/One-Time-Pad

Hmmmmm ... aber AFAIK nur, solange der Schlüssel (= die Kette echter Zufallszahlen) genauso lang ist wie der Klartext.
Sobald Du den Schlüssel kürzt (und sei es noch so intelligent - alles, was Du kannst, kann ein Angreifer auch), schwächst Du den Algorithmus.

Das mag durchaus noch reichen, aber es entspricht nicht mehr dem "One-Time-Pad-Ideal".

Gruß,

Simon2.

P.S.: Sobald Du einen Schlüssel mehrfach verwendest, ist das natürlich auch implizit eine "Kürzung" des Schlüssels - es gibt schon einen Grund, warum keiner wirklich ein ideales One-Time-Pad verwendet: Es bringt nichts.

rapso@work schrieb:

wenn man vorher eh beiden per cd den key geben will, dann reicht als key auch ein seed in einem radom-number-generator. dann einfach immer xor der aktuellen daten mit den fortlaufenden random numbers und diese verschluesselung ist bewiesener massen unknackbar (sofern die random numbers wirklich random sind).

http://de.wikipedia.org/wiki/One-Time-Pad

Hmmmmm ... aber AFAIK nur, solange der Schlüssel (= die Kette echter Zufallszahlen) genauso lang ist wie der Klartext.
Sobald Du den Schlüssel kürzt (und sei es noch so intelligent - alles, was Du kannst, kann ein Angreifer auch), schwächst Du den Algorithmus.

Das mag durchaus noch reichen, aber es entspricht nicht mehr dem "One-Time-Pad-Ideal".

Gruß,

Simon2.

P.S.: Sobald Du einen Schlüssel mehrfach verwendest, ist das natürlich auch implizit eine "Kürzung" des Schlüssels - es gibt schon einen Grund, warum keiner wirklich ein ideales One-Time-Pad verwendet: Es bringt nichts.

schoen dass du nochmal zusammengefasst hast was auf wikipedia steht.

...schoen dass du nochmal zusammengefasst hast was auf wikipedia steht.

Ob Du's glaubst oder nicht: Wiki habe zu dem Thema noch gar nicht befragt (ich bin irgendwie recht "old fashioned" - mein Gott, ich werde alt) ... an Wiki denke ich oft viel zu spät - und ehrlich gesagt: Dass ich mal gemerkt habe, wie einfach jeder Hansel da etwas reinschreiben kann, steigert mein Vertrauen auch nicht unbedingt (bei "Promi-Themen" schon, aber in "Randbereichen" kann da jahrelang Unsinn drinstehen, ohne dass das jemand merkt)....

Aber gut, dass Du nochmal darauf hingewiesen hast.

Mir war jedenfalls der Zusammenhang zwischen Deinem "Schlüssellängensparansatz" und der Aussage "... bewiesenermaßen unknackbar ...." schien es mir nötig zu machen, das nochmal klarzustellen.

Gruß,

Simon2.

rapso schrieb:

...schoen dass du nochmal zusammengefasst hast was auf wikipedia steht.

ob du's glaubst oder nicht, das war sarkasmus

Mir war jedenfalls der Zusammenhang zwischen Deinem "Schlüssellängensparansatz" und der Aussage "... bewiesenermaßen unknackbar ...." schien es mir nötig zu machen, das nochmal klarzustellen.

Die klarstellung steht schon im Wiki, ich hab auch direkt dorthin verlinkt ;)... aber du hast natuerlich recht, da steht gerade in fachlichen Dingen viel Falsches und die Zensur die dort durchgaengig betrieben wird, hat die Faerbung der leute die dort Einfluss haben und nicht von der Richtigkeit abhaengig.
Aber ich versuch auch nur in seltenen Faellen dorthin zu verlinken wenn ich genau weiss was auf einer seite steht.