Softraid und Verschlüsselung

buebo

buebo

Well-Known Member
Moin,
bis Dato läuft Partitionsverschlüsselung ja noch nicht zusammen mit Vinum, ich kann mich aber düster erinnern da mal irgendwelche Gerüchte aufgeschnappt zu haben das ein neues Framework in der Mache sein soll das diese Sachen regelt.
Bei mir steht anfang des neuen Jahres das Anschaffen eines weiteren Raid-Verbandes an und da wollte ich doch mal Erkundigungen einziehen mit was ich zu rechnen habe.

buebo
im Bewusstsein ziemlich vage zu sein

Edit: Ich bin natürlich für Verweise auf entsprechende Schriftstücke dankbar.
 
Zuletzt bearbeitet:
Hi buebo,

GEOM soll sowas transparent können. Soll auch funktionieren, wenn auch die Performance wohl noch ausbaufähig wäre. Hab's selber noch nicht ausprobiert und Doku zu GEOM gibt's bisher AFAIK nicht. (options GEOM_BDE # Disk encryption.)
Achso: Wir sprechen schon von 5.2?

Grüsse,

-Kaeptn
 
Bin grade erst aus dem Urlaub zurück, wir sprechen im Prinzip von 5.2 (könnte und würde ich dann entsprechend "hoch-cvsuppen"), ich hab jetzt mal etwas gegoogelt, werde aber nicht wirklich schlau aus der Ganzen Sache.
Verstehe ich das richtig das GEOM im Prinzip sowohl Verschlüsselung wie auch Raid Handhaben kann?
Irgendwie habe ich auch noch keine Erfahrungsberichte gefunden nach denen ich zumindest ansatzweise auf die Stabilität schliessen könnte.

Gruß
buebo
 
Ich benutze geom_bde auf meinem Laptop, um dort "wichtige" Sachen zu speichern. Bisher funktioniert das absolut problemlos (wenn wir von den paar Tagen absehen, in denen ein wilder commit das AES zerschossen hatte...).

Aus hobby-kryptographischer Sicht finde ich das System sehr gut und sicher. Was ich mich frage ist, warum Du dein RAID verschlüsseln möchtest?
 
Original geschrieben von current

Aus hobby-kryptographischer Sicht finde ich das System sehr gut und sicher. Was ich mich frage ist, warum Du dein RAID verschlüsseln möchtest?
Zum Vergrößern anklicken....

[Leicht Off-Topic]
Nenn es eine eigentümliche Art von Perfektionismus, aber ich finde es auf eine bestimmte Art unglaublich faszinierend das Heute "der Kleine Mann", in einer Zeit steigernder Repressionen, plötzlich Werkzeuge in der Hand hält mit denen er (bei kluger Anwendung) sämtliche Nationalstaaten der Erde an der Nase herumführen kann. Darauf in weiterem Maße einzugehen würde den Rahmen hier sprengen (ausserdem sind wir Techniker, keine Politologen).
Im Moment habe ich die folgende Situation. Mein Homeverzeichniss und ganz allgemeine die Deponie liegen auf einem Vinum-Softraid, weil das alles Daten sind die ich gerne halbwegs sicher aufgehoben wissen will. Nebenher habe ich noch eine ältere 20 Gigs Platte als "Crypta" also verschlüsselt mit gdbe im Einsatz, zuerst weil ich es einfach mal ausprobieren wollte, mittlereile benutze ich die eigentlich auch richtig, nur ist das Setup kontraproduktiv, denn die Sachen die ich gerne Schützen will kann ich aus Redundanz-Gründen nicht in die Crypta stecken (die Vorstellung Datenrettung auf einer Verschlüsselten Partition zu machen treibt mir den kalten Schweiss auf die Stirn) und die, die drinn sind entbehren jeder Wichtigkeit.
Da mein Raid so langsam aber sicher anfängt an seine Speicher-Grenzen zu stoßen zeichnet sich mittlerweile am Horizont ein neuer Schub Festplatten ab und am liebsten wäre es mir natürlich wenn ich bis dahin die Möglichkeit hätte *irgendwie* dieses Raid zu verschlüsseln. Unangenehm wird das vor allem noch dadurch das ein Hardware-Raid-5 meinen Geldbeutel völlig sprengen würde, vor allem weil ich beim nächsten Raid sowieso schon ein neues Gehäuse (und vielleicht auch ein Netzteil) brauchen werde um die ganzen Platten unterzubringen.
Ich will das auch gar nicht als Meckerei gegen die Entwickler verstanden wissen, ganz im Gegenteil die machen alle einen wirklich guten Job, nur versuche ich mir Klarheit zu verschaffen was an diesen Aspekten vor mir liegt und wie ich am besten vorgehe.

Gruß
buebo
 
buebo schrieb:
[Leicht Off-Topic]
Nenn es eine eigentümliche Art von Perfektionismus, aber ich finde es auf eine bestimmte Art unglaublich faszinierend das Heute "der Kleine Mann", in einer Zeit steigernder Repressionen, plötzlich Werkzeuge in der Hand hält mit denen er (bei kluger Anwendung) sämtliche Nationalstaaten der Erde an der Nase herumführen kann. Darauf in weiterem Maße einzugehen würde den Rahmen hier sprengen (ausserdem sind wir Techniker, keine Politologen).
Zum Vergrößern anklicken....

GEOM_BDE finde ich auch ziemlich faszinierend unter FBSD. Kann man die swap-Partition (wie bei OpenBSD) auch gleich mitverschlüsseln? - Sofern durch keine Linux-Allergie oder -Phobie hast, kannst du dir ja auch mal probeweise die cryptoAPI unter 2.6 anschauen (hab's gerade unter tinysofa 0.2 laufen), hier wird auch eine starke Verschlüsselung der gesamten Festplatte(n) mit USB-Stick ermöglicht.
 
AFAIK geht swap Verschlüsselung noch nicht.

gbde wird wohl (wenn überhaupt schon) nur mit geom_vinum laufen, da dass normale vinum ja nicht mit geom kann.
 
Na schön, dann warten wir noch etwas. :)

Ansonsten habe ich gerade meine Schwäche für das kleine Tool ccrypt entdeckt, das einen sehr starken Verschlüsselungsalgorithmus nutzt und offensichtlich auch sehr schnell ist: Nachdem ich aus /dev/random einen 128 Byte langen Binärschlüssel erzeugt habe, konnte ich mit diesem als Keyfile und ccrypt als Engine ein 4 GByte großes Festplattenimage innerhalb von nur 8 Minuten verschlüsseln. Peter Selinger hat offensichtlich ganze Arbeit bei der Implementioerung des Algorithmus geleistet.
 
Selinger scheint für ccrypt eine dem Rijndael-Algorithmus vorausgegangene Entwicklung implentiert zu haben, die mit 256-Bit-Blöcken arbeitet anstatt mit 128 wie beim ursprünglichen AES. Offensich können mit ccrypt verschlüsselte Dateien mit keiner anderen AES-Implementierung entschlüsselt werden. Ich erlaube mir hier einmal, Selinger wörtlich zu zitieren, damit du dir einen ersten Eindruck verschaffen kannst:


Block ciphers operate on data segments of a fixed length. For instance, the Rijndael block cipher used in ccrypt has a block length of 32 bytes or 256 bits. Thus, this cipher encrypts 32 bytes at a time.

Stream ciphers operate on data streams of any length. There are several standard modes for operating a block cipher as a stream cipher. One such standard is Cipher Feedback (CFB), defined in FIPS 81 and ANSI X3.106-1983. ccrypt implements a stream cipher by operating the Rijndael block cipher in CFB mode.

Let P and C be the ith block of the plaintext and ciphertext, respectively. CFB mode specifies that


C = P ^ E(k,C[i-1])

Here ^ denotes the bitwise exclusive or function, and E(k,x) denotes the encryption of the block x under the key k using the block cipher. Thus, each block of the ciphertext is calculated from the corresponding block of plaintext and the previous block of ciphertext. Note that in fact, each byte of P can be calculated from the corresponding byte of C, so that the stream cipher can be applied to one byte at a time. In particular, the stream length need not be a multiple of the block size.

Assuming that blocks are numbered starting from 0, a special "initial" ciphertext block C[-1] is needed to provide the base case for the above formula. This value C[-1] is called the initialization vector or seed. The seed is chosen at encryption time and written as the first block of the encrypted stream. It is important never to use the same seed more than once; otherwise, the two resulting ciphertext blocks C[0] could be related by a simple xor to obtain information about the corresponding plaintext blocks P[0]. If the same seed is never reused, CFB is provably as secure as the underlying block cipher.

In ccrypt, the seed is constructed as follows: first, a combination of the host name, current time, process id, and an internal counter are hashed into a 28-byte value, using a cryptographic hash function. A fixed four-byte "magic number" is combined with this value, and the resulting 32-byte value is encrypted by one round of the Rijndael block cipher with the given key. The result is used as the seed and appended to the beginning of the ciphertext. The use of the magic number allows ccrypt to detect non-matching keys before decryption.
Zum Vergrößern anklicken....


Mich persönlich würde hier näher interessieren, woher ccrypt seine Entropie bezieht und ob es in irgendeiner Weise einen echten Zufallsgenerator (sagen wir, von der Qualität von ISAAC) gibt, unter dessen Verwendung ccrypt den gerade verwendeten Schlüssel in 256 Bit zerhackt. Eine nähere Untersuchung der Sourcen dürfte hier Aufklärung bringen, sofern ausreichender mathematischer Background vorhanden ist.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben