# loop-AES - generelle Fragen

## slick

Hallo,

ich habe gerade https://forums.gentoo.org/viewtopic.php?t=31363&highlight=aes gelesen. Ist die Anleitung dort noch up-to-date oder verstehe ich die Zusammenhänge noch nicht ganz?

Wozu ist der USE-Flag crypt bei der Erstellung von util-linux? Macht der nicht das gleiche die das patchen der util-linux in o.g. Anleitung? Wozu ist dann AES in den gentoo-sources wenn man loop-AES extra runterladen muss?

Also irgentwie verstehe ich das alle noch nicht ganz richtig. 

Ich will mir ein verschl. Dateisystem anlegen und nicht nur irgentwelche Befehle abtippen sondern sie auch verstehen. Gebt mir (und dem Rest der Welt  :Wink:  ) bitte mal eine Überblick über dieses Thema!

mfg Slick

----------

## bonsaikitten

Das mit util-linux ist mir auch noch nicht ganz klar, die .11 Version unterstuetzt loopback-encryption nicht, die maskierte .12 schon !?

Ein verschluesseltes Dateisystem wird in Linux ueber den loopback-treiber gemacht. Als erstes brauchst du eine Datei oder Partition, die du dafuer nehmen kannst. Diese solltest du mit zufaelligen Bitfolgen erstmal sichern, denn sonst sind deine verschluesselten Daten gut sichtbar, und selbst diese Information wollen wir einem Angreifer nicht bieten.

Ich habe meine Crypto-Datei so initialisiert:

```

dd if=/dev/urandom of=/dev/hdb1 bs=1M count=15000

```

Dann brauchst du die Krypto-Module ... Ich habe mich fuer das in 2.4.22 und 2.6 enthaltene Crypto-API entschieden. loop-AES sollte zwar aehnlich funktionieren, doch erscheint mir ein kerneleigenes System zukunftssicherer.

```

modprobe cryptoloop

modprobe blowfish

modprobe sha512

```

laedt die benoetigten Module ... cryptoloop ist selbsterklaerend, blowfish ist fuer die verschluesselung der daten und sha-512 ist fuer das erzeugen eines gehashten Passwortes aus einem Passwort zustaendig. Jetzt muss die Partition formatiert werden:

```

losetup -e blowfish  /dev/loop0 /dev/hdb1
```

aktiviert loopback, dabei wird auch nach einem Passwort gefragt.

Dies sollte relativ lang sein, keine Sonderzeichen enthalten und einfach zu merken sein. Leerzeichen duerfen auch vorkommen, Gross- und Kleinschreibung werden unterschieden.

```

mkreiserfs --format 3.6  /dev/loop0

```

formatiert das ganze mit reiserfs.

Das sollte nach Bedarf angepasst werden, ist aber fast universell einsetzbar.

```

mount /dev/loop0 /mnt/crypt

```

mountet das device schliesslich. Fertig!

----------

## slick

Danke, soweit hilft mir das schonmal weiter. Hier noch ein paar Unklarheiten:

1. bei loop-AES in der Doku. stand man sollte in irgendeinem Zusammenhang kein journaling Filesystem verwenden. Genau konnte ich aber nicht entziffern, mein English ist nicht sooo gut. D.h. welches Dateisystem empfiehlt sich?

2. Wie kann ich testen ob meine Swap bzw. 'normale' Partition wirklich verschlüsselt sind?

3. Welches ist der empfohlene Verschl-.Alg. in Bezug auf Sicherheit und Performance?

mfg Slick

----------

## bonsaikitten

[quote="slick"]Danke, soweit hilft mir das schonmal weiter. Hier noch ein paar Unklarheiten:

1. bei loop-AES in der Doku. stand man sollte in irgendeinem Zusammenhang kein journaling Filesystem verwenden. Genau konnte ich aber nicht entziffern, mein English ist nicht sooo gut. D.h. welches Dateisystem empfiehlt sich?

[quote]

Nachdem die Daten nicht direkt auf die Festplatte geschrieben werden, sondern durch das loop-device gehen, kann es vorkommen dass die Datenbloecke nicht in der fuers Journaling noetigen Reihenfolge weggeschrieben werden. Das kann (muss aber nicht) zu Datenverlust trotz journaling fuehren.

 *Quote:*   

> 
> 
> 2. Wie kann ich testen ob meine Swap bzw. 'normale' Partition wirklich verschlüsselt sind?
> 
> 

 

versuch die direkt zu mounten, wenn das nicht geht ist es schon ein guter Hinweis, dass es verschluesselt sein kann. Ein garantierter Test faellt mir momentan nicht ein.

 *Quote:*   

> 
> 
> 3. Welches ist der empfohlene Verschl-.Alg. in Bezug auf Sicherheit und Performance?
> 
> mfg Slick

 

Das haengt von deinen Anforderungen ab. Du solltest auch bedenken dass jeder Algorithmus nur vermutlich so oder so sicher ist, aber keinerlei Garantien existieren. Daher solltest du ueberlegen welche Ressourcen ein Angreifer anwenden wird. Ich habe mich fuer blowfish entschieden weil die Performance relativ gut ist. AES ist noch relativ neu und daher nicht so gut analysiert, scheint aber keine fatalen Fehler zu haben.

