Dateiverschlüsselungs DLL

[hamZta]

Am besten ich paste den ganzen Code mal hier rein

Delphi-Quellcode:

{     Dateiverschlüsselung, by hamZta                              }
{     - Zum Verschlüsseln CryptFile(datei, neuerName) verwenden    }
{     - Zum Entschlüsseln DeCryptFile verwenden                    }
{     Verschlüsselt und Entschlüsselt 500 Dateien in 6 Sekunden    }
library dll2;
  

uses
  SysUtils,
  Classes;
  

{$R *.res}
//Das Array in dem die Werte gespeichert sind
var key: Array[1..6] Of Byte;

function SetKey(k1,k2,k3,k4,k5,k6: Integer):integer; stdcall;
begin
    //Alle Werte füllen
    key[1] := k1;
    key[2] := k2;
    key[3] := k3;
    key[4] := k4;
    key[5] := k5;
    key[6] := k6;
end;

//Funktion zum Verschüsseln einer Datei
//  oldFile: PChar = Die Datei die verschlüsselt werden soll
//  newFile: PChar = Der Name den die verschlüsselte Datei bekommen soll
Function CryptFile(oldFile, newFile: PChar): integer; stdcall;
var oFile, nFile: File of Byte;
var cByte, currKey: Byte;
var i: Integer;
begin
  //Die neue Datei schreiben
  AssignFile(nFile, String(newFile));
  ReWrite(nFile);
  //Die alte Datei öffnen
  AssignFile(oFile, String(oldFile));
  Reset(oFile);
  //Hauptvorgang
  //Die ganze alte Datei durchgehen
  for i := 0 to FileSize(oFile)-1 do
    begin
      //Ein Byte auslesen
      Read(oFile,cByte);
      //Den aktuellen Keywert verändern
      currKey := currKey + 1;
      //Der Key ist nur 6stellig
      if currKey > 6 then currKey := 1;
      //Das Byte mithilfe von Xor und dem aktuellem Keywert verschlüsseln
      cByte := cByte Xor key[currKey];
      //Und in die neue Datei schreiben
      Write(nFile,cByte);
    end;
  closefile(oFile);
  closefile(nFile);
end;

//Die Funktion DeCryptFile ist genau dieselbe Funktion wie CryptFile
//(Existiert eigentlich nur der Übersicht halber :D)
Function DeCryptFile(oldFile, newFile: PChar): integer; stdcall;
var oFile, nFile: File of Byte;
var cByte, currKey: Byte;
var i: Integer;
begin
  //Write new File
  AssignFile(nFile, String(newFile));
  ReWrite(nFile);
  //Read old File
  AssignFile(oFile, String(oldFile));
  Reset(oFile);

  //Hauptvorgang
  for i := 0 to FileSize(oFile)-1 do
    begin
      Read(oFile,cByte);
      currKey := currKey + 1;
      if currKey > 6 then currKey := 1;
      cByte := cByte Xor key[currKey];
      Write(nFile,cByte);
    end;
  closefile(oFile);
  closefile(nFile);
end;

exports
  CryptFile name 'CryptFileA',
  DeCryptFile name 'DeCryptFileA',
  SetKey name 'SetKeyA';

begin

end.

Vielleicht kann ja irgendwer was damit anfangen

hamZta

[edit=Chakotay1308]Delphi- ([delphi]) statt Code-Tags ([code]). Mfg, Chakotay1308[/edit]

[titus]

hä?

Zitat:

//Die Funktion DeCryptFile ist genau dieselbe Funktion wie CryptFile
//(Existiert eigentlich nur der Übersicht halber :D)

[Matze]

Das verstehe ich auch nicht ganz, ist es also so, wie bei der XOR-Verschlüsselung, dass man eine Prozedur hat, die beides erledigt? :gruebel:

Wie sicher ist denn dieses Verfahren?

Edit: :shock: Das ist ja XOR :shock:

[hamZta]

dachte mir das das unverständlich ist
beispiel:
man hat eine Datei, verschlüsselt diese mit CryptFile("datei.bmp","verschluesselt.bmp").
jetzt könnte man diese Datei auch wieder mit CryptFile("verschluesselt.bmp","datei.bmp") in den Originalzustand versetzen, aber da dies bei langem Code verwirrend ist hab ich die 2te Funktion, DeCryptFile, gemacht.

verständlicher?

[titus]

Aso, für einen selber, damit man merkt: Aha die Datei hab ich ent bzw. verschlüsselt?
Richtig?

mfG

[hamZta]

richtig ;)
das ganze ist relativ sicher.
was is denn an xor so schlecht?

[Matze]

Zitat:

Zitat von hamZta

richtig ;)
das ganze ist relativ sicher.
was is denn an xor so schlecht?

Sicher? Also XOR ist die unsicherste Verschlüsselungsart, die ich kenne.

XOR haben wir auch schon in der Code-Library drin, siehe XOR. ;)
Eine viel bessere ist RC4, das haben wir hier auch: RC4 und, man kann eigentlich sagen, das Beste ist das DEC von Hagen Redmann(sry, falls es falsch geschrieben ist :roll: hier bekannt als negaH.

[negaH]

Zitat:

richtig
das ganze ist relativ sicher.
was is denn an xor so schlecht?

Sorry, du meintest wohl relativ unsicher, richtig ?

Ok, ich schicke dir Daten die du dann verschlüsseln sollst. Diese Daten könnten Zb. am Anfang aus 24 Bytes Nullen bestehen. Verschlüsselst du mit deinem Algorithmus so kann ich anhand der Verschlüsselten Daten in den ersten 24 bytes DIREKT deinen Schlüssel auslesen ! Probiere es und verschlüssele mal 24 Bytes aus Nullen und schaue dir danach den Output genau an.

So, da du aber Blockweise a 24 Bytes die Datei verschlüsselst ist jeder Block unabhänig vom anderen Block. Bei einer Datei mit 24 * 256 Bytes größe ist die Wahrscheinlichkeit ca. 50% für jedes dieser Bytes das es in der Datei vorher 0 war. Sogesehen könnte man mit sehr hoher Wahrscheinlichkeit direkt aus den verschlüsselten Daten den benutzten Schlüssel berechnen. Dies ist weit weit effizienter als wenn man alle möglichen Schlüssel durchbprobieen würde. Eine Verschlüsselung gilt dann als unsicher wenn es einen Weg zum Knacken gibt der schneller als eine Brute Force Attacke ist.

Komme mir jetzt nicht mit der Aufforderung "Hagen ich habe mal eine Datei verschlüsselt, kannst du versuchen dieses zu knacken ?, NEIN kann und werde ich nicht da es DEINE Aufgabe ist UNS zu beweisen das deine Verfahren sicher ist.


Gruß Hagen

PS: scherzhaft gesagt, ich habe schon bessere Verfahren zur Speicherung eines Passwortes in einer Datei gesehen ;)

[negaH]

XOR ansich ist nicht schlecht, nicht im gerngsten. Es ist eine Operation die mit absolut ausgewogener Wahscheinlichkeit zwei Datenbytes miteinander verknüpf. So gesehen ist XOR sogar eine perfekt lineare Operation für Veschlüsselungen.

Das Problem mit deiner XOR Variante ist nicht die XOR Operation sondern die Daten->der Schlüsselstrom mit dem due die Nachricht verschlüsselst. Dieser ist absolut unsicher, da du
1.) direkt den Schlüssel dazu benutzt, und somit die verschlüsselten Daten einen direkten Zusammenhang zum Schlüssel + Daten bilden
2.) du jeden Block unabhänig von den anderen Blöcken verschlüsselst, und somit die Variations-Wahrscheinlichkeit für verschiedene Angriffe drastisch erhöhst.

Die RC4 Verschlüsselung ist auch eine XOR Verschlüsselung, allerdings gibt es
1.) keinen direkten Zusammenhang von Schlüssel zu den Daten + verschlüsseltem Output
2.) produziert RC4 eine kontinuierlichen Schlüsselstrom bei denen es keine Wiederholungen gibt, sprich keine Blöcke
3.) wurde RC4 von anerkannten Kryptoexperten analysiert und schon seit Jahren als sicher bestätigt

Gruß Hagen

[DP-Maintenance]

Dieses Thema wurde von "Chakotay1308" von "Neuen Beitrag zur Code-Library hinzufügen" nach "Sonstige Fragen zu Delphi" verschoben.
Beitrag ist nun hier in der Code-Library zu finden.

[benst]

Zitat:

Zitat von hamZta

richtig ;)
das ganze ist relativ sicher.
was is denn an xor so schlecht?

XOR-Verschlüsselung ist sicher, wenn...

• der Schlüssel genau so lang wie die geheime Nachricht ist

