🚀 go-pugleaf

helmut zeisel schrieb:
> Welche Loopback Verschluesselung ist unter SuSE 9.2 Out-of-the Box 
> aktiv? Ich erhalte auf
> 
> losetup -e xxx /dev/loop0 device
> 
> immer
> 
> ioctl LOOP_SET_STATUS Das Argument ist ung�ltig. Required cipher or key 
> length not supported by kernel.
> 
> Bei aelteren SuSE habe ich dann immer loop_aes nachinstalliert.
> 
> Encryption sollte ja im Kernel 2.6 standardm��ig drinnen sein. 
> Unterst�tzt SuSE weiterhin nur ihr eingenes twofish, oder gibt es 
> inzwischen eine einheitliche Verschl�sselung, die SuSE out-of-the-Box 
> und Knoppix out-of-the-box gemeinsam verstehen?

Ich kann jetzt nur f�r Suse 9.0 mit 2.4er Kernel sprechen. Aber AFAIK
ist tats�chlich nur twofish out-of-the-box dabei (was meinst Du mit ihr
eigenes? Ist twofish von Suse?). Wobei ich den Algorithmus f�r durchaus
brauchbar halte und auch verwende.

Ich hatte �brigens unter dem genannten System Probleme einen
Cryptoloop-Container > 1GB mit ext3 zu formatieren. Bei ext2 begannen
die Probleme dann ab Container > 40GB. Der Prozess hat sich einfach beim
erstellen der Nodes irgendwann aufgeh�ngt (Ist auch reproduzierbar).
Kann das jemand best�tigen?

-- 
GnuPG-PublicKey -> http://www.hobsons.de/pgp/kai_hessing.asc

Wer Unrecht tut ist ungluecklicher als wer unrecht leidet.
(Demokrit, um 460 v. Chr.)

F'up nach dcoulm gesetzt

helmut zeisel schrieb:

> Encryption sollte ja im Kernel 2.6 standardm��ig drinnen sein.
> Unterst�tzt SuSE weiterhin nur ihr eingenes twofish, oder gibt es
> inzwischen eine einheitliche Verschl�sselung, die SuSE out-of-the-Box
> und Knoppix out-of-the-box gemeinsam verstehen?

Ich habe �ber Weihnachten loop-aes auf einer SuSE-Maschine installiert (mit
einem 2.4.28-Kernel). Dazu habe ich die im loop-aes-Patch angegebene
Version der Util-Linux heruntergeladen, gepatcht und anschliessend
compiliert und installiert und den Kernel gepatcht und neu compiliert. Die
Syntax der /etc/fstab musst du ggf. so anpassen, wie es in der Doku der
Util-Linux steht.

Gruss

Roman

Kai Hessing wrote:

> Ich kann jetzt nur f�r Suse 9.0 mit 2.4er Kernel sprechen. Aber AFAIK
> ist tats�chlich nur twofish out-of-the-box dabei (was meinst Du mit ihr
> eigenes? Ist twofish von Suse?).

Meines Wissens hat SuSE die Encryption schon sehr frueh dabei gehabt, 
aber aufs falsche Pferde gesetzt. Mainstream ist dann AES geworden, SuSE 
twofish ist eben leider nicht kompatibel mit Knoppix.

> Wobei ich den Algorithmus f�r durchaus
> brauchbar halte und auch verwende.

Ich habe keine Grund, daran zu zweifeln. Ich moechte nur ein 
Verschluesselung, die moeglichst ohne viel zu patchen sowohl bei SuSE 
als auch bei Knoppix klappt.

> Ich hatte �brigens unter dem genannten System Probleme einen
> Cryptoloop-Container > 1GB mit ext3 zu formatieren. Bei ext2 begannen
> die Probleme dann ab Container > 40GB. Der Prozess hat sich einfach beim
> erstellen der Nodes irgendwann aufgeh�ngt (Ist auch reproduzierbar).

Dazu kann ich nichts sagen. Ich verschluessle ganze Partitionen und 
verwende Reiser oder ext2.

Helmut

["Followup-To:" header set to de.comp.os.unix.linux.misc.]
helmut zeisel <zei2003d@liwest.at> schrieb:
> Welche Loopback Verschluesselung ist unter SuSE 9.2 Out-of-the Box 
> aktiv?

Neuerdings ist der Default "twofish256" (fr�her war es "twofish",
was, glaube ich, twofish128 entspricht).

> Ich erhalte auf
>
> losetup -e xxx /dev/loop0 device
>
> immer
>
> ioctl LOOP_SET_STATUS Das Argument ist ung�ltig. Required cipher or key
> length not supported by kernel.

Du musst das Modul vor der ersten Benutzung explizit laden:
Als root "modprobe loop_fish2" eingeben
(wird von /etc/rc.d/boot.crypto beim Booten erledigt,
falls Du entsprechend mit Yast konfigurierst hast).

