Verschlüsselungsverfahren, welches?

[mirage228]

Hi Hagen,

ist "Elliptic Curves" nicht patentiert? Oder habe ich mal etwas Falsches gelesen?

mfG
mirage228

[negaH]

@mytar:

über RC4 sollte man ne Menge im WEB finden. Aber, da RC4 offiziell auf mysteriöse Weise unerlaubt aus den RSA Labs. "entflohen" ist, also nie offiziell veröffentlicht wurde, gibt es im Grunde keine anerkannten Expertiesen über dessen Sicherheit. Allerdings, das Grundprinzip und die cleveren Tricks im RC4 dienten später als Grundlage für viele andere Streamcipher. Somit haben sich wesentliche Neuheiten im RC4 Design durchgesetzt, und das spricht für dessen Sicherheit.

Zitat:

ist "Elliptic Curves" nicht patentiert? Oder habe ich mal etwas Falsches gelesen?

Nein. Das Grundprinzip aller ECC Varianten ist nicht patentiert, aber...
Man muß unterscheiden in welchen Domains und mit welchen Zahlensystemen die ECC implementiert werden. ECC arbeitet in Galois Fields -> GF() modular. Aber die Domain selber kann GF(p) oder GF(n^m) oder GF2(n) sein. GF(p) arbeitet in Zp also modularen Ringen zu einer Primzahl. GF(m^n) arbeitet ganz anders, d.h. selbst die Addition, Subrationen sind unterschiedlich definiert. Nun, die Grundlagen der ECC sind nicht patentiert, aber sehr wohl die darauf aufsetzenden verschiedenen kryptographischen Algortihmen und auch die verschiedenen nötigen mathematischen Operationen und Algorithmen damit man in GF(n^m) sehr schnell rechnen kann. Das ist deshalb bedeutsam weil die ECC ideal für SmartCard Prozessoren, also Hardware, geeignet sind. Eben weil ECC's mit kleineren Schlüsseln auskommen bei gleicher Sicherheit im Vergleich zu RSA. Ein 1024 RSA ist so sicher wie ein 168 Bit ECC. Somit sind auch die Berechnungen in ECC, besonders in GF2(n) besonders effizient und schnell in hardware zu integrieren. Nun, auf diesem Gebiet ist heutzutage eine "Schlacht" auf Patentebene im Gange. Das liegt eben auch daran das wenn man schon die Grundlagen der ECC nicht patentieren kann, man denoch versuchen kann alle nötigen mathematischen Operationen drumherum zu patentieren.

Allerdings relativiert sich das für jeden Hobby-Kryptographen, weil dieser nur an ECC in GF(p) interessiert sein sollte. Denn nur ECC in GF(p) sind tatsächlich als sicher bewiesen. D.h. man hat bis heute noch nicht eindeutig beweisen können das ECC in anderen Domains wie GF(n^m) oder GF2(n) wirklich so sicher sind wie in GF(p). man hat also noch nich mathematisch beweisen können ob man die Eigenschaften in Punkto Sicherheit aus der Domain GF(p) nach andere Domains wie GF(n^m) übertragen kann. Wenn man dies aber noch nicht mathematisch beweisen konnte so fehtl auch der mathematische Beweis das ECC in zb. GF(n^m) so sicher ist wie in GF(p).

Zudem sind auf PCs die ECC's in GF(p) nur unwesentlich aufwändiger und ineffizienter (im Millisekundenbereich), und so gibt es eigentlich keinen Grund nicht GF(p) zu nutzen. Meine GF(p) Impelemntrierung im DEC erzeugt zB. 192Bit ECC GF(p)Schlüssel in maximal 300ms und Signaturen in 2ms auf einem P4 1.5 GHz. D.h. mit ca. durchschnittlich 5 Millisekunden pro kryptographischer Operation ist man bei weitem schneller als bei anderen Verfahren wie RSA usw. Es besteht also kein Grund ECC GF(p) nicht zu benutzen. Einzigstes Augenmerk ist auf verschiedene Anstrengungen zu richten ECC durch die Hintertür zu patentieren bzw. zu blockieren. Man versucht also irgendwelche speziellen Algorithmen zu patentieren und über diese "rückwirkend" grundsätzliche unpatentierte ECC Eigenschaften zu patentieren.

Gruß Hagen

[mirage228]

Hi Hagen,

Danke für Deine ausführliche Antwort.