Ich denke fuer Heimanwender ist 128bit (fast egal was) mehr als ausreichend, ansonsten solltest du ueberlegen wieviel die Daten wert sind und dementsprechend vorgehen.

----------

## slick

hmmm...

 *Quote:*   

> Nachdem die Daten nicht direkt auf die Festplatte geschrieben werden, sondern durch das loop-device gehen, kann es vorkommen dass die Datenbloecke nicht in der fuers Journaling noetigen Reihenfolge weggeschrieben werden. Das kann (muss aber nicht) zu Datenverlust trotz journaling fuehren.

 

d.h. ? sollte man lieber ext2 statt ext3 o. reiser nehmen? 

Die Sicherheit meiner Daten ist mir schon wichtig. Wenn ich das verschlüssel und mich somit in Sicherheit wäge und dann durch so 'nen blöden Fehler Daten verloren gehen könnten wäre das echt Sch...

mfg

----------

## bonsaikitten

 *slick wrote:*   

> hmmm...
> 
> d.h. ? sollte man lieber ext2 statt ext3 o. reiser nehmen? 
> 
> Die Sicherheit meiner Daten ist mir schon wichtig. Wenn ich das verschlüssel und mich somit in Sicherheit wäge und dann durch so 'nen blöden Fehler Daten verloren gehen könnten wäre das echt Sch...
> ...

 

Wenn du wirklich paranoid bist sind die Daten nicht nur an einem Ort gespeichert  :Smile: 

Mit loopback solltest du ext3 mit journal=data verwenden. Damit zerschiesst du dir zwar die Performance, aber dafuer hast du relativ starke Garantien was die Integritaet deiner Daten angeht. Dass du trotzdem ein Backup deiner Daten hast muss ich wohl nicht erwaehnen ...

----------

## slick

obige Befehle scheinen nicht zu funzen... was hast du für einen kernel mit welcher config und evt. zusätzlicher software?

mfg

----------

## bonsaikitten

Ich benutze momentan 2.6.0test3 mit CryptoAPI komplett, alle Module.

util-linux 2.12 manuell gemerged. (hat cryptoloop-patch)

2.4.22 sollte auch CryptoAPI unterstuetzten, habe ich aber bisher nicht getestet.

Falls moeglich solltest du Fehlermeldungen posten damit ich eine Idee habe was nicht funktioniert ... "funzt net" ist fuer Fehlerbehebung nicht besonders hilfreich  :Smile: 

----------

## slick

 *Quote:*   

> util-linux 2.12 manuell gemerged. (hat cryptoloop-patch) 

 

Soweit ich sehe ist in den util-linux-2.12 auch der

util-linux-2.11z-crypt-gentoo.patch.bz2 der auch bei den 2.11z eingespielt wird wenn man das Useflag "crypt" setzt. Also sollten AFAIK die 2.11z auch den patch haben, wenn es denn dieser ist!?

 *Quote:*   

> alls moeglich solltest du Fehlermeldungen posten damit ich eine Idee habe was nicht funktioniert ... "funzt net" ist fuer Fehlerbehebung nicht besonders hilfreich

 

Ich wollte keine Fehlermeldung abgeben bevor ich nicht weis mit was ich überhaupt arbeiten muss.  :Wink:  Werde dann mal mit deiner Config testen.

----------

## bonsaikitten

2.11 hat bei mir nicht funktioniert, vielleicht ist das inzwischen behoben.

2.12 scheint stabil zu sein, ist aber noch maskiert.

----------

## PartyCharly

ich hab 2.4.22 kernel mit util-linux 2.11z-r7

und unter 2.6er kernel mit util-linux 2.12 am laufen ...

, was datensicherheit und performance anbelangt ... 

auf dem laptopf so plattenperformance eh fürn a... iss hab ich ext2,

auf meinem server ... hab ich 2 80erplatten jeweils mit ext3 vercrypted und das via raid1 redundant ... superschnell und ausreichend ...

aes iss der momentan performanteste und relativ sicherste algorithmus ...

bis denn, viel spass beim crypten

----------

## slick

Es funzt !!!  :Very Happy: 

Also Kernel gentoo-sources verwenden und dort Crypto-Api mit benötigten Modulen aktivieren. Normales loopback-device (vorher) nicht vergessen, sonst ist cryptoloop nicht verfügbar.

Dann das Useflag "crypt" setzen.

Dann die aktuellen util-linux (2.11z-r6 - bekommen automatisch patch bei Useflags "crypt") neu übersetzen.

Thats it  :Wink: 

mfg Slick

----------

## slick

Nachtrag: 

 *Quote:*   

> Mit loopback solltest du ext3 mit journal=data verwenden. 

 

Wie setze ich das ein beim manuellen mounten und per fstab??

mfg Uwe

----------

## bonsaikitten

 *slick wrote:*   

