Dateien verschlüsseln

[negaH]

Hi Gina,

Fragen sind immer gut

Zitat:

1.) Heißt das, der Header wird mit PKCS#5 verschlüsselt?
2.) Und wozu wird SHA1 oder RIPEMD-160 benutzt?
3.) Und dieser Zufallswert (Salt), der in den ersten Bytes abgeöegt ist? Normalerweise würde man doch damit ein Passwort verschlüsseln um es zu speichern.
4.) Das wird doch aber nicht getan. (oder?)

1.) PKCS#5 ist ein Standard, ein technisches Papier das vorschreibt wie man mit welchem Algorithmen was verschlüsseln sollte. (ganz einfach ausgedrückt). Es gibt verschiedene solcher Standards und ich persönlich mag PKCS# nicht besonders weil er alt und amerikanisch ist. Das ist aber eine andere Sache und sagt reingarnichts über dessen Tauglichkeit aus. PKCS#5 ist gut und es ist absolut sinnvoll sich an solche anerkannten Standards zu halten.
Im Falle des Programmes geht es nur darum wie man aus einem Passwort eines Menschens ein technisch sicheres Passwort=Sessionkey erzeugt. Dazu wird ein zufälliger Salt == Zufallsbytes und eine Einweg Hashfunktion benutzt. Der Humankey + der Zufallswert landet in einer KDF=Key Derivation Function=Schlüsselableitungsfunktion um darin mit Hilfe von SHA1/RipeMD als Hashfunktionen einen sicheren Sessionkey zu erzeugen. Diesen Sessionkey kann man nur reproduzieren wenn man den Humankey + Salt + Verfahren kennt. Eine KDF dient also dazu einen zufällig aussehenden und nicht zurückrechenbaren aber reproduzierbaren sicheren Schlüssel zu erzeugen. Die Aufgabe der KDF ist der Schutz des Humankey denn wird durch eine Brute Force Attacke ein Schlüssel gebrochen so ist das nur ein KDF-SessionKey und nicht der reale HumanKey. Will man weitere Nachrichten brechen so muß man wiederholt eine neue Brute Force Attacke durchführen. Hätte man direkt mit dem HumanKey verschlüsselt so hätte man mit der erfolgreichen Attacke auf EINE Datei auch gleichsam ALLE anderen Dateien des Benutzers gebrochen. Ergo: eine KDF mit Zufallssalt schützt den Humankey vor Brute Force oder Dictionary Angriffen. Dictionary=Wörterbuch Angriffe zielen auf die Verwendung von schlechten HumanKeys ab. Zb. "Hagen" als Humankey ist echt unsicher und würde in einem Dictionary eines Angreifers gespeichert sein. Ergo: beschleunigen solche Dictionary Angriffe auf real benutzte Humankeys und somit die Kryptoanalyse. Um sowas zu verhindern dient ebenfalls die KDF und im ganz besonderen der Zufalls-Salt. Dieser macht aus dem zu kurzen und fixiertem HumanKey also bei JEDER Benutzung dieses Keys einen pseudo-zufälligen und nicht direkt rückrechenbaren Sessionkey. Die Hash Funktion verhindert dabei das direkte Rückberechnen des SeesionKeys in den HumanKey. Wie du siehst erst die Anwendung aller drei Merkmale -> HumanKey + Zufallssalt + Hashfunktion innerhalb einer KDF() sichert das ganze System gut ab. Und im PKCS# Standard wird genau beschrieben wie eine solche KDF aussehen könnte !! Es gibt bessere Standards, und denoch ist die Anwendung des PKCS#5 Standards weit weit besser als garkeine KDF zu benutzen.

2.) siehe 1.)

3.) siehe 2.) Wobei zu sagen ist das es ein Unterschied ist ob ich eine Berechnung "rückgängig" machen kann oder ob ich die gleiche Berechnung "wiederholen", also reproduzieren kann. Nun aus einem HumanKey + Zufallssalt + Hashfunktion kann ich zu jeder Zeit den gleichen Ausgangswert re-produzieren. Aber ohne HumanKey und nur mit dem Ausgangsprodukt + Hashfunktion + Zufallswert sollte man niemals in der Lage sein in erträglicher Zeitspanne den HumanKey zu berechnen. Deswegen heisen Hashfunktionen auch besser "secure Oneway Functions".

In dem benannten Program werden aber Salts auch noch an anderen Stellen benutzt. Zb. eben auch als Zufallswert der vor der Verschlüsselung des Headers an den Anfang des Headers gespeichert sind. Schau mal: der Aufbau und die Daten eines Headers sind bekannt, wir wissen das dort als erstes nach den Zufallsbytes das Wort "TRUE" stehen muß. Ohne Zufallsalt verschlüsseln wir also immer den absolut gleichen Header aber mit unterschiedlichen Schlüsseln. Die differentielle Kryptoanalyse macht sich genau dies zunutze. Sie kennt Mittel und Wege aus vielen inhaltlich bekannten aber verschlüsselten Nachrichten den benutzten Schlüssel schneller als eine Brute Force Attack zu berechnen. Und um exakt solche Angriffe zu verhindern wird die eigentliche Nachricht randomisiert. Aus der ursprünglich immer gleichen Nachricht wird durch den vorangestellten Zufallssalt eine komplett andere Nachricht gemacht. Solche Feinheiten sagen mir das die Konstrukteure des Programmes real nachgedacht haben und gutes Fachwissen der Kryptographie besitzen müssen.

4.) nach Aussagen der Programmierer der Software wird niemals, auch kein umgewandeltes Passwort des Benutzers gespeichert. Ob es real so ist kann ich nicht sagen, aber im Zusammenhang mit all den anderen Aussagen würde ich diesen Aussagen vertrauen wollen. Um zu erkennen ob das Passwort=HumanKey und die gewählten Algorithmen richtig sind wird ein verschlüsselter Header zu Testzwecken entschlüsselt. Sollte nach dem Salt das Wort "TRUE" im Plaintext stehen so geht die Software davon aus das alle Parameter korrekt sind. Erst nachdem sie alle verfügbaren Algorithmen mit dem HumanKey auf den verschl. Header angewendet hat, und keinmal das Wort "TRUE" im Plaintext stand wird die Software davon ausgehen das der HumanKey falsch sein muß. Durch diesen Trial&Error Trick wird das Verfahren probalistisch und ist nicht mehr deterministisch. Im grunde muß also selbst die Software eine "Brute Force" Attacke auf seine eigenen Daten durchführen. Aber eben mit wahrscheinlich korrektem HumanKey und somit ist der nötige Suchraum nur auf alle angebotenen Algorithmen beschränkt = 8 Stück. Ein potentieller Angreifer kennt aber weder den HumanKey noch welches der 8 Verfahren benutzt wurde. Ergo: erhöht sich der Aufwand für den Angreifer bei erträglicher Aufwandserhöhung für die Software. Allerdings halte ich persönlich nichts von solchen Konstrukten da sie eben nur minimal mehr Sicherheit bieten. Besser ist es die Sicherheit des Humankeys oder der Stärke der benutzen Algorithmen zu erhöhen. Aber zumindestens reduzieren solche Konstrukte NICHT die reale Sicherheit des Gesamtsystemes sie machen es nur komplizierter, also ist nichts einzuwenden dagegen. Ich stehe eben mehr auf simple=beautifull.

Ganz im Gegensatz dazu steht aber die Mehrfachverschlüsselungen, sprich wie in der Software möglich die Verschlüsselung mit zb. AES + Serpent + DES nacheinander. Bei solchen Konstrukten gibt es bisher fast keine fundierte Forschungsarbeit und überall wo sich die Experten darüber geäußert haben, meinten die Experten das man das tunlichst vermeiden sollte. Eben weil es keine Forschungen darüber gibt. Und eines ist absolut tödlich für jeden Kryptographen -> Unwissen und Glauben und Bauchgefühl. Kryptographen sind Konstrukteure der Mathematik, sie konstruieren sich immer eine beweisbare und vollkommen durchdachte Welt. Und die Mehrfachverschlüsselungen sind eben eine sehr schlechte Idee. Angenommen wir verschlüsseln mit AES eine Nachricht und danach mit DES. Bei einer ganz bestimmten Konstellation könnte aber DES eine Entschlüsselungsfunktion vom AES sein. In diesem Moment wäre die Nachricht wieder entschlüsselt worden und absolut unsicher. Und exakt diese Möglichkeit besteht rein theoretisch, und demnach müsste man AES + DES gemeinsam aus einem komplett neuem Blickwinkel analysieren um solche Konstellationen wissentlich und mathematisch beweisbar ausschließen zu können. Und exakt das hat bisher nich kein Mensch getan, ergo: Mehrfachverschlüsselungen sind als potentiell unsicher einzustufen.

Aber das macht ja nichts im Falle der Software, man muß das als Anwender nur wissen und dann stellt man die Software auf AES als alleinige Verschlüsselung ein, fertig. Somit nur ein Wermutstropfen.

Hoffe ich konnte deine Fragen beantworten.

Gruß Hagen

[Gina]

Hi Hagen,

tausend Dank für diese ausführliche Darstellung. Ich lese deine Beiträge immer wieder gerne

Nun ist mir auch endlich einiges klarer geworden. Danke dir...
Ich persönlich würde es auch bedeutend sicherer empfinden, wenn ich aus dem HumanKey+Salt+Iteration+hash einen anderen Schlüssel ermittle, um damit zu verschlüsseln.

Allerdings steht in der Doku:

Zitat:

Hash Algorithm
Allows you to select which hash algorithm TrueCrypt will use. The selected hash algorithm is used
by the random number generator (which generates the master key, salt, and the values used to
create IV and whitening values). It is also used in deriving the new volume header key.

TrueCrypt currently supports two hash algorithms: RIPEMD-160, which was designed by an open
academic community, and SHA-1 designed by the NSA and NIST.
Note that the output of a hash function is never used directly as an encryption key. Please refer to
the section Technical Details for more information.

Das verwirrt mich nun wieder. Ist das in deren Augen etwa unsicher, den Output einer Hashfunktion zu verwenden?

Nach deinen Erläuterungen hatte ich das jetzt so verstanden, dass mit dem Salt und dem Hash etc. der SessionKey erzeugt wird und dann damit der Header mit dem vom User ausgewählten Algo (AES etc.) verschlüsselt wird. Beim entschlüsseln wird anhand des eingegebenen HumanKeys wiederum ein SessionKey erzeugt und dann alle Algos damit duchprobiert, bis im Header TRUE steht. Anschließend steht nach meinem Verständnis nun der eigentliche Master-Key im Header, mit dem der Datenteil des Containers verschlüsselt ist...

An welcher Stelle verstehe ich nun etwas falsch?

Und was ist dieser IV (initialisation vector)?

Nochmals vielen lieben Dank, Gina.

[negaH]

Hi Gina,

deine Frage ist berechtigt. Nach nochmaligem durchlesen der Doku scheinen sich Teile davon zu widersprechen, und auch ich bin verwirrt. Es ist eben keine Software von mir persönlich und vielleicht solltest du die Entwickler mal direkt hinterfragen.

Aus dem obigen Abschnitt kann man einige Antworten ziehen. Zb. redete ich immer von einem Zufalls-Salt. Nur wie erzeugt man denn einen kryptographisch sicheren Zufall ? Auch dazu werden Hashfunktionen verwendet. Man benötigt einen nicht reproduzierbaren Input, zb. die individuellen Eingaben eines Menschens über die Tastatur oder die Maus. Die damit erzeugten Datenströme sind aber in ihrer Entropie nicht besonders geeignet. Deshalb benutzt man eine Hashfunktion um, wie zb. bei Bruce Schneier's Yarrow Verfahren, aus diesen Eingangsdaten kryptographisch sichere Ausgangsdaten zu erzeugen. Dazu muß man wissen was die besonderen mathematischen Eigenschaften der Hashfunktionen sind. Diese Funktionen versuchen einen digitalen Fingerabdruck aus beliebig großen Eingangsdaten zu erzeugen. Dabei ist es aber wichtig das wenn sich nur 1 Bit verändert hat in den Eingangsdaten das das dann einen komplett anderen Fingerabdruck erzeugen muß. Man nennt sowas auch Lawineneffekt, denn nur 1 Bit reicht aus um den kompletten Ausgangswert zu verändern. Mathematisch kommt man damit in Regionen die den Komprimierungsverfahren sehr sehr ähnlich sind. D.h. Hashfunktionen sind auch Komprimierungsfunktionen, sie komprimieren Daten mit wenig Entropie pro Informationseinheit in einen Ausgangswert der eine sehr hohe Entropie=Informationsdichte in Bezug auf die Eingangsdaten aufweist. Somit sind Hashfunktionen ebenfalls auch sehr gute Pseudo-Zufalls-Generatoren, und als zusätzlichen Nutzen sind sie nicht "vorhersagbar" = unpredictable. Die Vorhersagbarkeit bezieht sich dabei aber nur auf die Ausgangsdaten, sprich man versucht die Frage zu beantworten in wie weit es möglich ist auf Grund eines gegebenen Hash-Ausgangs-Bit-Stromes den nächst wahrscheinlichsten Bitzustand zu errechnen. Und genau das ist unmöglich mit heutiger Technologie und die mathematische Basis für die technische Unmöglichkeit aus einem Fingerabdruck auf die Eingangsdaten zurückrechnen zu können.