Dann steht einer Benutzung meinerseits ja nichts mehr im Wege
Da Du gerade das DEC angesprochen hast, sprichst Du da von Part II, da in Part I ja keine asym. Verfahren drin sind?
Gibt es den zweiten Teil schon irgendwo zum Runterladen oder kommt der erst noch?

mfG
mirage228

[Alienhere]

Zitat von negaH:

@Alienhere:

Zitat:

Du hast mich dank Deiner Kompetenz zum inkompetenten Idioten gemacht.

Quatsch, erstens wäre das niemals meine Absicht, zweitens ist es für mich nur wichtig das sich kein Halb-Wissen verbreitet und drittens sind die meisten "Fehl"-Aussagen meistens nur teilweise richtig also nicht grundsätzlich ansich falsch.

Zitat:

Was bleibt mir übrig, als Dir zu danken?

Dank will ich keinen, am wichtigsten ist es für mich mein Wissen mit anderen zu teilen, so das du neue Impulse und besseres Wissen bekommst

Grundsätzlich sollten wir alle die Aussagen anderer Menschen nicht immer so negativ sehen. Meine Absichten sind immer positiv, auch wenn mein Schreibstil manchmal sehr direkt, kurzgefasst und somit beleidigend wirken sollte.

... und akzeptiert!

Aber nur so nebenbei angemerkt:

Vielleicht solltest Du bei Deinen künftigen "Rundumaufklärungen" darauf hinweisen, daß Hash-Codes und MD5 eigentlich nichts anderes als mathematische Quersummen (CRCs?) sind, wobei:

ein mal neun ( 1 mal 9 als Ziffer) ist neun

sprich "9" (daraus wir eine neun)

das Gleiche ergeben könnte wie:

drei mal drei ( 3 mal 3 als Ziffer). Ist auch neun.

sprich "3" "3" "3" (daraus wird auch eine neun).

Klar, ich weiß, daß meine Beispiele etwas hinken!

Aba wenn schon, dann denn schon!

Solltest Du das bereits getan haben: Dann formuliere es doch bitte etwas leichter verständlich und verstecke es nicht irgendwo in einer 200zeiligen Antwort über Kryptographie, denn Hash-Codes und MD5 haben m.M.n. an sich mit Verschlüsselung erst mal überhaupt nix zu tun!

msfg
Alienhere

[mytar]

Ich bräuchte ja lediglich eine genaue Beschreibung wie das
RC4-Verfahren funktioniert, nicht den theoretische bzw. mathematischen Hintergrund!

Danke

[mytar]

Hab bei Google gesucht, aber nichts gutes gefunden!

Und vor allem nicht in Deutsch!

Gibt hier in der Community nicht jemanden der sich mal intensiv mit diesem
Verfahren beschäftigt hat?

Danke

[negaH]

Zitat:

Da Du gerade das DEC angesprochen hast, sprichst Du da von Part II, da in Part I ja keine asym. Verfahren drin sind?
Gibt es den zweiten Teil schon irgendwo zum Runterladen oder kommt der erst noch?

DEC Part I enthält keine asymmetrischen Verfahren.
DEC Part II ist offiziell nicht erhältlich, aber eine binäre "Distributation" für Delphi 5,6 und 7 kann man hier im Forum finden. Sie enthält auch die ECC in GF(p) samt Schlüssel- und Kurvenerzeugung nach IEEE P1565 Standard. Ich betone dies weil die meisten ECC Libraries es eben nicht ermöglichen eigene und sicherer Kurven zu erzeugen. Für Delphi selber kenne ich keine andere als meine Library die das kann.

Zitat:

Vielleicht solltest Du bei Deinen künftigen "Rundumaufklärungen" darauf hinweisen, daß Hash-Codes und MD5 eigentlich nichts anderes als mathematische Quersummen (CRCs?) sind, wobei:

Jay, das ist falsch. Hash Funktionen sind Hash Funktionen, eben so wie eine Addition eine Addition ist und nicht XOR, obwohl man in GF2 mit XOR addiert.

Ein wesentlicher Unterschied zwischen Hash Funktionen und CRC's oder Quwersummen, ist eben der Punkt das man NICHT vom Hashdigest auf die Daten zurückschließen kann. Selbst wenn also nur EIN Bit an den Inputdaten verändert wurde so muß ein komplett anderer Hashdigest rauskommen. Auf Grund eines Hashdigest + einem fehlerhaftem Input kann und sollte man nicht die korrekten Daten "berechnen" können. Ich betrachte hier eine Brute Force Suche NICHT als Berechnung.
So, nun Checksummen und Quersummen sollen es aber ermöglichen exakt und direkt das Fehlerhafte Bit in einem Datenstrom zu erkennen und zu korregieren. Wenn man also Checksummen mit irgendwas vergleichen wollte dann nur mit deren Nachfahren -> den Fehlerkorrektur-Algortihmen wie dem Red Salomon Code.
CRC's sind also die Vorläufer er ECC == Error Correction Codes.