> Nachtrag: 
> 
>  *Quote:*   Mit loopback solltest du ext3 mit journal=data verwenden.  
> 
> Wie setze ich das ein beim manuellen mounten und per fstab??
> ...

 

mount -t ext3 -o journal=data /device /mountpoint

in /etc/fstab:

/dev/loop0              /mnt/crypt      ext3        noauto,noatime,journal=data

untested but may work  :Smile: 

mfg,

bonsaikitten

----------

## Bushmann

> /dev/loop0              /mnt/crypt      ext3        noauto,noatime,journal=data

muss heißen: data=journal

var ist data, mögliche optionen sind journal, ordered, writeback

----------

## MrIch

naja das mit den keinen Journaling Systemen sehe ich nicht so eng. Habe nun schon seit mehreren Jahren reiserfs für meine loop-aes Partitionen im Einsatz. Bisher ohne jegliche Probleme.

----------

## simex

hi

ich hatte auch bis vor kurzem mein /home-dir mit aes256 verschlüsselt, aber nachdem ich meinen kernel von 2.4.28-gentoo-r5 auf 2.4.28-gentoo-8 upgedatet habe, ging die partition nicht mehr zu mounten, mit einer 

 *Quote:*   

> invalid argument

 

-fehlermeldung.

zum glück hatte ich mir natürlich wie immer die option des bootens mit dem alten kernel gelassen und konnte mein altes system also wieder booten.

beim nachschauen in der kernelconfig des neuen kernels fand ich, dass es unter -->file systems die option --> cryptoloop nicht mehr gab! (also auch, wenn loopback angewählt war)

anscheinend wurde die funktion aus den kernelquellen rausgenommen, warum auch immer. hab dazu leider im forum bisher nichts gefunden.

gibts da abhilfe oder muss ich weiter mit kernel -r5 fahren?

mfg

simex

ps. ich weiss zwar nicht, wozu das gut ist, aber ich hab util-linux 2.12i-r1

----------

## Mr Faber

Soweit ich weiß ist Cryptoloop für dein Logo  :Very Happy: . Da nur ein einziger Key zum verschlüsseln verwendet wird, sollte es sehr einfach möglich sein zumindestens Teile von deine Daten wiederherzustellen. Ich weiß ja nicht vor wem Du deine Daten schützen möchtest, aber da kannst du dir die Performanceeinbußen und anderen Einschränkungen sparen.

Folgendes stammt aus der loop-aes-Readmedatei

 *Quote:*   

> 
> 
> 4)  Loop is used in single-key mode. Neither password seed nor gpg encrypted
> 
>     key file are used. This level is vulnerable to optimized dictionary
> ...

 

Wenn du deine Festplatte unter Linux nach dem heutigen Stand sicher verschlüsseln möchtest, solltest Du schon wie Anfangs von Dir erwähnt loop-aes einsetzen. Da musst Du zwar ein extra Modul und auch einen Teil von util-linux neu kompilieren, aber damit hättest Du sehr wahrscheinlich das gewünschte Resultat erreicht. Loop-aes verschlüsselt das Dateisystem mit 64 zufällig generierten Schlüsseln, die in einer mit GnuPG verschlüsselten Datei gespeichert werden.

cu

Mr Faber

----------

## schachti

Cryptoloop ist veraltert und wird demnächst ganz aus dem Kernel fliegen. Wer jetzt neu verschlüsselt, sollte das unbedingt mit dm-crypt tun, damit er später auch mit aktuellem Kernel an die Daten kommt!

Es gibt zum Thema schon einige Threads, einfach mal nach suchen.

----------

## Mr Faber

Auch wenn dm-crypt neu ist, verschlüsselt es die Partitionen auch nur mit einem Key. Vom Standpunkt der Sicherheit ist es nach dem aktuellen Stand genauso schlecht wie cryptoloop.

cu

Mr Faber

----------

## schachti

Es ging auch nicht um die Sicherheit der Verschlüsselung, sondern um die Zukunftssicherheit. Wenn jemand heute seine Daten verschlüsselt, vermute ich mal, daß er auch noch in 2 Jahren an die Daten rankommen möchte. Cryptoloop wird aber in 2 Jahren bestimmt aus den aktuellen Kerneln verschwunden sein, so daß man dann entweder einen alten Kernel nutzen oder einen aktuellen Kernel von Hand patchen muß.

----------

## Mr Faber

Bitte nicht böse sein, aber ROFL.  :Wink:  Wer sollte denn seine Daten verschlüsseln wollen und damit alle möglichen Nachteile in Kauf nehmen, wenn die Verschlüsselungsmethode nicht sicher ist?

Nebenbei wird loop-aes auch ständig weiterentwickelt und ist soweit ich weiß auch voll abwärtskompatibel und kann auch durch cryptoloop verschlüsselte Laufwerke lesen.

cu

Mr Faber

----------

## schachti

Ich glaube, wir reden aneinander vorbei - inwiefern sollte dm-crypt nicht sicher sein?

----------

## Haldir

