mikrocontroller.net

Forum: PC-Programmierung Sicherheitsalgorithmen was ist sicherer / besser


Autor: Anton (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hallo Ihr,

ich weiß, Sicher geht nicht, aber das ist auch nicht Sinn und zweck der 
Übung. Hier geht es um die Bewertung von Verschlüsselungs und Signatur 
Algorithmen, insbesondere um sha256WithRSAEncryption und RSASSA-PSS

gibt es irgendwo Informationen z.B. ein Ranking für solche Algorithmen?

Punkte wie momentan Knackbar, ggf. erfolgreiche knack Versuche in 
Vergangenheit oder die Chance die Nachricht zu errechnen wäre 
Interessant einsehen zu können.

ich weiß, viele denken sich jetzt ob jetzt 2000 Jahre oder 3000 Jahre 
(mit heutiger Technologie) ist doch egal... aber in der Tat definiert es 
den Algorithmus welcher 3000 Jahre bedarf <- in diesen Punkt besser.

Vielen Dank für jeden Tipp

PS. Bei diesem Thema geht es um Verschlüsselung relevanter Marktdaten 
wir werden hier auch in den nächsten Monaten einen Verschlüsselungs 
Experten mit an den Tisch holen... trotzdem ist es FÜR MICH (als aktiver 
Gesprächspartner) enorm wichtig, diverse Basics zu diesem Thema zu 
verstehen. Wie die ganzen Verschlüsselungen arbeiten bin ich auch gerade 
am lernen... aber das macht die unterschiedlichen Methoden für mich noch 
nicht gleich "Vergleichbar"

: Verschoben durch Moderator
Autor: Daniel H. (Firma: keine) (commander)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Vom BSI gibt es regelmäßig aktualisierte Empfehlungen für aktuell als 
sicher angesehene Algorithmen und Schlüssellängen.

https://www.bsi.bund.de/DE/Publikationen/Technisch...

RSASSA-PSS gilt aktuell als sicher sofern die Schlüssellänge mindestens 
2048 Bit beträgt. Wenn ich mich recht erinnere basiert 
sha256WithRSAEncryption auf RSASSA-PKCS-V1_5, das sollte man bei 
Neuentwicklungen nicht mehr verwenden.

Autor: Jack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
https://www.bsi.bund.de/DE/Publikationen/Technisch...

Ob du denen traust musst du selber wissen. Das BSI ist die ehemalige 
Zentralstelle für das Chiffrierwesen des Bundesnachrichtendienstes, alte 
Kumpels der Amerikaner.

Vom amerikanischen NIST gibt es ähnliche Empfehlungen. Von denen ist 
bekannt, dass die NSA ihnen in SP 800-90A einen schwachen 
Zufallsgenerator "untergeschoben" hat. Was der NSA einmal gelingt 
gelingt ihr auch zweimal.

FIPS hat sicher auch etwas, vermutlich mit Verweis auf NIST. Einfach 
suchen.

Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

erstmal danke für die Konstruktive und Hilfreiche Diskussion :)

ja, BSI ist gut... hier geht es eher um Standards und Haftbarkeit <- 
eigen Beurteilungen sind eben auch IMMER gewagt.
=> vertrauen (Privat) eher fraglich. In einem Großunternehmen, 
vermutlich nicht anders möglich. Dennoch will ich mich nicht nur auf 
deren Aussage verlassen sondern eben mir selbst BASIS-Wissen aneignen 
(ich bin gerade "nebenbei" dabei mich mit Bouncy-Castle auseinander zu 
setzen... aber es ist einfacher zu verschlüsseln und entschlüsseln als 
es zu verstehen ^^)

Aber gibt es denn noch weitere Anlaufstellen. Hier kann man sich ja nur 
"weiterbilden" indem man mehr und mehr liest...

=> was mich wundert ist, dass die Standardisierungsprozesse bei welchen 
die Kryptografien "durchnummeriert" werden, den sha256WithRSAEncryption, 
später einstufen als den RSASSA-PSS:
http://oid-info.com/get/1.2.840.113549.1.1.11 <- hier die Endnummer 11
http://oid-info.com/get/1.2.840.113549.1.1.10 <- hier die Endnummer 10

ich weiß, dass neuere Entwicklungen nicht immer besser sind, aber hier 
wundert es mich doch sehr <- oder verstehe ich hier etwas nicht "ganz 
richtig"...

von:
http://oid-info.com/get/1.2.840.113549.1.1.5
weiß ich z.B. sicher, dass es geknackt ist...

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-8 lesenswert
nicht lesenswert
Anton schrieb:
> ja, BSI ist gut... hier geht es eher um Standards und Haftbarkeit <-

Daniel H. schrieb:
> RSASSA-PSS gilt aktuell als sicher sofern die Schlüssellänge mindestens
> 2048 Bit beträgt.


 2048 bit ist gleichzusetzen mit einem Text von 256 Zeichen. Ein
 einfaches XOR mit 32 beliebigen Zeichen über Sourcetext und den so
 gewonnenen Text noch einmal mit 32 beliebigen Zeichen XOR-en - das
 schafft kein Computer in Tausend Jahren.
 Und wenn das zweite XOR nicht von Position 0 anfängt, sondern um eine
 gewisse Anzahl Zeichen verschoben wird - unknackbar für immer.
 Wahrscheinlich ginge es auch mit 16 Zeichen, was einer Schlüssellänge
 von insgesammt 256 bit entspricht.

 Aber komplizierte Algorithmen mit komplizierten Namen - das hört sich
 schon mal nach unknackbar, auch wenn es nicht so ist...

: Bearbeitet durch User
Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der ultimative Vergleich: https://www.keylength.com/

