# mit welcher verschluesselung verschluesselt ihr festplatten?

## pieter_parker

mit welcher verschluesselung verschluesselt ihr eure festplattenlauferke ?Last edited by pieter_parker on Fri Apr 16, 2010 1:04 am; edited 1 time in total

----------

## michael_w

mit gar keiner!?

----------

## think4urs11

ich benutze zuhause ein zweifach angewendetes Involutionsverfahren und auf dem Firmenschleppi Truecrypt-Container (nur für die Daten, nicht das OS).

verschoben ins Diskussionsforum

----------

## manuels

ich nutze LUKS für alles (also OS und /home) auf dem Laptop

----------

## papahuhn

 *Think4UrS11 wrote:*   

> ich benutze zuhause ein zweifach angewendetes Involutionsverfahren

 

Dein Rechner ist dir zu schnell, was?  :Wink: 

----------

## think4urs11

nicht direkt; ein Wrap ist vieles aber sicher nicht schnell  :Wink: 

----------

## Ampheus

Wenn die Frage sich auf das Programm bezog, dm-crypt+LUKS. Wenn es um den Algorithmus ging, Twofish. Twofish ist schnell genug für root-Verschlüsselung und bis jetzt nicht einmal theoretisch geknackt, siehe hier.

----------

## l3u

Ich mach das Verzeichnismäßig mittels EncFS (was FUSE benutzt). Ist ne feine Sache! Da sind zwar Anzahl, Zugriffsrechte und Größe der Dateien sichtbar, dafür läuft es aber schön im Userspace, die Einrichtung ist in 20 Sekunden passiert und man kann Backups des verschlüsselten Zustandes ziehen (und auch z. B. auf eine CD brennen).

----------

## misterjack

 *Ampheus wrote:*   

> Wenn die Frage sich auf das Programm bezog, dm-crypt+LUKS. Wenn es um den Algorithmus ging, Twofish.

 

same here  :Smile: 

----------

## schachti

Home-Verzeichnisse und ein paar Datenverzeichnisse sind mit AES 256 verschlüsselt und wird mittels pam_mount beim Einloggen des jeweiligen Users gemountet. Die / Partition ist bei mir momentan nicht verschlüsselt.

----------

## SkaaliaN

 *misterjack wrote:*   

>  *Ampheus wrote:*   Wenn die Frage sich auf das Programm bezog, dm-crypt+LUKS. Wenn es um den Algorithmus ging, Twofish. 
> 
> same here 

 

bei mir ebenfalls

----------

## manuels

also ich nutze Blowfish - ist aelter - hab allerdings keine Ahnung wie der Performance-Unterschied zu Twofish ist - weiss da jemand was naeheres?

----------

## pieter_parker

auf einer 1,5tb festplatte liegen ein paar videos, musik, bilder und text -dateien

die festplatte macht 60..70...90mb/s, diese geschwindigkeiten brauche ich aber nicht

wenn am ende 10..20mb/s oder etwas mehr noch moeglich sind, ist das ausreichend

die cpu ist eine intel quad core cpu mit 2,4 ghz, sie hat die meiste zeit nichts zu tun

cryptsetup -v -c aes-cbc-essiv:sha256 -h sha -s 256 luksFormat /dev/loop/1

so hab ich die festplatte verschluesselt

wie sicher ist das?

wie kann ich es sicherer machen?

was fuer eine verschluesselung wuerdet ihr mir empfeheln fuer mein vorhaben?

----------

## Ampheus

Also AES gilt generell nicht mehr als wirklich sicher. Es gilt als "hinreichend sicher", was soviel bedeutet wie: Für den Heimgebrauch tu du das ma nehmen.

Wenn allerdings sensible Daten auf der Platte sind (ggf. urheberrechtlich geschützte Inhalte) und Personen mit entsprechenden Mitteln Interesse daran haben könnten, würde ich wirklich Twofish mit entsprechend sicherem Schlüssel empfehlen.

Hier gibt es nähere Informationen zu AES und dessen Sicherheit.

----------

## pieter_parker

hab mir das durchgelesen, ein wenig hab ich glaub auch davon verstanden, aber wirklich weitergeholfen hat es mir nicht bei der suche nach der verschluesselung die ich nehmen will leider nicht

----------

## Anarcho

 *Ampheus wrote:*   

> Also AES gilt generell nicht mehr als wirklich sicher. Es gilt als "hinreichend sicher", was soviel bedeutet wie: Für den Heimgebrauch tu du das ma nehmen.
> 
> Wenn allerdings sensible Daten auf der Platte sind (ggf. urheberrechtlich geschützte Inhalte) und Personen mit entsprechenden Mitteln Interesse daran haben könnten, würde ich wirklich Twofish mit entsprechend sicherem Schlüssel empfehlen.
> 
> Hier gibt es nähere Informationen zu AES und dessen Sicherheit.

 

Na logisch,

für ein paar MP3s und Filme wird sicherlich jeder Staatsanwalt sofort einen BlueGene mieten um deine Daten zu kriegen...

Also soo unsicher ist AES nun auch nicht. Aber soll jeder nehmen was ihm die Paranoia vorschreibt. Ich denke es gibt keinen grossen Unterschied. AES ist halt etwas flotter, Twofish theoretisch etwas sicherer.

Meine Platte ist mit AES-Verschlüsselt (LUKS, DM-Crypt).

----------

## manuels

Blowfish (1994) ist kanpp ein halbes Jahrzehnt älter als Twofish (1998).

Da somit länger Zeit war Blowfish zu analysieren, _kann_ man davon ausgehen, dass er sicherer ist - auch wenn einige Leute jetzt sagen "was sind schon vier Jahre".

Nach Kryptografie-Legende Bruce Scheier ist Twofish auf einem Pentium ~8,6% schneller als Blowfish.

Ein bisschen mehr Sicherheit oder ein bisschen mehr Performance - das ist persönliche Entscheidung

EDIT: URL korrigiert

2nd EDIT: Wenn ich es mir recht überlege - (8,6% Performance im Vergleich zu 14 bzw 10 Jahre Analysemöglichkeit - ich entscheide mich für Blowfish

----------

## schachti

 *Ampheus wrote:*   

> Also AES gilt generell nicht mehr als wirklich sicher. Es gilt als "hinreichend sicher", was soviel bedeutet wie: Für den Heimgebrauch tu du das ma nehmen.

 

Wo hast Du das denn her?

----------

## Ampheus

 *schachti wrote:*   

>  *Ampheus wrote:*   Also AES gilt generell nicht mehr als wirklich sicher. Es gilt als "hinreichend sicher", was soviel bedeutet wie: Für den Heimgebrauch tu du das ma nehmen. 
> 
> Wo hast Du das denn her?

 

Das habe ich von mehreren Quellen, welche zumindest theoretische Angriffsmöglichkeiten gefunden haben. Spontan fällt mir Wikipedia ein:

 *Wikipedia wrote:*   

> Kurz vor der Bekanntgabe des AES-Wettbewerbs stellten verschiedene Autoren eine einfache algebraische Darstellung von AES als Kettenbruch vor. Dies könnte für erfolgreiche Angriffe genutzt werden. Hierzu gibt es einen Videovortrag von Niels Ferguson auf der HAL 2001.
> 
> 2002 wurde von Courtois and Pieprzyk ein theoretischer Angriff namens XSL gegen Serpent und Rijndael vorgestellt (siehe Serpent).

 

Diese Seite erläutert das etwas genauer. Vor Allem der oberste Eintrag sollte Grund zur Besorgnis sein.

----------

## amne

 *l3u wrote:*   

> Ich mach das Verzeichnismäßig mittels EncFS (was FUSE benutzt). Ist ne feine Sache! Da sind zwar Anzahl, Zugriffsrechte und Größe der Dateien sichtbar, dafür läuft es aber schön im Userspace, die Einrichtung ist in 20 Sekunden passiert und man kann Backups des verschlüsselten Zustandes ziehen (und auch z. B. auf eine CD brennen).

 

Das schaut mir einmal praktisch aus! Hast du schon länger Erfahrung damit, v.a. was Stabilität usw angeht?

----------

## schachti

 *Ampheus wrote:*   

>  *Wikipedia wrote:*   Kurz vor der Bekanntgabe des AES-Wettbewerbs stellten verschiedene Autoren eine einfache algebraische Darstellung von AES als Kettenbruch vor. Dies könnte für erfolgreiche Angriffe genutzt werden. Hierzu gibt es einen Videovortrag von Niels Ferguson auf der HAL 2001. 

 

Das ist noch kein Angriff, noch nicht mal ein theoretisch möglicher.

 *Ampheus wrote:*   

>  *Wikipedia wrote:*   2002 wurde von Courtois and Pieprzyk ein theoretischer Angriff namens XSL gegen Serpent und Rijndael vorgestellt (siehe Serpent). 

 

Dazu zitiere ich ebenfalls die Wikipedia, aber die englischsprachige:

 *Quote:*   

> 
> 
> In 2002, a theoretical attack, termed the "XSL attack", was announced by Nicolas Courtois and Josef Pieprzyk, showing a potential weakness in the AES algorithm.[9] Several cryptography experts have found problems in the underlying mathematics of the proposed attack, suggesting that the authors may have made a mistake in their estimates. Whether this line of attack can be made to work against AES remains an open question. At present, the XSL attack against AES appears speculative; it is unlikely that the current attack could be carried out in practice.
> 
> 

 

Siehe dazu auch http://www.usdsi.com/aes.html.

 *Ampheus wrote:*   

> 
> 
> Diese Seite erläutert das etwas genauer. Vor Allem der oberste Eintrag sollte Grund zur Besorgnis sein.

 

Da ich kein Polnisch kann (das meinst Du doch?), kann ich das nicht beurteilen. Ich halte AES jedoch für sicher...

----------

## l3u

Ich glaub, das mit Rijndael ist mehr ne theoretische Sache. Man muß nicht zu ängstlich sein.

@amne: Ich benutze EncFS jetzt schon ein paar Jahre und hatte noch nie Probleme damit. Läuft stabil und ist äußerst praktisch, bisher gab es auch keine Inkompatibilitäten oder sowas. Wird vermutlich langsamer sein als z. B. dm-crypt, aber es ist ja auch nicht dazu gedacht, eine ganze Partition zu verschlüsseln. Und mir geht es zumindest so, daß ich nicht alles verschlüsseln will, sondern eben nur ein paar „wichtige“ Sachen. Und dafür ist es einfach perfekt.

----------

## boris64

 *Ampheus wrote:*   

> Also AES gilt generell nicht mehr als wirklich sicher. Es gilt als "hinreichend sicher", was soviel bedeutet wie: Für den Heimgebrauch tu du das ma nehmen.
> 
> Wenn allerdings sensible Daten auf der Platte sind (ggf. urheberrechtlich geschützte Inhalte) und Personen mit entsprechenden Mitteln Interesse daran haben könnten, würde ich wirklich Twofish mit entsprechend sicherem Schlüssel empfehlen.
> 
> Hier gibt es nähere Informationen zu AES und dessen Sicherheit.

 

AES nur für den Heimgebrauch? Das ist ja mal eine interessante Theorie  :Razz: 

Auszug aus Wikipedia Artikel:

 *Quote:*   

> AES ist in den USA für staatliche Dokumente mit höchster Geheimhaltungsstufe zugelassen.

 

PS: Auch hier dmcrypt/luks mit aes256

----------

## pieter_parker

was haltet ihr von serpent-twofisch-aes

----------

## tamiko

@pieter_parker:

Ich empfehle dir einen der drei genannten Algorithmen zu verwenden.

In Fragen der "Sicherheit" geben sich diese drei Verfahren in meinen Augen so gut wie nichts. Sie sind nicht umsonst die drei Finalkandidaten des AES-Wettbewerbs.

Viel wichtiger in meinen Augen, für die Festplatten-Verschlüsselung, ist die Wahl eines guten Modus. (Es gibt eine gute Zusammenfassung in der Wikipedia.)

Du kannst einen noch so tollen Algorithmus verwenden, benutzt du ECB als Modus, kannst du dir die Verschlüsselung am besten sparen.

In dieser Hinsicht empehle ich den aktuellen Vorschlage der IEEE P1619, nämlich XTS. (Oder den Vorgänger LRW)

(Von CBC rate ich ab - ich habe dazu ein sehr aufschlussreiches Paper gefunden, dass Kollissionsangriffe (unabh. vom Algo.) auf CBC beschreibt - ich finde es nur nicht mehr...)

Für dm-crypt lautet dann die Verschlüsselung z.B.  twofish-xts-plain, aex-xts-plain, oder serpent-xts-plain (Bemühe eine Religion deiner Wahl, um deinen Kandidaten auszusuchen.)

Übrigens: Wenn du Truecrypt benutzt, so lassen dich die Entwickler überhaupt nicht aussuchen, was für einen Modus du benutzt. Die neueste Truecrypt-Version benutzt XTS (Vorgänger LRW).

Noch eine kleine Philosophie zu Algo1-Algo2-Algo3 in truecrypt:

Für jeden angegebenen Algo wird eine komplette Verschlüsselung samt Modus gefahren, d.h. selbt bei aes-128bit + xts-128bit sind wir bei 768bit, dass an Passwort benötigt wird!

Dies entspricht einem Passwort von 128 Zeichen Länge (bei angenommenen 6-bit pro Zeichen). Gegen dieses Entropie-Loch nutzt auch eine gute Passwortableitung nichts.

Alle gängigen Angriffsmethoden sind aktuell Brute-Force-Angriffe - Nimm also lieber ein einfaches Mapping und überleg dir ein gutes Passwort

----------

## pieter_parker

lese was ihr schreibt manchmal 2 mal durch bis ich es halbwegs verstanden hab

gut, cbc also nix gut, und wie ist es mit cbc mit essiv erweiterung ?

also

cryptsetup -v -c aes-cbc-essiv:sha256 -h sha -s 256 luksFormat /dev/... 

fuer wie sicher haltet ihr das ?

lrw und xts sind sind beide im kernel als experimental makiert, nutze "expirmental" makierte sachen meistens nur wenn es wirklich notwendig ist

was versteht ihr unter einem "gutem passwort" ?

cryptsetup -v -c aes-cbc-essiv:sha256 -h sha -s 256 luksFormat /dev/... 

wenn das denn sicher ist (??) wuerde ich dafuer ein passwort mit 43 zeichen verwenden das grosse und kleine buchstaben hat, zahlen von 0 bis 9 und mindestes 10 sonderzeichen hat, oder besser mehr sonderzeichen ? gibt es sonderzeichen die nicht erlaubt sind ?

----------

## mv

Für Passworte gilt generell: Hauptsache lang. Und am Einfachsten verwendest Du keine Sonderzeichen, dann kannst Du auch niemals Ärger damit haben. Da die Länge exponentiell, die Zeichenzahl aber nur polynomial eingeht, zeigt eine einfache Rechnung, dass schon sehr wenige Zeichen mehr die Nichtbenutzung von Sonderzeichen kompensieren.

----------

## boris64

Ich würde zuerst einmal den Hash mit "sha" nicht angeben, da eh ohne explizite 

Angabe per default "ripemd160" ausgewählt wird, bei welchem (wenigstens laut Wikipedia :/) 

noch keine echten Schwächen bekannt geworden sind.

Auch bei der Erstellung von Truecrypt-Containern wird imo standardmäßig ripemd-160 benutzt.

Was Passwörter angeht, empfehle ich zusätzliche Schlüsseldateien (z.B. mit Inhalt aus /dev/urandom),

die man auf einem externem Media (USB-Stick o.ä.) mitnehmen kann.

----------

## pieter_parker

also so 

cryptsetup -v -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/... 

?

wie lang sollte denn das passwort sein ?

oder wie gross, wieviel zeichen sollte eine schluesseldatei sein ?

----------

## cryptosteve

Hier ist via LUKS mit aes-cbc-essiv:sha256 verschlüsselt. Mein Passwort ist >15 Zeichen lang und enthält Gross-/Kleinschreibung, sowie Sonderzeichen. Das reicht fürs erste; diejenigen, die die Kiste im Notfall brechen könnten, sind mir eh wurscht, weil ich - falls es jemals soweit kommt, dass solche Freaks an meiner Kiste arbeiten - das Sonnenlicht eh nie wiedersehen werde.

----------

## STiGMaTa_ch

 *Think4UrS11 wrote:*   

> nicht direkt; ein Wrap ist vieles aber sicher nicht schnell 

 

Etwa dieses WRAP?

Hach.... Herrliche Teile. Habe zwei Stück davon im Einsatz. Suuuuper!!!

Aber wie du sagst... schnell? Mitnichten   :Laughing: 

----------

## pieter_parker

kann man 384 oder 512 bit lange passwoerter verwenden ?

----------

## kernelOfTruth

 *pieter_parker wrote:*   

> kann man 384 oder 512 bit lange passwoerter verwenden ?

 

OUCH!

wie willst du dir das bitte merken ?  :Wink: 

mein passwort ist in der Reinform um die 130-140 bit lang

für wie sicher schätzt ihr whirlpool512 als hash-algorithmus ein ?

also der luksFormat Befehl lautet bei mir:

 *Quote:*   

> cryptsetup -y --cipher twofish-lrw-benbi --key-size 384 -h wp512 luksFormat /dev/foo 

 

gibst neben benbi noch was besseres ?

 *Quote:*   

>  * Different IV generation algorithms:
> 
>  *
> 
>  * plain: the initial vector is the 32-bit little-endian version of the sector
> ...

 

V generation algorithms gibt es wohl noch nicht - oder ?

----------

## pieter_parker

was bedeutet 130...140 bit in der reinform lang ?

sorrie, aber es faellt mir noch schwer das alles zuverstehen

----------

## kernelOfTruth

 *pieter_parker wrote:*   

> was bedeutet 130...140 bit in der reinform lang ?
> 
> sorrie, aber es faellt mir noch schwer das alles zuverstehen

 

na das ist das, was zumindest truecrypt anzeigt:

ich hab's dort mal als passwort eingegeben und es wurden über 130 bit angezeigt   :Wink:   (wieviel zeichen das sind hängt vom einsatz der sonderzeichen bzw. zeichen generell ab)

----------

## think4urs11

 *kernelOfTruth wrote:*   

>  *Quote:*    * Different IV generation algorithms: V generation algorithms gibt es wohl noch nicht - oder ?

 

Also falls sich die Frage nach V auf eine Art Version beziehen soll - in dem Kontext steht 'IV generation' nicht für '4te Generation' sondern für den Initialization Vector'  :Wink: 

 *pieter_parker wrote:*   

> was bedeutet 130...140 bit in der reinform lang ?

 

Grob gerechnet kommst du mit Groß/Kleinschreibung auf knapp 6Bit/Zeichen, mit Ziffern und den diversen druckbaren Sonderzeichen dazu auf gut 7. Ergibt also 'über den breiten Daumen' ca. 20 Zeichen.

Für den Hausgebrauch 'tut' es auch ein simpler Merksatz ala 'Mein Hamster furzt im Schlaf' oder 'Popel helfen gegen Durchfall'. Es dürfte mit herkömmlichen Passwortknackern ausreichend lange dauern den zu knacken und es ist merkbar. Und ja das widerspricht der Regel das Paßworte in keinem Wörterbuch stehen sollten; ist aber für non-military-use recht brauchbar.

----------

## l3u

Na dann muß man's halt als 13376p34k schreiben, und schon steht's nicht mehr im Wörterbuch:

 *Quote:*   

> M3!n H4m5t3r furz7 1m 5ch14f

 

 *Quote:*   

> P0p31 h31f3n g3g3n Durchf411

 

oder sowas ;-)

----------

## mv

 *l3u wrote:*   

> Na dann muß man's halt als 13376p34k schreiben, und schon steht's nicht mehr im Wörterbuch:

 

Und was hast Du dadurch gewonnen? Gerade ein paar Bits Redundanz mehr pro Wort! Es ist tatsächlich nicht schlimm, wenn die Worte in einem Wörterbuch stehen, vor allem wenn sie kurz sind, weil das auch nur ein paar Bytes pro Wort verkürzt. Den Hinweis, lieber einen langen Satz zu  nehmen, als verkorkste Zeichen, die dann unbequem einzugeben sind und daher in der Praxis das Passwort verkürzen, haben sogar Microsoft auf einer Seite mit Sicherheitshinweisen veröffentlicht (den Link habe ich jetzt nicht zur Hand, aber die Hinweise waren wirklich seriös und alle mathematisch begründet).

----------

## l3u

Na dann …

----------

## tamiko

Und bitte, bitte, egal was ihr tut.

Benutzt LUKS

Also

```
cryptsetup luksFormat ....
```

Und dann luksOpen zum öffnen... 

Denn ihr wollt eine sinnvolle Passwortableitung.

----------

## pieter_parker

wie ist das eigentlich wenn ich nicht zukomme

cryptsetup luksClose festplatte

zumachen weil .. weil z.b. ein stromausfall war

mit welchem schaden ist zurechnen ?

----------

## kernelOfTruth

 *pieter_parker wrote:*   

> wie ist das eigentlich wenn ich nicht zukomme
> 
> cryptsetup luksClose festplatte
> 
> zumachen weil .. weil z.b. ein stromausfall war
> ...

 

das dürfte nix ausmachen, im grunde hängt das aber vom zugrundeliegenden dateisystem ab:

* mit jfs hatte ich alle daten der partition verloren (unsauber umounted oder was weiß ich)

* mit reiserfs hatte ich bis jetzt, soviel ich weiß, keine probleme

* xfs ...

* ...

----------

## Anarcho

 *pieter_parker wrote:*   

> wie ist das eigentlich wenn ich nicht zukomme
> 
> cryptsetup luksClose festplatte
> 
> zumachen weil .. weil z.b. ein stromausfall war
> ...

 

Wie mein Vorredner schon sagte hängt das stark vom FS ab.

Bei meiner ext3-Partition ist bisher nie was passiert. Und die hat schon einiges mitmachen müssen als mit der USV rumgebastelt habe  :Wink: 

----------

## amne

 *l3u wrote:*   

> @amne: Ich benutze EncFS jetzt schon ein paar Jahre und hatte noch nie Probleme damit. Läuft stabil und ist äußerst praktisch, bisher gab es auch keine Inkompatibilitäten oder sowas. Wird vermutlich langsamer sein als z. B. dm-crypt, aber es ist ja auch nicht dazu gedacht, eine ganze Partition zu verschlüsseln. Und mir geht es zumindest so, daß ich nicht alles verschlüsseln will, sondern eben nur ein paar „wichtige“ Sachen. Und dafür ist es einfach perfekt.

 

Danke, tut inzwischen bei mir auch fein!

----------

## schachti

Zumindest einer der Twofish-Erfinder (!) empfiehlt, AES anstatt Twofish zu benutzen: http://groups.google.com/group/sci.crypt/browse_thread/thread/7834ad13db22e207/6f6e157149330057.

----------

## Sujao

Hab seit ca 3 Jahren XFS und ext3 alles mit LUKS+AES256 verschlüsselt. Bisher keinerlei Probleme gehabt. Denke da gehts einem mit Verschlüßelung nicht anders wie ohne Verschlüßelung.

Ich finde, dass diese Diskussion über Algorithmen Schwachsinn sind. Ihr seid nicht der CIA oder Bundesnachrichtendienst mit einer Selbsmordpille in eurem Mund und hochbrisanten Daten.

Wenn die Leute wirklich an eure Daten ranwollen, dann brechen die bei euch ein, wenn ihr nicht zu Hause seid und installieren eine 1cm³ Kamera und filmen eure Passwordeingabe ab oder installieren einen 0.3cm³ Keylogger, den ihr niemals bemerken werdet.

Oder wenn das keine staatliche Organisation ist, dann kommen die zu euch nach Hause und kneifen euch solange Finger mit der Zange ab, bis ihr das Passwort verratet.

Also scheisst drauf ob die Platte nun in 1 oder 2 Jahren mit einem Supercomputer gecrackt werden kann. Die Fingerabkneifmethode kostet maximal 0.0001 und hat die gleiche Wirkung.

----------

## ScytheMan

 *Sujao wrote:*   

> 
> 
> Ich finde, dass diese Diskussion über Algorithmen Schwachsinn sind. Ihr seid nicht der CIA oder Bundesnachrichtendienst mit einer Selbsmordpille in eurem Mund und hochbrisanten Daten.
> 
> 

 

Und wer nichts zu verbergen hat, der muss erst gar nicht verschlüsseln. Ihr seid doch alles potentielle Terorristen!

Sry, aber erklär mir den Zusammenhang zwischen Algorithmen und Brisanz der Daten.

----------

## Sujao

Denk nochmal nach über das was ich geschrieben habe. Das was du schreibst, habe ich nie behauptet.

----------

## SkaaliaN

 *ScytheMan wrote:*   

>  *Sujao wrote:*   
> 
> Ich finde, dass diese Diskussion über Algorithmen Schwachsinn sind. Ihr seid nicht der CIA oder Bundesnachrichtendienst mit einer Selbsmordpille in eurem Mund und hochbrisanten Daten.
> 
>  
> ...

 

Sorry..aber so einen Blödsinn habe ich selten gelesen..! Es gibt auch noch Leute die evtl. personenbezogene Daten Zuhause haben!? Und selbst wenn nicht...!? Man kann sich für solche Dinge interessieren. Wieso sollte man es nicht tun!? Ist das verboten? Dein Post zeugt nicht von geistiger Reife...

----------

## ScytheMan

*hust* http://de.wikipedia.org/wiki/Ironie *hust*, sry mein Hals. Die Aussage hat doch förmlich nach Ironie gestunken... vllt. sind Ironietags wohl doch nicht so unnütz wie ich dachte, wenn erwartet wird, dass alles offenkundig sein muss.

Allerdings disqualifiziert man sich mit Aussagen wie "Diskussionen über Algorithmen sind Schwachsinn"  für eine weitere Diskussion, denn eine Verschlüsselung besteht nunmal im Kern aus einem Algorithmus. Prinzipiell ist es egal, wie wichtig die Daten sind. Eine Verschlüsselung dient für mich vor allem der Zugangskontrolle, keiner hat eben darauf Zugriff ohne Erlaubnis. Und wenn es dann um Sicherheit geht, dann will ich den sichersten Algorithmus und keinen unsicheren. Wofür ich da ein Geheimdienst sein muss, weiß ich nicht. WEP kann quasi auch jeder knacken. Oder nutzt du etwa immer noch WEP, weil Diskussionen über Algorithmen Schwachsinn sind?

Achja, das es keine 100%ige Sicherheit gibt und geben wird, ist denke ich jedem klar.

----------

## Sujao

OK, ich versuchs nochmal anders auszudrücken:

Wir gehen davon aus, dass sowohl AES als auch Blowfish und Twofish hinreichend sicher sind. Wenn AES eine  Schwäche hat, dann ist das nur marginal und heisst nicht, dass Daten die mit AES verschlüßelt sind, bereits in 0.0001 der Zeit einer Bruteforceattacke entschlüßelt werden können. Es sind pessimistisch betrachtet 0.5, schlimmstensfals 0.1. Da selbst Supercomputer einige Jahre brauchen um AES normal zu knacken, werden sie dann halt mit der Schwachstelle vielleicht einen Monat brauchen.

Ein Monat Supercomputerzeit kostet bestimmt ein Vielfaches des Einbaus einer Überwachsungskamera/Keylogger die eure Passphrase auspionieren (Staatliche Methode). Ein Schläger der euch irgendwo überfällt und euch Finger abschneidet, bis ihr im die Passphrase freiwillig verratet, ist noch viel billiger (illegale Methode, aber auch möglich).

DESWEGEN ist es scheissegal ob der Algorithmus Schwächen hat, aber immer noch zu sicher ist um mit normalen PCs in vertetbarer Zeit geknackt zu werden. Und DESWEGEN ist auch der Vergleich Schwachsinn. Solange AES nicht auf das Niveau von WEP rutscht, wird sich keiner den Aufwand machen eure Daten zu Bruteforcen.

Jetzt klar was ich meine?

----------

## Yamakuzure

???

...Das ist es also... Die Linux-Welt ist durchfurcht von Paranoikern...   :Shocked: 

Wer was gegen mich hat und mich hacken will, kann sich gerne mit meinem Router unterhalten. Der schiebt alles brav nach /dev/null. Per SSH? Viel Spaß, bei reinem Key-Auth. Einzig der Diebstahl meiner Festplatten wäre ärgerlich. Ja, dafür würde sich eine Verschlüsselung in der Tat lohnen.

Aber jetzt mal Scherz beiseite:

Ich habe mir den Thread durchgelesen, und habe den Eindruck Ihr glaubt das da draussen eine Milliarde hochspezialisierter Profi-Hacker aller erdenklicher Vereinigungen lauern genau *euren* Computer zu hacken. Es gibt nur eine funktionierende Methode Daten zu verstecken: "Erzähle niemandem, dass sie da sind!"

Denn merke: Nur wenn ein hochqualifizierter Hacker es genau auf dich und aus einem verdammt guten Grund abgesehen hat, könntest du, vielleicht, ein Problem bekommen.

Was gibts denn da draußen sonst? Script-Kiddies. Und Dumm-User die ihre Windoofs-Kiste mit Freuden mit allem möglichen Mist zumüllen. (Obwohl ich auch schon "Profis" gesehen habe, die dem User "Test" der Gruppe "wheel" gestatten sich ohne Passwort per SSH zu verbinden...   :Rolling Eyes:  )

----------

## b3cks

Hier geht es darum seine Daten vor unbefugtem (direkten) Zugriff (auf die Festplatte) zu schützen. Vor wem ist dabei vollkommen unerheblich. Und wie stark man diese schützen möchte, ist jedem selbst überlassen. Im Normalfall möchte man ja den bestmöglichen Schutz. Und das wurde hier u.a. diskutiert. Es geht nicht direkt um Hacker, Script-Kiddies oder neugierige Freunde, es geht ums Prinzip seine Daten und somit auch sich zu schützen!

----------

## mastacloak

Eine Verschlüsselung von Notebook-Festplatten und externen Festplatten halte ich schon für sinnvoll. Ein Notebook mag man vielleicht nicht so schnell vergessen (irgendwo hab ich mal gehört, dass an Flughäfen ein ganzes Sammelsurium von Notebooks in den Fundbüros rumliegen muss), bei einer externen Festplatte kann das schon schneller mal passieren. Und nicht zu vergessen: Notebook-Diebstahl. Dann ist es schon ärgerlich genug, dass der Rechner weg ist, aber wenigstens kann ich einigermaßen sicher sein, dass der Dieb keinen Zugriff auf meine Daten hat. Und seien das nur der abgespeicherte Lebenslauf, die Kontoauszüge etc. pp. und meine Urlaubsbilder muss er auch nicht unbedingt haben...

Also nix Paranoia. Wer allerdings seine Daten freiwillig im Internet publiziert oder unsichere Online-Speicher nutzt, braucht auch seine lokalen Festplatten nicht zu verschlüsseln.

----------

## mv

 *Sujao wrote:*   

> Wir gehen davon aus, dass sowohl AES als auch Blowfish und Twofish hinreichend sicher sind.

 

Woher nimmst Du diese vollkommen unbegruendete Annahme?

 *Quote:*   

> Wenn AES eine  Schwäche hat, dann ist das nur marginal und heisst nicht, dass Daten die mit AES verschlüßelt sind, bereits in 0.0001 der Zeit einer Bruteforceattacke entschlüßelt werden können. Es sind pessimistisch betrachtet 0.5, schlimmstensfals 0.1.

 

Woher nimmst Du diese vollkommen unbegruendete Annahme? Genau darum ging doch die Diskussion, ob das denn richtig ist. Bei Triple-DES beispielsweise ist der Faktor vermutlich wohl inzwischen wesentlich (etliche Zehnerpotenzen) kleiner als Deine "schlimmstenfalls 0.0001". AES ist noch nicht so lange auf dem Markt, also auch noch nicht ganz so gut analysiert. Bei einem Faktor von 0.5 oder 0.1 wuerde niemand von einer Schwaeche eines Algorithmus sprechen.

----------

## Sujao

Woher nimmst Du diese vollkommen unbegruendete Annahme, dass meine Aussage nicht stimmt?

Leute schieben schon Panik, wenn eine möglicherweise unter bestimmten Umständen. potentielle. zum Teil auftretende. äußerst seltene. zum Teil unbewiesene mathematische Schwäche in einem Algorithmus gefunden wird.

----------

## manuels

 *Sujao wrote:*   

> Leute schieben schon Panik, wenn eine möglicherweise unter bestimmten Umständen. potentielle. zum Teil auftretende. äußerst seltene. zum Teil unbewiesene mathematische Schwäche in einem Algorithmus gefunden wird.

 

Verständlicher Weise. Eine kleine Schwachstelle entwickelt sich schnell zu einer großen.

Es kann ganz schnell sein, dass die aktuelle top sichere Verschlüsselung von heut auf morgen nix mehr wert ist.

----------

## Yamakuzure

@Sujao:

Ich sag doch: Alles Paranoiker!  :Wink: 

----------

## schachti

 *Yamakuzure wrote:*   

> ???
> 
> Einzig der Diebstahl meiner Festplatten wäre ärgerlich. Ja, dafür würde sich eine Verschlüsselung in der Tat lohnen.
> 
> 

 