dm-crypt hat einige prinzip bedingte Schwächen, z.b. kann man Watermark Attacken drauf starten, liegt einfach am Design, was prinzipiell noch aus der Crypto-loop Zeit kommt.

Damit ist es nicht "knackbar", sondern man kann mit einigem Aufwand bestimmte Dateien auf deiner Crypto partition finden. Dieses Problem hat z.b. Loop-aes nicht.

Das hat jedoch nix mit "unsicher" zu tun, an deine Daten kommt man trotzdem nicht, man kann höchstens herausfinden ob du bestimmte Dateien verschlüsselt hast.

Man könnte z.b. erkennen ob du ReiserFS drunter hast oder NTFS oder was auch immer, damit ist die Schwäche halt, dass man überhaupt die Crypto Partition von Random Data unterscheiden kann.

Der Loop-AES macher hat noch einige Sachen mit Speziellen Dateien dafür vorgeschlagen als Beispiel, die sind aber zwischen Theoretisch und Overkill einzuordnen  :Wink: 

Diese Diskussion zwischen dem Loop-AES programmierer und den CryptoLoop Typen gibts scho länger...

Zusammenfassend:

Wenn ihr schon loop-aes habt, bleibt dabei.

Wenn ihr mit Kernel 2.6 neu anfangen wollt, könnts ihr auch dm-crypt nehmen.Last edited by Haldir on Thu Mar 17, 2005 10:37 pm; edited 1 time in total

----------

## schachti

Die Watermark Attacken gehören seit Kernel 2.6.10 der Vergangenheit an, siehe http://www.saout.de/misc/dm-crypt/.

----------

## Mr Faber

 *schachti wrote:*   

> Die Watermark Attacken gehören seit Kernel 2.6.10 der Vergangenheit an, siehe http://www.saout.de/misc/dm-crypt/.

 

Das wusste ich noch nicht. Hast du genauere Informationen?

Das Zitat stammt von der dm-crypt-Seite

 *Quote:*   

> 
> 
> I've read about security problems.
> 
> Yes, the IV schemes currently supported by dm-crypt are the same as the ones supported by cryptloop. There's the ECB mode which is a catastrophe (no IV at all) and the "plain" mode, which is already a lot better. Older cryptoloops used ECB by default, but with dm-crypt the default is "plain" (which is the unhashes sector number used as IV).
> ...

 

Soweit ich weiß ist es nicht so einfach die kompletten Daten mittels der Watermark-Attacken zu entschlüsseln, aber einen Teil, was ausreichen sollte, um gewisse Informationen über Dateien herauszubekommen, was ich als nicht sicher erachten würde.

Ob man an die Daten nicht herankommt ist fraglich. Ich bin kein Experte, aber wenn man 80 GB oder mehr mit nur einem Key verschlüsselt ohne zusätzliche Verschleierungsmethode kann es nicht sicher sein. Der Key ist soweit ich weiß maximal 256 Bit groß. Nenbei gibt es in einem Dateisystem häufig sehr viel freien Platz und bekannte Daten.

Das als sehr sicher geltene Serpent ist zum Beispiel angreifbar für Known-Plain-Text-Angriffe, meine ich in einer Abhandlung von der AES-Auswahl gelesen zu haben. Wie viele Daten man da aber für bräuchte weiß ich nicht. Bestimmt mehr als vorliegen  :Very Happy: .

Nochmal, wer Dateiverschlüsselung einsetzt, kommt gar nicht an Mulitkeyverschlüsselung oder einer erweiterten Whiteningmethode vorbei. DM-Crypt kann noch so toll implementiert sein, es ist einfach angreifbar, nicht der Verschlüsselungsalgorithmus sondern die Implementierung. Der einzige Nachteil an loop-aes ist de ein wenig komplizierte Installation. Was aber verglichen mit anderen linuxtechnischen Sachen vergleichsweise einfach ist. Dann sollte man eigentlich das gewünschte Ergebnis haben. Man kann auf jeden Fall besser schlafen als mit dm-crypt  :Wink: 

cu

Mr Faber

----------

## slick

Mal abgesehen davon das Cryptoloop veraltet ist, in welchen Dimensionen sprechen wir hier wenn es um Unsicherheit geht? Das es Nachbarssohn nicht hacken könnte scheint mir klar aber wie sähe der Aufwand auf den jemand treiben müsste um das "unsichere" "veraltete" Cryptoloop zu knacken? Also wenn das jetzt beispielsweise nicht mehr bei theoretischen >100 Millionen Jahren für BruteForce sondern nurnoch bei 20 Millionen Jahren liegt ist mir das eigentlich Wurst.

----------

## schachti

 *Mr Faber wrote:*   

> 
> 
>  *schachti wrote:*   
> 
> Die Watermark Attacken gehören seit Kernel 2.6.10 der Vergangenheit an, siehe http://www.saout.de/misc/dm-crypt/.
> ...

 

Ich habe mich nochmal ein wenig schlaugemacht, es sieht wie folgt aus:

- Auch cryptoloop ist von den Watermark Attacken betroffen.

- In dm-crypt kann man diese Angriffe verhindern, wenn man den Initialisierungsvektor der Blockverschlüsselung besser wählt. Ich gebe aus diesem Grund cryptsetup immer die Option -c aes-cbc-essiv:sha256 mit.

Details findest Du hier: http://clemens.endorphin.org/LinuxHDEncSettings, http://mareichelt.de/pub/notmine/wisa2004.pdf.

 *Mr Faber wrote:*   

> 
> 
> Ob man an die Daten nicht herankommt ist fraglich. Ich bin kein Experte, aber wenn man 80 GB oder mehr mit nur einem Key verschlüsselt ohne zusätzliche Verschleierungsmethode kann es nicht sicher sein. Der Key ist soweit ich weiß maximal 256 Bit groß.
> 
> 

 

Die Datenmenge hat keinen Einfluß auf die Sicherheit, solange dem Angreifer keine Daten im Quelltext sowie ihre Position im verschlüsselten Text bekannt sind. Und ein 256 Bit langer Key ist meiner Meinung nach sicher. Ich empfehle Dir als Lektüre mal das Buch "Applied Cryptography" von Bruce Schneier, dem Kryptoguru schlechthin. Das gibt es inzwischen in der Second Edition und erklärt Kryptographie ziemlich gut. Ein weiterer interessanter Einstiegspunkt ist http://www.schneier.com/.

 *Mr Faber wrote:*   

> 
> 
> Nenbei gibt es in einem Dateisystem häufig sehr viel freien Platz und bekannte Daten.
> 
> 

 

Deswegen sollte man vor der Verschlüsselung die gesamte Partition, die man verschlüsselt (bzw. die verschlüsselte Containerdatei) mit Werten aus /dev/random füllen.

 *Mr Faber wrote:*   

> 
> 
> Nochmal, wer Dateiverschlüsselung einsetzt, kommt gar nicht an Mulitkeyverschlüsselung oder einer erweiterten Whiteningmethode vorbei. DM-Crypt kann noch so toll implementiert sein, es ist einfach angreifbar, nicht der Verschlüsselungsalgorithmus sondern die Implementierung.Der einzige Nachteil an loop-aes ist de ein wenig komplizierte Installation. Was aber verglichen mit anderen linuxtechnischen Sachen vergleichsweise einfach ist. Dann sollte man eigentlich das gewünschte Ergebnis haben. Man kann auf jeden Fall besser schlafen als mit dm-crypt 
> 
> 

 

Ich halte diese Aussage für komplett falsch. Wenn es so unsicher wäre, meinst Du, die Kernelentwickler hätten dann cryptoloop als deprecated bezeichnet und dm-crypt als Nachfolger bezeichnet?

----------

## Mr Faber

 *schachti wrote:*   

> Ich halte diese Aussage für komplett falsch. Wenn es so unsicher wäre, meinst Du, die Kernelentwickler hätten dann cryptoloop als deprecated bezeichnet und dm-crypt als Nachfolger bezeichnet?

 

Genau das ist ja gerade das lustige. Es war Anfangs keinen deut sicherer. Nur halt irgendwie besser programmiert. Mitlerweile scheint es ja eine sichere Methode zu geben, trotzdem würde ich loop-aes den Vorzug geben. Das ist schon seit zwei Jahren nach dem heutigen Stand sicher.

Nebenbei weiß keiner ob die neue Technik von dm-crypt so sicher ist. Sie muss sich erst noch beweisen, was bei loop-aes schon seit 2 Jahren der Fall ist.

cu

Mr Faber

----------

## schachti

 *Mr Faber wrote:*   

>  *schachti wrote:*   
> 
> Ich halte diese Aussage für komplett falsch. Wenn es so unsicher wäre, meinst Du, die Kernelentwickler hätten dann cryptoloop als deprecated bezeichnet und dm-crypt als Nachfolger bezeichnet?
> 
>  
> ...

 

Genau, das ist ja der Grund, warum es cryptoloop ablösen soll. Wenn man zwei Verfahren hat, von denen man ausgeht, daß sie von der Sicherheit her vergleichbar sind, nimmt man doch nicht diejenige, die die Kernel-Entwickler selbst als unsauberen Hack bezeichnen, sondern diejenige, die als gut strukturierte und sauber aufgebaute Lösung angesehen wird.  :Wink: 

Mit dem anderen Punkt hast Du natürlich Recht - aber die Tatsache, daß sich cryptoloop ein paar Jahre länger bewährt hat, heißt nicht zwangsläufig, daß es sicherer ist oder daß man dort in Zukunft weniger sicherheitskritische Fehler finden wird als in dm-crypt.

----------

## Mr Faber

Ich weiß nicht ob Du mich falsch verstehst, aber cryptoloop war mist und ist mist. Es hat sich vom Standpunkt der Sicherheit nie bewährt.

Ich rede von loop-aes, dass es schon seit mehr als zwei Jahren gibt. Es ist auch stabil, zumindest für mich und laut der Bugliste bzw. der Mailingliste für fast alle, und hat einen stark optimierten AES-Assemblercode.

Was möchte man mehr? Das bisschen Installationsaufwand sollte keinen abschrecken.