Autor: Torsten Robitzki (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
Marc V. schrieb:

>  2048 bit ist gleichzusetzen mit einem Text von 256 Zeichen. Ein
>  einfaches XOR mit 32 beliebigen Zeichen über Sourcetext und den so
>  gewonnenen Text noch einmal mit 32 beliebigen Zeichen XOR-en - das
>  schafft kein Computer in Tausend Jahren.

Das ist mit verlaub, totaler Blödsinn: wenn Du c = p ^ k1 ^ k2 nimmst, 
dann ist das identisch zu c = p ^ (k1 ^ k2) = p ^ kx. Es wird also durch 
den zweiten Lauf nicht sicherer. Und wenn Du an irgend einer Stelle 
einen Anhaltspunkt dafür gibst, wie der plaintext aussieht, dann hast Du 
sofort den Schlüssel: kx = p ^ c.

Und selbst, wenn Du keine plain text Attacken zuläßt, ist so eine 
Verschlüsselung extrem einfach zu knacken. Mach doch mal ein einfaches 
Text-Beispiel, mit z.B. 2000 Zeichen. Das knackt Dir hier jeder 
Informatik-Student in einer halben Stunde.

>  Aber komplizierte Algorithmen mit komplizierten Namen - das hört sich
>  schon mal nach unknackbar, auch wenn es nicht so ist...

Bei Cryptographie, ist es wie mit der Juristerei: wenn man davon keine 
Ahnung hat, sollte man sich lieber Experten-Hilfe suchen, sonst wird es 
teuer. Zum Glück bekommen wir die als SW-Entwickler in Form von bereits 
vorhandenen und bewärten Algorithmen bereits geschenkt.

mfg Torsten

: Bearbeitet durch User
Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Torsten R. schrieb:
> Das ist mit verlaub, totaler Blödsinn: wenn Du c = p ^ k1 ^ k2 nimmst,
> dann ist das identisch zu c = p ^ (k1 ^ k2) = p ^ kx. Es wird also durch
> den zweiten Lauf nicht sicherer.

 LOL.
 Ich habe nur als Beispiel gleiche Schlüssellängen angegeben. Wenn aber
 k1 192 bit lang ist und k2 320 bit lang ist, wobei beide Schlüssel
 beliebige Längen zwischen 64 und 448 bit haben können (als Beispiel)
 - was dann ?
 Und k2 kann in zuerst verschlüsseltem Text zwischen 0 und 1023 bit
 verschoben sein (als Beispiel) ?


Torsten R. schrieb:
> Und selbst, wenn Du keine plain text Attacken zuläßt, ist so eine
> Verschlüsselung extrem einfach zu knacken. Mach doch mal ein einfaches
> Text-Beispiel, mit z.B. 2000 Zeichen. Das knackt Dir hier jeder
> Informatik-Student in einer halben Stunde.

 LOL.

Autor: Torsten Robitzki (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Marc V. schrieb:
> Torsten R. schrieb:
>> Das ist mit verlaub, totaler Blödsinn: wenn Du c = p ^ k1 ^ k2 nimmst,
>> dann ist das identisch zu c = p ^ (k1 ^ k2) = p ^ kx. Es wird also durch
>> den zweiten Lauf nicht sicherer.
>
>  LOL.
>  Ich habe nur als Beispiel gleiche Schlüssellängen angegeben. Wenn aber
>  k1 192 bit lang ist und k2 320 bit lang ist, wobei beide Schlüssel
>  beliebige Längen zwischen 64 und 448 bit haben können (als Beispiel)
>  - was dann ?

Dann kommst Du immer noch extrem einfach vom plain text und dem cypter 
text auf die beiden Schlüssel.

Gibt es Dir nicht zu bedenken, dass noch kein Security-Experte (ausser 
Dir) auf diese Idee gekommen ist?

Autor: Schreiber (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Marc V. schrieb:
> Torsten R. schrieb:
>> Und selbst, wenn Du keine plain text Attacken zuläßt, ist so eine
>> Verschlüsselung extrem einfach zu knacken. Mach doch mal ein einfaches
>> Text-Beispiel, mit z.B. 2000 Zeichen. Das knackt Dir hier jeder
>> Informatik-Student in einer halben Stunde.
>
>  LOL.

Korrekt. Er benötigt hierzu einen Text der Länge r*k1*k2 wobei r eine 
hinreichend große, rationale Zahl ist (für r>100 wird es trivial)
Den Rest kann man an einem Tag mit Matlab und einfachen Grundkentnissen 
in Stochastik zusammenfrickeln.

Tipp: In einem Text kommt nicht jeder Buchstabe gleich oft vor. Man muss 
nur zählen können...

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Torsten R. schrieb:
> Dann kommst Du immer noch extrem einfach vom plain text und dem cypter
> text auf die beiden Schlüssel.

 Erstens ist das nicht extrem einfach und zweitens:
 Wenn du dir plain text besorgen kannst, warum überhaupt nach
 Schlüssel suchen ?

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Schreiber schrieb:
> Tipp: In einem Text kommt nicht jeder Buchstabe gleich oft vor. Man muss
> nur zählen können...

 LOL.
 Ja.
 Deswegen wird zweites XOR bitweise verschoben.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Üblicherweise ist zwar beim gleichen Verfahren der längere Key 
sicherer. Aber beim Vergleich verschiedener Verfahren funktioniert das 
nicht mehr. So ist der "Sicherheitswert" eines Bits bei RSA in keiner 
Weise vergleichbar mit beispielsweise ECDH oder gar AES. Da können die 
bei RSA genannten 2048 Bits in anderen Verfahren 224 oder 112 Bits 
entsprechen.

Ein Vergleich von 2048 Bits bei RSA mit einem zufälligen Text aus 256 
Zeichen führt schon deshalb in die Irre.

: Bearbeitet durch User
Autor: Torsten Robitzki (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Marc V. schrieb:

>  Erstens ist das nicht extrem einfach und zweitens:

Doch, dein Verschieben der Schlüssel führt nur dazu, dass Du einen 
Gesammt-Schlüssellänge hast, die maximal dem kleinsten gemeinsamen 
Vielfachen beider Schlüssellängen entspricht. Die beiden Einzelschlüssel 
brauchst Du überhaupt nicht mehr, um andere, verschlüsselte Texte zu 
entschlüsseln.

>  Wenn du dir plain text besorgen kannst, *warum überhaupt nach*
>  Schlüssel suchen ?

Je nach dem, wo das Verschlüsselungsverfahren eingesetzt wird, gibt es 
Möglichkeiten, als Angreifer, entweder Teile dessen, was übertragen wird 
zu kennen (HTTP Header, C-Quellcode fängt meistens mit "#include" an, 
etc) oder es dem Verschlüsseler unter zu jubeln. Wenn es mir gelingt, 
Dir zu sagen, was Du verschlüsseln sollst und mir dann den 
verschlüsselten Text gibst, hast Du mir auch den Schlüssel gegeben. Das 
ist eine sehr große Schwäche in einem Verschlüsselungsverfahren und 
keiner würde ohne große Not so etwas einsetzen.

Details kannst Du Dir hier nachlesen: 
https://en.wikipedia.org/wiki/Known-plaintext_attack

Nochmal: Warum glaubst Du, dass Du schlauer bist, als alle anderen 
Kryptoexperten zusammen? Wenn Dein Verfahren keine Schwächen hätte, 
würde es verwendet werden.

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Anton schrieb:
> => was mich wundert ist, dass die Standardisierungsprozesse bei welchen
> die Kryptografien "durchnummeriert" werden, den sha256WithRSAEncryption,
> später einstufen als den RSASSA-PSS:

Ulkiges Kriterium. Die Geheimnisse der Nummerierung von Algorithmen sagt 
sehr wenig aus über deren Qualität. Patente bewertet man ja auch nicht 
nach der Nummer.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten R. schrieb:
> Dir zu sagen, was Du verschlüsseln sollst und mir dann den
> verschlüsselten Text gibst, hast Du mir auch den Schlüssel gegeben.

Verschlüsselungsverfahren sind in sehr unterschiedlichem Mass 
empfindlich gegenüber einer known plaintext attack. Während die Kenntnis 
bereits von Teilen des Klartextes bei der ollen Enigma sehr nützlich 
war, ist es bei AES für die Katz. Wie auch in dem von dir verlinkten 
Artikel steht.

Autor: Torsten Robitzki (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Torsten R. schrieb:
>> Dir zu sagen, was Du verschlüsseln sollst und mir dann den
>> verschlüsselten Text gibst, hast Du mir auch den Schlüssel gegeben.
>
> Verschlüsselungsverfahren sind in sehr unterschiedlichem Mass
> empfindlich gegenüber einer known plaintext attack. Während die Kenntnis
> bereits von Teilen des Klartextes bei der ollen Enigma sehr nützlich
> war, ist es bei AES für die Katz. Wie auch in dem von dir verlinkten
> Artikel steht.

Richtig und der "Vesely Park" Algorithmus ist sehr anfällig für known 
plaintext attack.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anton schrieb:
> gibt es irgendwo Informationen z.B. ein Ranking für solche Algorithmen?

Neben den Algorithmen selbst kann auch die Implementierung der 
Algorithmen eine wesentliche Rolle spielen. Und damit meine ich nicht 
Implementierungsfehler sondern side channel attacks: Die Möglichkeit, 
korrekt implementierte Algorithmen zu knacken, in dem man irgendwelche 
Nebeneffekte wie Details beim Stromverbrauch oder Zeitverhalten nutzt, 
um sich den Zugang zum Schlüssel zu erleichtern. Da kann der exakte 
innere Ablauf von Befehlssequenzen in modernen Prozessoren einem 
Nachbarprozess mehr Information vermitteln, als dem Anwender lieb ist.

https://en.wikipedia.org/wiki/Side-channel_attack

Autor: Peter M. (r2d3)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Hallo Marc,

Marc V. schrieb:
> 2048 bit ist gleichzusetzen mit einem Text von 256 Zeichen. Ein
>  einfaches XOR mit 32 beliebigen Zeichen über Sourcetext und den so
>  gewonnenen Text noch einmal mit 32 beliebigen Zeichen XOR-en - das
>  schafft kein Computer in Tausend Jahren.
>  Und wenn das zweite XOR nicht von Position 0 anfängt, sondern um eine
>  gewisse Anzahl Zeichen verschoben wird - unknackbar für immer.
>  Wahrscheinlich ginge es auch mit 16 Zeichen, was einer Schlüssellänge
>  von insgesammt 256 bit entspricht.
>
>  Aber komplizierte Algorithmen mit komplizierten Namen - das hört sich
>  schon mal nach unknackbar, auch wenn es nicht so ist...

das von Dir vorgeschlagene Verfahren nutzt einen unsicheren Modus:

https://de.wikipedia.org/wiki/Electronic_Code_Book_Mode

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Torsten R. schrieb:
> Richtig und der "Vesely Park" Algorithmus ist sehr anfällig für known
> plaintext attack.

> Möglichkeiten, als Angreifer, entweder Teile dessen, was übertragen wird
> zu kennen (HTTP Header, C-Quellcode fängt meistens mit "#include" an,
> etc) oder es dem Verschlüsseler unter zu jubeln.

 Manomanoman.

 Du verwechselt ständig einen Schlüssel mit fester Länge mit zwei
 Schlüsseln mit variabler Länge, wovon der zweite Schlüssel noch um
 etliche Stellen verschoben in schon einmal verschlüsseltem Text begint.

 Wieviele Versuche brauchst du für einen einzigen Schlüssel mit 512
 bit Länge ?

 Wieviele Versuche für 2 Schlüssel wenn jeder zwischen 64 und 448 bit
 lang sein kann ?

 Und wieviele Versuche wenn das alles noch um 1023 (Beispiel) bits
 verschoben werden kann ?

 Es gibt nicht mehr nur Blocks mit fester Länge und es gibt auch keine
 Regelmässigkeiten mehr, noch dazu ist alles ist um eine unbekannte
 Anzahl der bits verschoben.

 Somit gibt es auch keine häufigsten Buchstaben bzw. Buchstabengruppen
 mehr.

: Bearbeitet durch User
Autor: Torsten Robitzki (Firma: robitzki.de) (torstenrobitzki)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Marc V. schrieb:

>  Du verwechselt ständig einen Schlüssel mit fester Länge mit zwei
>  Schlüsseln mit variabler Länge, wovon der zweite Schlüssel noch um
>  etliche Stellen verschoben in schon einmal verschlüsseltem Text begint.

Nein, Du übersiehst den Punkt, dass deine zwei Schlüssel, durch einen, 
längeren Schlüssel ersetzt werden können:

Nehmen wir der Einfachheit halber mal zwei Schlüssel, der eine k1 2 Byte 
lang und der zweite k2 3 Byte lang (das gleiche Phänomen hast Du auch, 
wenn ein Schlüssel 8 Byte und der andere 56 Byte lang ist).

Dann verschlüsselst Du jedes Byte plaintext (px) mit den einzelnen Bytes 
der Schlüssel (k10-k11 und k20-k22):
p0  p1  p2  p3  p4  p5  p6
xor xor xor xor xor xor xor
k10 k11 k10 k11 k10 k11 k10
xor xor xor xor xor xor xor
k20 k21 k22 k20 k21 k22 k20
=   =   =   =   =   =   = 
c0  c1  c2  c3  c4  c5  c6

richtig?

Dann wird Dir auffallen, dass ab p6 deine Schlüssel-Bytes wieder 
gemeinsam anfangen. Hier können wir aus k10 xor k20 bis k11 xor k22 
einfach einen Schlüssel ks generieren, der genau so gut funktioniert, 
aber etwas länger erscheint:
p0  p1  p2  p3  p4  p5  p6
xor xor xor xor xor xor xor
k10 k11 k10 k11 k10 k11 k10
xor xor xor xor xor xor xor
k20 k21 k22 k20 k21 k22 k20
=   =   =   =   =   =   = 
p0  p1  p2  p3  p4  p5  p6
xor xor xor xor xor xor xor
ks0 ks1 ks2 ks3 ks4 ks5 ks0
=   =   =   =   =   =   = 
c0  c1  c2  c3  c4  c5  c6

Der gemeinsame Schlüssel, ist also maximal so lang, wie das kleinste 
gemeinsame Vielfache der Längen deiner beiden Schlüssel. Im Fall von 64 
und 448 wären es sogar nur 448. Jetzt machst Du also nichts anderes als 
ein one time pad, bei dem Du alle 448 bits den Schlüssel wieder 
verwendest.

>  Wieviele Versuche brauchst du für einen einzigen Schlüssel mit 512
>  bit Länge ?

Wenn ich ein 512 bit langes plaintext / cypthertext Paar habe, dann 
brauche ich genau einen Versuch. Du verwechselst xor mit einem 
funktionierenden Verschlüsselungsalgorithmus, wie AES.

Wenn ich einen kürzeres plaintext / cypthertext Paar habe, kann ich 
daraus immer noch einen Teil des Schlüssels extrahieren.

Wenn ich weder plaintext habe, noch cypthertext habe und der plaintext 
von der Länge her <= 512 bits ist, dann ist ein one time pad nicht 
knackbar.

>  Wieviele Versuche für 2 Schlüssel wenn jeder zwischen 64 und 448 bit
>  lang sein kann ?

Wenn ich z.B. annehmen kann, dass der plaintext, Text in deutscher 
Sprache ist und ich genügend cypher text habe, dann gehe ich in 
Schritten von der Gesamtschlüssellänge von 448 bit durch den cypher text 
und gucke mir die Verteilung an und vergleiche die ermittelte Verteilung 
mit der, der deutschen Sprache: Bei gleicher Verteilung habe ich mit 
hoher Wahrscheinlichkeit, das entsprechende plaintext byte gefunden und 
damit dann das entsprechende Byte im Schlüssel. Dass ganze wiederhole 
ich 448/8 mal.

>  Und wieviele Versuche wenn das alles noch um 1023 (Beispiel) bits
>  verschoben werden kann ?

Das änderst überhaupt nichts: die ersten 1023 bits werden halt mit einem 
one time pad verschlüsselt, bei dem sich der Schlüssel entsprechend der 
ersten Schlüssellänge wiederholt. Ich werfe die ersten 1023 bit cypher 
text weg und gehen, wie oben beschrieben vor. Die ersten 1023 bit 
entschlüsselt dann das erste Semester ;-)

Auch wenn Du zwei Schlüssellängen wählst, die als KGV das Produkt aus 
beiden Längen hat: der gesamte Schlüssel ist nicht mehr Zufällig und Du 
hast eine direkte Zuordnung von jedem bit des plaintext, über ein bit 
des Schlüssels zu exakt einem bit im cypher text.

>  Es gibt nicht mehr nur Blocks mit fester Länge und es gibt auch keine
>  Regelmässigkeiten mehr, noch dazu ist alles ist um eine unbekannte
>  Anzahl der bits verschoben.

Wie sollte das gehen? Die Schlüssel wiederholen sich irgend wann und 
damit werden sie auch immer eine gemeinsame Periode haben. Wenn es keine 
Regelmässigkeit gäbe, wäre auch der Empfänger nicht in der Lage, den 
cypher text zu entschlüsseln.

Vorschlag zur Güte. Du scheinst Dir ja sehr sicher zu sein, den Stein 
der Weisen gefunden zu haben: Implementiere Deinen Algorithmus doch mal 
in python, javascript oder ruby etc. Dann veröffentlichst Du das Skript 
und gibst einem Admin hier die beiden Schlüssel.

Der Admin prüft dann, dass man aus den beiden Schlüsseln nur mit der 
Kenntnis des Algorithmus und des cyphertexts auf den plaintext kommt und 
veröffentlicht einen 100kByte Text-Datei in deutscher Sprache und den 
cyphertext dazu.

Wenn es innerhalb einer Woche keiner schafft, den cypher text zu 
entschlüsseln, dann spende ich 100€ für einen guten Zweck.

Wenn es einer schafft, dann spendest Du die 100€ für einen guten Zweck.

Do we have deal mister Vesely?

Autor: Mathias (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Ich gehe davon aus, dass du (Marc 4) folgendes meinst:
2 feste Schlüssel, gegebener aber unterschiedlicher Länge. Dann ist die 
gefühlte Schlüssellänge tatsächlich größer, aber auch nur der KGV von 
den beiden Schlüssellängen. Wenn beide teilerfremd sind (z.B. Prim), 
multipliziert sich die gefühlte Schlüssellänge.

Weils so schön ist, hab ich das mal schnell in Javascript umgesetzt.

https://jsfiddle.net/wkf4e56p/4/

Es wird ein zufälliger "text" generiert, ist jetzt kein Text, hat aber 
ordentlich Bias (Zufallszahlen zwischen 0 und 64).
Es werden 2 Keys unterschiedlicher Länge produziert.
Dann wird alles ordentlich zusammen geXort. Der Graph ist die 
Häufigkeitsverteilung des Ciphertextes.

Der Bias ist immernoch heftig, auch wenn ich relativ lange und sehr 
teilerfremde Keys voreingestellt habe. Schwächend kommt leider hinzu, 
dass ich nur Byte-lange Keys erlaube, weil ich zu Faul war das auf 
Bitebene zu implementieren. Dafür sind die Keys deutlich länger als 
vorgeschlagen.

Das verschieben des zweiten Keys bringt nicht wirklich was. Im besten 
Fall werden die ersten n Bits mit nem eigenen Key verschlüsselt, weil da 
der zweite noch nicht greift. Wenn der zweite einfach um n-Bits 
geshiftet wird, dann bringt das genau 0.

In der realen Anwendung sieht man den Bias längst nicht so schön, wie 
hier, weil sich realer Text eben deutlich anders verhält als meine 
Zufallszahlen. Aber dennoch braucht man kein Bruteforce, sondern nur 
genug Ciphertext und eine Vermutung, wie der Bias aussieht.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Anton schrieb:
> ich weiß, Sicher geht nicht
Das Stimmt nicht. OTP ist sicher. Aber nur, wenn:
1) die Schluessellaenge mindestens der Klartextlaenge entspricht
2) der Schluessel nur ein einziges mal verwendet wird

Ist Punkt 1 nicht erfuellt, fuehrt das automatisch dazu, das der 
Schluessel mehrfach verwendet wird. Dann sogar innerhalb derselben 
Nachricht. Damit ist Punkt 2 auch nicht mehr einzuhalten.

Das aber nur als Anmerkung zu "Sicher geht nicht".

Wenn ihr qualifizierte Aussagen zu der Sicherheit von 
Verschluesselungsalgorithmen haben wollt, dann wendet euch einfach an 
Prof. Chris­tof Paar, von der Ruhr-Universitaet Bochum.
https://www.emsec.rub.de/chair/_staff/christof-paar/

Autor: jz23 (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Anton schrieb:
>> ich weiß, Sicher geht nicht
> Das Stimmt nicht. OTP ist sicher.

Und Quantenverschlüsselung ebenfalls. Zumindest solange die 
Heisenbergsche Unschärferelation nicht widerlegt ist.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jz23 schrieb:
> Und Quantenverschlüsselung ebenfalls. Zumindest solange die
> Heisenbergsche Unschärferelation nicht widerlegt ist.
Und damit moechtest du was sagen?

Autor: Horst (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Wirklich sicher war nur KRYPTO mit der Vollbitverschlüsselung vom 
Kryptochef. Das war so sicher, dass er seine Webseite auf Druck von 
Geheimdiensten vom Netz nehmen musste. Anschließend ist er 
untergetaucht. Die Geheimdienste suchen ihn immer noch (oder haben ihn 
schon?).

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Kaj G. schrieb:
>> Und Quantenverschlüsselung ebenfalls. Zumindest solange die
>> Heisenbergsche Unschärferelation nicht widerlegt ist.
> Und damit moechtest du was sagen?

Gleich kommt Kurt. ;-)

Autor: Daniel H. (Firma: keine) (commander)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Anton schrieb:
> http://oid-info.com/get/1.2.840.113549.1.1.11 <- hier die Endnummer 11
> http://oid-info.com/get/1.2.840.113549.1.1.10 <- hier die Endnummer 10

Das sind lediglich nach PKCS#1 (nichts anderes steckt hinter 
1.2.840.113549.1.1) standardisierte IDs. Warum die so gewählt wurden, 
musst du die RSA Laboratories fragen. Die "Höhe" der OID gibt jedoch 
keinerlei Auskunft darüber, wie sicher der dahinter stehende Algorithmus 
ist.

Marc V. schrieb:
> 2048 bit ist gleichzusetzen mit einem Text von 256 Zeichen. Ein
>  einfaches XOR mit 32 beliebigen Zeichen über Sourcetext und den so
>  gewonnenen Text noch einmal mit 32 beliebigen Zeichen XOR-en - das
>  schafft kein Computer in Tausend Jahren.

Nein, das ist falsch. Bei den beschriebenen RSA-basierten Verfahren sind 
2048 Bit eher mit einem symmetrischen 112 Bit Schlüssel (= 14 Zeichen) 
gleichzusetzen. Hintergrund ist, dass der Schlüssel (oder genauer: das 
Schlüsselpaar) nur aus Primzahlen gebildet werden kann, was den gesamten 
Schlüsselraum stark einschränkt, deswegen müssen RSA-Schlüssel deutlich 
länger sein.

Was du beschreibst ist zweifacher OTP mit zwei verschiedenen, 
symmetrischen 2048 Bit Schlüsseln. Dieses System bietet dir aber keine 
der Eigenschaften, die dir ein asymmetrisches Verfahren bietet. Da 
Empfänger und Sender den gleichen Schlüssel benötigen, kann z.B. der 
Empfänger auch Nachrichten im Namen des Senders fälschen. Schließlich 
bleibt das Problem der Schlüsselverwaltung, da OTP nur als sicher zu 
betrachten ist, wenn ein einmal verwendeter Schlüssel nicht 
wiederverwendet wird. Willst du also Datenmenge N verschlüsseln, dann 
musst du auch die gleiche Menge an zufälligem Schlüsselmaterial erzeugen 
und a) sicher zwischen Empfänger und Sender austauschen und b) 
speichern. Im von dir vorgeschlagenen Verfahren musst du sogar die 
doppelte Menge an Schlüsselmaterial vorhalten, ohne dass dir die zweite 
OTP-Rund irgendeine zusätzliche Sicherheit bietet. Im Gegenteil, es 
könnte sogar sein, dass du durch die zweite Runde die Sicherheit sogar 
schwächst.

>  Und wenn das zweite XOR nicht von Position 0 anfängt, sondern um eine
>  gewisse Anzahl Zeichen verschoben wird - unknackbar für immer.
>  Wahrscheinlich ginge es auch mit 16 Zeichen, was einer Schlüssellänge
>  von insgesammt 256 bit entspricht.

Vollkommen unerheblich, aufgrund des Aufwandes für das 
Schlüsselmanagement ist der Ansatz im täglichen Leben nicht praktikabel. 
Du kannst gerne auch noch 20 mal verschieben und XORen, du gewinnst 
nichts, musst aber immer mehr Rechenzeit investieren.

>  Aber komplizierte Algorithmen mit komplizierten Namen - das hört sich
>  schon mal nach unknackbar, auch wenn es nicht so ist...

Das ist dann ein Problem aufseiten des Lesers/Zuhörers, insbesondere 
wenn er sich nicht weiter informiert bzw. nicht weiter informieren will 
(oder der Meinung ist, dass sein selbst ausgedachtes System viel besser 
ist).

Als unknackbar wird in der Kryptographie nichts betrachtet. Es gibt 
lediglich Verfahren, die nach aktuellem Wissensstand kryptographisch 
sicher sind, sich also mit vertretbarem Aufwand nicht in absehbarer Zeit 
brechen lassen. Ein Verfahren, das heute noch als sicher gilt, kann 
morgen schon gebrochen sein. Beispiele dafür gibt es zur Genüge, z.B. 
MD5, SHA-1, DES, viele weitere High-Level-Protokolle wie z.B. WEP, WPA2, 
A5/1, A5/2, SS7 etc.

: Bearbeitet durch User
Autor: jz23 (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Kaj G. schrieb:
> jz23 schrieb:
>> Und Quantenverschlüsselung ebenfalls. Zumindest solange die
>> Heisenbergsche Unschärferelation nicht widerlegt ist.
> Und damit moechtest du was sagen?

Der TO fragte oben nach Verschlüsselungsalgorithmen und wie sicher die 
sind. Quantenkryptographie ist zwar nicht direkt ein Algorithmus aber 
trotzdem eine Verschlüsselung und zwar eine aktuell unknackbare.

Autor: malsehen (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Horst schrieb:
> Wirklich sicher war nur KRYPTO mit der Vollbitverschlüsselung vom
> Kryptochef.

Mir fehlten die Worte,
Kryptochef!!!

Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ist ja spannend geworden :)

anbei für die entschlüsselungsexporten :)

RSA Verschlüsselt
> ;212170374;196004503;394095273;623762517;120405286;372248707;310428316

gesucht ist ein WORT mit 7 Buchstaben :)  <- muss ja GAAAAANZ EINFACH 
SEIN ;=)

so, jetzt zurück zum "ernsten" Thema.

@A.K. ja, das war mir auch klar, dass die "Nummer" nicht was über die 
Qualität aussage,... aber es könnte ja sein, dass man davon ausgehen 
kann, dass das (Fiktive Zahlen) 2015ner verfahren BESSER ist als das 
2006er verfahren!?
<- aber während hier viele versuchen meinen Schlüssel zu knacken waren 
auch ein paar Konstruktive Inhalte dabei...

noch ein paar Fragen... hat mein Verschlüsselungsalgorithmus bzw. mein 
Signaturalgorithmus was mit dem Zertifikat zu tun?
=> okay soweit ich weiß ist die Schlüssellänge im Zertifikat ... d.h. 
wenn ich ein Zertifikat mit 2048 Bit Schlüssellänge habe kann ich nicht 
mit einer Schlüssellänge von 4096 Verschlüsseln...

Aber ob ich nun RSA oder AES oder PSS, Elyptisch oder sonst wie 
Verschlüssle definiert mein Program <- oder gibt es Einschränkungen wo 
man sagt, mit dem Zertifikat kann man nur "Kacke" verschlüsseln!?
=> PS. wir und viele Marktpartner verwenden die BouncyCastle Library

@jz23 <- nun gut, es sollte Realisierbar sein... wir Sprechen hier von 
einen Markt mit ein paar tausend Marktparntern, teilweise Großkonzerne, 
teilweise 3 Mann-Firmen d.h. ich geh davon aus dass etliche sich auf 
eine Simple Dienstleistung von einem Provider einlassen... 
Quantenkryptografie ist jetzt noch ein wenig schwer herzubekommen und 
noch schwerer handzuhaben :) <- aber lustige Idee

Grundsätzlich gehts hier auch nur um die Bewertung der Verschlüsselung 
für den Übertragungsweg, wie sicher die Systeme am ende sind kann und 
will ich hier nicht beurteilen <- Frech gesagt geht das an meiner 
Aufgabe vorbei :P (Aber ja, richtig, es bringt nix, die geilste 
Alarmanlage zu haben, wenn das Cabrio dann offen herumsteht)

1000 Dank erstmal an alle :)

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Anton schrieb:
> aber es könnte ja sein, dass man davon ausgehen
> kann, dass das (Fiktive Zahlen) 2015ner verfahren BESSER ist als das
> 2006er verfahren!?

Andersrum: Ein altes Verfahren, das den Test der Zeit überlebt hat und 
heute immer noch als sicher gilt, würde ich einem taufrischen und wenig 
erprobten Verfahren vorziehen.

Nur würde ich bei der Altersbestimmung nicht nach der Nummerierung des 
Verfahrens gehen, sondern nach der Nummerierung des Jahres der 
Veröffentlichung. Das muss sich nicht decken.

: Bearbeitet durch User
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
A. K. schrieb:
> Kaj G. schrieb:
>>> Und Quantenverschlüsselung ebenfalls. Zumindest solange die
>>> Heisenbergsche Unschärferelation nicht widerlegt ist.
>> Und damit moechtest du was sagen?
>
> Gleich kommt Kurt. ;-)
Ohne Helm und ohne Gurt? :P

Autor: Arc Net (arc)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Anton schrieb:
> noch ein paar Fragen... hat mein Verschlüsselungsalgorithmus bzw. mein
> Signaturalgorithmus was mit dem Zertifikat zu tun?
> => okay soweit ich weiß ist die Schlüssellänge im Zertifikat ... d.h.
> wenn ich ein Zertifikat mit 2048 Bit Schlüssellänge habe kann ich nicht
> mit einer Schlüssellänge von 4096 Verschlüsseln...

Natürlich geht das. Wobei erst mal die Frage ist, um was es eigentlich 
genau geht? Sicherstellen, dass die Daten vom Urheber kommen und 
unverändert sind und/oder ob sie auch sicher verschlüsselt von A nach B 
kommen.
Zurück zur Schlüssellänge:
Beispiel: PGP, Sender erzeugt zufälligen Key, verschlüsselt (bspw. RSA 
4096) diesen mit dem öffentlichen Schlüssel des Empfängers, 
verschlüsselt die Nachricht (bspw. AES-256) mit dem zufälligen Key und 
(erzeugt aus den unverschlüsselten Daten eine Signatur) und schickt 
alles an den Empfänger.

jz23 schrieb:
> Kaj G. schrieb:
>> Anton schrieb:
>>> ich weiß, Sicher geht nicht
>> Das Stimmt nicht. OTP ist sicher.
>
> Und Quantenverschlüsselung ebenfalls. Zumindest solange die
> Heisenbergsche Unschärferelation nicht widerlegt ist.

OTP = One Time Pad = das einzige Verfahren, das beweisbar sicher ist und 
dessen Sicherheit nicht auf Vermutungen basiert wie
RSA = Faktorisierung von Primzahlen ist schwer (bis es Quantencomputer 
gibt) oder z.B.
ECC = Eliptic Curve Cryptography = Diskreter Logarithmus ist schwer zu 
finden (bis es Quantencomputer gibt)
oder Quantenverschlüsselung (No-Cloning Theorem).
Problem bei OTP: Schlüssel darf nur ein einziges Mal verwendet werden 
1), Schlüssellänge >= Nachrichtenlänge, muss absolut zufällig sein und 
dann auch noch sicher zu allen Empfängern kommen... da würde dann ein 
Quantenschlüsselaustauschverfahren helfen...

1) schönes Beispiel mit Bildern: 
https://crypto.stackexchange.com/questions/59/taki...

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Arc N. schrieb:
> 1), Schlüssellänge >= Nachrichtenlänge, muss absolut zufällig sein und
> dann auch noch sicher zu allen Empfängern kommen... da würde dann ein
> Quantenschlüsselaustauschverfahren helfen...

Wenn du schon eine sichere Übertragungsstrecke für einen Schlüssel 
baust, der mindestens so lang ist wie die zu übertragenen Daten, kannst 
du da auch gleich die Daten übertragen an Stelle des Schlüssels. ;-)

Abgesehen davon, dass es nicht immer ganz einfach ist, an einen völlig 
zufälligen OTP Schlüssel zu kommen, und das beweisbar dauerhaft. Das ist 
nämlich der Knackpunkt bei diesem ach so beweisbar sicheren Verfahren.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Arc N. schrieb:
>> 1), Schlüssellänge >= Nachrichtenlänge, muss absolut zufällig sein und
>> dann auch noch sicher zu allen Empfängern kommen... da würde dann ein
>> Quantenschlüsselaustauschverfahren helfen...
>
> Wenn du schon eine sichere Übertragungsstrecke für einen Schlüssel
> baust, der mindestens so lang ist wie die zu übertragenen Daten, kannst
> du da auch gleich die Daten übertragen an Stelle des Schlüssels. ;-)

https://en.wikipedia.org/wiki/Quantum_key_distribution

> Abgesehen davon, dass es nicht immer ganz einfach ist, an einen völlig
> zufälligen OTP Schlüssel zu kommen, und das beweisbar dauerhaft. Das ist
> nämlich der Knackpunkt bei diesem ach so beweisbar sicheren Verfahren.

Naja, dass ist das übliche Problem bei allen Verfahren: Theoretisch 
sicher heißt nicht automatisch, dass auch die Implementierungen sicher 
sind. Gab's oben schon mal mit RSA, PKCS und dem Bleichenbacher-Angriff 
http://archiv.infsec.ethz.ch/education/fs08/secsem...
Und von den div. Seitenkanälen haben wir noch gar nicht angefangen ;)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc N. schrieb:
> Und von den div. Seitenkanälen haben wir noch gar nicht angefangen ;)

Doch. ;-)

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Daniel H. schrieb:
> speichern. Im von dir vorgeschlagenen Verfahren musst du sogar die
> doppelte Menge an Schlüsselmaterial vorhalten,

 Menge an Schlüsselmaterial ist unerheblich - ob 64 Zeichen oder 256
 Zeichen, macht ja keinen Unterschied - man muss es sich nicht merken
 und ob Klartext einmal oder zweimal verschlüsselt wird, macht kaum
 einen merkbaren Unterschied - es kann sich nicht einmal um ms handeln.

> ohne dass dir die zweite
> OTP-Rund irgendeine zusätzliche Sicherheit bietet. Im Gegenteil, es
> könnte sogar sein, dass du durch die zweite Runde die Sicherheit sogar
> schwächst.

 Die Zweite Runde dient dazu, um zu verhindern, dass durch ausprobieren
 gleich Klartext rauskommt (Brute-Force-Attack). Durch variable Länge
 der beiden Schlüssel wird zusätzliche Sicherheit geboten.


> Du kannst gerne auch noch 20 mal verschieben und XORen, du gewinnst
> nichts, musst aber immer mehr Rechenzeit investieren.

 Verschieben ist dazu da, um Blöcke mit Schlüssellänge zu verhindern
 oder zumindest die erkennung von diesen zu erschweren.
 Und Rechenzeit ist kein Argument - 2 Mal XOR-en, 1 Mal verschieben...

Daniel H. schrieb:
> Das ist dann ein Problem aufseiten des Lesers/Zuhörers, insbesondere
> wenn er sich nicht weiter informiert bzw. nicht weiter informieren will
> (oder der Meinung ist, dass sein selbst ausgedachtes System viel besser
> ist).

 Selbstverständlich bin ich nicht der Meinung, dass das viel besser ist.
 Es war nur eine Idee und da ich kein Experte in Kryptographie bin, kann
 ich dies nicht einmal mathematisch belegen.

 Die ganzen aufgeführten Probleme mit Schlüsseln sind natürlich wahr.
 Aber das gilt für alle Schlüssel.


 P.S.
 Und ich glaube immer noch, dass ein Text der auf diese Art
 verschlüsselt wird, in absehbarer Zeit nicht zu knacken ist.

: Bearbeitet durch User
Autor: Anton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wobei erst mal die Frage ist, um was es eigentlich genau geht?

SORRY,... mein Fehler.