TrueCrypt benutzt also die Hashfunktionen um die nötigen Zufallsdaten für die Salts und verschiedene Schlüssel zu erzeugen.
Aber gleich nach diesem Absatz im obigen Auszug behaupten sie das TrueCrypt eben keine Schlüssel per Hashfunktionen benutzen/erzeugen würde. Das widerspricht sich natürlich.

Am besten du fragst direkt bei den Entwicklern nach, die werden konkreter antworten können.
Der Verweis auf PKCS#5 und KDF's in ihren Erläuterungen lässt mich aber mit 99% Sicherheit vermuten das sie sehr wohl mit Hashfunktionen ein gegebenen HumanKey in einen sicheren SessionKey für die Verschlüsselung umwandeln und benutzen.

About IV:
Ja das ist ein InitVector. Das ist ein Datenbereich der während der Verschlüsselung mit zb. AES im sogenannten Feedback Register des "äußeren" Algorithmus landet, als Initialisierung. Der IV sollte zufällig gewählt werden. Es gibt grob gesagt 2 wichtige Gruppen von symmetrischen Verschlüsselungsalgorithmen, die Strom-Verschlüsselungen und die Block-Verschlüsselungen. AES und DES sind Blockverschlüsselungen. Jede Blockverschlüsselung besteht aus mindestens 2 verschiedenen Algorithmen. Der innere Kern von Algorithmus ist das eigentliche Verschlüsselungsverfahren, eben AES,DES,Blowfisch etc. pp. Diese Algos. arbeiten immer nur auf einen festen Block von Daten, zb. 8,16 oder 32 Bytes. Würde man nur mit diesem "inneren Kern" alleine verschlüsseln so würde eine 256 Bytes große Nachricht also in kleine 8 Bytes große Blöcke zerlegt und jeder dieser Blöcke würde unabhängig von den anderen Blöcken verschlüsselt. Sowas ermöglicht ganz spezielle Angriffe, zb. könnte man so verschlüsselte Banküberweisungen eines Kunden abfangen, und dann Blockweise auseinanderschneiden das man daraus eine komplett neue Banküberweiseung an sich selber mit einem hohen Betrag erzeugen kann. Dazu muß man nur wissen welche Daten blockweise in den verschlüsselten Daten vorkommen. Ich animiere dich dann eine Übrweisung auf mein Konto über 15 Euro zu tätigen und fange aber alle deine Daten ab. Ich weis auch das du eine Überweisung der Miete von 1000 Euro getätigt hast und könnte nun den Block mit der Summe aus meinen Überweisungsdaten mit dem der 1000 Euro Überweisung austauschen. Das alles wäre möglich wenn man aussließlich nur den "inneren Kern", sprich das reine AES Verfahren benutzen würde. Deshalb gibt es einen "äußeren Rahmen" Algorithmus, den sogenannten Cipher-Modus. Dieser verknüpft über Feedback Register die Daten des vorherigen Blockes mit den Daten des nachfolgenden Blockes usw. usw. Somit gibt es einen virtuellen Nullten Datenblock VOR der eigentlichen Nachricht. Und das ist der Initvector der mit Zufallsdaten gefüttert wird. Klar, dieser Block wird mit dem 1. Nachrichtenblock XOR verknüpft und anschließend verschlüsselt. Dabei landet er als neuer Feedback Wert im Feeback Register für die Vorbehandlung des 2. Nachrichtenblocks usw.usw. So, nun kann ich nicht mehr deine Bankdaten zu meinem Gunsten manipulieren. Übrigens solche Angriffe sind real geschehen, also keine Fiktion.
Die Art und Weise WIE man nun die einzelnen Blöcke miteinander verbindet ist im Grunde vollkommen unabhängig vom "innern Kern" der Verschlüsslung, man kann also jeden Blockverschlüsselungs-Algo. einsetzen. Es gibt verschiedene solcher Verfahren wie CBC = Cipher Block Chaining, OFB = Output Feedback Modus, CFB = Cipher Feedback Modus, CTS = Cipher Text Stealing, CTR = Counter Modus etc. pp. Benutzt man nur den "innern Kern" so nennt sich das ECB = Electronic Code Book. Im ECB sollte man ausschließlich NUR Zufallsdaten verschlüsseln oder eben andere Ciphermodis drüberstülpen. TrueCrypt benutzt CBC. Interessant ist der Fakt das er seit relativ sehr kurzer Zeit sich die Kryptologen über die beste Sicherheit dieser Ciphermodis Gedanken machen. Die Ciphermodis wurden immer eher stiefmütterlich behandelt. Erst mit dem AES Auswahlverfahren des NIST, das bekanntlich Rijndael = AES gewann, gibt es auch eine Auswahlverfahren für die Ciphermodis.

Der IV ist also wichtig um den 0. Block zu bilden. Damit man wieder entschlüsseln kann muß dieser IV aber lesbar an die Nachricht drangehangen werden. Durch das Befüllen mit Zufallsdaten und der verketteten Benutzung im Ciphermodus wird die Nachricht randomisiert. Alledings tendiere und empfehle ich nicht einen Zufalls-IV ansich zu verwenden sondern vor der Verschlüsselung einer Nachricht diese am Anfang mit Zufallsdaten zu randomisieren. Diese Zufallsdaten + die Nachricht werden dann sequientiell verschlüsselt. Somit ist das wie ein IV aber mit dem Unterschied das dieser "IV" in der eigentlichen Nachricht mitverschlüsselt wurde. Ein normaler IV wäre direkt unverschlüsselt und somit lesbar. Der Effekt dieses Salts ist identisch zum Zufalls-IV, aber die Sicherheit muß größer sein. Nebenbei hat es auch praktische Vorteile, eine Nachricht zu expandieren vor einer Verschlüsselungen ist meistens einfacher als an die Verschlüsselten Daten im Nachhinein den lesbaren IV "dranzuhängen". Wir hätten dann technisch gesehen einen Footer, ein Header wäre aber besser.

Nungut, ich bin schon wieder viel zu tief in die Materie eingedrungen, sorry

Gruß Hagen

[Jan]

Hallo Hagen!

Ich bin beeindruckt sowohl von deinem hart erarbeiteten Fachwissen, als auch von deinem Willen dein Wissen zu teilen.

Nun habe ich mich vor kurzen zu Studienzwecken mit Krypto-Verfahren beschäftigt. Erstmal auf simplem Wege (Monoalphabetische Substitution, Vigenère Chiffre etc..), wobei ich für jeden dieser und weiterer Verfahren chiffrierte Texte "knacken" musste.
Das hat dann auch mit Hilfe einiger simpler Java-Programme und statistischen Analysen sehr schnell geklappt.

Letzen Endes lief das Ganze dann darauf hinaus einen mathematisch anspruchsvolleren Algorithmus zu programmieren: Die RSA-Chiffre.

Nun habe ich bei der Dokumentation des Algorithmus' gelesen, dass dies ein public key Verfahren ist. Allerdings braucht man noch immer einen private key.
Nun frage ich mich was denn nun der Sinn ist mit 2 Schlüsseln zu arbeiten? der eine Schlüssel muss doch noch immer an den "Entschlüssler" übermittelt weren. Theoretisch habe ich doch während der Übermittlung also noch immer die selbe Sicherheitslücke wie bei Verfahren, die nur einen Schlüssel nutzen? Warum also der Aufwand?

Weiterhin frage ich mich, warum bei all dem Fachgesimpel über Verschlüsslungsverfahren (welchem ich höchst interessiert gelauscht habe) die RSA-Chriffre nie erwähnt wurde.
Das kann meiner Meinung nach 3 Gründe haben:
- Die RSA-Chiffre ist unsicher. In dem Falle hätte ich mich wohl falsch informiert.
- Die RSA-Chiffre ist ungeeignet zum Verschlüsseln größerer Datenmengen.
- Die RSA-CHiffre ist vom Prinzip her nur zu verschlüsselten Datenübertragung, nicht aber zum Verschlüsseln/Entschlüsseln von Daten geeignet.


Ganz nebenbei und nur um mal Korinthen zu kacken und zu zeigen, dass auch Hagen mal Fehler macht, was ich ja bisher für unmöglich gehalten habe:

Zitat:

2^256 * 8 = 2^260

Hast Du weiter oben geschrieben.

Aber ich denke wir beide wissen, dass das 2^259 ergibt. (2^256)*(2³)=2^(256+3)=2^259

Ahja und noch viel nebenbeier:
Das Stückchen Code zur xor Verschlüsselung was am Anfang dieses Beitrags gepostet wurde variiert nur unwesentlich von der Vigenère Chiffre und lässt sich innerhalb von einer Minute von meiner relativ simplen Java-Anwendung knacken.

So ich denke das war dann mal Alles.
Gruß
Jan

[negaH]

Zitat:

1.) Nun habe ich bei der Dokumentation des Algorithmus' gelesen, dass dies ein public key Verfahren ist.

2.) Nun frage ich mich was denn nun der Sinn ist mit 2 Schlüsseln zu arbeiten?

3.) der eine Schlüssel muss doch noch immer an den "Entschlüssler" übermittelt weren. Theoretisch habe ich doch während der Übermittlung also noch immer die selbe Sicherheitslücke wie bei Verfahren, die nur einen Schlüssel nutzen?

4.) Warum also der Aufwand?

5.) Weiterhin frage ich mich, warum bei all dem Fachgesimpel über Verschlüsslungsverfahren (welchem ich höchst interessiert gelauscht habe) die RSA-Chriffre nie erwähnt wurde ?

6.) 2^256 * 8 = 2^259

1.) ja, RSA ist ein Public Key Verfahren, oder viel besser ausgedrückt ein a-symmetrisches Verfahren

5.) eben weil im TrueCrypt ausschließlich nur symmetrische Verfahren angewendet werden, wozu RSA erwähnen

3.) nein, du machst einen Denkfehler. Verallgemeinert gesagt gibt es bei den asymmetrischen Verfahren mindestens zwei verschiedene Schlüssel-Formen: die Öffentlichen Schlüssel und die Privaten Schlüssel. Mit dem öffentlichen Schlüssel = public Keys werden Nachrichten ver-schlüsselt, dürfen aber mit diesem Schlüssel NICHT mehr ent-schlüsselbar sein. Mit dem Privaten Schlüssel = private Key kann man ent-schlüsseln sowie auch ver-schlüsseln. Willst DU eine Nachricht verschlüsselt an MICH senden so benötigst DU MEINEN Öffentlichen Schlüssel. Ich muß also, damit man mir eine Nachricht senden kann jedem meinen Öffentlichen Schlüssel zur Verfügung stellen. Mein Privater Schlüssel wird niemals an die Öffentlichkeit weitergegeben, er bleibt ausschließlich in meinen Händen.

Soweit so gut. Aber warum rede ICH von "verschiedenen Schlüssel Formen" ?
In der heute allgemeingültigen Literatur der Experten werden asymmetrische Verfahren immer so dargestellt das man zwei verschiedene Schlüssel benötigen würde. Ich persönlich erachte diese Sichtweise als einen Fehler der zu logischen Denkfehlern bei Leuten wie dir führen muß, wenn es um die Herleitung der verschiedenen asymmetischen Operationen geht (also auch das Verständnis wie man die Schlüssel verteilen muß)

Deshalb rede ich von verschiedenen Schlüssel-Formen ein und des selben Schlüssels. Anders ausgedrückt auf RSA bezogen. RSA kennt nur einen wahren Schlüssel, nämlich den Privaten Schlüssel. Mit diesem kann man
a.) ent-schlüsseln
b.) ver-schlüsseln
c.) die Öffentliche Schlüssel-Form erzeugen

Erklärbar wird diese andere, meine Sicht der Dinge durch:

a.) wird mit dem Privaten Key ent-schlüsselt so kann die Nachricht vorher mit der Öffentlichen oder Privaten Form ver-schlüsselt worden sein, diese Operation nennt man Verschlüsselung von Nachrichten, zb. um eben mir eine Nachricht zu senden

b.) wird mit der Öffentlichen Form eines Schlüssel eine bekannte Nachricht ver-schlüsselt so kann man dieses Produkt mit einem Ver-Schlüsselten Produkt der gleichen bekannten Nachricht der Privaten Schlüssel Form binär auf Gleichheit prüfen: das nennt man Verifizierung/Erzeugung einer Digitalen Signatur ! oder Authentifizierungs- Operation.

Wie du sieht ergibt sich aus der Definition der Schlüssel Formen ein logisch sauberes Bild wenn man erklären möchte wie die 2 wichtigsten Operationen der asymmertischen Verfahren auf Grund der unterschiedlichen Schlüsselformen entstehen. Desweiteren wird nun auch zwangsweise logisch erklärbar warum ich dir meine Öffentliche Schlüsselform zusenden muß damit du mir eine Nachricht an mich senden kannst.

Mathemtisch gesehen kenne ich KEIN asymmetrisches Verfahren bei dem der Öffentliche Schlüssel nicht direkt aus dem Privaten Schlüssel abgeleitet wird. Ergo: der öffentliche Schlüssel ist nur eine andere Form des Privaten und somit einzigst wahren Schlüssels.