Das einzigen Vorteil von dm-crypt ist, dass es im Kernel integriert ist.

Es geht hier nicht um den schönsten Code oder die einfache Installation, sondern den besten Kompromiss aus vor allen Dingen Sicherheit mit Geschwindigkeit und Stabilität. Den besten bietet meiner Meinung nach unter Linux loop-aes.

Überzeuge dich doch einfach selber. Statt alle cryptoloop oder dm-crypt Partitionen neu auf cbc umzustellen könntest Du auch mal loop-aes ausprobieren.

cu

Mr Faber

----------

## schachti

Ich nutze einen Rechner, auf dem 4 Platten inkl. Betriebssystem komplett mit loop-AES (nach https://forums.gentoo.org/viewtopic.php?t=108162) verschlüsselt sind, und einen Rechner mit 3 Platten, alle mit dm-crypt verschlüsselt.

Ich konnte keinen Performance-Unterschied feststellen (obwohl der Rechner mit loop-AES den schnelleren Prozessor hat), und beide Lösungen laufen bei mir schon lange stabil.

----------

## Mr Faber

LOL Nicht schlecht, aber warum dann auch dm-crypt? Welchen Version (Modus) nutzt Du für loop-aes und welchen Verschlüsselungsalgorithmus?

cu

Mr Faber

----------

## schachti

 *Mr Faber wrote:*   

> 
> 
> LOL Nicht schlecht, aber warum dann auch dm-crypt?
> 
> 

 

Den Rechner mit loop-AES habe ich zuerst aufgesetzt, vor dem Aufsetzen des zweiten habe ich davon gelesen, daß loop-AES durch dm-crypt ersetzt werden soll und bin für den zweiten Rechner daher gleich auf dm-crypt umgestiegen.

 *Mr Faber wrote:*   

> 
> 
> Welchen Version (Modus) nutzt Du für loop-aes und welchen Verschlüsselungsalgorithmus?
> 
> 

 

Ich nutze loop-AES v2.0e (oder f) mit AFAIR AES256, ist schon 'ne Zeit her, daß ich den Rechner aufgesetzt habe.

----------

## Mr Faber

Aktuell ist loop-aes 3.0b. Wie soll denn dm-crypt loop-aes ersetzen wenn das ständige weiterentwickelt wird und der Entwickler unabhänging von cryptoloop/dm-crypt ist? Cryptoloop soll durch dm-crypt ersetzt werden, loop-aes aber ganz sicher nicht. Nochmal cryptoloop ist nicht loop-aes.

Loop-aes unterstützt drei Modi, in deiner Version nur zwei:

 *Quote:*   

> Loop-AES supports three different on-disk formats: v1, v2 and v3. v1 is from
> 
> old loop-AES-v1.X versions and it uses a single key to encrypt all data
> 
> sectors. v2 is from loop-AES-v2.X versions and it uses 64 keys to encrypt
> ...

 

Welchen nutzt Du? Den mit 64 Schlüssel bzw. der GnuPG-Datei oder halt nur die Variante mit einem, der ähnlich sicher wie dm-crypt ist.

cu

Mr Faber

----------

## schachti

Ich vermute, die Variante mit den 64 Schlüsseln wird unter 2.x der Standard gewesen sein, oder? Ich habe das nach https://forums.gentoo.org/viewtopic.php?t=108162 eingerichtet...

----------

## Haldir

Loop-Aes ist nicht essentiell sicherer als DM-Crypt (seit 2.6.10), der einzige Angriffspunkt bei der alten DM-Crypt implementierung war die Watermark Attacke, nachdem die nicht mehr relevant ist, ist das Thema gestorben.

Multiple Schlüssel sind nicht essentiel besser als nur ein Schlüssel, das Hauptproblem ist die IV Generierung und wenn ich Böse wäre, würd ich sagen, ein MD5-IV ist unsicherer als ein SHA IV von DM-Crypt.

Der Großteil ist hierbei Meinungsmache, weil der Loop-AES Mensch eingeschnappt war das seine Loop Implementation nicht die Cryptoloop Implementation ersetzt hat, als Kernel 2.5 in 2.6 umbenannt wurde.

Grundsätzlich ist halt dm-crypt weit eleganter als jedes loop basierte System  :Wink: 

Mr.Faber du hast es immer noch nicht verstanden, oder interpretierst die falschen Passagen:

1.) ECB Mode war in dm-crypt noch nie per default aktiviert sondern ist nur wegen cryptoloop (pre 2.4.10 oder so) drinnen (ist halt ein Modus)

2.) CBC Mode ist der Standard und hat gewisse Probleme mit Watermarks 

3.) CBC mit entsprechenden Prehashing usw ist seit 2.6.10 optional.

Keiner der mit Dm-crypt jetzt arbeitet wird den ECB mode benützen, außer er spezifiziert ihn selber...

Damit ist das ganze ungefähr 98% so sicher wie loop-aes.

und mit dem neuen Mode seit 2.6.10 ist das ganze 99.9% so sicher wie loop-aes.

