Möglichst zufälliges Passwort (masterkey) generieren

[Satty67]

Hallo,

kurz zum Umfeld: Ich habe Dokumente, die verschlüsselt in einem Blob-Feld abgelegt werden. Alle Dokumente sind mit einem "masterkey" verschlüsselt, der ebenfalls in der gleichen Datenbank abgelegt ist.

Nur der "masterkey" ist durch das Benutzerpasswort verschlüsselt (mit RFC2898 erweitert). Das ganze deshalb, dass bei Änderung des Benutzerpasswortes nur der "masterkey" neu verschlüsselt werden muss, nicht alle gespeicherten Dokumente.

Beim Anlegen der Tabelle wird/soll ein zufälliger "masterkey" erzeugt werden... möglichst sehr zufällig, da er ja für die Lebenszeit der Datenbank gültig ist (evtl. wird es eine Möglichkeit geben, auch mit mehr Zeitaufwand den "masterkey" zu ändern, was aber dann in der Realität niemand machen wird).

Die eigentliche Frage: Wie komme ich einen einen möglichst schwer zu ermittelnden Masterkey?

Ein Byte-Array mit ca 32 Byte Länge sollte reichen, es wird mit AES256 verschlüsselt. Mein erster Ansatz war, das ich einen RandSeed-Wert ermittelt hatte und mit Random das Byte-Array gefüllt hatte. Bis ich dann drauf kam, das es ja immer nur Int.MaxValue (ca. 2 Mrd.) Möglichkeiten sind, die mit heutiger Hardware sehr schnell durchprobiert werden kann.

Selbst wenn ich für alle 32 masterkey-Bytes jeweils einen neuen RandSeed-Wert ermittele, sind das nur rund 64 Mrd. Möglichkeiten, was auch an sehr schnell zu knacken ist.

Meine aktuelle Überlegung ist, den "masterkey" zu verlängern (bis 1 MByte ist kein Thema). Bin mir aber nicht sicher, ob es funktional ist, den AES256-Encrypter mit einem 1 MByte Passwort zu füttern. Bevor ich jetzt aber nach ein paar Tagen drauf komme, das da auch ein Haken ist, werfe ich die Aufgabe auch mal hier ins Forum :wink:

[BUG]

Was hältst du von: CryptGenRandom.

[Satty67]

Das liest sich schonmal sehr gut, zumindest spare ich mir viele Codezeilen.

Bei einer Schwäche kann ich die Schuld auf Microsoft schieben.

PS: Ich glaube, die bereits in der Cryptography bereitstehende Klasse "Rfc2898DeriveBytes" greift auch auf diesen speziellen besseren Random-Generator zu.

[xZise]

Wieso wird den eine Zufallszahl unsicher, nur weil sie aus 32 bit breiten Worten besteht? Das Passwort ABC ist doch sicherer als A ;) (natürlich ist der Unterschied gering, aber es geht hier um die Idee).

Das heißt du könntest doch einfach einen Key nehmen und den zusammenbauen:

Delphi-Quellcode:

var
  pass : AnsiString[32];
begin
  for i := 1 to 32 do
  begin
    pass[i] := Random(256);
  end;
end;

Hagen weiß bestimmt genaueres, aber wenn du so ein 32 Zeichen langes Passwort zusammenbaust ist es sicher genug. Übrigens bringt da ein 1 MB großes Passwort herzlich wenig, da doch der Schlüssel eh maximal 512 Byte Bit lang ist oder?

[edit]Und du hast ja schon geschrieben, dass du AES256 nutzt, also ist dein Schlüssel 256 Bit lang, und das sind 32 Byte, und ein AnsiString der Länge 32 füllt nun mal 32 Bytes :) Passt also perfekt[/edit]

MfG
Fabian

[BUG]

Zitat:

Zitat von xZise (Beitrag 1048976)

Wieso wird den eine Zufallszahl unsicher, nur weil sie aus 32 bit breiten Worten besteht? Das Passwort ABC ist doch sicherer als A ;) (natürlich ist der Unterschied gering, aber es geht hier um die Idee).

Das Passwort mit random zu generieren ist unsicher, da nur 2^32 verschiedene RandSeed: Longint gibt. Der Wert von RandSeed allein bestimmt das Passwort.