Kai Hessing wrote:

> Ich kann jetzt nur f�r Suse 9.0 mit 2.4er Kernel sprechen. Aber AFAIK
> ist tats�chlich nur twofish out-of-the-box dabei (was meinst Du mit ihr
> eigenes? Ist twofish von Suse?). Wobei ich den Algorithmus f�r durchaus
> brauchbar halte und auch verwende.

Alexander Bartolich hat mich da auf folgenden Text aufmerksam gemacht:

 > http://mareichelt.de/pub/texts.cryptoloop.php

"My recommendation is plain and simple: Do not use cryptoloop, dm-crypt, 
or loop-AES in single-key mode - you don't want to commit security 
malpractice, do you?

Get it done right and use loop-AES in multi-key mode (and encrypted swap!)"

Helmut Zeisel schrieb:
> Kai Hessing wrote:
> 
>> Ich kann jetzt nur f�r Suse 9.0 mit 2.4er Kernel sprechen. Aber AFAIK
>> ist tats�chlich nur twofish out-of-the-box dabei (was meinst Du mit ihr
>> eigenes? Ist twofish von Suse?). Wobei ich den Algorithmus f�r durchaus
>> brauchbar halte und auch verwende.
> 
> Alexander Bartolich hat mich da auf folgenden Text aufmerksam gemacht:
> 
>  > http://mareichelt.de/pub/texts.cryptoloop.php
> 
> "My recommendation is plain and simple: Do not use cryptoloop, dm-crypt, 
> or loop-AES in single-key mode - you don't want to commit security 
> malpractice, do you?
> 
> Get it done right and use loop-AES in multi-key mode (and encrypted swap!)"

Klingt durchaus mal interessant. Sobald ich Zeit habe, werd ich mal
tiefer reinschauen. Bisher sehe ich das Problem noch nicht so wirklich.
Das Brute-Force-Attacken auf die Passphrase m�glich sind, gilt immer,
wenn der Schl�ssel auf demselben System zu finden ist. Alles andere werd
ich mich mal tiefer reinlesen.
Swap ist ansonsten immer das Problem, das man gerne vergi�t (Siehe
Apple's FileVault)^^

-- 
GnuPG-PublicKey -> http://www.hobsons.de/pgp/kai_hessing.asc

Schlechter Leute Tadel ficht den Guten nicht an.
(Demokrit, um 460 v. Chr.)

Kai Hessing wrote:

> Helmut Zeisel schrieb:

>> > http://mareichelt.de/pub/texts.cryptoloop.php
>
> Bisher sehe ich das Problem noch nicht so wirklich.

Ich habe es auch nicht ganz verstanden.

> Das Brute-Force-Attacken auf die Passphrase m�glich sind, gilt immer,
> wenn der Schl�ssel auf demselben System zu finden ist. Alles andere werd
> ich mich mal tiefer reinlesen.

Sovweit ich es verstehe, geht es um "watermark" Attacken. Wenn ich es 
richtig verstehe, geht es hier um eine "known plaintext" Attacke. 
Gewisse "magic numbers" im Linux-Dateisystem sind bekannt, man wei� 
genau, wo sich diese Werte im verschluesselten Dateisystem befinden und 
kann dadurch die Brute-Force-Attacken erleichtern.

Kann das wer best�tigen oder genauer erkl�ren?

> Swap ist ansonsten immer das Problem, das man gerne vergi�t 

Ja, der ist bei mir derzeit auch noch unverschl�sselt.

Helmut

Helmut Zeisel wrote:


> Sovweit ich es verstehe, geht es um "watermark" Attacken. Wenn ich es 
> richtig verstehe, geht es hier um eine "known plaintext" Attacke. 
> Gewisse "magic numbers" im Linux-Dateisystem sind bekannt, man wei� 
> genau, wo sich diese Werte im verschluesselten Dateisystem befinden und 
> kann dadurch die Brute-Force-Attacken erleichtern.
> 
> Kann das wer best�tigen oder genauer erkl�ren?

Da habe ich noch was gefunden:

Watermark-attack ist also keine known-plaintext, sondern 
chosen-plaintext Attacke.

http://marc.theaimsgroup.com/?l=linux-kernel&m=107719798631935&w=

List:       linux-kernel
Subject:    Re: Oopsing cryptoapi (or loop device?) on 2.6.*
From:       Jari Ruusu <jariruusu () users ! sourceforge ! net>
Date:       2004-02-19 13:34:54
Message-ID: <4034BB7E.4ED20C2 () users ! sourceforge ! net>

Markku-Juhani O. Saarinen discovered watermark attack against 
cryptoloop, here is his paper:

     http://www.tcs.hut.fi/~mjos/doc/diskenc.pdf

This attack makes it possible to detect presense of specially crafted 
watermarked files, such as, unreleased Hollywood movies, cruise missile 
service manuals, and other content that you did not create yourself. 
Watermarked files contain special bit patterns that can be detected 
without decryption.

Helmut

Helmut Zeisel wrote:


>     http://www.tcs.hut.fi/~mjos/doc/diskenc.pdf

Der Link ist tot; da findet es man auch:

http://mareichelt.de/pub/notmine/diskenc.pdf

Helmut

> cryptoloop "unsicherheiten"

http://clemens.endorphin.org/LinuxHDEncSettings

cu, mg
-- 
/*The only secure computer is one that's unplugged, locked in a
safe, and buried 20 feet under the ground in a secret location...
and i'm not even too sure about that one.*/

Michael Gebetsroither wrote:

>>cryptoloop "unsicherheiten"
> 
> 
> http://clemens.endorphin.org/LinuxHDEncSettings

Kannst Du kurz zusammenfassen, worauf Du hinauswillst?

Danke,

Helmut

On 2005-01-20, Helmut Zeisel <helmut.zeisel@aon.at> wrote:
> Michael Gebetsroither wrote:

>>>cryptoloop "unsicherheiten"
>> http://clemens.endorphin.org/LinuxHDEncSettings
> Kannst Du kurz zusammenfassen, worauf Du hinauswillst?

Es gibt mehrere Schwachstellen in dem derzeitigen dm-crypt.
Allerdings kommt auch loop-aes nicht so ganz aus, allerdings ist diese
Schwachstelle eher theoretischer Natur.

Bei dm-crypt sind allerdings (siehe "Summarising" in der obrigen url)
einige schwerwiegende M�ngel.

z.b Kann man nicht sagen, dass eine mit dm-crypt verschl�sselte
Partition nur ganz zufllig einfach mit zufallszahlen �berschrieben
wurde (man kann _nicht_ verneinen, dass man verschl�sselte Daten auf der
platte hat).
Zu den restlichen schw�chen => url

cu, mg
-- 
/*The only secure computer is one that's unplugged, locked in a
safe, and buried 20 feet under the ground in a secret location...
and i'm not even too sure about that one.*/

Michael Gebetsroither wrote:

> Es gibt mehrere Schwachstellen in dem derzeitigen dm-crypt.
> Allerdings kommt auch loop-aes nicht so ganz aus, allerdings ist diese
> Schwachstelle eher theoretischer Natur.

Die Empfehlung aus http://mareichelt.de/pub/texts.cryptoloop.php
"Get it done right and use loop-AES in multi-key mode (and encrypted 
swap!)"  gilt also mangels besserer Alternative weiterhin?