• der Schlüssel aus einem echten Zufallsgenerator (mit statistischem Gleichgewicht) gewonnen wird, z.B. thermisches Rauschen, radioaktiver Zerfall, ...mehr dazu

• der Schlüssel darf nur ein einziges Mal verwendet werden (bei der nächsten Verschlüsselung muss ein neuer Schlüssel erzeugt werden)

Dann ist diese Verschlüsselungart (auch genannt One-Time-Pad) nicht nur relativ sicher, sondern nachweisbar unknackbar :-D .
Nachteile: :(

• der Schlüssel kann nur einmal verwendet werden

• der Schlüssel ist ziemlich lang

Gruß
Ben

[brechi]

rein programmiertechnsichfrag ich mich warum du

1) SetKey ne funktio nist die eh nichts zurückliefert
2) SetKey integers übergeben bekommen kann obwohl eh nur bytes benutz werden d.h. die keyanzahl minimiert sich auf 256^6;
3) Du 2 mal die Crypt Routine hast, könntest auch in der decrypt deine crypt routine aufrufen

kannst ja mal mit
SetKey(36864,43264,50176,57600,65536,73984,82944);

aufrufen und schaun wie toll die datei verschlüsselt ist ;P

[negaH]

@Beni

Zitat:

der Schlüssel aus einem echten Zufallsgenerator (mit statistischem Gleichgewicht) gewonnen wird, z.B. thermisches Rauschen, radioaktiver Zerfall

Diese Aussage halte ich für falsch. Man sollte in der Kryptographie NIEMALS echten Zufall benutzen.
Warum nicht ? Um das zu erklären betrachten wir den Hauptunterschied zwischen Echten Zufall und Pseudo Zufall, die Quelle ->

- echter Zufall -> Quelle sind physikalische Ereignisse bei denen man annehmen MUSS das sie zufällig wären
- Pseudo Zufall -> Quelle ist eine mathematische Formel die man somit auch mathematisch beweisen kann

Der Große Unterschied besteht also darin ob man die Zufälligkeit des erzeugten Zufalls auch wirklich zu 100% mathematisch beweisen kann. Nun echter Zufall ist niemals mathematisch beweisbar zufällig, darin liegt ja die Bedeutung des Wörtchen "echter". Denn zum heutigen Zeitpunkt sind die physikalische Vorgänge auf Grund deren wir den ZUfall erzeugen eben bei weitem nicht 100%'tig mathematisch analysiert, noch bewiesen, oder sogar auf Grund ihrer Komplexität für uns Menschen nicht beweisbar zufällig. Das bedeutet das wenn man einen echten Zufallsgenerator benutzt sich sozusagen auf Annahmen der Physiker verlassen muß, man muß also glauben das der produzierte Zufall auch wirklich echt zufällig ist, man kann es aber NIEMALS definitiv wissen.

Deshalb sollte man Pseudo Zufallsgeneratoren in der Kryptographie benutzen. Denn bei diesen Generatoren ist die zugrundeligende Mathematik absolut bekannt, analysiert und beweisbar. Man kann nun Pseudo Zufallsgeneratotren benutzen die mathematisch so konstruiert wurden das sie 100% beweisbar zu 100% sicher sind. Das dann einzigst sicherheitsrelevante Element wäre der Startwert=Seed des PRNG's. Nun dieser Seed sollte entweder in einbruchsicherer Hardware gespeichert werden oder zb. ein Input eine Menschens darstellen. Solange nun dieser Seed sicher ist kann der mit dem PRNG erzeugte Zufall nicht durch andere reproduziert werden.

Im Gegensatz dazu dann man einen Zufallsstrom eines "echten" Zufallsgenerators NIEMALS zu 100% mathematisch beweisbar als wirklichen Zufallsstrom erkennen. Wenn man als eine PRNG benutzt und damit Zufallsdaten erzeugt so kann man den Zufallsstrom NICHT von einem echten Zufallsstrom unterscheiden. Das Gleiche gilt auch umgekehrt: ein echter Zufallsstrom ist nicht unterscheidbar von einem PRNG Zufallsstrom. Und gerade aus diesem Grunde sollte man eben keinen "echten" RNG benutzen da man sich niemals 100%'tig sicher sein kann das die Hardwareauch wirklich das macht was sie uns verspricht, wir MÜSSEN also glauben das HW-RNG echten Zufall erzeugt, wir können es NIE wissen.

Das Sen der Kryptographie lautet: ALLES muß zu 100% mathematisch beweisbar sicher sein, also auch der benutzte Zufall. Die statistischen Zufallseigenschaften eines guten PRNGs unterscheiden sich in keinem Punkt von "echten" Zufall. Aus dieser Sicht sind beide Generatoren für die Kryptographie geeignet, aber eben mit dem Unterschied das wir beim PRNG uns mathematisch sicher sein können das er auch wirklich kryptographisch sicher ist, während dies beim HW-RNG niemals der Fall sein wird.

Jetzt könnte das Argument kommen das HW-RNG auf physikalische Ereignissen beruhen die der Mensch nicht vorhersagen kann. Ja, das stimmt auch aus unserer gegenwärtigen Sicht der Dinge und aus Sicht unseres aktuellen Wissenstand. Das muß aber nicht zutreffen auf "böse Ausserirdische", auf "Gott" oder für die Zukunft in der wir dann mit neuem Wissen sehr wohl in der Lage sein könnte diesen Zufall des HW-RNG vorherzusagen. All diese Wenn & Aber's und Unsicherheiten werden definitiv mit einem mathischen PRNG den wir absichtlich nach unseren Erfordernisse konstruiert haben ausgeschaltet. Wir können also bei einem Pseudo Zufallsgenerator absolut sicher sein das er exakt den Zufall erzeugt den wir benötigen. Dessen Sicherheit kann mathematisch zu 100% bewiesen werden.

Gruß Hagen

[benst]

Hi Hagen,
ich melde mich er jetzt, weil ich verreist war und nicht so viel Zeit hatte.
Vielen Dank für deine umfangreiche Antwort.
Ich habe recht viele Bücher gelesen und setze mich schon eine ganze Zeit mit dem Thema Kryptologie auseinander. Von dir höre ich zum ersten Mal, dass ein Pseudozufallsgenerator einem Echten Zufallsgenerator vorgezogen werden soll. Bisher habe ich immer nur von dem genauen Gegenteil gehört und gelesen. Mich würden daher Informationsquellen, die deine Argumentationsweise behandeln, sehr interessieren.
Meine Auffassung und Meinung kann ich leider nur aus dem mir bisher bekannten schließen. Zunächst die für mich beiden springenden Punkte:

Echter Zufall:
Es ist wahr, dass wir nicht mit 100%iger Wahrscheinlichkeit sagen können, dass die genannten physikalischen Ereignisse wirklich zufällig sind. Aber ... ("... Die interessante Frage, ob es überhaupt echten Zufall gibt, führt in die Philosophie und hat zumindest für die nächsten Jahre keinen Einfluss auf die Qualität der Zufälligkeit solch eines physikalischen Prozesses. Tatsache ist jedenfalls, dass es heute für Menschen unmöglich ist, zukünftige Ereignisse eines derartigen Prozesses vorherzusagen. Auch wenn es verborgene Parameter gäbe, die einen scheinbar zufälligen Prozess deterministisch beschreiben, wäre dieser Prozess zufällig, weil wir die Parameter nicht kennen. ..." Angewandte Kryptographie, Wolfgang Ertel)

Pseudozufall:
Wie du schon gesagt hast, hängen die Zufallszahlen eines Pseudozufallsgenerator, wenn der Algorithmus gut ist, zum größten Teil von den „seed numbers“ ab.

Mein Schluss:
Ich erachte es als wahrscheinlicher, dass ein Computer in absehbarer Zeit die seed number (bzw. die in Frage kommenden seed numbers) aus einem Teil der Zufallszahlen bestimmt und somit auch die folgenden Zufallszahlen bestimmen kann, als dass wir in absehbarer Zeit die physikalischen Ereignisse in diesem Maße beschreiben können.

Anmerkung: Es gibt Module, die "echten Zufall" aus thermischen Rauschen gewinnen und nachträglich mit einem Mikrokontroller nachbearbeiten (statistische Qualität gewährleisten und so).

Wie schon gesagt, ist mir dein Ansatz neu und mich interessiert diese Auffassung – konnte dazu bisher jedoch nichts finden. Wäre nett, wenn du mir Quellen nennen könntest.
Gruß
Ben

[negaH]

Zitat:

Wie schon gesagt, ist mir dein Ansatz neu und mich interessiert diese Auffassung ? konnte dazu bisher jedoch nichts finden. Wäre nett, wenn du mir Quellen nennen könntest.

Jo, mich als Quelle. Wie ich oben sagte ist das ausschließlich meine Meinung, stehe aber damit nicht alleine dar.

Es geht bei dieser Diskussion nur um eine einzigste Fragestellung: Was können wir mathematisch beweisen ?

Wir können beweisen das ein guter Pseudozufallsgenerator nur ausschließlich in der Vorhersagbarkeit von seinem Seed abhängt falls man

1.) die Schranken=Komplexität hoch genug wählt, dafür gibt es Formel'n -> siehe MOV Bedingung erklärt in "Handbook of Applied Cryptographie" von Menezes, van Oorschot und Vanstone, oder im IEEE Standard P1363 für Kryptographie.

2.) das verwendete Verfahren so lange sicher ist bis es gebrochen werden kann, dies wird man meistens veröffentlichen oder wird Konsequenzen in den entsprechenden Standards haben wie AES, PKCS#, P162, PGP, SRP, Internet Protokollen, nationale Standards der Japaner, Europäer, Amis, NIST, GOV-RU usw. usw. usw. haben. Deshalb sollte man immer ein öffentliches Verfahren benutzen wie zb. MD5, SHA, RipeMD usw. usw.

In all diesen Fällen reden wir immer von menschlichen mathematischen Konstrukten die zu 100% durch den Menschen konstruiert wurden.

Bei echten Zufallsgeenrtoren reden wir von:

- thermischen Sensoren die das Rauschen messen
- radioaktiven Sensoren die den radioaktiven Zerfall messen

uva. physikalischen Prozessen.

Bei diesen Prozessen ist es unmöglich die Zufälligkeit tatsächlich mathematisch zu beweisen, egal ob man im nachhinein die Entropie der Datenströme noch elektronisch verbessert. Wichtig ist einzigst und alleine das bei einem TRNG niemals beweisbar sicher die Quelle als wirklicher TRNG indenzifiziert werden kann.

Noch dazu kommt der Fakt das wir in der Kryptographie überhaupt nicht "echten" Zufall benötigen ! Wir benötigen nur einen Datenstrom dessen Bit-Eigenschaften sich wie Zufall verhalten aber nicht echt zufällig sein müssen. Wichtig ist nur das dieser Bitstrom NICHT ohne den Seed reproduzierbar sein darf (in erträglicher Zeit und mit mathematisch korrekter Abschätzung des nötigen technsichen Aufwandes).

Es ist also wichtig das alle Faktoren in der Kryptographie absolut berechnenbar und beweisbar sind.

Ich stimme also obigem Zitat in keinster Weise zu. Heutzutage hat ein Kryptograph durchaus die Wahl zwischen "True RNG's" und "secure PRNG's". Deren relevante Eigenschaften der produzierten Datenströme sind kryptrographisch gesehen von gleicher Qualität, mit dem einzigsten Unterschied das TRNG's nicht beweisbar sind, PRNG's aber 100%'tige Konstrukte der Menschheit sind, ergo 100% beweisbar sicher konstruiert sind und 100%'tig sicher betrieben werden können.

Also, warum? sollte ein Kryptrograph denoch mit TRNG's arbeiten wollen ? Nenne mir nur einen vernünftigen Grund.

Gruß Hagen

[negaH]

Achso fehlt noch die Frage der "Philosophie des Zufalls".

Darüber sollen sich Physiker und Philosophen streiten. Wir als Mathematiker und Kryptographen interessieren uns in keinster Weise ob Zufall zufällig ist. Wir gehen auf Nummer sicher und nehmen keinen echten Zufall sondern produzieren auf beweisbar sicherer Art & Weise einen Bitstrom dessen Eigenschaften ohne den Seed dem echten ZUfall gleichen aber beweisbar sind.

Das IST der relevante Unterschied, denn ein Kryptograph kann sich nicht auf die Standhaftigkeit der Thesen der Physik oder Philosophie verlassen, er MUSS isich sicher sein, alle anderen Wissenschaften dürfen sich irren ohne Konsequenzen.

Gruß Hagen

[benst]

So habe ich das ganze noch nie betrachtet...
Werde weiter darüber nachdenken und mich weiter schlau lesen - speziell unter dem neuen Gesichtspunkt.

Ich habe mich bisher noch nicht wirklich mit Pseudozufallsalgorithmen beschäftigt. Wie lang ist denn die Periode bei gängigen Algorithmen?

Gruß Ben

[negaH]

Zitat:

ch habe mich bisher noch nicht wirklich mit Pseudozufallsalgorithmen beschäftigt. Wie lang ist denn die Periode bei gängigen Algorithmen?

