Abhörsichere Übertragung



  • Wie kann man eine abhörsichere Datenübertragung im Internet realisieren?
    Wenn man z.B. RSA verwendet und den public Key sicher übergibt (z.B. CD übergabe). Ist es dann möglich z.B. anhand von Headern ein Muster zu finden, mit dem man die Schlüssel knacken kann? Würde es was bringen, wenn der Header zufällig generiert wird? 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. Dann wären die Headerinfos zufällig über die Nachricht verteilt und man kann kein gleichbleibendes Muster finden.

    Andere Ideen?



  • Ä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!

    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!



  • dsf46g.fg1tb-(43534<&l schrieb:

    Andere Ideen?

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



  • 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.

    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.



  • 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"?

    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.



  • [Doppelpost]



  • 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.



  • dsf46g.fg1tb-(43534<&a schrieb:

    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?



  • 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.

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



  • rüdiger schrieb:

    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.



  • Also ich kenn das auch so, erst Key mittels RSA/elliptic curve/... ausmachen, die Verbindung läuft dann über RC4/... verschlüsselt.
    Vor und hinter einem Paket eine variable Anzahl von zufällig generierten Bytes zu übertragen kann das ganze dabei wesentlich sicherer machen, da dadurch wie denke ich schon erwähnt wurde Angriffe auf den Key schwieriger werden.



  • 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



  • zum schlüssel austauschen kann man auch was bewährtes nehmen: http://en.wikipedia.org/wiki/Extensible_Authentication_Protocol



  • 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. 😉



  • Simon2 schrieb:

    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.



  • rapso schrieb:

    ...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.



  • Simon2 schrieb:

    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.


Anmelden zum Antworten