Der Rest ist Paranoia und Meinungsmache  :Wink: 

----------

## Mr Faber

Seit der Version 3 werden zur MD5 IV computation ein Passwort herangezogen, was es auf jeden Fall mindestens gleichberechtig sein sollte. Nebenbei ist sha1 wesentlich langsamer auf x86 System als md5.

Du glaubst also, dass wenn man 400 GB mit nur einem Schlüssel, lassen wir ihn mal 256 Bit groß sein, was die wenigsten ausgewählt haben werden, und dem CBC-Modus verschlüsselt, ist es so gut wie unmöglich an die Daten zu kommen? Es wird ein 128 Bit Blockchiffre verwendet, der im Fall von AES statische S-Boxen hat. Du weißt ja, Engima ist auch unknackbar und die Titanic unsinkbar. Deinen Technikglauben wollte ich haben  :Wink: 

Es geht nicht um Bruteforce eines 256 Bit Schlüssels. Das ist bis auf weiteres unmöglich. Aber es gibt so viele Dinge auf einer Festplatte, die bekannt sind. Denke nur mal an den ganzen Leerraum. Wer bitte schreibt den Zufallsdaten auf die Platte. Bestimmt nur wenige die dm-crypt einsetzen, weil es nunmal sich für Anfänger eignet. Das heißt nicht, dass es schlecht ist!

Desweiteren verwendet dm-crypt keinen Seed/Iteration, ist also sehr anfällig bei schlechten Passwörtern. Dm-crypt mag ja noch so elegant sein, wobei ich bisher noch nicht weiß, warum überhaupt, aber es stört mich sehr, dass es ähnliche "Kinderkrankheiten" wie cryptoloop mitbringt. Ein Seed und Iteration kostet nichts und machen Verschlüsselung selbst bei schlechtne Passwörtern sehr sicher. Außerdem kann man bei loop-aes mehrere Platten mit dem gleichen Schlüssel verschlüsseln, jedoch werden jedes mal andere zur Verschlüsselung der Partition verwendet, wenn man eine andere gpg-Datei einsetzt.

Nebenbei bemerkt hast du mich schon fast überzeugt  :Very Happy:  . Ich habe mich halt vorher in mehreren Foren/Mailinglists informiet. Entweder war nichts von loop-aes zu lesen und dm-crypt wurde gelobt oder es war etwas von loop-aes zu lesen und cryptoloop and dm-crypt wurden als unsicher deklariert.

Beurteilen kann das nur ein richtiger Kryptoexperte und die Zeit, und das bin ich nicht bzw. die habe ich nicht  :Smile: 

Wie schnell ist denn dm-crypt? Interessieren würde mich die Differenz zwischen maximaler Übertragungsate ohne und mit Verschlüsselung bzw. die Geschwindigkeit deiner CPU.

Weiß jemand, warum die neue Methode nicht mehr für Watermark anfällig ist?

[EDIT]Sehr interessant: http://en.wikipedia.org/wiki/Cipher_Block_Chaining

Vor allen Dingene die Bilder  :Very Happy: [/EDIT]

cu

Mr Faber

----------

## Haldir

Ehm ich weiß net, du hast nicht viel Ahnung von der Mathematik bzw. Cryptography allgemein oder?

AES ist bisher nicht geknackt, selbst wenn du einen Sektor wiederherstellen kannst, durch Watermark attacke oder was auch immer, hast du genau einen Sektor, der 512 Byte ist. Du weißt nix über alle anderen Sektoren  :Wink: 

Selbst mit einem normalen CBC ohne Sektor basiertem IV, müßte der Sektor 100% identisch sein, wenn du einen zweiten Sektor finden willst der die gleiche verschlüsselte Signatur aufweißt  :Wink: 

Statische S-Boxen, die Key länge und was weiß ich, hat wenig mit der eigentlichen Sicherheit von AES zu tun  :Wink: 

Ach ja tu mir einen Gefallen, bevor du Halbwissen verbreitest, lass es lieber, einige Leute ohne Wissen lesen diesen Thread auch und werden keine Ahnung haben was statische Sboxen überhaupt sind  :Wink: 

Es hat keinen Sinn über theoretische Nachteile von AES zu diskutieren, Sicherheitstechnisch nehmen sich Loop-aes und dm-crypt nichts, egal ob du ne 400GB Platte hast oder nur 100 Byte verschlüsselst  :Wink: 

----------

## Mr Faber

Meinst Du etwa, dass _Du_ mehr weisst? Du hast das doch auch alles nur gelesen?! Der größte Teil deines Wissens besteht aus Dingen die Du gehört bzw. gelesen hast und das ist ganz sicher kein Vorurteil.

Die Argumente von loop-aes sind meiner Meinung nach einfach logischer, auch wenn ich es nicht beweisen kann.

Ich kann dir auch erzählen cryptoloop ist sicher wegen der Technik xyz und du könntest es nicht beweisen, genauso wenig wie du beweisen kannst, dass dm-crypt mit cbc mit Prehasing sicher ist als vorher bzw. genauso sicher wie loop-aes. Du baust genauso auf den Aussagen von "Experten" auf die wiederum Ihr Wissen teilweise von "Experten" haben und halt ein wenig eigene Erfahrung damit verbinden.