Es gibt wirklich tausende von solchen Algrithmen, im Gegensatz zu zb. TRNG Hardware !!
Die Periode könnte man auf unendlich hochschrauben wenn man unendliche Resourcen hätte. Allerdings spielt im Bereich der Kryptographie die Periode eine eher untergeordnete Rolle, 2^128 wären absolut ausreichend, 2^2048 wären besser :)

Viel wichtiger sind die restlichen Eigenschaften der Verfahren, wie eben ob sie tatsächlich mathematisch bewiesen sicher sind. Es kursieren nänmlich viele halb-wissenschaftliche Verfahren deren math. Beweise sich oberflächlich betrachtet sauber anhöhren aber im Grunde nicht hieb und stich fest sind. Ein solches Verfahren ist ISAAC.
In diesem Sektor sollte man sich wirklich auf echte Mathematiker verlassen, zb. der Quadratische Restegenerator auch genannt Blum Blum Shub Generator nach seinen Entwicklern gilt als sehr sehr sicher. Vorrausgesetzt man arbeitet entsprechend der MOV Condition mit Primzahlen > 512 Bits.
Oder ein ganz anderes Verfahren, dessen Beweis aber viel schwieriger ausfällt, sind alle YARROW like RNG's basierend auf Bruce Schneier. Dabei wird der math. Beweis zweistufig geführt. Einmal der analytisch logisch Beweis den Bruce Schneier anführte um zu beweisen ads man eine secure Message Digest Funktion, auch Hash-Funktion genannt so umbauen kann das sie als PRNG arbeitet. Der zweite Bestandteil des Beweises liegt in der Begründung warum einen gewählte Hash Funktion sicher sein muß. Nun Bruce Schneier musste diesen Beweis leider nich anführen, das ist Aufgabe der Entwickler wie John Rivest für zb. MD4,MD5,SHA usw.

Und fehlt noch die Frage nach dem sicheren Startwert==Seed. Hier zeigte es sich das echter Zufall ebenfalls nicht stark genug sein kann. Viel besser sind "Zufalls-ereignisse" die eine ganz ganz individuelle Signatur aufweisen. Sprich also Human Input, eine Menschliche Eingabe, aberam sichersten wäre es definitiv ein super gut gewähltes Passwort zu benutzen. Alleine schon aus Gründen der Verifizierbarkeit. Denn jede zusätzliche Möglichkeit die Wirksamkeit eines Verfahrens reproduzierbar und denoch sicher zu überprüfen wird ein zusätzlicher Sicherheitsgewinn sein. Wir müssen also wissen und überprüfen das alles so funktioniert wie es auch soll. Jede kleine Ungereimtheit,sei es unberechenbarerechter Zufall, seien es nicht lesbare oder verfügbare Sourcen der Implementierungen, seinen es unberechtigte Nutzer oder unsichere Betriebssystem etc.pp. wird die Sicherheit des Gesamtsystemes reduzieren.
Fragt sich ob es die 100%'tige Sicherheit überhaupt geben kann.

Schau mal: ein Kryptograph versucht doch nur die Un-Sicherheit in Schranken zu setzen. Für ihn bedeutet ein Algorithmus wie DES der nun gebrochen wurde eben NICHT Unsicherheit sondern im Geneteil es ist eine Form der Sicheheit. Denn nun weis er das dieses Verfahren nicht mehr für seine Zwecke taugt, und dieses Wissen bedeutet wiederum einen Sicherheitsgewinn. Am schlimmsten für einen Kryprographen ist die Unsicherheit des Nicht-Wissens.

jedes kryptographsiche Verfahren ist mathematisch beweisbar gleichmaßen sicher wie auch unsicher, und dies bedeutet absolute Sicherheit. Denn auf Grund dieser Eigenschaften wissen wir exakt bei welchen Schranken ein Verfahren geknackt werden kann und somit unsicher ist. Dies umfasst den mathematischen Beweis wie auch die zur Verfügung stehende Technologie und auch die weitere Entwicklung unseres Wissenstandes. Wir können also heute schon mathematisch eine Abschätzung treffen wann inetwa zb. die nötigen Computer zur Verfügung stehen um ein Verfahren praktikabel knacken zu können. Weltweit werden solche Entwicklungen mit Argusaugen verfolgt um frühzeitg die Schranken höherschrauben zu können. All dies IST eine Form der Sicherheit. Benutzen wir TRNG's dann verzichten wir freiwillig auf die Form des Wissens und somit Sicherheit. Somit ist Zufall im Grunde unerwünscht.

