Verschlüsselung testen



  • rapso schrieb:

    du kannst den einmaligen schluessel z.b. eben pi immer weiter verwenden ohne das sich etwas wiederholt.

    dann darfst du aber niemandem verraten wie es funktioniert (allein aus dem grund ist es schon unsicher) und die gefahr ist gross, dass angreifer herausfinden, dass du die pi-ziffernkette verwendest.



  • @rapso: Ich glaube, du hast das Prinzip immer noch nicht verstanden:

    OTP:
    Ich erzeuge eine echt zufällige Folge von 0 und 1 und brenne sie auf CD. Dann packe ich eine Kopie davon in meinen Tresor und gebe dir eine Kopie. Im Endeffekt kennen nur wir beide diese Folge.
    Wenn ich dir jetzt eine Nachricht schicke, muß ich dir ja mitteilen, welchen Schlüssel ich verwendet habe, also schicke ich den Index in der Schlüsselsequenz mit, an der ich begonnen habe. Daraus kannst du (indem du auf der CD nachsiehst) den nötigen Schlüssel ermitteln, aber sonst niemand.

    berechnetes OTP:
    Wir verwenden beide z.B. die Zahl pi (oder einen beliebigen Zufallsgenerator), um den Schlüssel zu erzeugen. Dann ist nicht davon auszugehen, daß nur wir diesen Algorithmus kennen - die Ziffern von pi kann jeder berechnen, und die Folge, die ein Zufallsgenerator liefert, ist auch deterministisch.
    Wenn ich eine Nachricht schicke, benötigst du wieder den richtigen Schlüssel, also muß ich dir die Anfangsposition in der Ziffernfolge von pi (bzw. den Seed-Wert für den Zufallsgenerator) übermitteln. Und daraus kann JEDER den verwendeten Schlüssel berechnen.

    -> Im Endeffekt ist der verwendete Schlüssel NICHT die Ziffernfolge von pi, sondern lediglich die Information, wo in dieser Ziffernfolge du beginnst, den Schlüssel herauszuziehen.

    (Daß ich bereits verwendete Teile des Schlüssels nicht nochmal nehme, versteht sich von selbst. Aber ich kann nicht davon ausgehen, daß alle bisher verschlüsselten Nachrichten wirklich angekommen sind und dein Bytezähler mit meinem übereinstimmt)

    ohne einen unverschluesselten text bringt dir das weiterhin nichts.

    Doch, du hast die Differenz zweier natürlichsprachlicher Texte mit ihren typsichen statistischen Verteilungen - und die kannst du auch mit statistischen Methoden angreifen.



  • rapso schrieb:

    ...es ist irrelevant. du must weder pi noch einen anderen randomnumbergenerator uebertragen, du kannst den einmaligen schluessel z.b. eben pi immer weiter verwenden ohne das sich etwas wiederholt.

    Du schlägst ein bestimmtes "Protokoll" vor, das selbst unsicherer ist als der OneTimePad.
    Entweder versuchst Du, zu verheimlichen, dass Du Pi als Schlüsselquelle nutzt ("security by obscurity" ist immer ein schlechter Weg) oder Du musst die Absprache, welche Teil von Pi Du jeweils verwendest, mitteilen. Diese Information stellt dann aber den eigentlichen Schlüssel dar und sein Wertebereich den Schlüsselraum.
    Es ist nämlich kryptographisch irrelevant, ob Du

    cypher[textPos] = plain[textPos] ^ key[keyPos]
    

    oder

    cypher[textPos] = plain[textPos] ^ pi[key[keyPos]]
    

    rechnest.
    Bleibt Dir also nur die alte Wahl: Du musst soviele Bits übertragen, wie der Plaintext lang ist ... auch wenn Du Diese Bits zur Auswahl der verwendeten Stellen von Pi verwendest.

    EDIT: Kreuzsakra !! Ich werde nochmal zu "Einbuchstabenantworten" übergehen, um wenistens ab&zu mal schneller zu sein als CStoll.

    CStoll schrieb:

    ...
    berechnetes OTP:
    ...oder einen beliebigen Zufallsgenerator ... und die Folge, die ein Zufallsgenerator liefert, ist auch deterministisch....

    Sagen wir mal so: Wenn sie nicht deterministisch wäre, hätten wir in diesem Zusammenhang nichts gewonnen. 😉

    Gruß,

    Simon2.



  • CStoll schrieb:

    ...

    wenn du meinst, dass ein nicht echt zufaelliger schluessel unsicher ist, dann hast du das selbe problem bei jedem anderen verschluesselungsverfahren die pseudorandom keys generieren. egal ob du jetzt einen 128bit key fuer des oder als index in pi nutzt.



  • rapso schrieb:

    CStoll schrieb:

    ...

    wenn du meinst, dass ein nicht echt zufaelliger schluessel unsicher ist, dann hast du das selbe problem bei jedem anderen verschluesselungsverfahren die pseudorandom keys generieren. egal ob du jetzt einen 128bit key fuer des oder als index in pi nutzt.

    die pseudo-random functions leben von den 'nonces', das sind möglichste echte zufallswerte, mit denen die gefüttert werden. wenn die berechenbar sind (etwa wie ein paar pi-ziffern) dann ist natürlich auch der output der PRF reproduzierbar und somit nicht mehr sicher...
    🙂



  • rapso schrieb:

    CStoll schrieb:

    ...

    wenn du meinst, dass ein nicht echt zufaelliger schluessel unsicher ist, dann hast du das selbe problem bei jedem anderen verschluesselungsverfahren die pseudorandom keys generieren. egal ob du jetzt einen 128bit key fuer des oder als index in pi nutzt.

    Weswegen wir auch echte Zufallszahlengeneratoren verwenden. 😃

    Es bleibt einfach dabei: OneTimepad ist gleichzeitig ideal (wenn optimal betrieben) und extrem anfällig gegenüber Aweichung vom "Optimalbetrieb".

    Gruß,

    Simon2.



  • vista schrieb:

    sowas lässt sich aber reproduzieren, computer-zufallsgeneratoren erzeugen irre lange zahlenketten, aber keine echten zufallszahlen.
    für einen versierten crypto-hacker sollte es kein problem sein, das zu knacken 😉

    Software-Zufallszahlengeneratoren sind keine "echten" zufallszahlen und folgen einem Algorythmus, es gibt aber durchaus möglichkeiten am Computer an "echte" Zufallszahlen zu kommen



  • vista schrieb:

    rapso schrieb:

    CStoll schrieb:

    ...

    wenn du meinst, dass ein nicht echt zufaelliger schluessel unsicher ist, dann hast du das selbe problem bei jedem anderen verschluesselungsverfahren die pseudorandom keys generieren. egal ob du jetzt einen 128bit key fuer des oder als index in pi nutzt.

    die pseudo-random functions leben von den 'nonces', das sind möglichste echte zufallswerte, mit denen die gefüttert werden. wenn die berechenbar sind (etwa wie ein paar pi-ziffern) dann ist natürlich auch der output der PRF reproduzierbar und somit nicht mehr sicher...
    🙂

    hab ich ja gesagt, wenn du den anfangsindex weisst, dann hast du das password, aber das herauszubekommen ist mindestens so schwer wie fuer jedes andere symmetrische verfahren auch.



  • PI als Password zu verwenden bringt garnichts. Das Problem wird nur verlagert. Der sinn eines pwds ist ja, dass es der andere nicht kennt, aber pi kennt jeder. das was daran geheim ist, ist die nforamtion das es pi ist (oder eine andere endlich lange rechenvorschrift) und der anfangsindex. Und wenn der anfangsindex eine unendlich große zahl ist, dann kannst du auch die nehmen



  • dermitdemlangen schrieb:

    PI als Password zu verwenden bringt garnichts. Das Problem wird nur verlagert. Der sinn eines pwds ist ja, dass es der andere nicht kennt, aber pi kennt jeder. das was daran geheim ist, ist die nforamtion das es pi ist (oder eine andere endlich lange rechenvorschrift) und der anfangsindex. Und wenn der anfangsindex eine unendlich große zahl ist, dann kannst du auch die nehmen

    Du weißt aber nicht, dass es Pi ist.

    Die Pins der Kontokarten sind auch nur 4Stellen, sprich viele Menschen haben die gleiche Pin, aber niemand weiß wer welche Pin hat.



  • PI kann mit einer Rechenvorschrift dargestellt werden. Das Passwort ist also ein Text der so lang ist wie diese.

    Bei Pins kann man normal nicht beliebig oft eine falsche ausprobieren, was man beim Password zum Textentschlüsseln schon kann.



  • darthdespotism schrieb:

    vista schrieb:

    sowas lässt sich aber reproduzieren, computer-zufallsgeneratoren erzeugen irre lange zahlenketten, aber keine echten zufallszahlen.
    für einen versierten crypto-hacker sollte es kein problem sein, das zu knacken 😉

    Software-Zufallszahlengeneratoren sind keine "echten" zufallszahlen und folgen einem Algorythmus, es gibt aber durchaus möglichkeiten am Computer an "echte" Zufallszahlen zu kommen

    Genau das macht man ja auch für das "echte OTP". Allerdings nützt es dir nichts, wenn du die Zufallszahlen nur auf deinem Rechner hast - dein Gesprächspartner muß sie auch kennen.

    lolz schrieb:

    dermitdemlangen schrieb:

    PI als Password zu verwenden bringt garnichts. Das Problem wird nur verlagert. Der sinn eines pwds ist ja, dass es der andere nicht kennt, aber pi kennt jeder. das was daran geheim ist, ist die nforamtion das es pi ist (oder eine andere endlich lange rechenvorschrift) und der anfangsindex. Und wenn der anfangsindex eine unendlich große zahl ist, dann kannst du auch die nehmen

    Du weißt aber nicht, dass es Pi ist.

    Die Tatsache, daß du Pi verwendest, fällt aber unter entweder unter die Rubrik "Security by Obscurity" (schlecht - eine Verschlüsselung sollte nur auf der Geheimhaltung des Schlüssels basieren) oder die verwendete Zahl (pi, e, sqr(2)) gehört zum Schlüssel (das ist schon besser, aber damit hast du wieder einen endlichen Schlüssel - und der ist praktisch knackbar.

    Die Pins der Kontokarten sind auch nur 4Stellen, sprich viele Menschen haben die gleiche Pin, aber niemand weiß wer welche Pin hat.

    Deswegen hast du ja auch nur drei Versuche, bevor die Karte eingezogen wird 😉

    @rapso: Nochmal zur Differenzanalyse:
    Im korrekten betrieb hast du einen zufälligen Schlüssel, d.h. jede mögliche Zeichenfolge könnte als Ausgangspunkt der Verschlüsselung in Frage kommen - also auch jeder sinnvolle Text.
    Bei der Verrechnung zweier identisch verschlüsselter Texte fällt der Schlüssel heraus und du hast die Differenz zweier Klartexte. Damit kannst du zu jedem möglichen Klartext sein "Spiegelbild" finden und beide nebeneinander betrachten.



  • vista schrieb: sowas lässt sich aber reproduzieren, computer-zufallsgeneratoren erzeugen irre lange zahlenketten, aber keine echten zufallszahlen. für einen versierten crypto-hacker sollte es kein problem sein, das zu knacken

    Wie/Womit kann man dann "sichere" Schlüssel generieren?

    Grüße S.

    PS zum rumspielen gibts Cryptool.



  • Space235 schrieb:

    vista schrieb: sowas lässt sich aber reproduzieren, computer-zufallsgeneratoren erzeugen irre lange zahlenketten, aber keine echten zufallszahlen. für einen versierten crypto-hacker sollte es kein problem sein, das zu knacken

    Wie/Womit kann man dann "sichere" Schlüssel generieren?

    Grüße S.

    PS zum rumspielen gibts Cryptool.

    Gibt genügend Zufallszahlgeneratoren auf Basis von Rauschdioden.


Anmelden zum Antworten