Peter Jordan:
> Jochen Schulz, Sun Jul 26 2009 12:35:53 GMT+0200 (CEST) :
>> Peter Jordan:
>>
>>> 1. Disk mit Zufallsdaten überschreiben
>>> dd if=/dev/random of=/dev/sdc bs=1024
>>
>> Wenn die Platte neu ist, kannst Du Dir das eigentlich sparen. Mit
>> /dev/random wird das auch ewig dauern, wenn Du nicht gerade einen
>> Hardware-RNG hast. Nimm besser /dev/urandom oder gleich /dev/zero.
>>
>
> Ich meinte auch /dev/urandom. Und wenn die Platte neu ist und ich das
> nicht mache, kann man sehen wo Daten stehen und wo keine stehen.
> Insofern ist das auch bei neuen Platten nicht sinnlos.
Naja gut. Den Erkenntnisgewinn halte ich jetzt nicht für entscheidend,
aber ok.
>> Aus welchem Grund weichst Du vom default (aes-cbc-essiv:sha256) ab?
>>
>> Nicht, dass ich eine fundierte Meinung dazu habe, aber gerade deswegen
>> würde ich eher den default übernehmen.
>
> Ich erinnere mich, mal irgendwo gelesen zu haben, dass
> serpent-cbc-essiv:sha256 sicherer aber langsamer ist, als der Standard.
Ok, Google bestätigt mir das gerade.
>> Ist grundsätzlich ok. Ich habe bisher nicht mit externen Keys
>> gearbeitet, das sieht aber so ok aus. Was mir bei diesem Vorgehen nicht
>> klar ist: wie schützt Du das Keyfile vor Zugriff?
>
> Der Key dient dem automatischen Backup (wenn man mal von der
> Notwendigkeit des Anschließens der Festplatte absieht). Der Key schützt
> also Daten die auf dem entschlüsselten Laufwerk, auf dem der key liegt,
> sowieso verfügbar sind, also brauch er nicht gesondert geschützt zu werden.
Wie jetzt? Du erstellst ein Backup von Deinem verschlüsselten System,
auf dem auch der Key für das Backup liegt? Und wie kommst Du dann beim
Totalausfall an den Key? Oder verstehe ich Dich miss?
J.
--
Fashion is more important to me than war, famine, disease or art.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
Attachment:
signature.asc
Description: Digital signature