Gruß Hagen

[benst]

Zitat:

Schau mal: ein Kryptograph versucht doch nur die Un-Sicherheit in Schranken zu setzen. Für ihn bedeutet ein Algorithmus wie DES der nun gebrochen wurde eben NICHT Unsicherheit sondern im Geneteil es ist eine Form der Sicheheit. Denn nun weis er das dieses Verfahren nicht mehr für seine Zwecke taugt, und dieses Wissen bedeutet wiederum einen Sicherheitsgewinn. Am schlimmsten für einen Kryprographen ist die Unsicherheit des Nicht-Wissens.

Jo. Das hat man ja auch schon öfters in der Vergangenheit gesehen (e.g. Enigma).

Gracías - Du hast mir eine Menge Anregungen gegeben, mich mit der Materie zu beschäftigen - jetzt muss ich nur noch die Zeit (und Quellen) dafür finden. :coder:

Gruß Ben

[benst]

Hi Hagen,
habe mich mal ein wenig umgeschaut. Pseudozufallsalgorithmen gibt es einige... habe mich jedoch noch nicht in einen vertieft.
Vorerst bewegt mich noch die Thematik "Pseudo vor physikalische Erzeugung".

Zitat:

Jo, mich als Quelle. Wie ich oben sagte ist das ausschließlich meine Meinung, stehe aber damit nicht
alleine dar.

Das was du mir gesagt hast, klingt alles sehr einleuchtend und deine Antworten fand ich qualifiziert und sehr ausführlich. :thumb: Ich würde dennoch gerne andere Quellen über diese Thematik zu rate ziehen (du hast ja auch gesagt, dass du nicht alleine mit dieser Meinung dastehst), um noch mehr darüber zu erfahren und mich nicht allein auf eine Quelle zu stützen - ich hoffe du verstehst das. Ist ja im Sinn von Kryptologie, da sollte man nicht einfach alles so annehmen, sondern mehrere Quellen holen und dann alles selber prüfen. :coder2:
Im Netz konnte ich bisher keine entsprechenden Bücher, Artikel oder Ausarbeitungen finden. (An den meisten Stellen steht leider nur, man benötige echten Zufall, den man aus physikalischen Prozessen erhält.)
Hast du noch nen Tipp für mich, wo ich nach so etwas schauen kann?
Gruß
Ben

[negaH]

Jay, erwischt.

Ok, ich möchte hier keine unwahren Referenzen abgeben, ich weiß aber definitiv das Bruce Schneier in seinem Buch "Angewendete Kryptrographie" und auch im Buch "Handbook of Applied Cryptographie" von Menenzes, van Oorschot, Vanstone und in dem Buch "A Course in Computational Algebraic Number Theory" von Henri Cohen, ungefähr folgendes steht:

"In der Kryptographie existiert nur eine Wahrheit, die Wahrheit der analytischen Mathematik"

Das bedeutet das in jedem Falle die Sicherheit der Kryptographie ausschließlich nur auf mathematischen Beweisen fussen darf.

Daraus leite ICH für MICH analytisch korrekt die Aussage ab, das wenn man physikalischen Zufall nicht mathematisch beweisen kann dieser für die Kryptographie absolut untauglich sein muß.

Ich gebe dir absolut recht mit der Aussage das man diese Implikation nirgends zu lesen bekommt. Ich weis nun nicht warum dies so ist, entweder weil es den Mathematiker'n schnuppe ist, oder einfach zu trivial, oder sie ihren Kollegen den Physikern nicht vor den Kopf stossen wollen. Aber eines weis ich ganz genau: analytisch & logisch betrachtet muß meine Aussage richtig sein.

Eines werde ich aber garantiert machen, wenn ich das nächste mal meinen Mathematik-Experten (ein echter Statistiker) wieder an der Strippe habe werde ich ihm exakt die gleiche Frage stellen. Gefühlsmäßig weis ich aber jetzt schon welche Antwort ich zu erwarten habe, eine infinitve wie für Mathematiker so üblich.

Gruß Hagen

[Boldar]

Nur um das Thema hier mal abzuschliessen, (Ich weiss, dass das uralt ist, aber diese Falschaussagen hier zu sehen ist ja schrecklich)

Die absolute Zufälligkeit von bestimmten physikalischen Verfahren (thermisches Rauschen, Quantenzerfall) ist mathematisch BEWIESEN