Es geht um praktikable Emailübertragung von "undefinierten" Systemen 
(wobei natürlich Systeme [z.B. mangels unterstützung] ausgeschlossen 
werden können). Die Emails sind in 99% aller Fälle Automatisch 
generierte Emails in welcher Maschinenlesbare Daten enthalten sind 
(Stichwort EDIFACT <- hier aber erstmal egal).

Selbstverständlich MUSS dabei der Content verschlüsselt werden UND die 
Signatur validierbar sein. Das heißt, den Inhalt vor Veränderung 
schützen UND den Sender zu Identifizieren <- den Inhalt davor zu 
Schützen, dass er von anderen "lesbar" ist, ist in diesem fall sogar 
eher "Sekundär" (aber ich geh davon aus, wenn man den Inhalt lesen kann, 
kann man ihn auch verändern)...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anton schrieb:
> (aber ich geh davon aus, wenn man den Inhalt lesen kann,
> kann man ihn auch verändern)...

PKI Signaturverfahren haben genau den einen Sinn, Veränderungen lesbarer 
Mails erkennbar zu machen.

Autor: Hugo (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Marc V. schrieb:
> Die ganzen aufgeführten Probleme mit Schlüsseln sind natürlich wahr.
>  Aber das gilt für alle Schlüssel.

Grundfalsch!
Scheinbar kennst du nicht den Unterschied zwischen symmetrischen und 
asymmetrischen Schlüsseln?

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Anton schrieb:
> Es geht um praktikable Emailübertragung von "undefinierten" Systemen

Was spricht aus deiner Sicht gegen die bereits verbreiteten Verfahren 
für verschlüsselte Mails? Also PGP und S/MIME?

Ebenso ist es problemlos möglich, die übliche Technik zur 
Mailübertragung (SMTP) mit Verschlüsselung der Übertragung und strenger 
Verifikation von Zertifikaten zu betreiben. Die Technik ist längst da, 
wird aber im üblichen Internet-Mailverkehr tolerant gegenüber beliebigen 
Zertifikaten betrieben.

: Bearbeitet durch User
Autor: Schreiber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wenn du schon eine sichere Übertragungsstrecke für einen Schlüssel
> baust, der mindestens so lang ist wie die zu übertragenen Daten, kannst
> du da auch gleich die Daten übertragen an Stelle des Schlüssels. ;-)
Nein, man kann auch unterschiedliche Übertragungswege nutzen. Etwa einen 
Kurier für den Schlüsseln und das Telefon für die verschlüsselte 
Nachricht


> Abgesehen davon, dass es nicht immer ganz einfach ist, an einen völlig
> zufälligen OTP Schlüssel zu kommen, und das beweisbar dauerhaft. Das ist
> nämlich der Knackpunkt bei diesem ach so beweisbar sicheren Verfahren.
Da gabs früher schon passende Lösungen für. Etwa einen 
Geigerzählerzusatz für den Lochstreifenlocher...
Die beiden Schlüssellochstreifen mussten sofort nach Verwendung 
verbrannt werden.

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Marc Vesely
Ich würde sagen, deine Konstruktion ist nicht sooo schlecht, wie hier 
geschrieben. Sie ist auf keinen Fall sicher in irgendeinem 
Cryptographischen Sinne, aber so für Crypte eines Laien schon nicht 
schlecht. Auf jeden Fall besser, als einiges was ich gesehen habe, womit 
Geschäftsgeheimnisse geschützt werden. Dennoch: Ich würde nie behaupten, 
das ist ein sicheres Verfahren. Alles was man braucht, ist hinreichend 
viele verschlüsselte Daten. Aber es wird auch immer der gleiche 
Keystream gebildet, das heißt gleiche Nachrichten verschlüsseln zum 
gleichen Crypto text. Kann man auch wieder irgendwie umgehen, klar, 
abe4r wirklich sicher wird sowas nie werden.

@Anton
Wenn es nicht gute Gründe dagegen gibt, dann auf jeden Fall GPG oder 
S/MIME nutzen. Wie schon geschrieben, es gibt auch nur signiert ohne 
Verschlüsselung. Die Nachricht kann dann natürlich verändert werden, 
aber dann stimmt die Signatur nicht mehr.
S/Mime hat nen Vorteil, wenn du öfters mal Maschinen hinzufügst und du 
nicht allen den neuen Key mitteilen willst. Bei S/MIME kann man die Keys 
in einer Hierarchie aufbauen. Der Root Key signiert deine Client Keys. 
Jeder der den Root PubKey vertraut, vertraut auch allen Client Keys. 
Dann muss man nicht allen Clients alle nötigen Keys mitgeben, dennoch 
weiß jeder genau wem er vertrauen kann. Zertifikate kann man von 
anerkannten CAs signieren lassen, für dich wäre aber wohl sinnvoller 
deine eigen CA zu erstellen und allen anderen das Vertrauen zu 
entziehen.
PGP/GPG ist dagegen für kleinere oder statische Setups vielleicht 
einfacher aufzubauen. Jeder Teilnehmer bekommt einfach alle relevanten 
Keys mit ausgeliefert und dann muss man sich nicht ums Zertifikate 
Signieren kümmern.

Autor: Mathias (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
@A. K.
Per Quanten Key-Exchange lassen sich witzigerweise keine Nachrichten 
übertragen. Es braucht selbst für den Key-Exchange noch einen 
klassischen (unsicheren) Kanal.


@Schreiber (Gast)
Ein Kurier ist aber kein Beweisbar sicherer Übertragungsweg, damit ist 
die Beweisbare Sicherheit des OTPs total dahin.
Dann lieber klassische Pubkey Krypto. Auch wenn die ihre eigenen 
Probleme hat, siehe Infineon gerade.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mathias schrieb:
> @Marc Vesely
> Ich würde sagen, deine Konstruktion ist nicht sooo schlecht, wie hier
> geschrieben. Sie ist auf keinen Fall sicher in irgendeinem
> Cryptographischen Sinne, aber so für Crypte eines Laien schon nicht
> schlecht. Auf jeden Fall besser, als einiges was ich gesehen habe, womit
> Geschäftsgeheimnisse geschützt werden. Dennoch: Ich würde nie behaupten,
> das ist ein sicheres Verfahren. Alles was man braucht, ist hinreichend
> viele verschlüsselte Daten. Aber es wird auch immer der gleiche
> Keystream gebildet, das heißt gleiche Nachrichten verschlüsseln zum
> gleichen Crypto text. Kann man auch wieder irgendwie umgehen, klar,
> abe4r wirklich sicher wird sowas nie werden.

Die Idee von oben war
"2048 bit ist gleichzusetzen mit einem Text von 256 Zeichen. Ein
 einfaches XOR mit 32 beliebigen Zeichen über Sourcetext und den so
 gewonnenen Text noch einmal mit 32 beliebigen Zeichen XOR-en - das
 schafft kein Computer in Tausend Jahren.
 Und wenn das zweite XOR nicht von Position 0 anfängt, sondern um eine
 gewisse Anzahl Zeichen verschoben wird - unknackbar für immer.
 Wahrscheinlich ginge es auch mit 16 Zeichen, was einer Schlüssellänge
 von insgesammt 256 bit entspricht."

Als Beispiel mit der Annahme, dass ein Angreifender c1 und c2 (s.u.) 
abfangen/mitlesen kann
k1 = Key 1, k2 = Key 2 
p1 = plain text 1, p2 = plain text 2
c1 = cipher text 1, c2 = cipher text 2

|k1] = |k2| = 4
|p1| = |p2| = 16
offset = 2

c1[0] = p1[0] ^ k1[0]
c1[1] = p1[1] ^ k1[1]
c1[2] = p1[2] ^ k1[2] ^ k2[0]
c1[3] = p1[3] ^ k1[3] ^ k2[1]
c1[4] = p1[4] ^ k1[0] ^ k2[2]
c1[5] = p1[5] ^ k1[1] ^ k2[3]
c1[6] = p1[6] ^ k1[2] ^ k2[0]
c1[7] = p1[7] ^ k1[3] ^ k2[1]
c1[8] = p1[8] ^ k1[0] ^ k2[2]
c1[9] = p1[9] ^ k1[1] ^ k2[3]
c1[a] = p1[a] ^ k1[2] ^ k2[0]
c1[b] = p1[b] ^ k1[3] ^ k2[1]
c1[c] = p1[c] ^ k1[0] ^ k2[2]
c1[d] = p1[d] ^ k1[1] ^ k2[3]
c1[e] = p1[e] ^ k1[2] ^ k2[0]
c1[f] = p1[f] ^ k1[3] ^ k2[1]
      
c2[0] = p2[0] ^ k1[0]
c2[1] = p2[1] ^ k1[1]
c2[2] = p2[2] ^ k1[2] ^ k2[0]
c2[3] = p2[3] ^ k1[3] ^ k2[1]
c2[4] = p2[4] ^ k1[0] ^ k2[2]
c2[5] = p2[5] ^ k1[1] ^ k2[3]
c2[6] = p2[6] ^ k1[2] ^ k2[0]
c2[7] = p2[7] ^ k1[3] ^ k2[1]
c2[8] = p2[8] ^ k1[0] ^ k2[2]
c2[9] = p2[9] ^ k1[1] ^ k2[3]
c2[a] = p2[a] ^ k1[2] ^ k2[0]
c2[b] = p2[b] ^ k1[3] ^ k2[1]
c2[c] = p2[c] ^ k1[0] ^ k2[2]
c2[d] = p2[d] ^ k1[1] ^ k2[3]
c2[e] = p2[e] ^ k1[2] ^ k2[0]
c2[f] = p2[f] ^ k1[3] ^ k2[1]

OTP Key Reuse first step:
n[0] = c1[0] ^ c2[0] = p1[0] ^ k1[0]         ^ p2[0] ^ k1[0]         = p1[0] ^ p2[0]
n[1] = c1[1] ^ c2[1] = p1[1] ^ k1[1]         ^ p2[1] ^ k1[1]         = p1[1] ^ p2[1]
n[2] = c1[2] ^ c2[2] = p1[2] ^ k1[2] ^ k2[0] ^ p2[2] ^ k1[2] ^ k2[0] = p1[2] ^ p2[2]
n[3] = c1[3] ^ c2[3] = p1[3] ^ k1[3] ^ k2[1] ^ p2[3] ^ k1[3] ^ k2[1] = p1[3] ^ p2[3]
n[4] = c1[4] ^ c2[4] = p1[4] ^ k1[0] ^ k2[2] ^ p2[4] ^ k1[0] ^ k2[2] = p1[4] ^ p2[4]
n[5] = c1[5] ^ c2[5] = p1[5] ^ k1[1] ^ k2[3] ^ p2[5] ^ k1[1] ^ k2[3] = p1[5] ^ p2[5]


Was man schön sehen kann, ist, dass sich 1. ein Schlüssel wiederholt
k1[2] ^ k2[0]
k1[3] ^ k2[1]
k1[0] ^ k2[2]
k1[1] ^ k2[3]
und 2. mit derselben Schlüssellänge wie im Fall ohne zusätzliche "Runde" 
und, mit etwas genauerem Hinschauen, dass man bei genügend großer 
verschlüsselter Nachricht nur eine Nachricht braucht für das was folgt:
https://crypto.stackexchange.com/questions/2249/ho...
und
https://crypto.stackexchange.com/questions/33376/w...

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Mathias schrieb:
> Ein Kurier ist aber kein Beweisbar sicherer Übertragungsweg, damit ist
> die Beweisbare Sicherheit des OTPs total dahin.
Sorry, aber das ist unfug! Denn nach deiner Logik ist auch AES total 
unsicher, weil man den Schluessel ja erstmal sicher uebertragen muss.

Hier muss unterschieden werden zwischen:
- Verschluesselung
- Schluesselaustausch

Das sind naemlich 2 verschiedene paar Schuhe.

OTP ist sicher. Warum das so ist, da kommt man sehr leicht von alleine 
drauf, wenn man sich OTP laenger als 2 Minuten anschaut. Den Schluessel 
sicher zu uebertragen ist ein voellig anderes Problem und schwaecht die 
Sicherheit von OTP in keinster Weise.

https://de.wikipedia.org/wiki/One-Time-Pad#Sicherheit

Natuerlich muss der Schluessel geheim bleiben, wie bei allen anderen 
Verfahren auch. Auch Public-Key-Verfahren sind nur solange sicher, wie 
der private Schluessel geheim bleibt.

Und um einen Schluessel sicher zu uebertragen gibt es den DHKE:
https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%...

Einige hier anwesenden sollten doch mal in einem Hoersaal der RUB Platz 
nehmen und die Krypto-Vorlesungen besuchen.
Wem das zu aufwaendig ist, die Vorlesungen gibt es auch auf Youtube:

Youtube-Video "Lecture 3: Stream Ciphers, Random Numbers and the One Time Pad by Christof Paar"
Youtube-Video "Lecture 13: Diffie-Hellman Key Exchange and the Discrete Log Problem by Christof Paar"
Youtube-Video "Lecture 14: The Generalized Discrete Log Problem and the Security of Diffie-Hellman by Christof Paar"
Youtube-Video "Lecture 22: MAC (Message Authentication Codes) and HMAC by Christof Paar"

: Bearbeitet durch User
Autor: Daniel H. (Firma: keine) (commander)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Und um einen Schluessel sicher zu uebertragen gibt es den DHKE:
> https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%...

Der aber wiederum, strikt nach Lehrbuch implementiert, anfällig für 
Man-in-the-Middle-Angriffe ist, wodurch eine weitere 
Autentifizierungsschicht benötigt wird. Egal wie man es dreht und 
wendet, am Ende kommt man immer an dem Punkt aus, dass initial ein 
vertraulicher Datenaustausch zwischen zwei Kommunikationspartner 
stattfinden muss.

: Bearbeitet durch User
Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Arc N. schrieb:
> |k1] = |k2| = 4
> |p1| = |p2| = 16
> offset = 2

 Nicht ganz.
 Bei gleicher Länge und Offset aber mit Schlüssel:
 k1 =  7
 k2 = 11

 c1[0] = p1[0] ^ k1[0] ^ k2[3]
 c1[1] = p1[1] ^ k1[1] ^ k2[4]
 c1[2] = p1[2] ^ k1[2] ^ k2[0]
 c1[3] = p1[3] ^ k1[3] ^ k2[1]
 c1[4] = p1[4] ^ k1[4] ^ k2[2]
 c1[5] = p1[5] ^ k1[5] ^ k2[3]
 c1[6] = p1[6] ^ k1[6] ^ k2[4]
 c1[7] = p1[7] ^ k1[0] ^ k2[5]
 c1[8] = p1[8] ^ k1[1] ^ k2[6]
 c1[9] = p1[9] ^ k1[2] ^ k2[7]
 c1[a] = p1[a] ^ k1[3] ^ k2[8]
 c1[b] = p1[b] ^ k1[4] ^ k2[9]
 c1[c] = p1[c] ^ k1[5] ^ k2[10]
 c1[d] = p1[d] ^ k1[6] ^ k2[0]
 c1[e] = p1[e] ^ k1[0] ^ k2[1]
 c1[f] = p1[f] ^ k1[1] ^ k2[2]

 Sieht das ein bißchen anders aus, oder ?.

Autor: Patrick J. (ho-bit-hun-ter)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hi

Und/Oder man verwendet zwei/mehrere Verbindungen, Die nur zusammen 'ein 
Bild' ergeben.
Dann müssen schon zwei 'Man in the middle' drin sein und Die müssen auch 
noch 'miteinander wollen'.

MfG

Autor: Arc Net (arc)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Marc V. schrieb:
> Arc N. schrieb:
>> |k1] = |k2| = 4
>> |p1| = |p2| = 16
>> offset = 2
>
>  Nicht ganz.
>  Bei gleicher Länge und Offset aber mit Schlüssel:
>  k1 =  7
>  k2 = 11
> ...
>  Sieht das ein bißchen anders aus, oder ?.

Sieht anders aus, ja. Es wiederholt sich erst nach kgv(7,11) = 77...
Ändert aber am Prinzip nichts: Sind zwei Nachrichten 
abgefangen/mitgehört ist c1[x] ^ c2[x] = p1[x] ^ p2[x] bzw. bei einer 
Nachricht c1[x] ^ c1[x + 77] = p1[x] ^ p1[x + 77]. Der/die Schlüssel 
fällt/fallen raus

Autor: Mathias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc N. schrieb:
> Sieht anders aus, ja. Es wiederholt sich erst nach kgv(7,11) = 77...

Im Prinzip war das aber auch schon seine Aussage: Wenn man zwei 
Schlüssel unterschiedlicher Länge nimmt, dann erhöht sich die 
Sicherheit. 2x mit 256 Bit Schlüssel Xoren bringt nix zusätzlich. Aber 
1x mit 255 und 1x mit 257 macht die Sache schon schwieriger. Klar ist 
immernoch einfaches Xor und ich behaupte mal, wenn man sich das genauer 
anguckt ist die resultierende Schlüsselkomplexität nicht 65535 
bit(255*257) sondern eher in der Nähe der Summe. Aber ich glaube nicht, 
das der besagte Informatik Student das mit 100kb Text knacken kann.

Kaj G. schrieb:
> Hier muss unterschieden werden zwischen:
> - Verschluesselung
> - Schluesselaustausch

Muss man? Ich guck mir immer das Gesamtpaket an. Klar ist ein OTP 
sicher, wenn man den Schlüsseltausch ignoriert. Dafür ist der 
Schlüsseltausch alles andere als Trivial. Nen ECC-Key kann man sich 
vorlesen oder per QR code Scannen. Der Private Key landet im Hardware 
Keystore und schwirrt nie im Ram rum, wo er geklaut werden kann. Mir ist 
klar, das auch solche Module Fehler/Backdoors haben können. Das sind 
dennoch Vorteile, die in realen Situationen deutlich wichtiger sind als 
der Theoretische Vorteil der OTPs.

Ich stell mir gerade vor, Estland verteilt an ihre Bürger Ausweise mit 
16GB OTP, weil alles andere ja nicht sicher ist... Mir fallen wenige 
Anwendungen ein, wo der Schlüsselaustausch per Kurier praktikabel ist.

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Arc N. schrieb:
> Sieht anders aus, ja. Es wiederholt sich erst nach kgv(7,11) = 77...
> Ändert aber am Prinzip nichts: Sind zwei Nachrichten
> abgefangen/mitgehört ist c1[x] ^ c2[x] = p1[x] ^ p2[x] bzw. bei einer

 LOL.
 Ganz so einfach ist es nicht. Verschlüsselte Nachricht abfangen/
 mithören ist nicht gleichzusetzen mit ursprünglicher Nachricht in
 Klartext abfangen/mithören/besitzen.

> Nachricht c1[x] ^ c1[x + 77] = p1[x] ^ p1[x + 77]. Der/die Schlüssel
> fällt/fallen raus

 Es wiederholt sich immer nach len(k1) * len(k2) nur - wer weiss wie
 lang k1 und wie lang k2 ist ?

: Bearbeitet durch User
Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Arc N. schrieb:
>> Sieht anders aus, ja. Es wiederholt sich erst nach kgv(7,11) = 77...
>> Ändert aber am Prinzip nichts: Sind zwei Nachrichten
>> abgefangen/mitgehört ist c1[x] ^ c2[x] = p1[x] ^ p2[x] bzw. bei einer
>
>  LOL.
>  Ganz so einfach ist es nicht. Verschlüsselte Nachricht abfangen/
>  mithören ist nicht gleichzusetzen mit ursprünglicher Nachricht in
>  Klartext abfangen/mithören/besitzen.

Oben sind ein paar Links zu Stackoverflow... Hier nur noch mal der mit 
dem schönen graphischen Beispiel und wie man bei verschlüsselten Texten 
weiter vorgehen würde 
https://crypto.stackexchange.com/questions/59/taki...

>> Nachricht c1[x] ^ c1[x + 77] = p1[x] ^ p1[x + 77]. Der/die Schlüssel
>> fällt/fallen raus
>
>  Es wiederholt sich immer nach len(k1) * len(k2) nur - wer weiss wie
>  lang k1 und wie lang k2 ist ?

Security by obscurity? Auch keine gute Idee.
Es ist egal wie lang k1 oder k2 sind, ob |k1| und |k2| Primzahlen sind 
und damit die Periode bis sich das wiederholt verlängern. Es ändert 
nichts.