Helmut

On 2005-01-20, Helmut Zeisel <helmut.zeisel@aon.at> wrote:

> Die Empfehlung aus http://mareichelt.de/pub/texts.cryptoloop.php
> "Get it done right and use loop-AES in multi-key mode (and encrypted 
> swap!)"  gilt also mangels besserer Alternative weiterhin?

Jein (ich hoffe nicht mehr lange).

Es gibt als neuen ciphermode LRW und als sicheren key-speicher LUKS.
Auch gibt es eine Implementation vom EME cipher mode f�r Linux.

Allerdings befindet sich beides daweil nicht im vanilla kernel und auch
die user-basis die es verwendet ist noch relativ klein (um nicht zu
sagen mikroskopisch klein).

Ich hab das ganze mal testweise laufen, aber wirklich wichtige Daten
w�rd ich dem daweil nicht antrauen.
Weniger wegen der Angst um Laufzeitfehler, sondern um inkompatibilit�ten
zu neuen  Versionen.

Und nein, dm-crypt zusammen mit cryptoloop ist �berhaupt nicht
kompliziert zu bedienen.
Es gibt auch einige sehr gute scripts um das ganze zu verwenden.

Wie gesagt, auch was wirklich sicheres muss man derzeit im vanilla
kernel leider noch warten.

cu, mg
-- 
/*The only secure computer is one that's unplugged, locked in a
safe, and buried 20 feet under the ground in a secret location...
and i'm not even too sure about that one.*/

Kai Hessing schrieb:

> Klingt durchaus mal interessant. Sobald ich Zeit habe, werd ich mal
> tiefer reinschauen. Bisher sehe ich das Problem noch nicht so wirklich.
> Das Brute-Force-Attacken auf die Passphrase m�glich sind, gilt immer,
> wenn der Schl�ssel auf demselben System zu finden ist. Alles andere werd
> ich mich mal tiefer reinlesen.