Und was ist, wenn mal eine Festplatte während der Garantie kaputtgeht und eingeschickt werden muss? Ich mag den Gedanken nicht, dass da evtl. ein Service-Techniker in meinen Bewerbungsschreiben, Briefen an Versicherungen, Steuerdaten etc. herumschnüffelt. Oder dass gar die instandgesetzte Festplatte an einen ganz anderen Kunden geht... (Zumindest vor ein paar Jahren war das angeblich üblich, wie sieht das aktuell aus?)

Persönliche Daten sind schützenswert, wie uns die Datenskandale der letzten Zeit gezeigt haben. Das gilt nicht nur für das, was man unfreiwillig in Kundendateien von Versicherern, Kreditinstituten, Telekommunikationsunternehmen etc. bzw. freiwillig bei StudiVZ und Co. preisgibt, sondern auch für das, was preisgegeben werden könnte, wenn jemand an meinen PC oder meine Festplatte kommt. Nein, ich habe nichts auf der Platte, das strafrechtlich relevant oder zumindest sehr peinlich für mich wäre - und trotzdem verschlüssele ich meine Home-Partition, einfach nur für den Fall der Fälle.

----------

## SkaaliaN

Ich weiß gar nicht wieso man es überhaupt großartig erklären muss ob und wann und warum man seine Partition verschlüsselt. 

Es steht außer Frage das man seine Daten auf eine gewisse Art und Weise schützen soll. Wie bleibt jedem selbst überlassen. Die einen machen mehr für Ihren Schutz, die anderen weniger. Die einen interessieren sich für Verschlüsselung und probieren es aus. Die anderen machen es weil sie es müssen und andere wiederrum sagen das es ihnen sonst wo vorbeigeht und machen es gar nicht. 

Ich schütze meine Daten ebenfalls. Allein aus Interesse und zudem auch aus Datenschutzgründen. Ich hab einfach keine Lust meine defekte Festplatte (falls es mal so sein sollte) an meinen für die Garantie zuständigen Anbieter ohne Verschlüsselung abzugeben.  Gleiches gilt für einen Einbruch u.s.w.!  Was auf meiner Festplatte ist geht niemanden was an. Andernfalls würde ich es sharen. 

Bei mobilen Festplatten würde ich persönlich grundsätzlich verschlüsseln, da diese natürlich auch schneller in falsche Hände geraten könnten.

Jeder musst für sich ausmachen was er möchte und was ihm am liebsten ist und ob er sich einlesen oder auch einarbeiten will..

Mal davon abgesehen das dieser Thread mittlerweile total vom eigentlichen Thema abdriftet, sollte doch die Frage des Threadstellers mittlerweile doch beantwortet sein. Oder nicht?

----------

## Yamakuzure

Davon einmal ganz abgesehen, dass es natürlich absolut sinnvoll ist zumindest die Partition auf der sich /home (und etwaige andere persönliche Daten) befindet zu verschlüsseln, wüßte ich persönlich noch ganz gerne, was denn überhaupt empfehlenswert ist? Damit meine ich nicht den Algorithmus, sondern die Software, mit der man das ganze bewerkstelligt. dmcrypt? truecrypt? was anderes? Wie sind da eure Erfahrungen?

@metal1ty:

Es ging mir nicht darum die Verschlüsselung ansich zu hinterfragen. bei persönlichen Daten sinnvoll bis heutzutage notwendig, keine Frage. Es ging mir um die völlig überzogene Diskussion um "den stärksten Algorithmus", die ich, nach wie vor, für überzogen halte.  :Wink: 

----------

## kernelOfTruth

 *Yamakuzure wrote:*   

> Davon einmal ganz abgesehen, dass es natürlich absolut sinnvoll ist zumindest die Partition auf der sich /home (und etwaige andere persönliche Daten) befindet zu verschlüsseln, wüßte ich persönlich noch ganz gerne, was denn überhaupt empfehlenswert ist? Damit meine ich nicht den Algorithmus, sondern die Software, mit der man das ganze bewerkstelligt. dmcrypt? truecrypt? was anderes? Wie sind da eure Erfahrungen?
> 
> @metal1ty:
> 
> Es ging mir nicht darum die Verschlüsselung ansich zu hinterfragen. bei persönlichen Daten sinnvoll bis heutzutage notwendig, keine Frage. Es ging mir um die völlig überzogene Diskussion um "den stärksten Algorithmus", die ich, nach wie vor, für überzogen halte. 

 

da bei truecrypt die leute nicht wirklich wissen wer dahinter steckt (NSA, ... ???)

sind klar cryptsetup(-luks) und eCryptFS demgegenüber zu empfehlen

ich nutze zur Zeit cryptsetup und damit sehr zufrieden

----------

## Yamakuzure

klasse, danke!

----------

## Sujao

Hmm, laut Wikipedia ist Truecrypt Open Source, der Quellcode ist also theoretisch nachprüfbar. Ich nutze aber auch lieber Cryptsetup-Luks weil es besser in das system integrierbar ist. Truecrypt nur für Windowspartitionen.

----------

## schachti

Ich nutze für meine Home-Partition eine dm-crypt verschlüsselte Partition, die mittels pam_mount beim Einloggen automatisch gemountet wird, so dass keine zusätzliche Passworteingabe erforderlich ist. Finde ich sehr angenehm.

----------

## Yamakuzure

Das klingt doch gut.

Wenn ich mich recht entsinne habe ich hier im Forum auch irgendwo ein dm-crypt + pam-mount howto gesehen.

----------

## schachti

Du meinst sicher diesen Thread.

----------

## doedel

Ich hab meine Root-Partition mit aes-cbc-essiv:sha256 verschlüsselt und meine Datenpartition mit Truecrypt (da weiss ich gar nicht mehr genau was ich gewählt habe, da hier drauf sowieso nichts allzuwichtiges ist, Musik, Filme, ...). Den Truecrypt Container habe ich, da ich von meinem Windows aus ebenfalls auf die Daten zugreifen will.

Ich habe noch eine recht kleine Partition auf der wichtige Briefe usw liegen, ebenfalls mit dm-crypt/luks aber zusätzlich zum Passwort, ein Keyfile auf der Root-Partition, die wird beim booten automatisch entschlüsselt.

----------

## pieter_parker

 *Quote:*   

> Neuer Angriff auf AES-Verschlüsselung
> 
> Besser als Brute-Force, aber keine reale Gefahr für AES
> 
> Forscher der Universität Luxemburg haben eine neue Angriffsmethode auf AES vorgestellt. Damit lässt sich das bisher als sicher geltende AES schneller knacken als mit einem Brute-Force-Angriff.

 

http://www.golem.de/0907/68117.html

----------

## think4urs11

und ein paar Zeilen weiter lesen wir

 *Quote:*   

> Die Angriffe seien theoretischer Natur und würden es vermutlich auch bleiben, so Schneier. Doch auch wenn es derzeit keinen Grund gebe, von einer Verwendung von AES abzusehen,

 

Solange das Brechen eines Schlüssels noch >>2^75 Versuche benötigt und ich nicht gleichzeitig auf der Liste der top wanted in den top 10 auftauche ist alles prima. Und derzeit scheint das beste Verfahren hier (bei einigen Schlüsseln) 2^96 Versuche zu brauchen.

Beim Hashen sieht das etwas anders aus, aber selbst dort ist noch kein akuter Handlungsbedarf für $ich!=Topterrorist

----------

## Sujao

Ich glaube das "Problem" ist eher, dass selbst das CIA mit ihren Supercomputern jetzt nicht mehr 10000 Jahre sondern nur noch 100 Jahre braucht. Ich denke, dass kann man verschmerzen.

----------

## mv

 *Sujao wrote:*   

> Ich glaube das "Problem" ist eher, dass selbst das CIA mit ihren Supercomputern jetzt nicht mehr 10000 Jahre sondern nur noch 100 Jahre braucht.

 

Nach Moores Gesetz wären sie dann also in ca. 9 Jahren so weit, dass sie im Schnitt nur noch 1 Jahr brauchen. Wenn Du politisch unliebsam bist, solltest Du also keine Daten mit AES verschlüssseln, die Dir in 10 Jahren schaden könnten.

----------

## schachti

Ich zitiere dazu mal heise online:

 *Quote:*   

> 
> 
> "Die neuen Angriffe funktionieren nur, wenn man annimmt, dass ein Angreifer den unbekannten Schlüssel manipulieren kann", erläutert Christian Rechberger, Kryptologe an der TU Graz, gegenüber heise Security.
> 
> 

 

Das ist also bisher wirklich nur ein theoretischer Angriff.

----------

## pieter_parker

Fujitsu liefert Bridge für SATA-Festplatten an USB 3.0

Controller mit AES-Verschlüsselung für schnelle externe Laufwerke

-> http://www.golem.de/0907/68609.html

----------

## moe

Ich würde gerne nochmal auf dieses Thema zurückkommen:

 *kernelOfTruth wrote:*   

>  *pieter_parker wrote:*   wie ist das eigentlich wenn ich nicht zukomme
> 
> cryptsetup luksClose festplatte
> 
> zumachen weil .. weil z.b. ein stromausfall war
> ...

 

Ich habe seit etwa einem halben Jahr eine Partition mit LUKS und aes-cbc-essiv:sha256 verschlüsselt, und dadrin ein jfs-Dateisystem. Das ganze wird vie pam_mount beim Einloggen eingehangen. Der Rechner ist schon häufig abgestürzt, ohne das meine Daten weg waren. Insofern würd ich die Aussage von kernelOfTruth als bedauerlichen Einzelfall sehen.

Aber meine eigentliche Frage, wie verhält man sich im Fall von unsauberen umounts? Ein automatischer fsck beim Booten fällt ja aus, pam_mount tut auch scheinbar nichts in Richtung fsck. Ich mache es momentan so, dass ich nach nem Absturz als root anmelde, luksOpen usw. mache und dann fsck.jfs, aber das ist bestimmt nicht das Optimum, oder?

----------

## Sujao

Hab seit ca 4-5 Jahren XFS ohne jemals ein Problem gehabt zu haben und seit 1,7 Jahren XFS und ext3 und ebenfalls niemals Probleme gehabt.

----------

## pieter_parker

Einschläge bei AES-256 kommen näher -> http://www.heise.de/newsticker/meldung/142899

----------

## Yamakuzure

 *pieter_parker wrote:*   

> Einschläge bei AES-256 kommen näher -> http://www.heise.de/newsticker/meldung/142899

 Haha! *Quote:*   

> Der Angriff gegen AES-256 mit neun Runden benötigt Zeit in der Größenordnung 2^39, die selbst ein regulärer PC bewältigen kann, und mit zehn Runden 2^45. Der Zeitaufwand gegen elf Runden liegt mit 2^70 jedoch knapp oberhalb der Durchführbarkeit.

 Und weiter unten: *Quote:*   

> AES-256 verwendet standardmäßig 14 Runden. 

 Alleine mit der Steigerung von 10 auf 11 Runden zeigt, wie es wohl bei 12 aussieht.  :Very Happy:  Da sind 14 wohl noch eine Weile recht sicher....

----------

## think4urs11

 *pieter_parker wrote:*   

> Einschläge bei AES-256 kommen näher -> http://www.heise.de/newsticker/meldung/142899

 

Aber eben nur -256. AES128 kann weiterhin als sicher angesehen werden.

Bei -192/-256 ist es bedingt durch die zu niedrige Anzahl der Runden vergleichsweise leichter den Schlüssel herauszubekommen.

----------

## pieter_parker

hab seit ein paar monaten eine 1tb festplatte mit luks und aes verschluesselt

hab die festplatte mit aes-cbc-essiv verschluesselt

auf der festplatte sind ca 200.000 dateien

texte, bilder, musik und videodateien

wenn ich ein verzeichnis erstellen will dauert es 3 bis 5 sekunden bis es erstellt ist (sehe im gkrellm das er in der zeit mit 400...700kb/s liest)

das kopieren von dateien geht mit bis zu 70mb/s aber ich sehe bei munin das es sehr viele io-wait erzeugt

ich bin nicht wirklich zu frieden damit

----------

## mv

 *pieter_parker wrote:*   

> wenn ich ein verzeichnis erstellen will dauert es 3 bis 5 sekunden bis es erstellt ist

 

Bist Du sicher, dass das ein Problem der Verschluesselung ist? Das klingt eher so, als wenn sich die Platte zwischenzeitlich schlafengelegt hat und erst wieder hochlaeuft.

 *Quote:*   

> aber ich sehe bei munin das es sehr viele io-wait erzeugt

 

USB-Platte? Moeglicherweise kann die Platte bei Dir wegen Hardwareinkompatibilität nicht im optimalen Modus betrieben werden. Bist Du sicher, dass das nicht auch ohne Verschluesselung auftritt?

Außerdem: Hast in /etc/modules.d Aliase für die prozessoroptimierten Algorithmen gesetzt, oder benutzt Du nur die generischen?

----------

## ScytheMan

 *mv wrote:*   

> 
> 
> Außerdem: Hast in /etc/modules.d Aliase für die prozessoroptimierten Algorithmen gesetzt, oder benutzt Du nur die generischen?

 

sry fürs hijacken, aber muss man das (spreche jetzt von dem aes modul das es ja generisch und als 64bit optimierte version gibt)?

Angenommen ich baue es fest in den Kernel ein, wie mache ich dann davon Nutzen? Ich dachte der Kernel nutzt die optmierte Version automatisch.

gruß ScytheMan

----------

## mv

 *ScytheMan wrote:*   

> Ich dachte der Kernel nutzt die optmierte Version automatisch.

 

Die optimierte Version ist ja anscheinend als eigenes Modul implementiert, nicht nur als "Verbesserung" einiger Code-Teile des alten Moduls. Weshalb sollte der Kernel also automatisch ein per Userspace explizit angefordertes Modul gegen ein anderes austauschen? (Falls er nicht mit "alias" dazu angewiesen wurde?). Sicher war ich zunaechst auch nicht, aber einfache Benchmarks reichen aus, das zu bestaetigen.

----------

## kernelOfTruth

 *Quote:*   

> 4.2.  Implementing a cipher
> 
> A cipher is the basic of an cryptographic encryption algorithm that can be registered. The user has to fill the struct crypto_alg, and the struct cipher_alg which is embedded in the first one.
> 
>  
> ...

 

Quelle: http://diploma-thesis.siewior.net/html/diplomarbeitch4.html

somit dürfte im Idealfall die Software bzw. userspace selbst das passende assembler-basierte Module (falls vorhanden) verwenden   :Smile: 

update:

also anscheinend fehlt cryptsetup diese funktion optimierte module zu erkennen (stand 2007):

http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg400433.html

 *Quote:*   

> 
> 
> Bug#445186: cryptsetup: Please load optimized cipher kernel modules by default

 : http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg400205.html

wenn jemand mehr darüber weiß - nur zu  :Smile: 

ich würde gerne meine datei transfers mit verschlüsselung beschleunigen

update2:

sorry falls ich nur stuss schreib - ich komm im mom. zu recht wenig schlaf   :Rolling Eyes: 

anscheinend beziehen sich die patches nur auf das laden von asm-Modulen, dass diese unterstützt werden - davon wird auszugehen sein ....

----------

## mv

 *kernelOfTruth wrote:*   

> ich würde gerne meine datei transfers mit verschlüsselung beschleunigen

 

Falls ich die alias-Geschichte unklar formuliert haben sollte. Bei mir sieht es so aus:

 */etc/modoprobe.d/x86_64.conf wrote:*   

> #alias aes      aes-x86_64
> 
> alias aes       aes-ni_intel
> 
> alias salsa20   salsa20-x86_64
> ...

  bzw.  */etc/modprobe.d/i586.conf wrote:*   

> alias aes       aes-i586
> 
> alias salsa20   salsa20-i586
> 
> alias twofish   twofish-i586

 

Ob dies das empfohlene Vorgehen ist, weiss ich nicht, aber die cryptsetup-Partionen sind damit merklich schneller geworden.

----------

## pieter_parker

Erste Passwort-Erzwingungshaft in Großbritannien

In Großbritannien sind zwischen 1. April 2008 und 31. März 2009 erste Haftstrafen verhängt worden, weil Beschuldigte die Herausgabe von Passwörtern bzw. von kryptografischen Schlüsseln verweigerten

http://www.heise.de/newsticker/meldung/143462

wie ist das bei uns in .de ?

----------

## ScytheMan

sowas wie beugehaft für passwörter gibts imho in deutschland (noch) nicht, ansonst hilft nur plausible deniability  :Smile: 

----------

## schachti

 *mv wrote:*   

> bzw.  */etc/modprobe.d/i586.conf wrote:*   alias aes       aes-i586
> 
> alias salsa20   salsa20-i586
> 
> alias twofish   twofish-i586 

 

Ich weiß nicht, ob das wirklich nötig ist - ich habe das nicht eingestellt, dennoch sagt bei mir lsmod folgendes:

```

Module                  Size  Used by

aes_i586                7892  12

aes_generic            26932  1 aes_i586

```

----------

## mv

 *schachti wrote:*   

> ich habe das nicht eingestellt, dennoch sagt bei mir lsmod folgendes:
> 
> ```
> 
> Module                  Size  Used by
> ...

 

lsmod gibt ja keine Auskunft darüber, welche Module benutzt werden, sondern nur, welche geladen wurden: Es spiegelt eher das wieder, was in Deiner /etc/conf.d/modules steht (falls Du baselayout-2 benutzt; wie das bei baselayout-1 war, habe ich schon lange vergessenI).

Die Module werden ja nicht automatisch von cryptsetup geladen (außer, das ist in den letzten Versionen geändert worden), sondern cryptsetup spricht nur die geladenen Module an und gibt einen (IIRC ziemlich unverständlichen) Fehler aus, wenn sie nicht geladen wurden.

----------

## Anarcho

Also ich habe einfach das jeweils richtige AES Modul im Kernel drin, das andere erst garnicht aktiviert. Da brauche ich doch nicht den Unsinn mit mod aliases usw.

Einfach gleich das richtig auswählen und gut ist.

----------

## mv

 *Anarcho wrote:*   

> Also ich habe einfach das jeweils richtige AES Modul im Kernel drin, das andere erst garnicht aktiviert.

 

Das geht nicht immer, etwa wenn man den selben Kernel auf mehreren Rechnern haben will. Außerdem ist nicht ganz klar, ob dies den gewünschten Effekt hat: Für CONFIG_CRYPTO_AES_586 musst Du CONFIG_CRYPT_AES automatisch mitselektieren. (Zum Vergleich: Bei CONFIG_CRYPTO_TWOFISH_586 wird nur CONFIG_CRYPTO_TWOFISH_COMMON nicht aber CONFIG_CRYPTO_TWOFISH mitselektiert.)

----------

## schachti

 *mv wrote:*   

> lsmod gibt ja keine Auskunft darüber, welche Module benutzt werden, sondern nur, welche geladen wurden: Es spiegelt eher das wieder, was in Deiner /etc/conf.d/modules steht (falls Du baselayout-2 benutzt; wie das bei baselayout-1 war, habe ich schon lange vergessenI).
> 
> Die Module werden ja nicht automatisch von cryptsetup geladen (außer, das ist in den letzten Versionen geändert worden), sondern cryptsetup spricht nur die geladenen Module an und gibt einen (IIRC ziemlich unverständlichen) Fehler aus, wenn sie nicht geladen wurden.

 

Ich lade keine AES-Module explizit, sondern die werden automatisch von cryptsetup (oder pam_mount) geladen. Über /etc/conf.d/modules lade ich nur nvidia, aufs, fuse und die VirtualBox-Module. Und die Spalte count in der Ausgabe von lsmod gibt an, wie oft das Modul genutzt wird.

----------

## pieter_parker

wenn ich so um die 50mb/s an datendurchsatz haben moechte und eine intel atom cpu mit 2 kernen verwende, welche verschluesselung koennte ich dann fuer die festplatte im besten fall benutzen ?

gibt es kein geraet das ich zwischen mainboardsataport und festplattesataport haenge das mir die daten ent und ver -schluesselt ? meine fuer ide mal soetwas gesehen zuhaben ...

----------

## avx

 *Quote:*   

> wenn ich so um die 50mb/s an datendurchsatz haben moechte und eine intel atom cpu mit 2 kernen verwende

 Könnte schwierig werden, ich schaff das mit ach und krach auf einem E6600 - gut, bei mir ist's auch Serpent. Wenn's um Speed geht, dürfte Blowfish bei dem System wohl erste Wahl sein.

 *Quote:*   

> gibt es kein geraet das ich zwischen mainboardsataport und festplattesataport haenge das mir die daten ent und ver -schluesselt ?

 Klar gibt es Crypto-Karten, z.B. von Sun, die sind aber alles andere als billig(600€+, jedenfalls bei meinen Bedürfnissen).

----------

## Yamakuzure

 *pieter_parker wrote:*   

> Erste Passwort-Erzwingungshaft in Großbritannien
> 
> In Großbritannien sind zwischen 1. April 2008 und 31. März 2009 erste Haftstrafen verhängt worden, weil Beschuldigte die Herausgabe von Passwörtern bzw. von kryptografischen Schlüsseln verweigerten

 Lösung: TrueCrypt benutzen und "Hidden Volumes" erstellen.  :Wink: 

----------

## avx

 *Quote:*   

> Lösung: TrueCrypt benutzen und "Hidden Volumes" erstellen.

 Na, das ist wieder so ein "Argument", was einem in dieser Situation mehr Ärger einbringt als es nutzt.

Wenn die nicht beweisen können, dass es existiert, kannst du auch nicht beweisen, dass es nicht existiert - ausser natürlich man legt alles offen. Bei einem Gegner, der nicht fair spielt, beisst man sich damit selbst ziemlich in den Hintern.

----------

## pieter_parker

in raum1 steht computer1 (itx intel atom mainboard)

in raum2 steht computer2 (mittelgrosser server computer, ausreichend leistung)

raum1 ist von raum2 etwa 12m per kabelweg entfernt, es liegen netzwerkkabel

an computer1 sind 2 sata wechselfestplatten mit je 2tb groesse angeschlossen und die sollen an computer2 gemountet werden

die wechselfestplatten sollen verschluesselt werden

die festplatten per dm_crypt in computer1 einhaengen und dann eine nfs freigabe darauf ?

oder die festplatten unverschluesselt in computer1 einhaengen und dann computer2 eine 2tb grosse verschluesselte datei erstellen lassen die dann in computer2 eingehangen wird?

wie wuerdet ihr es machen ?

----------

## papahuhn

Für sowas wären Network Block Devices prädestiniert. Ich hab das mal vor Jahren getestet, aber das wars noch nicht ganz stabil. Vielleicht ist es heute besser geworden.

 *pieter_parker wrote:*   

> in raum1 steht computer1 (itx intel atom mainboard)
> 
> in raum2 steht computer2 (mittelgrosser server computer, ausreichend leistung)
> 
> raum1 ist von raum2 etwa 12m per kabelweg entfernt, es liegen netzwerkkabel
> ...

 

----------

## pieter_parker

koennen nbd festplatten auch jederzeit in andere computer eingebaut werden und dann da benutzt werden ?

welche nachteile bringt es wenn ueber das netzwerk und die nfs freigabe in einer 2tb grossen verschluesselten datei geschrieben und von gelesen wird ?

----------

## schachti

Die Verschlüsselung sollte der Rechner machen, an dem die Platten hängen.

----------

## pieter_parker

ich befuerchte nur das ein rechner mit atom cpu zuschwach ist und dann nicht genug mb/s rumkommen werden

----------

## schachti

Dann würde ich persönlich die Platten an den Rechner anschließen, der sie im wesentlichen auch nutzt.

----------

## pieter_parker

 *schachti wrote:*   

> Dann würde ich persönlich die Platten an den Rechner anschließen, der sie im wesentlichen auch nutzt.

 

bietest du dich als dj an ? :D 

nein, immer in raum2 der auf einer anderen etage liegt zulaufen um die platte(n) zuwechseln waere nicht gut

----------

## schachti

ok, mir war irgendwie entgangen, dass das Wechsel-Festplatten sind - das macht's nicht einfacher.

Ich persönlich vertrete immer noch die Philosophie, dass die Verschlüsselung derjenige Rechner machen sollte, an den die Platten angeschlossen sind. Teste doch einfach mal, welchen Durchsatz Du auf dem Rechner mit entsprechender Verschlüsselung erreichst (zum Beispiel eine Datei als Loopback-Device einhrichten und dann mit dmcrypt verschlüsseln). Ich kenne mich mit den Interna des Blocklayers und von dmcrypt nicht aus, daher weiß ich nicht, was schiefgehen könnte, wenn der Client selbst verschlüsselt.

----------

## root_tux_linux

LUKS + Serpent

----------

## pieter_parker

ist es inzwischen moeglich die gpu fuer festplattenverschluesselungsberechnungen mit einzubeziehen ?

----------

## pieter_parker

fragezeichen

----------

## Max Steel

Unter Umständen ist da was mit CUDA möglich. Allerdings kann ich dazu nichts weiter sagen. Leider.

Ich weiß genaugenommen nichteinmal was alles mit CUDA möglich ist.

----------

## kernelOfTruth

 *Max Steel wrote:*   

> Unter Umständen ist da was mit CUDA möglich. Allerdings kann ich dazu nichts weiter sagen. Leider.
> 
> Ich weiß genaugenommen nichteinmal was alles mit CUDA möglich ist.

 

mit CUDA ist einiges möglich:

unter anderem wird jetzt die Analyse im neuen Intrusion Detection System Suricata beschleunigt

http://linux.slashdot.org/story/09/12/31/2143250/New-Open-Source-Intrusion-Detector-Suricata-Released

Kaspersky nutzt CUDA auch in der Analyse von Viren,

es sollte wohl außer Frage stehen, ob CUDA die Verschlüsselung beschleunigen kann - die Frage wird sein, wo es als erstes aufschlägt ...

ist CUDA nicht proprietär bzw. nicht opensource'd ?

so wird evtl. TrueCrypt damit als erstes anfangen

ich wage es zu bezweifeln, dass Linus Support für so etwas in den Linux-Kernel lässt   :Rolling Eyes: 

----------

## pieter_parker

hab ein 1tb grosses laufwerk mit ca 1.000.000 dateien und aes-cbc-essiv:sha256 verschluesselung

das laufwerk schafte früher 70 bis 100 mb/s beim lesen und schreiben, in letzter zeit ist die schreibrate bei ca 3 bis 10 mb/s

im syslog kommen bei laengerem schreiben diese meldungen

```
Mar 16 02:49:49 pc1 kernel: [1312854.000075] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Mar 16 02:49:49 pc1 kernel: [1312854.000083] ata3.00: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/00 tag 0 pio 512 in

Mar 16 02:49:49 pc1 kernel: [1312854.000084]          res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)

Mar 16 02:49:49 pc1 kernel: [1312854.000091] ata3.00: status: { DRDY }

Mar 16 02:49:49 pc1 kernel: [1312854.000096] ata3: hard resetting link

Mar 16 02:49:54 pc1 kernel: [1312858.847040] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Mar 16 02:49:54 pc1 kernel: [1312858.849448] ata3.00: configured for UDMA/133

Mar 16 02:49:54 pc1 kernel: [1312858.849465] ata3: EH complete

Mar 16 02:53:58 pc1 kernel: [1313103.000870] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Mar 16 02:53:58 pc1 kernel: [1313103.000878] ata3.00: cmd b0/d8:00:00:4f:c2/00:00:00:00:00/00 tag 0

Mar 16 02:53:58 pc1 kernel: [1313103.000879]          res 40/00:48:17:f6:82/00:00:72:00:00/40 Emask 0x4 (timeout)

Mar 16 02:53:58 pc1 kernel: [1313103.000881] ata3.00: status: { DRDY }

Mar 16 02:53:58 pc1 kernel: [1313103.000887] ata3: hard resetting link

Mar 16 02:53:59 pc1 kernel: [1313103.510269] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Mar 16 02:53:59 pc1 kernel: [1313103.544298] ata3.00: configured for UDMA/133

Mar 16 02:53:59 pc1 kernel: [1313103.544314] ata3: EH complete

Mar 16 02:56:34 pc1 kernel: [1313259.001032] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Mar 16 02:56:34 pc1 kernel: [1313259.001040] ata3.00: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/00 tag 0 pio 512 in

Mar 16 02:56:34 pc1 kernel: [1313259.001041]          res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)

Mar 16 02:56:34 pc1 kernel: [1313259.001044] ata3.00: status: { DRDY }

Mar 16 02:56:34 pc1 kernel: [1313259.001049] ata3: hard resetting link

Mar 16 02:56:37 pc1 kernel: [1313262.264029] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Mar 16 02:56:37 pc1 kernel: [1313262.266451] ata3.00: configured for UDMA/133

Mar 16 02:56:37 pc1 kernel: [1313262.266469] ata3: EH complete

Mar 16 03:00:53 pc1 kernel: [1313517.991176] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Mar 16 03:00:53 pc1 kernel: [1313517.991184] ata3.00: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/00 tag 0 pio 512 in

Mar 16 03:00:53 pc1 kernel: [1313517.991185]          res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)

Mar 16 03:00:53 pc1 kernel: [1313517.991188] ata3.00: status: { DRDY }

Mar 16 03:00:53 pc1 kernel: [1313517.991193] ata3: hard resetting link

Mar 16 03:00:55 pc1 kernel: [1313519.572150] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Mar 16 03:00:55 pc1 kernel: [1313519.574564] ata3.00: configured for UDMA/133

Mar 16 03:00:55 pc1 kernel: [1313519.574588] ata3: EH complete

Mar 16 03:03:32 pc1 kernel: [1313676.991359] ata3.00: NCQ disabled due to excessive errors

Mar 16 03:03:32 pc1 kernel: [1313676.991365] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Mar 16 03:03:32 pc1 kernel: [1313676.991376] ata3.00: cmd b0/d0:01:00:4f:c2/00:00:00:00:00/00 tag 0 pio 512 in

Mar 16 03:03:32 pc1 kernel: [1313676.991378]          res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)

Mar 16 03:03:32 pc1 kernel: [1313676.991382] ata3.00: status: { DRDY }

Mar 16 03:03:32 pc1 kernel: [1313676.991390] ata3: hard resetting link

Mar 16 03:03:35 pc1 kernel: [1313680.051052] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Mar 16 03:03:35 pc1 kernel: [1313680.053496] ata3.00: configured for UDMA/133