Wenn es eine Gruppe von Algorithmen gibt die mit Hashfunktionen bestimmte Eigenschaften teilen, dann sind es die Komprimierungsfunktionen und Kombinatorische Verwürflungen == Combinatoric Shuffling. Denn Hash Funktionen sollten eine kleine Entropie von Daten in eine große Entropie im Hashdigest umwandeln. Nun Komprimierungen machen das gleiche, sie entfernen Redundanzen und somit sollte der Ausgabestrom kleiner als der Eingangsdatenstrom sein.
Desweiten solten Hashfunktionen bei Änderungen von nur EINEM Bit in den Eingangsdaten über deren Lawineneffekt kombinatorisch die Internen Register so verwürflen das zum Schluss zu diesen Daten ein komplett anderer Hashdigest rauskommt.
ABER, zu beiden Verfahren gibt es einen WICHTIGEN Unterschied zu den Hashfunktionen. Beide Verfahren können direkt die Ausgangsdaten zu deren entsprechenden Eingangsdaten zurückrechen,und das sollte bei Hashfunktionen nur, und ausschließlich nur, über eine Brute Force Suche möglich sein. Wenn also die hashfunktion 128 Bit breit ist, so müsste man per Brute Force Suche 2^128 verschiedene Kombinationen durchrechnen um die daten zu erhalten. Aber die gilt natürlich nur für Datenmengen <= 128 Bit. Bei Datenmengen > 128, zB. 129 bit wird es also schon 2 komplet verschiedenen Nachrichten geben die den gleichenHashdigest teilen. Bei Daten mit 256 Bits wird es also 2^128 verschiedene Nachrichten geben die sich jeweils EINEN der Hashdigest von 2^128 Digest teilen.

Mathematisch kann man daran erkennen das man bei Hashfunktionen mit 128 Bit Breite die Eingangsdaten bei 256 Bit Länge ihren Sicherheits-Breakeavenpoint haben. Man sollte also um beste Sicherheit mit einer 128 Bit Hashfunktion zu erlangen mit Daten größer 256 Bit arbeiten. Denn angenommen ein Angreifer versucht eine Brute Force Suche so hat er bei 256 Bit Inputdaten einerseits 2^128 verschiedene Hashdigest zu durchsuchen, wobei aber ein Hashdigest selber auf 2^128 verschiedene Eingangsnachrichten mappt. D.h. neben der dem Durchsuchen von 2^128 hashdigest müssen pro Digest noch 2^128 Nachrichten durchsucht weren, ergo: 2^256 Kombinationen effektiv.


@RC4:

tja, wenn es nur englische Literatur zu RC4 gibt dann muß man englisch lernen, ist leider mal so.
Im RC4 sich ganz verschiedene kryptographische Operationen enthalten, wie Transposition, Rekombination und eben die Substitution mit Hilfe einer veränderlichen und variablen Tabelle. Diese Tabellen nennt man meisten SBOX = Shuffling Box. RC4 kombiniert alle diese Verfahren nun sehr clever und das mit nur sehr sehr wenigen Operationen. Dies führt dazu das RC4 eben leicht zu codieren und denoch relativ effizient ist. Desweiteren ist es auch wichtig zu analysieren auf welcher Datenebene die einzelnen Operationen (Transposition, Substitution, Rekombination) stattfinden,ob eben auf Bit, Byte, Word Ebene. Nun RC4 arbeitet da auf Bit und Byte Ebene, was zusätzlich eine bessere Gesamtstärke ergibt. Dann fehlt noch die Fragestellung ob diese Operationen Linear oder Nichtlinear sind. Linear ist im Grunde schwächer, wenn man es schafft die Operationen nichtlinear auszulegen ohne die Gleichverteilung und Wahrscheinlichkeiten damit negativ zu beeinflussen. Nun, RC4 enthält solche Nichtlinearitäten. Eine solche Nichtlineare Operation könnte eine dynamische SBOX Indizierung sein (wie im RC4 auf den Inputdaten basierend) odr auch nur eine Multiplikation wie beim IDEA Cipher. Die Multiplikationhat abr den Nachteil das die nicht gleichverteilt auf den Schlüsselraum arbeitet, es ist also schwierige sie so zu kompensieren das sie wieder gleichverteilt arbeitet. Desweiteren ensteht ein Problem bei der Entschlüsselungen,d.h. die Multilikation bei der Verschlüsselung MUSS invertierbar sein. Nun, IDEA ist ein ideales Beispiel für die Anwendung einer solchen Multiplikation, und zwangsläufig ist IDEA ein Cipher der zur Verschlüsselungen einen komplett anderen Algorithmus benutzt als zur Entschlüsslung. D.h. beide Algorithmen sind nicht invers zueinander. Obwohl RC4 nun auch eine solche nichtlineare Operation enthält ist er denoch symmetrisch, man benutzt zur Ver- und Entschlüsselung den gleichen Algorithmus. Das funktioniert weil RC4 dafür den Datenstrom benutzt.


Ich könnte hier noch viel mehr erzählen, aber ab einer gewissen Stufe sprengt das den Rahmen für die Delphi Praxis. Dafür gibt es geeignetere Foren im WEB und natürlich viel viel bessere Experten mit weit mehr Wissen als ich es je haben werde.

Gruß Hagen

[mirage228]

Zitat von negaH:

Zitat:

Da Du gerade das DEC angesprochen hast, sprichst Du da von Part II, da in Part I ja keine asym. Verfahren drin sind?
Gibt es den zweiten Teil schon irgendwo zum Runterladen oder kommt der erst noch?

DEC Part I enthält keine asymmetrischen Verfahren.
DEC Part II ist offiziell nicht erhältlich, aber eine binäre "Distributation" für Delphi 5,6 und 7 kann man hier im Forum finden. Sie enthält auch die ECC in GF(p) samt Schlüssel- und Kurvenerzeugung nach IEEE P1565 Standard. Ich betone dies weil die meisten ECC Libraries es eben nicht ermöglichen eigene und sicherer Kurven zu erzeugen. Für Delphi selber kenne ich keine andere als meine Library die das kann.

Hi Hagen,

ich habe jetzt fast eine Stunde gesucht und dieses Attachment von Dir nicht gefunden
Könntest Du es vielleicht neu anhängen oder, falls Du noch weisst, wo Du das gepostet hast, mir den Link nennen?

mfG
mirage228

[Sharky]

Hai,

ich möchte auch mal etwas sagen *g*

Ich persönlich stufe alle Verschlüsselungsfunktionen im DEC als unsicher ein!
.
.
.
.
.
Warum?
.
.
.
Ganz einfach: Ich habe überhaupt keine Ahnung von der Mathematik die hinter den Verschlüsselungsfunktionen steht. Ausserdem kann ich viel zu wenig Assembler um den Quellcode von Hagen verstehen zu können. Darum muss ich das DEC als "unsicher" einstufen!

So, damit möchte ich überhaupt nichts gegen das DEC und noch viel weniger gegen Hagen sagen
Vielmer wollte ich damit mal in einem kurzen Satz das ausdrücken was Hagen selber immer wieder sagt. Wer nicht weiss wie ein System funktioniert; und somit auch die Softwareumsetzung nicht nachvolziehen kann muss die Verschlüsselung als unsicher ansehen.

[negaH]

Jo, das ist in der letzten Konsequenz absolut korrekt.

Jeder der nun denoch Kryptographie anwenden muß, steht vor der Entscheidung, einem Experten und deren Sourcen vertrauen zu müssen.
Jeder hat nun die Wahl auf die Meinungen vieler zu hören und das durch diese empfohlene Produkt zu benutzen, oder aber seine eigenen Algos. zu coden.

Sekundär stellt sich dieses Problem aber beim DEC nicht so sehr. Denn DEC selber ist ncht verantwortlich dafür ob ein Cipher mathematisch sicher ist oder nicht, sondern muß nur sicherstellen das die implementieren Cipher mit den offiziellen Testdaten übereinstimmende Resultate liefern. D.h. man kann eine Implementation mit Hilfe von Testvektoren querchecken. Natürlich habe ich das auch getan, wobei es aber eben nicht für jeden Cipher solche offiziellen Daten gibt.

Aber primär vertraut man nicht dem DEC wenn man es benutzt, sondern immer meiner Person und meinem hoffentlich fundiertem Wissen, und indirekt dem Wissen der Experten die die Cipher entwickelt haben

In dem Moment wo man vermuten oder vertrauen muß, wir eine Sache unsicher, denn im Grunde glaubt man nur und weis es nicht definitiv.

Gruß Hagen