Das Problem der falschen Definition in den Lehrbüchern kann später zu dramatischen Problemen beim Verständnis weit komplexerer asymmetischer Verfahren führen. Zb. die Secret Sharing Schematas: dort gibt es viele private Teil-schlüssel die selber aber zurückzuführen sind auf EINEN einzigsten privaten Schlüssel. Somit sind diese vielen privaten Teil-schlüssel nur eine andere FORM des einen einzigsten privaten Schlüssel. Um ein Geheimniss zu teilen, benötigt man beim Secret Sharing entweder viele eizelne öffentliche Schlüsselformen oder nur die eine einzigste gemeinsam benutze öffentliche Schlüssel Form. Es gibt also beim Secret Sharing viel verschiedene Schlüssel-Formen die alle von dem einen ganzen privaten Schlüssel abgeleitet werden können. Je nachdem WIE man diese Ableitungen durchführt entstehen unterschiedliche Arten des Secret Sharings. Der "wahre" Schlüssel beim Secret Sharing wird normalerweise zerstört damit eben nicht EINE Person alleine alle anderen Parteien die am Secret Sharing beteligt sind betrügen kann. Es gibt also nur einen einzigst wahren Schlüssel und alle anderen verteilten Schlüssel sind nur Formen dieses einen Schlüssels. Besitzt man diesen wahren Key so kann man alle Operationen alleine durchführen. Das ist natürlich beim Secret Sharing NICHT erwünscht.
Oder es gibt Verfahren bei denen die Bedeutung der privaten/öffentlichen/geteilten Schlüssel-Formen komplett verkehrt herum sind, eben auch das Secret Sharing. Sie werden bei den kryprographischen Operationen also exakt invers benutzt und deren Bedeutung/Namensgebung ist widersprüchlich zur normalen Definition der Schlüssel. Aber egal wie man es dreht und wendet, alle diese Schlüssel-Formen sind andere Formen des einen wahren Schlüssels.

Allerdings, das ist meine rein private und für meine Logik die richtigste Sichtweise der asymmertischen Verfahren und deren Schlüssel-Formen. Es ist zum Begreifen und Arbeiten mit Problemen am wichtigsten mit logisch richtigen Definitionen zu arbeiten. Meine Definition der Schlüssel-Formen macht reingarnichts an der Logik kaputt, verändert aber die Sicht der Dinge entscheidend.

c.) man kann also aus dem privaten Schlüssel = wahren Schlüssel-Form die Öffentliche Schlüssel-Form erzeugen, somit ist der Öffentliche Schlüssel nur eine andere Form des privaten Schlüssels. Natürlich macht man das weil die anderen Formen mathematisch gesehen nur bestimmte Operationen durchführen können, die aber mit dem privaten, wahren und einzigsten Schlüssel alle durchführbar sind. Findet man einen Weg aus der Öffentlichen Schlüssel-Form den wahren privaten Schlüssel zu berechnen so hat man das Verfahren geknackt ! Und mathematisch infinitv betrachtet kann man tatsächlich JEDE Öffentliche Schlüssel-Form in den wahren Schlüssel umrechnen, dafür gibt es mathematische Verfahren. Im Falle von RSA eben die Faktorization = Zerlegung einer Zahl in deren Primzahlen. Somit enthält die öffentliche Schlüssel-Form alle notwenigen Informationen zum wahren/privaten Schlüssel. Nur, diese Faktorization = Trap Door Funktion ist praktisch unmöglich in einem erträglichen Zeitrahmen durchzuführen !! Und diese Eigenschaft der neuen öffentlichen Schlüssel-Form des wahren/privaten Schlüssels IST der Grund warum RSA ein asymmetrisches Verfahren IST. Es ist die Grundlage damit RSA funktioniert. Ergo: alle verschiedene Schlüssel-Formen des einen wahren/privaten Schlüssels könnten wie bei symmetrischen Schlüsseln benutzt werden zur Ver-/Ent-schlüsselung. Nur deren unterschiedliche Form benötigt unterschiedliche mathematische Verfahren um das zu erreichen. Und die Komplexität dieser unterschiedlichen Verfahren auf Grund der unterschiedlichen Form ist ebenfalls unterschiedlich. Während man mit der einen Form sehr schnell alle Operationen durchführen kann, geht das mit der anderen Form des gleichen Schlüssels eben nicht so einfach, aber mathematisch betrachtet ist es durchaus möglich !!
Fazit: es ist FALSCH von unterschiedlichen Schlüsseln zu reden da es mathematisch gesehen NICHT unterschiedliche Schlüssel SIND, sowas suggeriert uns nur das diese Schlüssel was komplett anders wären, und behindert uns logisch zu begreifen WIE und WARUM die Verfahren funktionieren. Deshalb MEINE persönliche Definition der Schlüssel-Form !

2.) siehe gerade eben
Damit jeder eine Nachricht an mich ver-schlüsseln kann die nur ich wieder ent-schlüsseln kann.
Damit ich eine digitale Signature ver-schlüsseln kann die Andere mit der öffentlichen Schlüsselform nur verifizieren aber eben nicht selber neu erzeugen können.

4.) siehe gerade eben
Weil mit den restlichen Verfahren = symmetischen Verfahren, eben nicht die Eigenschaften der a-symmetrischen Verfahren möglich sind. Es sind komplett verschiedene Dinge die konstruiert wurden um komplett unterschiedliche Lösungen für Sicherheitsprobleme zu ermöglichen.

6.) gut aufgepasst ich hatte den Fehler selber kurz nach dem Post entdeckt habe ihn aber stehen lassen um ... ?


Gruß Hagen

[negaH]

Ok, ich glaube ich muß nochmal genauer auf die Schlüssel-Formen eingehen.

Wir machen mal ein gedankliches Experiment und versuchen aus einem symmetrischen Verfahren ein asyymetrisches zu machen. Wir werden dann sehen das auch bei asymmertischen Verfahren es im Grunde nur einen Schlüssel gibt, wie auch bei den symmetrischen. Aber das die unterschiedlichen Formen dieses einen Schlüssels dazu führen das man asymmetrische mathematische Operationen benutzen muß.

Wir haben einen Schlüssel, eine Ver-Schlüsselungs-Funktion und eine Ent-Schlüsselungs-Funktion. Soweit gleichen sich per se die symmetrischen und asymmetrischen Verfahren.

Während bei den sym. Verfahren die Ent-Schlüsselungs Funktion eine reine Inversion der Ver-Schlüsslungs-Funktion ist müssen Unterschiede bei den a-symmertischen Verfahren exitieren.

Beispiel RSA:

Der Schlüssel ist P*Q, zwei große Primzahlen und E der Exponent und D der Entschlüsselungs-Exponent. Auf E,D gehe ich mal nicht näher ein. Wichtig ist nur das man D nur berechnen kann wenn man P,Q kennt.

Verschlüsselung ist C = M^E mod (P * Q)
Entschlüsselung ist M = C^D mod (P * Q)

Gut soweit ist das alles noch symmetrisch !

Wenn wir aber N = P*Q, die öffentliche Schlüsselform erzeugen und oben einsetzen dann ist

C = M^E mod N
M = C^D mod N

Auch noch symmetrisch, ups.

Nun setzen wir aber vorraus das nur ICH die Variable D kenne und erzeugen kann. Also MUSS ich P,Q kennen. Es gibt nun zwei Wege dies sicherzustellen

1.) ICH habe P,Q selber erzeugt
2.) DU kannst N in P,Q zerlegen, sprich faktorizieren

Ha, nun ist es asymmetrisch, denn ICH habe eine einfache Multiplikation N = P*Q die sehr schnell auszuführen ist.
Du aber mußt N in P,Q zerlegen, was mathematisch durchaus möglich ist aber praktisch gesehen bei goßem N nicht durchführbar schnell zum Erfolg führen wird. Denn dazu benötigt man Milliarden von Jahren bei großen N.

Aber!! N enthält durchaus die extrahierbare Information über P und Q und ergo auch D. Somit ist N nur eine andere Form von P*Q,D also dem einzigst wahren Schlüssel.

Und nun haben wie ein a-symmertisches Verfahren.

Es bedeutet das der Inhaber des privaten, einzigst wahren Schlüssels ALLE Operationen mit einfachen mathematischen Formel durchführen kann.
Und es bedeutet das man diesen wahren Schlüssel in eine andere Form transformieren kann so das es nur noch hochkomplizierte und praktisch undurchführbare Verfahren gibt um das Gleiche wie mit den wahren Schlüssel durchführen zu können.

Wenn also P,Q -> D der wahre Schlüssel sind, und N eine abgeleitete Form mit gleichem Informations-Inhalt darstellt so EXISTIERT in Wahrheit nur EIN wahrer Schlüssel, aber unterschiedliche Formen desselben. Erst die unterschiedliche Form bedingt das man unterschiedliche math. Verfahren benutzen muß um das Gleiche mit diesen Formen machen zu können. Und in fact es existieren immer solche math. Verfahren nur deren Komplexität ist asymmetrisch zu den verschiedenen Schlüssel Formen verteilt. Es gibt also NICHT unterschiedliche Schlüssel, sondern unterschiedliche mathematische Verfahren die sich ergeben wenn man den wahren Schlüssel in eine andere Form transformiert.

Gut soweit RSA. Nun mal vereinfacht ein Secret Sharing:

Dabei geht es darum das eine Gruppe von Leuten ein Geheimniss teilen möchten. Also nur eine Gruppe von Leuten soll in der Lange sein dieses geschützte Geheimnis wieder entschlüsseln zu können.

Ganz einfach: Man nehmen einen langen Schlüssel, den WAHREN Schlüssel und zerlege diesen in 5 Teile für 5 Leute. Es gibt also nun 5 Teil-Formen des wahren Schlüssels. Auch hier wieder die Form als Trick der es uns nun ermöglicht darauf aufbauen ganz bestimmte Kryprographische Protokolle zu konstruieren. Aber mathematisch nicht so wie beim RSA, oder Diffie Hellman oder ElGamal etc. pp. Wichtig ist nur das wir wieder von Formen sprechen denn diese Definition verbaut uns eben nicht die korrekte Sicht auf die Dinge.

Gruß Hagen

[Gina]

Hallochen Hagen...

Ich danke dir wie immer für die beeindruckende Antwort Endlich hab ich auch verstanden, was IV ist...

Was die Verschlüsselung des Headers angeht, so hatte ich bereits bei den Entwicklern angefragt und auch in deren Forum. Dort wurde ich jedoch leider nur auf die Doku verwiesen... Naja, vielleicht versuch ich es ja nochmal. Schließlich kann ich ja jetzt meine Fragen etwas genauer definieren

Es ist auf jeden Fall alles super lehrreich für jeden, der irgendetwas in dieser Richtung entwickeln möchte (einschließlich mir ) Man lernt schließlich nie aus

Die Materie fasziniert mich eben und man kann sich sicher eine halbe Ewigkeit damit intensiv beschäftigen und weiß immer noch nicht alles...

@Jan:
Zum Anwendungsgebiet von asymmetrischen und symmetrischen Verfahren...

Ich weiß nicht, ob es dafür überhaupt eine klare Trennung gibt, aber eines steht auf jeden Fall fest. Die asymmetrische Verschlüsselung wurde erfunden, damit der Schlüssel (der öffentliche) gefahrlos ausgetauscht werden kann, ohne dass jemand damit die geheime Nachricht entschlüsseln kann. Dies geht nämlich nur mit dem privaten Schlüssel, wie Hagen so wunderbar dargestellt hat.

Wenn A an B eine geheime Nachricht schicken will, dann verschlüsselt er diese.
- Bei einer symmetrischen Verschlüsselung muss A an B zusätzlich den Schlüssel schicken, den auch A selbst benutzt hat. Das ist natürlich sehr risikovoll, denn wer den Schlüssel abfängt, kann nun alle Nachrichten zwischen A und B entschlüsseln.
- Bei einer asymmetrischen Verschlüsselung benutzt A den öffentlichen Schlüssel von B, um die Nachricht zu verschlüsseln. B entschlüsselt diese mit seinem privaten Schlüssel. Der öffentliche Schlüssel kann gefahrlos ausgetauscht werden, da niemand damit etwas entschlüsseln kann. Der private Schlüssel verläßt seinen Besitzer nicht und somit ist das Risiko extrem verringert...

Durch das komplizierte Verfahren bei einer asymmetrischen Verschlüsselung ist es in der Regel auch nicht sehr schnell und daher hauptsächlich für Nachrichten und kleinere Datenmengen geeignet. Alles, was man z.B. per E-Mail abwickelt.

Symmetrische Verschlüsselungen sind in der Regel sehr schnell und werden hauptsächlich für große Datenmengen eingesetzt, wie z.B. das Verschlüsseln von Festplatten (SafeGuard Easy oder w.o. TrueCrypt) oder Backups auf externen Medien. Dabei ist ja auch der Austausch des Schlüssels nicht erforderlich und bringt entsprechend auch nicht das oben geschilderte Risiko mit sich...

Ich habe schon oft Kommentare gehört wie: Nur die asymmetrische ist sicher, die symmetrische nicht... etc. Das ist in meinen Augen absoluter Schwachsinn. Beide haben eben ihr Anwendungsgebiet, und genau dort sind sie auch sicher

Das ist zumindest mein Verständnis von diesen beiden Verfahren...

Liebe Grüße, Gina.

[negaH]

Hi Gina,