Mar 16 03:03:35 pc1 kernel: [1313680.053518] ata3: EH complete
```

von dem laufwerk lässt sich problemlos mit bis 100 mb/s lesen

es macht beim lesen und schreiben keine unnatürlichen geräusche, daher schliesse ich ein mechanischen fehler sogut wie aus

ist dm_crypt mit den fast 1.000.000 dateien überfordert ? cpu auslastung hab und hatte ich nie viel beim lesen/schreiben

sind die daten zusehr quer auf dem datenträger verteilt ?

----------

## py-ro

Die Meldungen deuten recht eindeutig auf Hardware hin, wir sehen die hier öfters.

Bei uns ist es dann der Dreisatz: Wechselrahmen, SATA-Kabel, Festplatte.

Und ganz selten der Controller.

MfG

Py

----------

## kernelOfTruth

wenn er problemlos lesen kann, handelt es sich wohl weniger um ein Kabel- oder Controller-Problem:

 *Quote:*   

> NCQ disabled due to excessive errors 

 

<-- das scheint ein NCQ-(Firmware) Problem zu sein  :Wink: 

versuch einmal Folgendes:

 *Quote:*   

> echo "the following practically disables NCQ which is buggy"
> 
> echo "on a lot of drives and known to drive CFQ and other i/o schedulers crazy "
> 
> for i in /sys/block/sd*; do
> ...

 

andernfalls könnte es auch ein Problem mit Barrier-Write-Support sein: das Laufwerk braucht zu lange zum Schreiben, dem System/Kernel dauert das zu lange und gibt Fehler aus

oder natürlich auch der schieren Menge an Dateien wegen:

bei mir tritt sowas ähnliches ab und zu mal auf, wenn ich sehr viele Dateien zum auf die Platte schreiben habe, in dem Falle:

 *Quote:*   

> echo "5" > /proc/sys/vm/dirty_background_ratio
> 
> echo "6"   > /proc/sys/vm/dirty_ratio
> 
> echo "100" > /proc/sys/vm/vfs_cache_pressure
> ...

 

einmal testen, ob das Besserung bringt

wenn du einen etwas älteren Kernel hast (und cfq):

 *Quote:*   

> for i in /sys/block/sd*; do
> 
> #         /bin/echo "cfq" >  $i/queue/scheduler
> 
>          /bin/echo "0" >  $i/queue/iosched/slice_idle # default: 6; 0 fixes low throughput with drives which have a buggy ncq implementation
> ...

 

----------

## pieter_parker

die fehlermeldungen haben sich von heute auf morgen gelegt, ich weiss nicht was das war oder woher es kam und warum es jetzt verschwunden ist

screenshot von der gkrellm cpu und festplatten anzeige

http://img3.imageshack.us/img3/3687/25725228.png

von sdf wird gelesen und auf sde wird geschrieben

beide laufwerke sind das gleiche model

beide schaffen bis zu 80..90mb/s schreiben

und beim lesen sogar etwas über 100mb/s

die cpu ist ein intel q6600 mit 4 echten kernen, die kiste hat 8gig ram

auf dem system lauft neben 2 vm die am ideln sind nichts

warum ist da soviel oranger cpu verbrauch ?

und warum so abgehackt auf jedem kern so ein bischen ?

bei dem laufwerk sde wo geschrieben wird, ist zubeobachten das das was geschrieben wird wellenförmig steigt und sinkt, hat das was zubedeuten ?

die schreibraten bei sde fallen manchmal auf bis zu 15mb/s fuer ein paar sekunden

bei einem dd if=/dev/sde oder sdf und of=/dev/null komme ich auf werte von über 100mb/s

beim lesen von /dev/mapper/verschluesseletefestplatte-sde1 oder sdf1 komme ich auf werte von 70 bis 80mb/s

irgendwie hab ich das gefühl als ob nicht genug cpu leistung die ja da ist genutzt wird

was kann ich tun für mehr datendurchsatz ?

----------

## bbgermany

Hi,

was für eine Virtualisierungslösung hast du denn am laufen? KVM, vmware, VBox...?

Ich hab vmware-server am laufen und bei mir sind die CPUs auch recht häufig am arbeiten, obwohl die VM selber nichts macht.

MfG. Stefan

----------

## pieter_parker

hab vmware-server 2 laufen, auch wenn ich ihn stoppe ändert sich an der cpu auslastung und den transferraten leider nicht

----------

## pieter_parker

kann es vielleicht sein das das laufwerk zu langsamme reaktionszeiten für das system und für die verschlüsselung hat und dadurch alles irgendwie ins stocken kommt ?

wenn dem so ist, was tut man per software um dem entgegen zuwirken ?

----------

## pieter_parker

oder kann es an der groesse vom laufwerk liegen ? hatte bisher nie laufwerke über 500gb verschlüsselt

das jetzige ist 1tb gross, und es lässt sich nur mit 5 bis 15mb/s darauf schreiben

wie bekomme ich es schneller ?

ohne verschlüsselung ist schreiben mit bis zu 70mb/s möglich

----------

## kernelOfTruth

*) ich würd auf jedenfall von aes-cbc-essiv:sha256  ---->   aes-lrw-benbi:sha256 --key-size 384

das ist sicherer und performanter

*) welches Dateisystem setzt du denn ein ?

bei etwas älteren Kerneln hab ich Probleme mit reiser4 & reiserfs beim Schreiben großer Datenmengen mit Verschlüsselung gehabt

*) ncq abschalten bzw. die Queue verringern bringt nix ?

*) wenn er viele Daten im Cache ansammelt und mit dem Schreiben nicht nachkommt, ist es evtl. besser, den Cache zu verkleinern:

 *Quote:*   

> /proc/sys/vm/dirty_background_ratio
> 
> /proc/sys/vm/dirty_ratio

 

<-- beide mal auf 5 setzen, vielleicht hilft das

*) /proc/sys/vm/vfs_cache_pressure

damit könntest du auch etwas herumspielen

*) setzt du 64bit ein ? mit den 64bit assembler-modulen dürfte der Durchsatz etwas besser sein

bei x86 die 586 assembler-Module nicht vergessen !

*) einmal Folgendes versuchen:

 *Quote:*   

> # playing it safe
> 
> for i in /sys/block/sd*; do
> 
>          /bin/echo "256" >  $i/queue/read_ahead_kb
> ...

 

*) du setzt CFQ als I/O-Scheduler ein?

versuch einmal den deadline scheduler, damit sollte der Durchsatz (noch) besser sein, dafür aber die Reaktionsfähigkeit schlechter

*) du könntest noch etwas mit CFQ herumspielen:

 *Quote:*   

> for i in /sys/block/sd*; do
> 
>          /bin/echo "cfq" >  $i/queue/scheduler
> 
> #         /bin/echo "6" >  $i/queue/iosched/slice_idle # default: 6, 0 fixes low throughput with drives which have a buggy ncq implementation
> ...

 

*) evtl. liegt es am CPU scaling governor, dann einmal diesen aussetzen bzw. permanent auf Leistung stellen:

 *Quote:*   

> echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

 

(und der anderen CPUs / Kerne einmal auf "performance" stellen, vielleicht hilft das)

ist

*) der Stromsparende CPU- bzw. SMT-Scheduler könnte auch aktiviert sein, diesen deaktivieren:

 *Quote:*   

> echo "0" > /sys/devices/system/cpu/sched_mc_power_savings

 

und 

 *Quote:*   

> echo "0" > /sys/devices/system/cpu/sched_smt_power_savings

 

*) performance counter deaktivieren:

 *Quote:*   

> echo "vboxdrv: Trying to deactivate the NMI watchdog permanently..."
> 
> echo "vboxdrv: Warning: 2.6.31+ kernel detected. Most likely the hardware p'erformance"
> 
> echo "vboxdrv: counter framework which can generate NMIs is active. You have to prevent"
> ...

 

mehr fällt mir gerade nicht ein ...

----------

## mv

 *kernelOfTruth wrote:*   

> aes-lrw-benbi

 

Gibt es einen Grund, dass Du lrw empfiehlst anstelle des Nachfolgers xts (also etwa aes-xts-essiv)?

----------

## pieter_parker

das sind eine ganze menge sachen zum durchprobieren

64bit benutze ich nicht, nein

da das laufwerk auch ohne verschlüsselung ab und zu probleme macht, macht es jetzt noch keinen sinn an der verschlüsselung selbst zu optimieren

http://en.wikipedia.org/wiki/AES_instruction_set

 *Quote:*   

> CPUs with AES instruction set
> 
>     * Intel
> 
>           o Intel Clarkdale processor (except Core i3).
> ...

 

hat von euch jemmand ein upgrade auf eine der cpus gemacht und kann von eventuellen geschwindigkeits veränderungen berichten ?

----------

## kernelOfTruth

 *mv wrote:*   

>  *kernelOfTruth wrote:*   aes-lrw-benbi 
> 
> Gibt es einen Grund, dass Du lrw empfiehlst anstelle des Nachfolgers xts (also etwa aes-xts-essiv)?

 

das hab ich ganz vergessen: ja, xts sollte man eher nehmen

der Grund ist Abwärtskompatibilität mit 2.6.25 (wenn ich mich richtig erinner setzt meine alte liveCD diesen oder so einen ähnlichen ein, der noch kein XTS kann)

ich hab kein Problem damit, weil ich aes-cbc-essiv auf meiner swap benutze und darum nicht vom Sicherheitsproblem betroffen bin ... (ist natürlich eigentlich Blödsinn weil aes-cbc-essiv weniger performant ist und bei Swap spielt das eh keine Rolle, ich werd also wohl demnächst wechseln   :Wink:  )

Danke für den HInweis !

----------

## kernelOfTruth

 *pieter_parker wrote:*   

> das sind eine ganze menge sachen zum durchprobieren
> 
> 64bit benutze ich nicht, nein
> 
> da das laufwerk auch ohne verschlüsselung ab und zu probleme macht, macht es jetzt noch keinen sinn an der verschlüsselung selbst zu optimieren
> ...

 

die Beschleunigung dürfte 10-fach sein: http://www.tomshardware.de/Intel-Clarkdale-Core-i5-661,testberichte-240477-3.html

leider unterstützt mein Lynnfield das noch nicht   :Sad: 

----------

## ScytheMan

 *kernelOfTruth wrote:*   

>  *mv wrote:*    *kernelOfTruth wrote:*   aes-lrw-benbi 
> 
> Gibt es einen Grund, dass Du lrw empfiehlst anstelle des Nachfolgers xts (also etwa aes-xts-essiv)? 
> 
> das hab ich ganz vergessen: ja, xts sollte man eher nehmen
> ...

 

also das wäre dann aes-xts-plain:sha256 richtig?  keysize müsste ja dann 256 sein, da man mit xts ja kein benbi braucht?

----------

## Jimini

Ich habe vor ein paar Wochen meinen Laptop verschlüsselt. Jetzt bin ich diesen Thread hier mal wieder durchgegangen und dabei stellte sich mir folgende Frage: da ein gutes Passwort einiges zur Sicherheit der Verschlüsselung beiträgt - wie sicher ist da ein Keyfile, welches mit 4096 Byte Zufallsdaten "gefüllt" wurde? Die Datei liegt natürlich nicht auf dem Rechner, sondern samt /boot auf einem USB-Stick. Klar, würde jemand den Stick in die Finger bekommen, wäre das eh hinfällig, aber mich würde mal interessieren, wie sicher 4096 Zufallsdatensalat sind.

Als Verschlüsselungsalgorithmus habe ich Blowfish gewählt, werde aber wohl auf AES umsteigen (nach dem was ich bisher gelesen habe, ist AES schneller und sicherer). Aufgesetzt habe ich das ganze mit dm-crypt und luks. Beispiel:

```
cryptsetup -c blowfish -h sha256 -d /dev/urandom create swap /dev/sda2
```

cryptsetup -y --cipher serpent-cbc-essiv:sha256 --key-size 256 luksFormat /dev/sda2

(Verständnisfrage hier: im 1. Schritt wurde die Festplatte verschlüsselt, was geschah noch gleich im 2. Schritt?)

Kann man das ganze noch irgendwie optimieren? Außer natürlich, dass ich statt Blowfish AES wählen werde.

MfG Jimini

----------

## tulali

was ist heut zu tage, anfang zwanzigzwölf die sicherste methode den zugriff und inhalt eines flash laufwerks (ssd) unbefugten personen jetzt und in naher zukunft zuerschweren?

ich würde mir gerne ein system zusammenstellen ... bin mir aber über einiges noch im unklaren

sicher bin ich mir aber das es eine intel cpu mit aes-ni wird

die maschiene soll 24 stunden 7 tage die woche laufen

es soll um die 10 virtuelle maschienen geben in denen sich dann fast alles abspielt

ich dachte an ein 240 gig grosses ssd

wovon ich nur 200 nutzen möchte, und 40 gig unberührt lassen möchte damit das ssd es nutzen kann um sich selbst ordentlich zuhalten - macht das sinn?

auf die anderen 200 gig soll das gesamte system

das home vom user der die vms nutzt wollte ich nochmal zusätzlich verschlüsseln

im home vom user liegen die einzelnen vms die ich alle einzeln auch zusätzlich verschlüsseln wollte

da das system vielleicht einmal im monat wegen kernel updates neugestartet wird, dachte ich boot komplett auf einen usbstick/sdkarte or whatever zulegen und nur bei einem start/reboot/kernelupdate anzustecken

im kopf dachte ich mir "ok, wenn mal jemmand durch die erste verschlüsselung kommt, hat er das home und darin dann noch die einzelnen vms - da hat der/die ganz schön was vorsich..."

zusätzlich dachte ich schon darüber nach ein ssd zunehmen das hardware verschlüsselung macht

weiter hatte ich über eine 3tb festplatte nachgedacht, und diese auch zuverschlüsseln, und darin nochmal eine 3tb datei anzulegen und diese ebenfalls zuverschlüsseln und darein dann erst die "nutzdaten"

----------

## ScytheMan

Eine nichtzugängliche sichere genügend lange Passphrase benötigt keinerlei Doppelverschlüsselung. Es sei denn du bist masochistisch veranlagt und stehst auf Performanceverlust.

Wenn ersteres vorhanden ist, dann kommt man (für den Fall das P!=NP) nur über Seitenkanäle und Lücken im Verschlüsselungsalgorithmus auf die verschlüsselten Daten. 

Eine Mehrfachverschlüsselung erfüllt hier also keinen weiteren Zweck, da eine VM nach unten hin keinerlei Zugriffe zulassen sollte. 

Von hardwareverschlüsselnden Speichermedien würde ich Abstand nehmen, ich hätte bei solchen proprietären Lösungen zu sehr Angst vor Key Escrow oder einem simplen XOR.

Btw.  auch manche AMD haben das aes-ni instruction set mittlerweile.

----------

## kernelOfTruth

wobei der Performance-Verlust nicht so hoch sein sollte wegen avx & aes-ni

du könntest einmal versuchen die erste Verschlüsselung mit AES (hardware-beschleunigt) zu machen und drinnen dann twofish oder serpent (langsam !) zu nehmen

da kommt keiner mehr durch

zusätzlich kannst du die SSE3-Beschleunigung für twofish, etc. und gethreadete Verschlüsselung (pcrypt) im Kernel aktivieren, 

damit sollten weitesgehend normale Geschwindigkeiten erreichbar sein

----------

## Sujao

Ich stimme ScytheMan zu. Keiner wird sich die Mühe machen deine Mehrmachverschlüßelung zu knacken, entweder prügelt man aus dir die Passwörter heraus oder man installiert andere Überwachungsmethoden und kommt so rein. Die Übernahme eines Gentoo-Mirrors ist z.B. viel einfacher als das Bruteforcen eines einzigen 128Bit Schlüssels.

----------

## Yamakuzure

Nette Wiederbelebung! (Mai 2010 -> Februar 2012)   :Shocked:  !

Es gibt nun sehr viele Methoden, ich frage mich nur, ob ich dich richtig verstanden habe: 200GB SSD und darin 10 VMs? SSD und viele Schreibzugriffe vertragen sich nicht wirklich. Aber darüber hinaus wundere ich mich ein wenig, denn dein text klingt so:

System (verschlüsselt)

-> /home (zusätzlich verschlüsselt)

--> /home/vm[1-10] (seperat verschlüsselt)

Also eine Dreifachverschlüsselung? Wofür? Was ist in den VMs drin? Denn eine dreifach Verschlüsselung bringt nicht so wirklich viel, wenn der Server am Netz hängt, und von draußen jemand direkt auf eine Windows-VM könnte (wie auch immer das anzustellen sei) ... Und selbst wenn die VM-Inhalte "sicher" sind, was so unglaublich wertvolles hast du, dass du glaubst so einen Aufwand betreiben zu müssen?

@Sujao: Gegen das "Herausprügeln" empfehle ich eine versteckte TrueCrypt-Partition.  :Wink:  "Klar, hier mein Passwort." - "bah. Da ist ja garnix interessantes."  :Very Happy: 

----------

## AmonAmarth

 *Yamakuzure wrote:*   

> @Sujao: Gegen das "Herausprügeln" empfehle ich eine versteckte TrueCrypt-Partition.  "Klar, hier mein Passwort." - "bah. Da ist ja garnix interessantes." 

 

klar und dann: "komisch, die partition ist nur 1GB groß obwohl die platte ein TB hat. was ist denn mit dem rest? unfähig bei dem knowhow eine festplatte vernünftig zu partitionieren? müssen wir wohl noch was finger abhacken..."

----------

## b3cks

 *AmonAmarth wrote:*   

>  *Yamakuzure wrote:*   @Sujao: Gegen das "Herausprügeln" empfehle ich eine versteckte TrueCrypt-Partition.  "Klar, hier mein Passwort." - "bah. Da ist ja garnix interessantes."  
> 
> klar und dann: "komisch, die partition ist nur 1GB groß obwohl die platte ein TB hat. was ist denn mit dem rest? unfähig bei dem knowhow eine festplatte vernünftig zu partitionieren? müssen wir wohl noch was finger abhacken..."

 

Zumal, wer macht sich die Mühe sein "Fake-System" forensisch sicher aussehen zu lassen? "Hm, irgendwie finden hier sehr selten Datenzugriffe und Schreibvorgänge statt. Letzter Login war vor 6 Monaten. Wie und wofür nutzen Sie das System denn?" Da muss man sich schon eine gute Ausredestrategie überlegen (alle Daten online, alles im "Private"-Mode, VPN, keine Logs, ...).

----------

## Yamakuzure

 *b3cks wrote:*   

>  *AmonAmarth wrote:*    *Yamakuzure wrote:*   @Sujao: Gegen das "Herausprügeln" empfehle ich eine versteckte TrueCrypt-Partition.  "Klar, hier mein Passwort." - "bah. Da ist ja garnix interessantes."  
> 
> klar und dann: "komisch, die partition ist nur 1GB groß obwohl die platte ein TB hat. was ist denn mit dem rest? unfähig bei dem knowhow eine festplatte vernünftig zu partitionieren? müssen wir wohl noch was finger abhacken..." 
> 
> Zumal, wer macht sich die Mühe sein "Fake-System" forensisch sicher aussehen zu lassen? "Hm, irgendwie finden hier sehr selten Datenzugriffe und Schreibvorgänge statt. Letzter Login war vor 6 Monaten. Wie und wofür nutzen Sie das System denn?" Da muss man sich schon eine gute Ausredestrategie überlegen (alle Daten online, alles im "Private"-Mode, VPN, keine Logs, ...).

 da habt ihr wohl etwas falsch verstanden. Die Punkte Verstecktes Betriebssystem und Verstecktes Laufwerk sind schon recht interessant. (Zitat: "It should be impossible to prove that a hidden TrueCrypt volume exists..., it should be impossible to prove that a hidden operating system exists.")

Edith merkte an: Es wird die Gesamtgröße angezeigt. Hat das Laufwerk 1TB, zeigt auch der offizielle Teil vor einem "versteckten" 1TB, nicht nur 1GB. Die Annahme ist also völlig falsch, AmonAmarth. (Ich habs ausprobiert.  :Wink: )

----------

## b3cks

@Yamakuzure: Was ich meine, und wenn ich das korrekt verstanden habe, ist folgendes. Wenn man das Feature "Hidden Operating System" nutz, hat man (mindestens) zwei Betriebssysteme installiert, wovon eines versteckt und dessen Existenz nicht nachweisbar ist (plausible deniability). Je nachdem welche Passphrase ich beim Booten eingebe, startet entweder das normale bzw. das versteckte System. Mein Hauptsystem wird wegen dessen Nichtnachweisbarkeit das versteckte sein, was ich also regelmäßig nutze und wo ich Spuren hinterlasse. Mein Alibi-/Fake-System werde ich in der Regel nicht nutzen und ich glaube nicht, dass sich jeder die Mühe mach dort täglich einzuloggen, um eine normale Nutzung vorzugaukeln. Wenn man also wirklich mal in die Bredouille gelangt seine Passphrase offen legen zu müssen und sich dann in Sicherheit wiegelt, weil man die des Alibi-Systems angibt, wird spätetens ein Forensiker binnen kürzerer Zeit anzweifeln, dass dies das üblich verwendete Betriebssystem sein soll. Außer man legt sich eine passende Strategie zurecht. Das meinte ich damit.

PS: Ja, wir spielen das ein wenig hoch. In vielen Ländern kann man noch nicht dazu gezwungen werden derartige Daten offen legen zu müssen und ein Zoll-Beamter an der Grenze ist auch kein Forensiker.

----------

## tulali

ecb, cbc, lrw oder xts?

welches sollte für ein 240gig ssd mit ext4 benutzt werden?

welches sollte für eine 3tb festplatte mit ext4 benutzt werden?

----------

## tulali

... was denkt ihr?!

----------

## kernelOfTruth

 *tulali wrote:*   

> ... was denkt ihr?!

 

in der Zeit hättest du nach allem googeln,

dir die Abbildungen in wikipedia anschauen und es evtl. sogar selbst ausprobieren können

ich sage: XTS

(kommt wie immer auf die Kernel-Version an, die du verwenden willst bzw. musst)

----------

## tulali

aktuellen 3.1 oder 3.2 kernel ...

aber ist xts genauso wie lrs nicht noch zu experimentel?

----------

## kernelOfTruth

 *tulali wrote:*   

> aktuellen 3.1 oder 3.2 kernel ...
> 
> aber ist xts genauso wie lrs nicht noch zu experimentel?

 

ich verwende es ungefähr, seit es verfügbar ist

und hatte bis jetzt noch keine Probleme damit - alle Daten sind noch da ^^

dass es EXPERIMENTAL genannt wird, bedeutet nicht unbedingt viel,

evtl. hat ja sogar jemand vergessen das zu entfernen  :Razz: 

reiser4 z.B. wurde (und wird immer noch) EXPERIMENTAL genannt und dennoch stabiler als so einige aktuellen Dateisystem (bevor die ganzen Änderungen im Kernel kamen und es etwas instabiler wurde - die Datenintegrität ist z.B. trotzdem 100% gewährleistet) - nur so am Rande

jedenfalls wird CBC, ESSIV, soviel ich weiß bei Ubuntu standardmäßig verwendet,

mit XTS fahre ich (und wie ich von anderen ebenfalls gelesen habe) recht gut damit

vielleicht können die anderen ja noch ihre Erfahrung dazu posten  :Smile: 

----------

## tulali

Wie verhällt es sich denn mit Festplatten die über 2TB gross sind?

Ist ext4 überhaupt empfehlenswert ... oder sollte besser ReiserFS verwendet werden auf verschlüsselten Laufwerken?

Was passiert wenn mal ein Stromausfall kommt? Mit welchem Dateiensystem und Verschlüsselung hat man die besten Möglichkeiten sogut wie keinen Datenverlust zuerleiden?

----------

## ScytheMan

 *tulali wrote:*   

>  Mit welchem Dateiensystem und Verschlüsselung hat man die besten Möglichkeiten sogut wie keinen Datenverlust zuerleiden?

 

mit einem backup.

ein dateisystem sollte in allererster linie performant und korrekt arbeiten. für eventualitäten würde ich mich nicht über das dateisystem absichern.

----------

## nowo

Na ja. Yin und Yang. Natürlich geht nichts über ein Backup. Aber man will ja _trotz_ Performance nicht bei jeder kleinen Inkonsistenz gleich das Backup aufspielen. Denn das ist entweder inaktuell oder vom Pflegeaufwand her nicht tragbar. Ein weiterer Grund, möglichst nicht auf Backups angewiesen sein zu wollen, ist Ausfallsicherheit. Deswegen verwenden Server manchmal RAID-Systeme, wo bestimmte Fehler in den Massenspeichern zu keinerlei Datenverlust führen und kein separates Backup eingespielt werden muss, was dann wieder eine Downtime bewirken würde.

Aber die Frage bezog sich ja auf Dateisysteme. Da lautet das Stichwort Journaling, was die Konsistenz angeht. Damit werden nicht abgeschlossene Transaktionen häufig nicht zu einem Problem. Die meisten aktuellen Dateisysteme können das. Bekannte Dateisysteme ohne Journaling sind FAT und ext2. Bei ext4 kann man es zumindest abstellen.

Bezüglich Datenredundanz hab ich keine Ahnung, ob das auch auf Dateisystemebene unterstützt wird. Das tät mich auch mal interessieren.

----------