Auf das alte Cryptoloop sind Attacken m�glich, die wesentlich besser als
Brute Force sind, n�mlich in O(log n) anstatt O(n) durchgef�hrt werden
k�nnen. Da gewisse Bytes am Anfang einer Partition immer gleich aussehen,
kann man diese mit den 1'000'000'000 wahrscheinlichsten Passw�rtern
verschl�sseln und die Daten sortiert in einer Datenbank ablegen. Wenn man
nun eine Partition knacken will und die verwendete Passphrase in der
Datenbank gespeichert ist, gen�gt es, die oben erw�hnten Bytes aus der
veschl�sselten Partition auszulesen und in der Datenbank nachzuschauen.

Gruss

Roman

["Followup-To:" header set to at.linux.]
On 2005-01-20, Roman Racine <roman.racine@gmx.de> wrote:

> Auf das alte Cryptoloop sind Attacken m�glich, die wesentlich besser als
> Brute Force sind, n�mlich in O(log n) anstatt O(n) durchgef�hrt werden
> k�nnen.

Ein einfaches loop-up in einer db halt (wobei das ja net unbedingt O(log
n) sein muss).

> Da gewisse Bytes am Anfang einer Partition immer gleich aussehen,
> kann man diese mit den 1'000'000'000 wahrscheinlichsten Passw�rtern
> verschl�sseln und die Daten sortiert in einer Datenbank ablegen.

Nein, das ging schon bei dem damaligen cryptoloop nicht mehr wenn man
etwas seinen Kopf benutzt.

Als zugangskey eine 256bit Zufallszahl und diese mit gnupg
verschl�sseln. Viel spa� mit deinen rainbow tables ;).

> Wenn man
> nun eine Partition knacken will und die verwendete Passphrase in der
> Datenbank gespeichert ist, gen�gt es, die oben erw�hnten Bytes aus der
> veschl�sselten Partition auszulesen und in der Datenbank nachzuschauen.

Tjo siehe oben, das ganz funktioniert nur solange keine PW's �ber 12
zeichen vorkommen.
Denn du musst ja noch jeden Cipher + verschiedene L�ngen miteinbeziehen.

Aber zumindestens NTLMv1 hashes haben gegen solche Angriffe keine
chance. Und ich bilde mir ein auch mal ein paper gelesen zu haben wo
ziehmlich deutlich daraus hervor ging, dass auch /etc/shadow im md5
Format nur wenig chancen hat (allerdings gings dort um "supercomputer"
welche den Angriff ausf�hren). Bei NTLM hashes sind die kompletten
rainbowtables imho nur 18GB gro�.

cu, mg
-- 
/*The only secure computer is one that's unplugged, locked in a
safe, and buried 20 feet under the ground in a secret location...
and i'm not even too sure about that one.*/

Michael Gebetsroither wrote:

> Es gibt als neuen ciphermode LRW und als sicheren key-speicher LUKS.
> Auch gibt es eine Implementation vom EME cipher mode f�r Linux.

Das ist eine gute Nachricht.

> Allerdings befindet sich beides daweil nicht im vanilla kernel und auch
> die user-basis die es verwendet ist noch relativ klein (um nicht zu
> sagen mikroskopisch klein).

Das ist die weniger gute - zurueck zu meiner Ausgangsfrace: bei Knoppix 
out-of-the-box ist das also wohl (im Gegensatz zu loop-aes) nicht dabei?

Helmut

["Followup-To:" header set to at.linux.]
On 2005-01-21, Helmut Zeisel <helmut.zeisel@aon.at> wrote:
> Michael Gebetsroither wrote:

>> Allerdings befindet sich beides daweil nicht im vanilla kernel und auch
>> die user-basis die es verwendet ist noch relativ klein (um nicht zu
>> sagen mikroskopisch klein).
> Das ist die weniger gute - zurueck zu meiner Ausgangsfrace: bei Knoppix 
> out-of-the-box ist das also wohl (im Gegensatz zu loop-aes) nicht dabei?

Loop-aes ist daweil wie man so sch�n sagt das bessere �bel.
Denn auch loop-aes sch�tzt z.b nicht gegen eine cipher text injection.
Dh. wenn du deinen Laptop verlierst kann jemand dir daten in deine
Cryptopartition einschleu�en. Die z.b dann bei gewissen watermark scanns
auftaucht und du daher gezwungen wirst deine Schl�ssel zu verraten um
deine Unschuld zu beweisen.

ps.: in grml (www.grml.org) ist auch der eme cipher vorhanden. lrw + ein
cryptsetup das luks beherrscht kommt (ma schauen wieviel probleme das
mitm kernel macht) warscheinlich n�chste version.

cu, mg
-- 
/*The only secure computer is one that's unplugged, locked in a
safe, and buried 20 feet under the ground in a secret location...
and i'm not even too sure about that one.*/