deine Erklärung der verschiedenen Verfahren ist sehr gut, denoch möchte ich einige Bemerkungen dazu abgeben (kann mich mal wieder nicht beherrschen)

Vorweg, das was Gina schrieb ist ansich nicht falsch, nur meiner Meinung nach sehr einseitig gefasst.

Zitat:

ohne dass jemand damit die geheime Nachricht entschlüsseln kann. Dies geht nämlich nur mit dem privaten Schlüssel, wie Hagen so wunderbar dargestellt hat.

Sehr richtige Aussage aber wie immer muß man konkret den Blinkwinkel unter dem diese Aussage gemacht wurde klarstellen.

Also, im technisch praktikablen Sinne stimmt Gina's Aussage absolut.
Aber im infinitiven also rein mathematischen Sinne eben nicht

Fast jeder Public Key ist nur eine andere Form des Private Key, soweit dürfte das klar geworden sein. Daraus folgt das man jede Nachricht auch mit dem Public Key entschlüsseln können muß. Aber das dazu nötige Verfahren ist sehr komplex und benötigt zur praktischen Lösung enorm viel Rechenpower.

Ergo: theoretisch also alles knackbar, praktisch aber eben theoretisch unmöglich

Kryptographen sind sehr witzige und enorm unfaire Mathematiker Sie schütten absichtlich einen Berg Sand auf mit dem Ziel das derjenige der von oben den Berg runter will es viel viel leichter hat als Derjenige der den Berg hinauf muß. Sie wissen dabei ganz genau das es nur sehr wenige bekannte Wege den Berg nach oben gibt und spielen durch ihre Regeln also immer unfair. D.h. es ist bei jedem heutigen asymmetrischen sogar symmetrischen Verfahren sehr wohl möglich es zu knacken, nur sind die Hindernisse dahin absichtlich so hoch gewählt das es keine praktische Lösung dafür gibt. Kryptographen spielen also mit der Mathematik und konstruieren ihre eigene Welt.

Zitat:

Durch das komplizierte Verfahren bei einer asymmetrischen Verschlüsselung ist es in der Regel auch nicht sehr schnell und daher hauptsächlich für Nachrichten und kleinere Datenmengen geeignet. Alles, was man z.B. per E-Mail abwickelt.

Auch sehr richtig. Zur Ergänzung muß aber gesagt werden das alle technischen Verfahren die asymmetrische Schematas benutzen fast immer Hybriden sind. Ein solcher Hybride ist also eine Kombination aus symmetrischen und asymmetrischen Verfahren. Das hat eben hauptsächlich zwei Gründe:

a.) asymmetrische Verfahren sind langsam, kompliziert und sehr anfällig gegen viele Angriffe, symmetrische Verfahren sind schnell, einfach und robust.
b.) die "Gesamtsicherheit" der unterschiedlichen Verfahren (wenn man das überhaupt vergleichen darf) ist zu Ungunsten der asymmetrischen Verfahren. Sie sind für viele und recht simple Angriffe empfindlich.

Deshalb gilt, nutzt man ein asymmetrisches Verfahren wie RSA zum Austausch einer sicheren Nachricht:

- sollte ein großer Zufalls-Schlüssel erzeugt werden mit dem man per symmetrischen Verfahren die Nachricht verschlüsselt
- sollte dieser Zufalls-Schlüssel per RSA verschlüsselt werden
- beides zusammen wird an den Empfänger verschickt

Das ist hybrid und kombiniert die Vorteile beider Welten und erhöht sogar noch die Sicherheit.
Es gilt: verschlüssele niemals mit einem asymmetrischen Verfahren direkt eine Nachricht, nur Zufall/Pseudozufall sollte damit verschlüsselt/signiert werden. Denn besonders die asymmetrischen Verfahren sind anfällig auf zb. die Known Plain Text, Reply Attack etc.

Zitat:

Ich habe schon oft Kommentare gehört wie: Nur die asymmetrische ist sicher, die symmetrische nicht... etc. Das ist in meinen Augen absoluter Schwachsinn.

Dem stimme ich voll und ganz zu. Es ist sogar so das fast KEINES der Verfahren ansich sicher ist, der Aufwand es zu brechen ist nur utopisch hoch vorrausberechnet worden. Es gibt nur ganz wenige Verfahren bei denen man beweisen konnte das sie absolut sicher sein müssen, leider sind sie absolut untauglich im normalen Leben.
Die meisten Verfahren die in den letzen 50 Jahren geknackt wurden, meistens sehr unerwartet für die Mathematiker, sind die asymmetrischen Verfahren. Sie in kryptographische Protokolle zu integrieren ist ein sehr heikler Task. Viele teil erfolgreiche oder hypothetische (rein rechnerische) Angriffe auf PGP waren Angriffe auf das Protokoll in denen asymmetrische Verfahren benutzt wurden.

Es hört sich also alles sehr einfach an, ich erzeuge meinen RSA Schlüssel, erzeuge N aus P*Q und versende an jeden der es möchte diesen Öffentlichen Schlüssel. Schwups schon der erste Fehler unterlaufen. Denn so ist es ein einfaches für eine potente Organisation eine Man in the Middle Attack auszuführen und MEINEN öffentlichen Schlüssel durch einen anderen auszutauschen. Die Sicherheit reduziert sich sofort auf -100%.
Es reicht eben nicht einfach einen guten Schlüssel zu erzeugen und damit zu verschlüsseln. Das funktioniert mit symmetrischen Verfahren perfekt, wir wissen ja das wir den Schlüssel mit größten Sicherheitvorkehrungen austauschen müssen. Bei asym. Verfahren aber sind schon hunderte von Angriffen möglich in einem gleichen Szenario.

Deshalb meine ich: mathematisch gesehen sind beide Gruppen identisch sicher, meistens sogar die asym. Verfahren sicherer als alle anderen. Aber technisch praktisch gesehen sind die sym. Verfahren sicherer denn man kann keine groben Fehler in ihrer Benutzung machen.

Gruß Hagen

[Jan]

Hallo Gina, hallo Hagen!
Danke euch beiden für eure ausführlichen Antworten.
Ich denke das hat schon ein wenig Licht auf das ganze geworfen, besonders, die Sichtweise, dass der öffentliche Schlüssel eigentlich nur eine andere Form des privaten Schlüssels ist. Nun bin ich aber eigentlich noch viel mehr verwirrt. Tut mir leid, wenn ich nicht ganz durchsteige durch das was ihr mir zu erklären versucht. Es gibt da mehrere Punkte, die ich jetzt mit Hilfe von Zitaten und meinem Quelltext mal auseinander klamüsern will.
Zunächst mal verwirrt mich die Aussage von Hagen:

Zitat:

b.) wird mit der Öffentlichen Form eines Schlüssel eine bekannte Nachricht ver-schlüsselt so kann man dieses Produkt mit einem Ver-Schlüsselten Produkt der gleichen bekannten Nachricht der Privaten Schlüssel Form binär auf Gleichheit prüfen: das nennt man Verifizierung/Erzeugung einer Digitalen Signatur ! oder Authentifizierungs- Operation.

Also: Ich nenne die öffentliche Schlüsselform jetzt mal n, weil Hagen das in seinem mathematischen Kurzdarstellungen das auch so gemacht hat. Du behauptest also, dass ich eine Nachricht alleine mit dem öffentlichen Schlüssel verschlüsseln kann und dann das selbe mit dem privaten Schlüssel machen kann, und die jeweiligen Produkte vergleichen kann. Allerdings kann ich doch mit n alleine garkeine nachricht Verschlüsseln, dazu brauche ich noch immer das e, so wie es auch bei dir steht:

Zitat:

C = M^E mod N

und aus e ergibt sich ja durch das modulare Inverse d.
Und GENAU da habe ich jetzt ein Verständnisproblem, weil du immer so eindeutig getrennt hast zwischen Verschlüsseln mit dem öffentlichen Schlüssel und Entschlüsseln mit dem privaten Schlüssel.
Ich brauche ja schließlich auch zum Verschlüsseln der Nachrichicht eine Information e, von der ich ganz ohne Probleme auf d schließen kann. Somit muss ich doch als Nachrichtenempfänger auch Informationen über meinen privaten Schlüssel preisgeben.

Der einzige Ausweg den ich mir jetzt aus diesem Dilemma konstruiert habe war nun, dass ich d nur aus solchen e berechnen kann, die auf den bekannten Primzahlen p und q basieren, dass ich allerdings die Nachricht mit beliebigem e verschlüsseln kann und die Nachricht auf Grund des konstanten n mit dem zuvor auf p und q basierenden d entschlüsselt werden kann.

Dazu fehlt mir leider die mathematische Grundlage das für mich zu versichern. 2 Semester Uni-Mathe reichen da noch nicht.

Das würde heißen ich müsste das e garnicht speichern, sondern könnte es bei jeden Verschlüsslungsvorgang neu wählen.

Wenn das der Fall wäre, dann hätte ich mit einem Schlag das ganze Prinzip Verstanden.


Ich wollte ja noch meinen source posten, der ist allerdings "leider" in JAVA:

Code:

   //Der Konstruktor, welcher mir die Schlüssel generiert
         RSA(){
      BigInteger p = BigInteger.probablePrime(512, new Random());
      BigInteger q = BigInteger.probablePrime(512, new Random());
      n=p.multiply(q);
      BigInteger f = p.multiply(q).subtract(p).subtract(q).add(BigInteger.ONE);
      e=new BigInteger("3");
      while(f.gcd(e).doubleValue()!=1.0)
         e=new BigInteger(String.valueOf(prim(e.intValue()+1)));
      d=e.modInverse(f);
   }
          
         //verschlüsseln
   public BigInteger encode(BigInteger t){
      return t.modPow(e,n);
   
   }
   
         /entschlüsseln
   public BigInteger decode(BigInteger c){
      return c.modPow(d,n);
   }

In wiefern das ganze jetzt mathematisch sicher ist, weiß ich nicht, da ich nicht weiß wie Random implementiert ist und auch nicht wie BigInteger implementiert ist, aber ich mache das ganze ja auch nur zu studienzwecken.
Weiterhin weiß ich auch nicht sicher ob e eine Primzahl sein muss, da in der Dokumentation die ich hatte dazu nicht weiter was drin stand aber alle Beispielzahlen Primzahlen waren; aber schaden kann es ja eigentlich allenfalls der Laufzeit.

Was man meinem source entnehmen kann ist, dass ich das e speichere und für jeden Verschlüsselungsvorgang wiederverwende.

Irgendwie sind unsere Dozenten/Profs hier alle Armleuchter, von denen war nicht ein einziger in der Lage mir so eine ausführliche und halbwegs verständliche Antwort zu geben wie Hagen, auch dass ich solche Verständnisschwierigkeiten habe denke ich mal liegt an der absolut mangelhaften und teilweise widersprüchlichen Vorlesung. Werd doch bitte mal schnell Prof an meiner Uni!


Eine Frage habe ich noch:

Zitat:

Während bei den sym. Verfahren die Ent-Schlüsselungs Funktion eine reine Inversion der Ver-Schlüsslungs-Funktion ist müssen Unterschiede bei den a-symmertischen Verfahren exitieren.
----------

Verschlüsselung ist C = M^E mod (P * Q)
Entschlüsselung ist M = C^D mod (P * Q)

Gut soweit ist das alles noch symmetrisch !

Wo ist denn da die Verschlüsselung das "Inverse" der Entschlüsselung? Also unter invers verstehe ich das Verhältnis zwischen + und - oder * und /.

Naja beanspruche wieder viel zu viel von anderer Leute Zeit.
Ich bedanke mich auf jeden Fall für die aufklärenden Worte!
Gruß
Jan

[Gina]

Hallo ihr zwei...

Vielen Dank für deine ergänzenden Worte, Hagen. So schön konnte ich das nicht formulieren, aber gemeint hatte ich das auch in diesem Sinne

Man muss sich natürlich darüber im Klaren sein, dass die Definition von "sicher" bei einer Verschlüsselung immer nur relativ (bezogen auf den Stand der Technik) ist. Als AES damals in 2000 den Wettbewerb gewann, hieß es, dieser Algo sei nach aktuellem Stand der Technik, unter Berücksichtigung der sprunghaften zu erwartenden Entwicklung, für etwa 30 Jahre "sicher". Damit ist eben genau das gemeint, was Hagen die ganze Zeit schreibt. Mathematisch gesehen, kann jedes Verfahren geknackt werden, aber praktisch ist es eben abhängig von der Technik. Und wenn ich mit den besten Computern der Welt immernoch ("nur") 1000 Jahre brauche, dann ist das für denjenigen, der die Nachricht entschlüsseln will einfach zu viel...

@Jan

Vielleicht könnten dich auch die Projekte von www.distributed.net interessieren. Dort werden verschlüsselte Nachrichten per Bruteforce "geknackt". Die Nachrichten sind natürlich speziell für diese Projekte erstellt worden . Besonders die Statistiken sind sehr interessant. Weiß ich wie viele 100.000e Computer arbeiten gemeinsam an einem Projekt und teilen sich somit die Arbeit, was einer Vervielfachung von Rechenleistung etwa gleichkommt...

Und vielleicht wäre auch www.cryptool.de für dich interessant. Insbesondere das RSA-Kryptosystem, wo du jeden Schritt nachvollziehen kannst...

Soweit erstmal von mir, liebe Grüße, Gina.