Siehe auch Heisenberg-Ungleichung

[gammatester]

Zitat:

Zitat von Boldar

Nur um das Thema hier mal abzuschliessen, (Ich weiss, dass das uralt ist, aber diese Falschaussagen hier zu sehen ist ja schrecklich)

Da gebe ich Dir völlig recht und verstehe deshalb nicht, warum Du weitere hinzufügst :evil:

Zitat:

Zitat von Boldar

Die absolute Zufälligkeit von bestimmten physikalischen Verfahren (thermisches Rauschen, Quantenzerfall) ist mathematisch BEWIESEN

Siehe auch Heisenberg-Ungleichung

Das sind ja wohl nicht nur Falschaussagen sondern darüberhinaus ziemlicher Blödsinn. Ein physikalische Aussage kann man nicht mathematisch beweisen, auch wenn man es noch so kursiv und GROSS schreibt. Und gerade die Heisenbergsche Unschärferelation zeigt ja gerade, daß die beiden betrachteten konjugierten Observablen nicht absolut (was immer das nun wieder heißen mag) zufällig sind.

[negaH]

Ja und es geht auch noch weiter.

Was ich in meinen obigen Pamphleten nicht deutlich heraus gearbeitet habe ist: Reproduzierbarkeit.
Eines der wichtigsten Instrumente der Wissenschaften ist die Reproduzierbarkeit. Kann man ein Expermient beliebig reproduzieren dann gilt dies quasi als indirekter aber überzeugender Beweis.

Nun echter Zufall ist eben nicht reproduzierbar. Benutzt man echten Zufall in der Kryptographie als Input so ist die ganze Kette der ansonsten sehr wohl reproduzierben Kryptographie die nachfolgt ebenfalls nicht mehr reproduzierbar. Mit der Nutzung von echtem Zufall verzichtet man also bewusst auf diese Reproduzierbarkeit der Kryptographie und das ist Anti-Kryptographisch ;)

Beispiel: Eine Smartcard enthält kryptographsische Primitive und benutzt einen gesicherten PRNG. Kennt man den sicheren Seed dieser Smartcard indem man im Nachhinhein diesen abfragt so kann man alle vorherig getätigten Operationen reproduzieren. Egal ob man das dann auf einem Computer macht oder sogar auf einem Blatt Papier manuell berechnet am Ende müssen auf jedem beliebigem Rechenweg exakt die gleichen Daten rauskommen wie sie die Smartcard vorherig geliefert hat. Würde die Smartcard nun einen TRNG benutzen so kann man diese praktische Beweisführung über die Reproduktion, also Wiederholung, der Ergebnisse nicht mehr führen.
Wenn man aber ein Ergebnis in unserer Umwelt nicht wiederholen kann dann ist die zugrundeliegende Idee/Verfahren für uns wertlos. Unsere ganze Welt basiert auf Reproduktion von Ereignissen, oder leben wir im echt zufälligen Chaos und wissen nicht wo Hinten noch Vorne ist ?

Aus Sicht eines Kryptographen geht es also garnicht darum das er Zufall benötigt, er benötigt ein für ihn reproduzierbares System das Daten erzeugt die für jeden Nichtlegimitierten wie Zufall wirken, also beechenbar garantiert nicht reproduzierbar sind. Und sowas kann ein echter TRNG eben nicht bieten, den das hiese das der Kryptograph bewusst und gezielt alle Bedinungen die zum Resulat des TRNGs führten auch wiederholen, eg. reproduzieren kann. Das ist perse aber bei TRNGs ja nun nicht möglich, hat ja Heisenberg behauptet.

Ergo: das Anführen der Heisenbergschen VERMUTUNG ist eher ein Beleg dafür eben nicht TRNGs sondern krypographisch sichere PRGNs zu benutzen.

Der Kryptograph versucht bewusst Unfairnis zu rezeugen und die Tatsache dieser Unfairnis mathematisch per Beweis zu untermauern. Ein TRNG ist ein System das für beide Seiten, dem Kryptographen und Kryptologen gleichermaßen fair wir unfair ist. Damit ist ein TRNG ein untaugliches Instrument um Unfairnis zu konstruieren. Das Ziel dieser Unfairnis ist es das ein legitimierter Nutzer seine Daten mit seinem Geheimnis so schützen kann das alle anderen nicht legimitierten Nutzer eben nicht diese Daten entschlüsseln können.

Gruß Hagen