Wenn ich die Passwörter ABC und ACB habe, und ich entscheide über ein zufälliges Bit, welches ich wähle, habe trotzdem immer noch nur 2 Möglichkeiten.

[Satty67]

Das Problem von Random hat BUG ja nochmal erklärt...

Zitat:

Zitat von xZise (Beitrag 1048976)

Übrigens bringt da ein 1 MB großes Passwort herzlich wenig

Der masterkey ist nicht direkt der key für AES256. Das ist die Basis (Passwort/Salt) um eine KEY/IV Kombination zu bilden, die dann natürlich die passende Länge haben muss. Aber grundsätzlich richtig, das nicht mehr als 32 Zeichen gebraucht werden, mein Problem war nur, die Zahl der BruteForce-Tests zu erhöhen.

Der Hinweis von BUG auf CryptGenRandom war schon passend.

[alzaimar]

Natürlich gibt es PRNG die kryptographisch sicherer sind, als das in Delphi implementierte Verfahren. Ich glaube, der Mersenne-Twister ist, richtig initialisiert, so ein Kandidat.

Ich denke, es würde auch ausreichen, die Reihenfolge des Befüllens zu ändern: Wenn man nicht weiss, das Du die Bytes einmalig von hinten nach vorne befüllst, oder drei mal um die Ecke, dann muss man eben doch ziemlich viel rumprobieren.

Delphi-Quellcode:

  For i := 0 to 255 do Bytes[i] := randomByte;
  ShuffleFisherYates(Bytes);

Deterministisch ist das ja, so wie bei allen PRNG, aber da soll mal einer drauf kommen. :stupid:

Alternativ kannst Du dir Krypto-Hardware besorgen.

[xZise]

Zitat:

Zitat von Satty67 (Beitrag 1048978)

Zitat:

Zitat von xZise (Beitrag 1048976)

Übrigens bringt da ein 1 MB großes Passwort herzlich wenig

Der masterkey ist nicht direkt der key für AES256. Das ist die Basis (Passwort/Salt) um eine KEY/IV Kombination zu bilden, die dann natürlich die passende Länge haben muss. Aber grundsätzlich richtig, das nicht mehr als 32 Zeichen gebraucht werden, mein Problem war nur, die Zahl der BruteForce-Tests zu erhöhen.

Okay so gut bin ich nun nicht in der Materie :D

MfG
Fabian

[Satty67]

Also mein größtes Problem war ja, das ich erstmal nicht wusste, welche Möglichkeiten in der vorhandenen Bibliothek stecken. Mit CryptGenRandom (und Google) kam ich dann auf die Lösung. Zu meiner Schande muss ich gestehen, dass ich den RNGProvider als Provider für eine RNG Verschlüsselung interpretiert hatte (vgl. AESProvider, DECProvider). :stupid:

Der spezielle RNG (RandomNumberGenerator) für Cryptologie kapselt scheinbar CryptGenRandom.

meine derzeitige Lösung sieht so aus:

Code:

public string GenerateRandomASCIIString(int length)
        {
            RNGCryptoServiceProvider rand = new RNGCryptoServiceProvider();
            
            byte[] randBytes = new byte[length];
            rand.GetBytes(randBytes);
            
            for (int i = 0; i < randBytes.Length; i++)
            {
                randBytes[i] = (byte)(randBytes[i] / 2);
                if (randBytes[i] < 33)
                    randBytes[i] = (byte)(randBytes[i] + 33);
            }
            
            string randString = Encoding.UTF8.GetString(randBytes);
            return randString;
        }

Ja, das ist jetzt kein Delphi-Code, aber war ja auch eine allgemeine Frage.

Im Moment wird noch auf darstellbare ASCII-Zeichen (unterer UTF-8 Zeichensatz) geschrumpft, damit ich das Ergebnis kontrollieren kann. Das ist nur temporär.

Das ganze ist Part einer Fuhrpark-Verwaltung, bei der spezielle Dokumente zu einem Fahrzeug verschlüsselt abgelegt werden können. Da das ganze universell werden soll, wollte ich gleich best mögliche Sicherheit implementieren.