Autor: Anton (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Was spricht aus deiner Sicht gegen die bereits verbreiteten Verfahren
für verschlüsselte Mails? Also PGP und S/MIME?

PGP unterstützt OAEP und RSAPSS-SSA nicht... Aber selbstverständlich 
lehnen wir uns an "Standards" ...
In meiner ersten Frage ging es ja auch nicht darum zu sagen wir wollen 
was anderes machen <- andernfalls müssten wir Tunnel bauen und die 
Datenübertragung tunneln (würde mir eh viel mehr gefallen).


und an alle anderen... ich finde es sehr spannend und lese aufmerksam 
mit... ABER es geht natürlich um "Praktikabilität" und Interoperabilität
1. muss das System auch Kleinstunternehmen zutraubar sein. Sich jetzt 
extra ein System für tausende € zu kaufen geht nicht.
2. muss es Marktalternativen geben, d.h. ich darf keine Software bereit 
stellen oder diese Verkaufen wenn es nicht die selben Funktionalität 
durch andere Anbieter gibt (Marktregulierung).
3. Natürlich wird ein asymmetrisches Verfahren mit privaten und 
öffentlichen Schlüsseln angepeilt. Die Schlüssel haben eine 
Maximalgültigkeit von 3 Jahren (gleichzeitig sollen die Schlüssel aber 
auch nicht wesentlich kürzer geltend sein). Der Schlüsselaustausch 
selbst ist meist "unsicher" z.B. über einer Homepage.
4. Es wird weder Root noch CA vorgeschrieben, dennoch können diverse CAs 
nicht vertraut werden. Die CA muss das Zertifikat selbst mit einem 
gewissen und gleichzeitig relativ sicheren Standard Signieren.

Ich weiß, dass viele "privat Personen" sich die Hände über den Kopf 
zerschlagen weil das ganze viel einfacher, und besser geht, aber uns 
sind die Hände gebunden...

Es geht hier hauptsächlich um die Standards welche OAEP, RSASSA-PSS, 
sha256WithRSAEncryption, sha512WithRSAEncryption und Co.

das mit OTP klingt z.B. Spannend, aber 1. lässt sich das nicht so 
einfach integrieren und 2. ist der Schlüsselaustausch eine echte 
Herausforderung <- vermutlich mehr als der Austausch der Nachricht 
selbst. Das funktioniert wenn 2 Großunternehmen genug Geld haben und 
Ihre Daten schützen wollen,... Aber auf einem Markt mit zig 
Marktpartnern funktioniert das leider nicht... <- aber ich durfte etwas 
dabei lernen, daher finde ich diese Kommentare sogar sehr gut.

Autor: Peter M. (r2d3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anton,

hier in Hannover bekämst Du eine kostenpflichtige Auskunft zu Deiner 
Frage von Ciphron. Ich arbeite nicht für diese Firma, habe deren 
Mitarbeiter aber kennengelernt.

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Anton schrieb:
> das mit OTP klingt z.B. Spannend, aber 1. lässt sich das nicht so
> einfach integrieren

 Das stimmt nicht, im Gegenteil.


> und 2. ist der Schlüsselaustausch eine echte
> Herausforderung <- vermutlich mehr als der Austausch der Nachricht
> selbst. Das funktioniert wenn 2 Großunternehmen genug Geld haben und
> Ihre Daten schützen wollen,... Aber auf einem Markt mit zig
> Marktpartnern funktioniert das leider nicht...

 Das stimmt aber 100% (leider).

 Obwohl, Zentrale <=> Marktpartnern ginge ohne Probleme - jeder Partner
 kriegt seinen eigenen Gesammtschlüssel (gk) von, sagen wir mal 2KB
 Länge sowie eine Codetabelle.
 Jede Nachricht wird Random verschlüsselt, Partner kriegt Nachricht mit
 z.B. COD1234 zugesendet.

 Bedeutet (Beispiel)
 Schlüssel 1 ist 103 Zeichen lang, beginnt um 7 Zeichen versetzt in gk,
 ergibt c1.
 Schlüssel 2 ist 71 Zeichen lang, beginnt um 19 Zeichen versetzt in gk,
 startet bei Zeichen 23 in c1.

 Wie gesagt, ich kenne mich nicht genügend aus, aber irgendwie habe
 ich das Gefühl, dass ohne Tabelle dieses Verfahren nicht zu knacken
 ist, lasse mich aber gerne eines Besseren belehren.

 Das Problem mit versenden und sicherem Aufbewahren der Codetabelle
 bleibt natürlich bestehen.

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Arc N. schrieb:
> Security by obscurity? Auch keine gute Idee.
> Es ist egal wie lang k1 oder k2 sind, ob |k1| und |k2| Primzahlen sind
> und damit die Periode bis sich das wiederholt verlängern. Es ändert
> nichts.

 Es ändert doch, weil sich die Schlüssellänge, Schlüssel selbst und
 die Position jedesmal ändern (siehe obige Post) - es sind praktisch
 jedesmal ganz andere Schlüssel.

: Bearbeitet durch User
Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Mathias schrieb:
> Muss man?
Ja, muss man. Denn das eine hat nichts mit dem anderen zu tun.

Mathias schrieb:
> Ich guck mir immer das Gesamtpaket an.
Kannst du machen, dann hast du aber elementare Dinge nicht verstanden.

Wie der Schluessel sicher von Alice zu Bob kommt, spielt bei der 
Betrachtung eines Kryptoverfahrens (OTP, DES, AES, Serpent, etc) keine 
Geige.

Was du offenbar nicht verstehen willst:
OTP ist beweisbar sicher. Alle anderen Algorithmen basieren auf der 
Annahme, das sie nach aktuellem Wissens- und Technikstand nicht 
knackbar sind. Das ist ein erheblicher Unterschied, der sich von heute 
auf morgen bei allen Algorithmen aendern kann, ausser bei OTP.

Um die Unterschiede zwischen OTP und allem anderen noch deutlicher zu 
machen:
Definition Informationstheoretische Sicherheit

Ein Kryptoverfahren ist informationstheoretisch oder beweisbar sicher,
wenn es auch dann nicht gebrochen werden kann, wenn dem Angreifer
beliebige(!) Rechenleistung zur verfuegung steht.
" beliebige Rechenleistung " ist hierbei der Knackpunkt.
Nimm einen OTP-Schluessel mit 10.000 Bit. Auch mit 2^10.000 Rechnern 
(beliebige Rechenleistung) die parallel arbeiten (jeder Rechner braucht 
nur einen einzigen Schluessel probieren) kann dieses OTP nicht gebrochen 
werden. Das es schlicht unmoeglich ist solch eine Rechenkapazitaet zu 
bauen, ist dabei egal (Anzahl der Atome im Universum ca. 2^266). Die 
Betrachtung geht aber von beliebiger Rechenleistung aus.

Alle anderen Kryptoverfahren beruhen aber auf 
berechenbarkeitstheoretischer Sicherheit:
 
Definition berechenbarkeitstheoretische Sicherheit

Ein Kryptosystem ist berechenbarkeitstheoretisch sicher, wenn fuer
alle probabilistischen Polynominalzeitalgorithmen gilt, dass sie das
System nur mit einer vernachlaessigbar kleinen Wahrscheinlichkeit
brechen koennen.
Diese Definition sagt, dass eine Chiffre berechenbarkeitstheoretisch 
sicher ist, wenn kein Algorithmus bekannt ist, der die Chiffre 
effizient brechen kann. Effizient bedeutet in diesem zusammenhang, 
dass kein Angriffsalgorithmus mit polynominaler Laufzeit existiert.

Der Unterschied sollte jetzt klar sein:
"auch mit beliebiger Rechneleistung nicht zu brechen" gegen "nur mit 
einer vernachlaessigbar kleinen Wahrscheinlichkeit zu brechen".

Bei OTP muss der Schluessel nichtmal von Alice zu Bob uebertragen 
werden. Das Uebertragen des Startwertes fuer einen CSPRNG wuerde 
reichen. Dann muessen nur noch Alice und Bob den gleichen CSPRNG 
verwenden. Bei einer entsprechenden Datenmenge dauert aber das erzeugen 
des Schluessels... bei einigen uC bekommt man z.B. alle paar Takte nur 1 
oder 2 Bit vom TRNG.

OTP ist nicht praktikabel, ich hab aber auch nie etwas anderes 
behauptet. Deswegen wird OTP ja auch praktisch nicht verwendet.
Mir ging es um die Aussage
> Sicher geht nicht
Doch, geht, bringt aber neue Probleme mit sich, wie man an OTP sieht.

Mathias schrieb:
> Ich stell mir gerade vor, Estland verteilt an ihre Bürger Ausweise mit
> 16GB OTP
Das verstoesst ja schon wieder gegen die Anforderungen an den 
OTP-Schluessel.

Mathias schrieb:
> weil alles andere ja nicht sicher ist...
Du kannst noch so sehr mit den Faeusten auf den Boden trommeln und 
versuchen die Sache mit unsinnigen Beispielen ins laecherliche zu 
ziehen, das aendert nichts an der Tatsache, dass ausser OTP kein anderes 
(bekanntes) Verfahren beweisbar sicher ist.


Anton schrieb:
> aber ich durfte etwas
> dabei lernen, daher finde ich diese Kommentare sogar sehr gut.
Freut mich. :)

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Noch was zum Thema "mehrfach verschluesseln":
Hier muss man hoellisch aufpassen!

Das beste Beispiel ist DES:
DES hat eine Sicherheit von 2^56.
Wendet man DES 2x an erhaelt man aber gerade mal eine Sicherheit von 
2^57. Der dazu passende Angriff nennt sich "MitM - Meet in the Middle".
Erst bei dreimaliger Anwendung von DES (Tripple DES) erhaelt man eine 
Sicherheit von 2^112.

Solange sowas nicht untersucht wurde, und man keine Ahnung hat was man 
da macht, waere ich mit solchen Vorschlaegen sehr vorsichtig.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Daniel H. schrieb:
> Kaj G. schrieb:
>> Und um einen Schluessel sicher zu uebertragen gibt es den DHKE:
>> https://de.wikipedia.org/wiki/Diffie-Hellman-Schl%...
>
> Der aber wiederum, strikt nach Lehrbuch implementiert, anfällig für
> Man-in-the-Middle-Angriffe ist, wodurch eine weitere
> Autentifizierungsschicht benötigt wird.
Ja. RSA ist ohne modifizierung aber auch angreifbar, wenn man es auf 
reinen Text anwendet. Deswegen wird es in der Regel in verbindung mit 
hybrider Verschluesslung eingesetzt.

Ganz ohne irgendeine Modifizierung geht es an vielen Stellen eben nicht, 
egal ob beim DHKE, RSA oder anderen Verfahren.

: Bearbeitet durch User
Autor: Mathias (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Mathias schrieb:
>> Ich guck mir immer das Gesamtpaket an.
> Kannst du machen, dann hast du aber elementare Dinge nicht verstanden.

Ich weiß sehr wohl, das OTPs beweißbar sicher sind, aber wenn du nicht 
das Gesamtpaket betrachten willst, hast du aber elementare Dinge nicht 
verstanden. Kommst wohl gerade von der Uni oder? Hast du schon irgendwo 
mal OTPs ausgerollt? Klar gibt es Anwendungen, wo das Praktikabel ist, 
ich höre mir gerne deine Anwendungen an.

und @Marc Vesely
Bitte höre auf, dein Verfahren als sicher zu bezeichnen. Für einen 
Cryptolaien ist das Verfahren nicht schlecht und ich denke auch nicht 
von jedem Studenten mit 100kb verschlüsseltem Text zu knacken, aber das 
wars. Cryptologen lachen über sowas. Wer keinen wirklichen Anspruch an 
Verschlüsselung hat, der kann sowas einsetzen. Wenn es entfernt wichtig 
ist, dass etwas nicht unbefugt entschlüsselt werden kann, dann ist das 
absolut untauglich.

Autor: Ex-Crypto-Mann (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Marc V. schrieb:
> Wie gesagt, ich kenne mich nicht genügend aus, aber irgendwie habe
>  ich das Gefühl, dass ohne Tabelle dieses Verfahren nicht zu knacken
>  ist, lasse mich aber gerne eines Besseren belehren.

Jeder, absolut jeder Mensch auf dieser Welt kann sich ein 
Verschlüsselungsschema ausdenken, das er selbst nicht knacken kann.

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ex-Crypto-Mann schrieb:
> absolut jeder Mensch auf dieser Welt kann sich ein
> Verschlüsselungsschema ausdenken, das er selbst nicht knacken kann.

Klar, je dümmer desto einfach.

Georg

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Mathias schrieb:
> und @Marc Vesely
> Bitte höre auf, dein Verfahren als sicher zu bezeichnen.

Ex-Crypto-Mann schrieb:
> Jeder, absolut jeder Mensch auf dieser Welt kann sich ein
> Verschlüsselungsschema ausdenken, das er selbst nicht knacken kann.

 Das mag ich - einfach behaupten, etwas ist knackbar.
 Alles ist knackbar, nur ist nicht alles zu Lebzeiten knackbar.


Marc V. schrieb:
> Es ändert doch, weil sich die Schlüssellänge, Schlüssel selbst und
>  die Position jedesmal ändern (siehe obige Post) - es sind praktisch
>  jedesmal ganz andere Schlüssel.

 Und das ist ganz einfach nicht knackbar - und selbst wenn du eine
 Nachricht zufällig entschlüssellt hast, nützt dir das bei der nächsten
 überhaupt nichts - du fängst bei der nächsten wieder ganz von vorne an.

 Aber es ist leichter ganz einfach zu schreiben, dass etwas knackbar
 ist, als dies zu beweisen (oder zumindest versuchen diese Behauptung
 zu belegen).

 Und deswegen behaupte ich, dass schon Plaintext XOR-ed with Random
 Bytes nicht knackbar ist. Es kann nur durch ausprobieren geknackt
 werden.


Mathias schrieb:
> wars. Cryptologen lachen über sowas.

 Nein, Laien und möchtegern Cryptologen lachen über sowas.

: Bearbeitet durch User
Autor: Daniel H. (Firma: keine) (commander)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Und deswegen behaupte ich, dass schon Plaintext XOR-ed with Random
>  Bytes nicht knackbar ist. Es kann nur durch ausprobieren geknackt
>  werden.

Also erst behauptest du, dass es nicht knackbar ist, nur um im nächsten 
Satz zu sagen, dass es doch knackbar ist? Was denn jetzt?

Insgesamt ist dein Verfahren nicht falsch, nur gibt es genau dafür 
moderne und beweisbar sichere Verfahren. Denn was in deinem Verfahren 
bisher komplett unter den Tisch fällt ist, wie Sender und Empfänger an 
die gleichen zufälligen Bytes für Ver- und Entschlüsselung kommen.

Ein deutlich einfaches Verfahren dazu ist z.B. AES im CFB- oder 
CTR-Modus. Hier wird zunächst aus einem zufällig generierten Nonce (das 
im Klartext übertragen werden kann) und einem geheimen Schlüssel mittels 
AES ein kryptographisch sicherer, pseudozufälliger Byte-String erzeugt, 
der anschließend mit dem Plaintext XORed wird. Der Vorteil ist, dass man 
lediglich einmalig den geheimen Schlüssel sicher verteilen muss, und 
dann "beliebig" viele Nachrichten verschlüsseln kann, ohne jedesmal 
austauschen zu müssen, was denn nun der aktuelle Schlüssel ist.

Auch hier aber wieder das Problem, wie man den Schlüssel sicher 
verteilen kann. Und da kommen wir wieder, zumindest bei großen, 
verteilten System mit möglicherweise tausenden Teilnehmern, bei der 
asymmetrischen Kryptographie vorbei, mit der man solche symmetrischen 
Schlüssel einfach austauschen kann ohne dass sie von anderen Teilnehmern 
beobachtet werden können.

Und nochmal, der TO möchte explizit asymmetrische Kryptographie nutzen, 
da hilft ihm ein, wie auch immer geartetes, XOR mit Zufallswerten genau 
gar nicht.

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Daniel H. schrieb:
> Also erst behauptest du, dass es nicht knackbar ist, nur um im nächsten
> Satz zu sagen, dass es doch knackbar ist? Was denn jetzt?

 Alles ist knackbar, fragt sich nur in welcher Zeit. Für dieses
 Verfahren gibt es kein Algorithmus, es muss ausprobiert werden, eins
 nach dem anderen und wenn der Schlüssel lang genug ist, ist es
 praktisch unknackbar.
 Eine Entschlüsselung nach 50 Jahren ist nutzlos.


Daniel H. schrieb:
> Insgesamt ist dein Verfahren nicht falsch, nur gibt es genau dafür
> moderne und beweisbar sichere Verfahren. Denn was in deinem Verfahren
> bisher komplett unter den Tisch fällt ist, wie Sender und Empfänger an
> die gleichen zufälligen Bytes für Ver- und Entschlüsselung kommen.

 So:
Marc V. schrieb:
> Obwohl, Zentrale <=> Marktpartnern ginge ohne Probleme - jeder Partner
>  kriegt seinen eigenen Gesammtschlüssel (gk) von, sagen wir mal 2KB
>  Länge sowie eine Codetabelle.
>  Jede Nachricht wird Random verschlüsselt, Partner kriegt Nachricht mit
>  z.B. COD1234 zugesendet.
>
>  Bedeutet (Beispiel)
>  Schlüssel 1 ist 103 Zeichen lang, beginnt um 7 Zeichen versetzt in gk,
>  ergibt c1.
>  Schlüssel 2 ist 71 Zeichen lang, beginnt um 19 Zeichen versetzt in gk,
>  startet bei Zeichen 23 in c1.

Autor: Daniel H. (Firma: keine) (commander)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Und wenn die Zentrale erfolgreich angegriffen wird sind sämtliche (gk) 
aller Partner auf einmal kompromittiert.

Das kann mit einem geeigneten, auf asymmetrischen Algorithmen 
basierenden Protokoll nicht passieren, da wäre dann "nur" der private 
Schlüssel der Zentrale kompromittiert. Den zu tauschen wäre deutlich 
leichter, als alle (gk) auszutauschen.

Üblicherweise nimmt man heute Verfahren zur 
Schlüsselvereinbarung/-austausche, welche über asymmetrische Verfahren 
abgesichert werden. Diese sind gut erforscht, bei korrekter Anwendung 
sicher und in der Praxis gut anzuwenden. Allein aus Haftungsgründen 
würde ich im kommerziellen Umfeld niemals ein selbstgestrickten 
Verfahren einsetzen.

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Meine Daumenregel: Ohne wirklich fundierte Kenntnisse sind eigene 
realistisch nutzbare Verfahren allenfalls so lange als sicher zu 
betrachten, wie sich kein Schwein wirklich ernsthaft dafür interessiert, 
was transportiert wird. Was für viele Anwendungen ein nicht ganz 
unrealistisches Szenario sein könnte.

: Bearbeitet durch User
Autor: MaWin (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Und deswegen behaupte ich, dass schon Plaintext XOR-ed with Random
> Bytes nicht knackbar ist.

Das stimmt nur, wenn deine "random Bytes" auch wirklich zufällig sind.
Sonst kannst du die Verschlüsselung über den RNG angreifen.

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
MaWin schrieb:
>> Und deswegen behaupte ich, dass schon Plaintext XOR-ed with Random
>> Bytes nicht knackbar ist.
>
> Das stimmt nur, wenn deine "random Bytes" auch wirklich zufällig sind.
> Sonst kannst du die Verschlüsselung über den RNG angreifen.

 Mikrofon in der Innenstadt oder im Einkaufszentrum, ADC Werte nehmen.

Autor: A. K. (prx)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Marc V. schrieb:
>  Mikrofon in der Innenstadt oder im Einkaufszentrum, ADC Werte nehmen.

Sicher, dass das reicht? Die Geräusche der Motoren von Ventilation, 
Aufzügen, Rolltreppen sind nicht sonderlich zufällig.

Autor: MaWin (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Mikrofon in der Innenstadt oder im Einkaufszentrum, ADC Werte nehmen.

Ich glaube du unterschätzt enorm, wie schwer es ist richtigen Zufall zu 
generieren und auch aufzunehmen.

Wenn nur wenige Bits deines RNG-Stroms mit einer geringen 
Wahrscheinlichkeit vorhersagbar sind, dann ist dein OTP angreifbar.

Autor: jz23 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Daniel H. schrieb:
>> Also erst behauptest du, dass es nicht knackbar ist, nur um im nächsten
>> Satz zu sagen, dass es doch knackbar ist? Was denn jetzt?
>
>  Alles ist knackbar, fragt sich nur in welcher Zeit.

Nein, es ist nicht alles knackbar. Wenn du alle Möglichkeiten 
durchprobierst (z.B. beim OneTime-Pad), dann hast du zwar unter den 
Millionen Lösungen auch irgendwo die richtige dabei, aber du hast auch 
eben noch die Millionen anderer Lösungen, die genauso möglich wären.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jz23 schrieb:
> Millionen Lösungen auch irgendwo die richtige dabei, aber du hast auch
> eben noch die Millionen anderer Lösungen, die genauso möglich wären.

Vorsichtige Leute bauen deshalb in ihre Rohdaten CRCs oder andere 
Signaturen ein. Das macht die Erkennung deutlich einfacher. ;-)

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
MaWin schrieb:
> Ich glaube du unterschätzt enorm, wie schwer es ist richtigen Zufall zu
> generieren und auch aufzunehmen.
Ach was. Alle Kryptographen und Mathematiker dieser Welt sind einfach 
nur zu dumm oder zu faul...
[/ironie]

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
MaWin schrieb:
> Wenn nur wenige Bits deines RNG-Stroms mit einer geringen
> Wahrscheinlichkeit vorhersagbar sind, dann ist dein OTP angreifbar.

 Angreifbar ist alles - ist aber nicht gleichzusetzen mit knackbar.

> Ich glaube du unterschätzt enorm, wie schwer es ist richtigen Zufall zu
> generieren und auch aufzunehmen.

 Und ich glaube du überschätzt enorm die Angriffsmöglichkeiten.
 Es muss gewisse Regelmässigkeiten geben und diese müssen sich auch in
 festen Intervalen wiederholen.

 Strassenverkehr in der Innenstadt ist mit Sicherheit absolut
 zufällig, zumindest für eine gewisse Zeit, die wiederum mehr als
 ausreichend ist.

Autor: Dussel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> jz23 schrieb:
>> Millionen Lösungen auch irgendwo die richtige dabei, aber du hast auch
>> eben noch die Millionen anderer Lösungen, die genauso möglich wären.
>
> Vorsichtige Leute bauen deshalb in ihre Rohdaten CRCs oder andere
> Signaturen ein. Das macht die Erkennung deutlich einfacher. ;-)
Ja, nur bekommst du zu jeder beliebigen Nachricht mit falschem CRC als 
Lösung auch die Nachricht mit richtigem CRC.
Es grenzt die möglichen Lösungen ein, aber unter denen hast du keine 
Möglichkeit, die richtige rauszufinden.

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
A. K. schrieb:
> Sicher, dass das reicht? Die Geräusche der Motoren von Ventilation,
> Aufzügen, Rolltreppen sind nicht sonderlich zufällig.

 Stimmt, aber diese sind auch nicht sonderlich laut und werden von
 anderen (zufälligen) Geräuschen überlagert.

 Und einzig Ventilation kann als einigermassen regelmässig bezeichnet
 werden - Aufzug is es bestimmt nicht und Rolltreppe dürfte je nach
 Belastung verschiedene Geräusche produzieren.
 Aber wie gesagt, das sind relativ leise Geräusche und werden Samstags
 um 12 Uhr kaum wahrzunehmen sein - diese können vielleicht raus-
 gefiltert werden, aber das nützt kaum bei der Entschlüsselung.

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
jz23 schrieb:
> Nein, es ist nicht alles knackbar.

 Doch, alles ist knackbar, nur ist eine Entschlüsselung nach
 2000 Jahren sinnlos.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
>  Stimmt, aber diese sind auch nicht sonderlich laut und werden von
>  anderen (zufälligen) Geräuschen überlagert.

Weshalb eine gängige Strategie, vorsichtshalber nur die unteren Bits zu 
verwenden, damit man nicht sofort raushört, ob das Einkaufszentrum in 
Dresden oder Stuttgart steht, genau jene überlagerten Geräusche enthält, 
die du selbst nicht wahrnimmst. Das macht es nicht gleich 
deterministisch, aber auch nicht rein zufällig.

: Bearbeitet durch User
Autor: jz23 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Doch, alles ist knackbar, nur ist eine Entschlüsselung nach
>  2000 Jahren sinnlos.

Hast du meinen Beitrag gelesen? Offensichtlich nicht, aber ich 
wiederhole es gerne noch einmal:

Du hast eine riesige Anzahl an Lösungen, die bei der Entschlüsselung 
eine OTP auftauchen, die sind alle sinnvoll. Und trotzdem ist nur eine 
dieser Lösungen richtig - es ist unmöglich zu sagen, welche, außer du 
bist im Besitz des OTP. Und deswegen ist das eben unknackbar.

Autor: MaWin (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Es muss gewisse Regelmässigkeiten geben

Und eben diese sind vorhanden, wenn du makroskopische Ereignisse 
aufnimmst.

> und diese müssen sich auch in festen Intervalen wiederholen.

Nein.

Es muss nur mit einer geringen Wahrscheinlichkeit teilweise vorhersagbar 
sein.


> Strassenverkehr in der Innenstadt ist mit Sicherheit absolut zufällig,


Worauf stützt du diese Aussage?

Autor: Marc Horby (marchorby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
>> Strassenverkehr in der Innenstadt ist mit Sicherheit absolut zufällig,
>
> Worauf stützt du diese Aussage?

Ich halte es für Sarkasmus!

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Marc H. schrieb:
> MaWin schrieb:
>>> Strassenverkehr in der Innenstadt ist mit Sicherheit absolut zufällig,
>>
>> Worauf stützt du diese Aussage?
>
> Ich halte es für Sarkasmus!

 Warum ?

 Welche Regelmässigkeiten gibt es in einem 10 sec. Zeitraum von,
 z.B. 7:44:28 bis 7:44:38, für sich alleine betrachtet ?

 P.S.
 Selbst mit 8bit und 20KHz ergibt das fast 200KByt.

: Bearbeitet durch User
Autor: MaWin (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Welche Regelmässigkeiten gibt es in einem 10 sec. Zeitraum von,
>  z.B. 7:44:28 bis 7:44:38, für sich alleine betrachtet ?

Motorengeräusche sind von sich aus schon sehr regelmäßig. Sonst würde 
der Motor nicht laufen.
Der Verkehr wird von Ampeln geregelt, die hoffentlich äußerst regelmäßig 
funktionieren.
Sprach- und Tiergeräusche sind äußerst regelmäßig, sonst würden sie zur 
Kommunikation nicht taugen.

Und hier willst du beweisbaren Zufall erzeugen?

Jede auch noch so geringe Regelmäßigkeit kann im Ciphertext sichtbar 
sein und damit ist dein Verfahren schon praktisch als gebrochen 
anzusehen.

Autor: MaWin (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Auch die oft getätigte Aussage, dass Regelmäßigkeiten verschwinden, 
indem man Zufall addiert, ist natürlich falsch.
Unterschiedliche Schallwellen addieren sich auf (grob gesagt).
Wenn da eine Regelmäßigkeit dabei ist, nutzt es kaum, wenn auch noch 
100 zufällige Schallquellen vorhanden sind.

Das kann jeder selbst durch nachdenken oder in seiner 
Tabellenkalkulation herausfinden.

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
MaWin schrieb:
> Motorengeräusche sind von sich aus schon sehr regelmäßig. Sonst würde
> der Motor nicht laufen.
> Der Verkehr wird von Ampeln geregelt, die hoffentlich äußerst regelmäßig
> funktionieren.
> Sprach- und Tiergeräusche sind äußerst regelmäßig, sonst würden sie zur
> Kommunikation nicht taugen.
>
> Und hier willst du beweisbaren Zufall erzeugen?

 Ja.

Autor: MaWin (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
>> Und hier willst du beweisbaren Zufall erzeugen?
>
>  Ja.

Dann bin ich ja mal gespannt.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Und hier willst du beweisbaren Zufall erzeugen?

Kann man das überhaupt beweisen? Oder gibts hier nur Negativbeweise - es 
gibt Verfahren dafür - und was die allesamt überlebt gilt vorläufig als 
zufällig?

: Bearbeitet durch User
Autor: MaWin (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
A. K. schrieb:
>> Und hier willst du beweisbaren Zufall erzeugen?
>
> Kann man das überhaupt beweisen?

Ok, das war etwas schlecht ausgedrückt.
Ich wollte sagen: Und hier willst du Zufall erzeugen, den man nicht mit 
gängigen Verfahren als nicht-zufällig entlarven kann?


Einen Crypto-Hash wie SHA drüberlegen zählt übrigens nicht, denn dann 
ist es keine OTP-Verschlüsselung mehr, sondern ein ganz "normaler" 
Verschlüsselungsalgorithmus.

Autor: Hi-Tech-Progger S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde das Thema sehr spannend und habe auch schon Einiges gelernt.

Ohne jetzt auf Details einzugehen, aber diese Frage:

MaWin schrieb:
> Das kann jeder selbst durch nachdenken oder in seiner
> Tabellenkalkulation herausfinden.

Was willst Du damit zeigen?

Dass der Zufall sich nicht zu Null addiert erfordert eine Integration 
der Zufallswerte. Was macht dabei der Sinus?

Und: Sind die Zufallszwerte in Excel wirklich gute Zufallswerte?

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
MaWin schrieb:
> Auch die oft getätigte Aussage, dass Regelmäßigkeiten verschwinden,
> indem man Zufall addiert, ist natürlich falsch.

Die Addition vieler nicht zufälliger Geräusche erzeugt etwas, das 
subjektiv zufällig wirken kann. Beispielsweise die Schritte von 
Menschen. Die Schrittfrequenz variiert etwas zwischen den Individuen. 
Beim Individuum selbst variiert sie hauptsächlich in Abhängigkeit von 
der Umwelt, ist sonst aber ziemlich regelmässig. Die Summe vieler 
Schritte mag dann sehr chaotisch klingen, ist aber als Quelle von Zufall 
völlig ungeeignet.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi-Tech-Progger S. schrieb:
> Was willst Du damit zeigen?

Das Regelmäßigkeiten nicht durch Addition von echtem Zufall 
verschwinden. Selbst wenn der Mensch dann die Regelmäßigkeit nicht mehr 
unmittelbar erkennen kann, z.B. durch seine Ohren.

Das ist in vielen Bereichen relevant. Wie z.B. hier bei der Addition von 
Schallwellen. Oder z.B. bei TCP-Paketen im TOR-Netzwerk. Dort kann man 
auch die Anonymität nicht erhöhen, wenn man die Pakete zufällig 
verzögert.

>Und: Sind die Zufallszwerte in Excel wirklich gute Zufallswerte?

Das spielt zur Demonstration kaum eine Rolle.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
A. K. schrieb:
> Die Summe vieler Schritte mag dann sehr chaotisch klingen,

Gemeint ist hier die Summe der Schritte vieler Menschen.

Autor: Hi-Tech-Progger S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Trotzdem verstehe Ich nicht, was der Sinus da soll.

Umgekehrt wäre es aussagefähiger: Zufall addieren und eine Kurve 
rausbekommen.

Das ist es nämlich was passiert.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi-Tech-Progger S. schrieb:
> Umgekehrt wäre es aussagefähiger: Zufall addieren und eine Kurve
> rausbekommen.

Der umgekehrte Fall ist interessanter: Eine beliebig kompliziert 
aussehende Kurve haben, und feststellen, ob es sich dabei um Zufall 
handelt.

Autor: MaWin (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi-Tech-Progger S. schrieb:
> Trotzdem verstehe Ich nicht, was der Sinus da soll.

Der Sinus ist ein Beispiel für eine regelmäßige Quelle.


>Umgekehrt wäre es aussagefähiger: Zufall addieren und eine Kurve rausbekommen.
> Das ist es nämlich was passiert.

Nein. Wie soll das gehen?

Autor: Dussel (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hi-Tech-Progger S. schrieb:
> Trotzdem verstehe Ich nicht, was der Sinus da soll.
Auch wenn man auf den (regelmäßigen) Sinus zufällige Werte addiert, 
bleibt der regelmäßige Sinus im Ergebnis nachweisbar (wenn auch nicht 
direkt erkennbar).

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Bei Zufallszahlen ist auch Vorsicht geboten.

Beispiel:
Ein CSPRNG liefert 16 bit Zufallszahlen.
Braucht man aber eine 32 bit Zufallszahl, und verbindet einfach 2 16 bit 
Zahlen (x = (z[0] << 16) | z[1]) so ist es mit der kryptographischen 
Sicherheit und auch mit dem Zufall ganz schnell vorbei.

Das aber nur als kleine Randnotiz.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Braucht man aber eine 32 bit Zufallszahl, und verbindet einfach 2 16 bit
> Zahlen (x = (z[0] << 16) | z[1]) so ist es mit der kryptographischen
> Sicherheit und auch mit dem Zufall ganz schnell vorbei.

Das hört sich interessant an. Könntest du genauer erklären, warum das so 
ist?

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erzähl mehr!

Wenn dem so wäre, dann müßtest du den CSPRNG ja von einer Zufallsfolge 
unterscheiden können, und dann wäre es kein ernstzunehmender CSPRNG.

Autor: Hi-Tech-Progger S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dussel schrieb:
> Hi-Tech-Progger S. schrieb:
>> Trotzdem verstehe Ich nicht, was der Sinus da soll.
> Auch wenn man auf den (regelmäßigen) Sinus zufällige Werte addiert,
> bleibt der regelmäßige Sinus im Ergebnis nachweisbar (wenn auch nicht
> direkt erkennbar).

Das ist unbestritten, erklärt aber nicht die Grundaussage, dass 
Zufallszahlen sich über die Zeit nicht zu völligem Zufall addieren. Das 
war ja die Aussage.

Im Gegenteil: Man muss ja annehmen, dass es weitgehend klappt, sonst 
könnte man den Nichtzufall, den Sinus ja nicht daraus extrahieren.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi-Tech-Progger S. schrieb:
> dass
> Zufallszahlen sich über die Zeit nicht zu völligem Zufall addieren. Das
> war ja die Aussage.

Nein, das war nicht die Aussage.

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
MaWin schrieb:
> Marc V. schrieb:
>>> Und hier willst du beweisbaren Zufall erzeugen?
>>
>>  Ja.
>
> Dann bin ich ja mal gespannt.


 Ich verstehe deine Einwände nicht, es ist für mich ganz einfach
 Sturheit.

 Es wird nicht im Studio aufgenommen, wo nur ein Motor 75 cm entfernt
 links von Mikrofon läuft, ein Moped 2,5m rechts, ein Vogel zwitschert
 20cm entfernt und alles bleibt schön statisch, regelmässig und mit
 gleicher Lautstärke. Und selbst wenn - ob es Regelmässigkeiten gibt
 oder nicht, ist vorerst uninteressant, beim Entschlüsseln weisst du
 das ganz einfach nicht.
 Und ob etwas mit Werten von 0 bis 255 verschlüsselt wird oder nur mit
 Werten von 121 bis 225 ist vorerst auch uninteressant - man muss alle
 Werte durchgehen. Erst wenn (falls überhaupt) durch Ausprobieren etwas
 sinnvolles rauskommt, kann man versuchen, gewisse Regelmässigkeiten
 rauszufinden.

 Es genügt aber nur, dass jemand kurz hupt und schon ist deine Regel-
 mässigkeit hinüber. Auspuff knallt, jemand pfeift einem Mädchen
 hinterher, ein Extremist jagt sich in die Luft - es mag für sich
 alleine regelmässig sein aber es wird durch einen anderen
 (regelmässigen oder nicht) Geräusch zu einem unbekannten und nicht
 vorhersehbaren Zeitpunkt unterbrochen.
 Und schon ist deine Regelmässigkeit hinüber.


 Und selbst dein Beispiel mit Sinus + Zufall steht nicht - es sind immer
 noch zufällige Werte - multipliziere die Werte mit 100 und dann siehst
 du das auch.
 Und mehr als einen Trend erkennen kann man in deinem Beispiel nicht.
 Einen Trend erkennen hat aber mit entschlüsseln genau nichts zu tun.
 Selbst die aufeinanderfolgenden Werte schwanken teilweise um mehr als
 50% - das hat nicht einmal R von Regelmässigkeit.

Autor: Hi-Tech-Progger S. (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
MaWin diskutiert an einem völlig anderen Ende der Wurst, wie mir 
scheint.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
>  ob es Regelmässigkeiten gibt
>  oder nicht, ist vorerst uninteressant, beim Entschlüsseln weisst du
>  das ganz einfach nicht.

Wenn du mit OTP encryption ein leeres Signal überträgst, dann liegt der 
RNG blank vor und kann auf Schwächen analysiert werden. Generell ist OTP 
mit schwachem Zufallsgenerator empfindlich für known plaintext attacks.

Autor: MaWin (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Ich verstehe deine Einwände nicht, es ist für mich ganz einfach Sturheit.

Nur weil du etwas nicht verstehst, musst du nicht gleich beleidigen.

> beim Entschlüsseln weisst du das ganz einfach nicht.

Doch.
Regelmäßigkeiten im Ciphertext lassen sich mit statistischen Methoden 
recht einfach erkennen. Solche Regelmäßigkeiten können nur von 
Regelmäßigkeiten im RNG kommen.

> Und ob etwas mit Werten von 0 bis 255 verschlüsselt wird oder nur mit Werten von 
121 bis 225 ist vorerst auch uninteressant

Nein das ist sehr wohl sehr sehr sehr interessant.
Ein derartiger Fehler führt zum sofortigen Zusammenbruch der 
Verschlüsselung.
Mit statistischen Methoden lässt sich aus dem Ciphertext der Klartext 
rekonstruieren, wenn der Schlüsselstrom nicht regelmäßig ist.
Als beispiel sei RC4 und WEP genannt.

> Es genügt aber nur, dass jemand kurz hupt und schon ist deine Regelmässigkeit 
hinüber.

Nein eben nicht. Genau das habe ich oben versucht zu erklären.

>  Und selbst dein Beispiel mit Sinus + Zufall steht nicht - es sind immer noch 
zufällige Werte

Nein. Der Sinus ist ganz klar für jeden nach der Addition noch 
erkennbar.

> multipliziere die Werte mit 100 und dann siehst du das auch.

Warum sollte sich durch eine Skalierung etwas ändern?

> Einen Trend erkennen hat aber mit entschlüsseln genau nichts zu tun.

Doch hat es. Ein guter Ciphertext ist von Zufall nicht unterscheidbar. 
Wenn der Ciphertext eine Regelmäßigkeit aufweist, dann kann man auf 
Schwächen im RNG und damit auf den Klartext schließen.

> Selbst die aufeinanderfolgenden Werte schwanken teilweise um mehr als
 50% - das hat nicht einmal R von Regelmässigkeit.

Dann filtern wir es doch mal mit einem simplen gleitenden Mittelwert und 
verschieben es um einen konstanten Wert auf der Y-Achse.
Plötzlich ist der "Zufall" kaum mehr von einem Sinus zu unterscheiden.
Und damit fütterst du dein OTP.

Autor: Hi-Tech-Progger S. (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Martin, es ging Anton um dies hier: #5179083:

> Hier geht es um die Bewertung von Verschlüsselungs und Signatur
> Algorithmen, insbesondere um sha256WithRSAEncryption und RSASSA-PSS

D.h. du müsstest Deinen Sinus so verschlüsseln, dass er nicht mehr 
erkennbar ist, aber wieder zu rekonstruieren.

Mit nur "Rauschen drauf" braucht man nur ein RC-Glied, um den Sinus zu 
sehen.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> wenn der Schlüsselstrom nicht regelmäßig ist.

wenn der Schlüsselstrom nicht zufällig ist.

natürlich :)

Autor: Hi-Tech-Progger S. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
MaWin schrieb:
> MaWin schrieb:
>> wenn der Schlüsselstrom nicht regelmäßig ist.
>
> wenn der Schlüsselstrom nicht zufällig ist.

Um das jetzt zu einem Abschluss zu bringen vielleicht mal Folgendes:

Wir hatten in meiner Ex-Firma vor einigen Jahren ein Projekt im Umfeld 
der Verschlüsselung des Bundeswehrfunks im Feld. D.h. es geht um den 
Digitalfunk - im Großen und Ganzen handelt es sich um ähnliche Themen, 
wie bei dem Polizeifunk.

Zur Anwendung kamen Algorithmen, die von Mitarbeitern einer ehemaligen 
Stelle der Stasi in der DDR (kein Witz!) entwickelt wurden und die heute 
in einer westdeutschen Firma eingegliedert ist - angeblich, um sie nach 
der Wende davon abzuhalten, zu den Russen zu wechseln.

Diese Stelle sitzt heute in Berlin (oder sie saß damals in Berlin) und 
produziert mit Mathematikern und Physikern spezielle Codierverfahren und 
Schlüssel, um sie in Rechnersysteme übernehmen zu können. Diese 
Verfahren bestehen aus Algorithmen zur Chiffrierung und Dechiffrierung 
sowie eben den Schlüsseln, die getauscht werden können und flossen in 
die Funkgeräteentwicklung und auch die Flugleitentwicklung, wenn es um 
das Bestimmen von Aufenthaltsorten von Flugkörpern geht, oder wenn ihnen 
per SDR Daten zugesendet werden sollen.

Diese Informationen werden so verschlüsselt, dass es praktisch ein 
Rauschsignal ist, welches so homogen und unauffällig ist, dass man es im 
normalen Rauschen verstecken kann. Das "normale" Rauschen ist an der 
Stelle aber ein bekanntes Rauschen, d.h. wenn man es empfängt, kann man 
es erkennen, einrasten und abziehen. Übrig bleibt dann das 
Zufallsrauschen aus der Atmospähre und der Elektronik sowie der 
scheinbar rauschende Code. Den muss man dann eben nochmal durch die 
Algorithmen jagen.

Dies soweit.

Autor: MaWin (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hi-Tech-Progger S. schrieb:
> Diese Informationen werden so verschlüsselt, dass es praktisch ein
> Rauschsignal ist,

Das ist bei jeder beliebigen sicheren Verschlüsselung der Fall.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
>> Rauschsignal ist,
>
> Das ist bei jeder beliebigen sicheren Verschlüsselung der Fall.

Sein Beitrag riecht danach, als ob sowohl Verschlüsselung als auch 
Funkmodulation gemeint sind. Es also auch darum geht, das HF-Signal 
selbst zu verstecken, nicht nur den Inhalt.

: Bearbeitet durch User
Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
MaWin schrieb:
> Marc V. schrieb:
>> Ich verstehe deine Einwände nicht, es ist für mich ganz einfach Sturheit.
>
> Nur weil du etwas nicht verstehst, musst du nicht gleich beleidigen.

 Ich habe dich nicht beleidigt oder zumindest nicht mit Absicht.

 Aber Floskel wie diese:

MaWin schrieb:
> Ein derartiger Fehler führt zum sofortigen Zusammenbruch der
> Verschlüsselung.
> Mit statistischen Methoden lässt sich aus dem Ciphertext der Klartext
> rekonstruieren, wenn der Schlüsselstrom nicht regelmäßig ist.

MaWin schrieb:
> Regelmäßigkeiten im Ciphertext lassen sich mit statistischen Methoden
> recht einfach erkennen. Solche Regelmäßigkeiten können nur von
> Regelmäßigkeiten im RNG kommen.

MaWin schrieb:
>
> Dann filtern wir es doch mal mit einem simplen gleitenden Mittelwert und
> verschieben es um einen konstanten Wert auf der Y-Achse.
> Plötzlich ist der "Zufall" kaum mehr von einem Sinus zu unterscheiden.
> Und damit fütterst du dein OTP.


 Was, womit und warum soll ich irgendetwas füttern ?
 Mit Sinus bestimmt nicht.

 Das sind abgeschriebene Floskeln und haben mit der Realität nichts
 zu tun.

 Und diese ganze Schreiberei über statistische Methoden, filtern und
 verschieben ist ganz einfach Blödsinn.

 Und Regelmässigkeiten in Ciphertext kannst du erst nach Entschlüsseln
 erkennen.



 P.S.
 Irgendwie habe ich das Gefühl, dass du dieses Verfahren ganz einfach
 nicht verstanden hast.

 Das einzige Problem bei dieser Methode ist das Versenden und sicheres
 Aufbewahren der Gesammtschlüssel und der Codetabelle.
 Knackbar ist es nicht, das steht mit Sicherheit fest.

: Bearbeitet durch User
Autor: MaWin (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Marc V. schrieb:
> Das sind abgeschriebene Floskeln und haben mit der Realität nichts
>  zu tun.

Ich habe mit RC4/WEP sogar Beispiele genannt.

> Und diese ganze Schreiberei über statistische Methoden, filtern und
> verschieben ist ganz einfach Blödsinn.

Nicht alles, was man nicht versteht, ist Blödsinn.

> Und Regelmässigkeiten in Ciphertext kannst du erst nach Entschlüsseln
> erkennen.

Du trollst doch.

Autor: MaWin (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Marc V. schrieb:
> Das einzige Problem bei dieser Methode ist das Versenden und sicheres
>  Aufbewahren der Gesammtschlüssel und der Codetabelle.
>  Knackbar ist es nicht, das steht mit Sicherheit fest.

Das trifft nur zu, wenn dein Schlüssel 100% und ausnahmslos zufällig 
ist.
Und das trifft auf deine Innenstadtaufnahmen ganz einfach nicht zu.

Sobald dein Schlüssel auch nur die geringsten Regelmäßigkeiten hat, wird 
dein Verfahren angreifbar.

Aber was rede ich; das habe ich schon mehrfach geschrieben.

Autor: Marc Vesely (Firma: Vescomp) (logarithmus)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
MaWin schrieb:
> Sobald dein Schlüssel auch nur die geringsten Regelmäßigkeiten hat, wird
> dein Verfahren angreifbar.

 Ja, fragt sich nur wie du die Regelmässigkeiten erkennen willst.

 Und wie gesagt, angreifen und entschlüsseln ist nicht dasselbe.

 Und wie gesagt, eine Entschlüsselung nach 2000 Jahren ist nutzlos.

Autor: MaWin (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Marc V. schrieb:
> Ja, fragt sich nur wie du die Regelmässigkeiten erkennen willst.

Es gibt viele Verfahren, um Zahlenfolgen von Zufallszahlenfolgen zu 
unterscheiden.
z.B. https://en.wikipedia.org/wiki/Diehard_tests

> Und wie gesagt, angreifen und entschlüsseln ist nicht dasselbe.

Das ist richtig.
Ein nicht 100%ig funktionierender RNG ist aber gerade für OTP eine 
enorme Lücke. Siehe z.B. Plaintext-Angriff. Gegen diesen bietet OTP 
keinerlei Schutz.
Deshalb wird aus einem Angriff gerade hier sehr schnell eine praktisch 
nutzbare Entschlüsselung.

> Und wie gesagt, eine Entschlüsselung nach 2000 Jahren ist nutzlos.

Es ist heute ohne weiteres für kleines Geld möglich, die Leistung von 
vielen tausend Bürorechnern per Click zu mieten. (z.B. Amazon). Da 
werden aus deinen 2000 Jahren ganz schnell 2000 Sekunden.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Bei Zufallszahlen ist auch Vorsicht geboten.
>
> Beispiel:
> Ein CSPRNG liefert 16 bit Zufallszahlen.
> Braucht man aber eine 32 bit Zufallszahl, und verbindet einfach 2 16 bit
> Zahlen (x = (z[0] << 16) | z[1]) so ist es mit der kryptographischen
> Sicherheit und auch mit dem Zufall ganz schnell vorbei.
>
> Das aber nur als kleine Randnotiz.
Asche auf mein Haupt, da hab ich mist erzaehlt. :(

Wie bin ich auf den Mist gekommen:
Ein ehemaliger Kollege, der mal bei Rohde & Schwarz SIT gearbeitet hat, 
hatte mir mal erzaehlt, dass dem so waere. Ist aber auch schon wieder 
ein paar Jahre her. Moeglicherweise hab ich da was durcheinander 
gebracht.

Ich hab jetzt aber mal Prof. Paar von der RUB gefragt, mit dem Beispiel 
von 2 4bit Zahlen. Seine Antwort:
Wenn jedes Nibble (4 Bit) echt zufällig ist, dh. gleichverteilt aus
der Menge 0...15 gezogen wird, ist das Gesamt-Byte auch gleichverteilt
im Bereich 0...255. Man muss die Wahrscheinlichkeiten hier
Multiplizieren: Um eine bestimmte (beliebige) 8Bitzahl zu bekommen, hat
man eine Wahrscheinlichkeit von 1/16 für das MSB Nibble und noch einmal
1/16 für das LSB Nibble, d.h. die Gesamtwahrscheinleichkeit für eine
beliebige 8Bitzahl ist 1/16 x 1/16 = 1/256. 

Nochmal sorry fuer diesen Muell. :'(

Autor: Schreiber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Ein ehemaliger Kollege, der mal bei Rohde & Schwarz SIT gearbeitet hat,
> hatte mir mal erzaehlt, dass dem so waere.
Kann es sein, dass Dein Kollege von SIT genau so denkt und er deshalb 
dort nicht mehr arbeitet?

Der Abteilungsleiter dort, Herr  Bat.....lag, ist ja dafür bekannt, daß 
er "hohe Anforderungen" hat. Zumindest kommuniziert er das so.

Autor: Nerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schreiber schrieb:
> Der Abteilungsleiter dort, Herr  Bat.....lag, ist ja dafür bekannt, daß
> er "hohe Anforderungen" hat. Zumindest kommuniziert er das so.

Der von Dir mutmaßlich genannte Mitarbeiter war kein Mitarbeiter der R&S 
SIT, sondern des R&S Stammunternehmens, allerdings an demselben Standort 
in Stuttgart Weilimdorf.

Autor: Gu. F. (mitleser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> Ja, fragt sich nur wie du die Regelmässigkeiten erkennen willst.

Eine FFT wäre eine Möglichkeit.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.