Das nennt man Glaube  :Wink: 

cu

Mr Faber

----------

## Haldir

 *Mr Faber wrote:*   

> Meinst Du etwa, dass _Du_ mehr weisst? Du hast das doch auch alles nur gelesen?! Der größte Teil deines Wissens besteht aus Dingen die Du gehört bzw. gelesen hast und das ist ganz sicher kein Vorurteil

 

Nein, ich studier den Schmarrn, ich kann AES selber implementieren und versteh auch noch die Mathe dahinter, macht mich zum Helden nicht wahr?

Im Gegensatz zu dir versuch ich nur nicht Anhand ein paar Fakten einer PDF Präsentation meine Argumentation aufzubauen  :Wink: 

Btw es ist ziemlich einfach beweißbar wieso CBC mit einem Sektornummerhash basierten IV sicherer ist, also mit z.b. statischem IV oder IV der ungehashed verwendet wird.

Gibt sogar einige lustige Beispiele, wie sich bei CBC verschlüsselten Daten, welche Bits wo ändern, wenn du beim Input ein Bit änderst usw.

Wir reden trotzdem hier nur von einem Minimalunterschied, du kannst gerne nützen was du willst, nur es ist nutzlos in einem Hilfeforum, das Marketinggeschwätz aus PDF Präsentationen zu wiederholen, das wird keinem bei der Entscheidung helfen  :Wink: 

----------

## Tazok

 *schachti wrote:*   

> Die Watermark Attacken gehören seit Kernel 2.6.10 der Vergangenheit an, siehe http://www.saout.de/misc/dm-crypt/.

 

Hm, wenn ich das richtig sehe, müsste ich dafür alles neu verschlüsseln, oder?

----------

## Haldir

Yup, du kannst aber zwie Mappings machen, steht im Wiki drin, wie man theoretisch Key und Cryptoparameter ändern kann.

Zwei Mappings anlegen, eins fürs Alte, eins fürs Neue, und dann einmal alle Dateien hin und her kopieren  :Wink: 

----------

## Mr Faber

Mit loop-aes wäre das alles nicht passiert, schon seit zwei Jahren  :Wink: 

cu

Mr Faber

----------

## schachti

 *Mr Faber wrote:*   

> 
> 
> Wie schnell ist denn dm-crypt? Interessieren würde mich die Differenz zwischen maximaler Übertragungsate ohne und mit Verschlüsselung bzw. die Geschwindigkeit deiner CPU.
> 
> 

 

Athlon XP 1800+, 768 MB RAM, Kernel 2.6.11-r4, dm-crypt, aes-cbc-essiv:sha256:

 *Quote:*   

> 
> 
> time dd if=/dev/zero of=dummy bs=1k count=1024000
> 
> 1024000+0 Datensätze ein
> ...

 

Das sind ca. 27 MB/s, die Platte schafft unverschlüsselt 40-45 MB/s.

Zum Vergleich: Athlon XP 2400+, 256 MB RAM, Kernel 2.6.11-r3, loop-AES 2.0x, AES256:

 *Quote:*   

> 
> 
> time dd if=/dev/zero of=dummy bs=1k count=1024000
> 
> 1024000+0 records in
> ...

 

Also ca. 28,5 MB/s, die Platte schafft unverschlüsselt ebenfalls ca. 40-45 MB/s. Ich denke, wenn man bedenkt, daß der Prozessor dieses Rechners 455 MHz schneller ist, schneidet dm-crypt ziemlich gut ab.

----------

## Mr Faber

Es kommt natürlich auch darauf an ob dm-crypt aes-128 oder auch wie loop-aes in deinem Fall aes-256 zum verschlüsselen verwendet. AES-256 ist ca. 25 % langsamer als AES-128.

cu

Mr FaberLast edited by Mr Faber on Sat Mar 19, 2005 9:02 am; edited 1 time in total

----------

## schachti

Ich nutze AES mit 256 Bit, daher sind die Zahlen vergleichbar:

 *Quote:*   

> 
> 
> kiste root # cryptsetup status storage
> 
> /dev/mapper/storage is active:
> ...

 

----------

## slick

@ all

sehr interessanter Artikel zum Thema (cryptoloop, weniger dm-crypt) auch in der CT 7/05 - Seite 146, kurze Einleitung hier.

----------

## b00gy

wie sieht das eigendich mit kompatibilität aus?

ich wollte meinen usb-stick auch verschluesseln, was ja kein problem ist, jedeoch MUSS ich ihn unter windows auch benutzen können

ich habe ein programm gefunden das kompatibel zu aes-loop ist

sind all diese verschluesselungsverfahren denn auch untereinander kompatibel?

oder sind die grundlegend verschieden?

oder hänge ich nun wegen der winwos sache an loop-aes? oder kennt einer andere programme/lösungs-ideen um eine verschluesselte partition/container auch unter win zu benutzen?

----------

