Verschlüsselung testen

[Simon2]

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.

[rapso]

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.

[vista]

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

[Simon2]

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.

[darthdespotism]

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

[rapso]

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.

[dermitdemlangen]

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

[lolz]

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.

[dermitdemlangen]

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.

[CStoll]

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.

[Space235]

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.

[DEvent]

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.