[linux-l] Sicherheit oder irgendwas, hauptsache einfach?

[Mike Dornberger]

Hi,

On Wed, Jun 14, 2006 at 03:33:14PM +0200, Benjamin Schieder wrote:
> On 14.06.2006 13:16:28, Mike Dornberger wrote:
> > On Tue, Jun 13, 2006 at 08:57:17PM +0200, Benjamin Schieder wrote:

> > [schlechte Implemtierung bei dm-crypt, truecrypt, ...? loop-AES
> > besser?]

> Vor einiger Zeit wars genau andersrum, da war loop-AES anfaellig. Daher

Hast du da mal ein paar Links zu? Aus der ChangeLog von loop-AES entnehme
ich, daß in Version 2.0b vom 29. 11. 2003 (2.0 / 2.0a waren glaube ich keine
offiziellen Releases), Multi-Key-Mode eingeführt wurde, was einerseits, wie
ich das verstanden habe, die Wasserzeichenangriffe (sagen wir mal: in der
bekannten Form) unterbindet und andererseits dafür sorgt, daß die
Wahrscheinlichkeit auf identischen Chiffretext verringert wird und sich
gleich ein ganzer 512 Byte Sektor ändert, sollte auch nur 1 Bit in den 512
Byte Klartext sich ändern. Ich glaube, das war war gar nicht so lange nach
dem Bekanntwerden des Wasserzeichenangriffs. Truecrypt hat wohl erst in
Version >=4.1 (welche noch nicht so alt ist) den Modus von CBC auf LRW
umgestellt. So, wie ich das aus deren ChangeLog neulich entnommen habe, wohl
wegen des Wasserzeichenangriffs (wurde nicht explizit so genannt). dm-crypt
hat nach meinem Kenntnisstand da wohl noch nichts gegen unternommen.

In loop-AES-Version 3.0a vom 27. 11. 2004 wurde noch ein zusätzlicher 65.
Key hinzugefügt (zu den 64 aus dem Multi-Key-Mode), um eine Schwäche in der
Berechnung des IV zu beseitigen, "die normalerweise nicht ausnutzbar ist".

Aktuelle Version ist 3.1d vom 10. 04. 2006.

Auch nicht zu unterschätzen ist die Tatsache, daß loop-AES 2.2, 2.4 und
2.6er-Kernel unterstützt. (Bei 2.2ern bin ich mir nicht zu 100% sicher.)

> bevorzuge ich das, was ich nicht alle drei, vier Kernelversionen neu
> patchen muss. Ich habe loop-AES ne Weile verwendet, und die Einfachheit
> von
> 
> 	losetup -e blowfish256 /dev/loop/1 /dev/discs/disc0/part1
> 
> war doch sehr beeindruckend. Allerdings war das regelmaessige neu patchen
> doch recht unangenehm, besonders wenn der neue Patch erst ein, zwei Wochen
> nach einem neuen Kernel rauskommt. Kombiniere das mit nem Exploit im Kernel
> und du hast ein Problem.

Ich habe jetzt nicht nachgesehen, aber der neueste 2.6er Kernel ist doch
sicherlich neuer als 10. April diesen Jahres? Falls ja, nehme ich mal an,
daß Jari daß entsprechende Makefile so weit angepaßt hat, daß es nahezu
unabhängig von der Kernel-Version ist. Vielleicht hängt daß auch nur damit
zusammen, daß ich schon öfter gelesen habe, daß loop.c komplett aus dem
Kernel fliegen soll und deshalb an dieser Baustelle keine Änderungen mehr
gemacht werden.

Aber ganz unabhängig davon: Wenn du ein Exploit im Kernel hast, hast du doch
mit allen Crypto-Systemen ein Problem.

Oder meintest du das jetzt in bezug auf: "loop-AES baut nicht mit neuem
Kernel"? Naja, zur Not halt noch 'nen UML-Kernel aus älteren Sourcen bauen
und dann NFS oder sowas, bis es wieder klappt... :)

Gut, da ich bis jetzt aus Mangel an 'nem Testrechner das ganze noch nicht
wirklich praktisch durchgespielt habe, kann ich nicht genau sagen, wie das
mit den Wartezeiten in der Vergangenheit war, bis loop-AES wieder baute. Mir
kam es jedenfalls beim Lesen der Mailingliste so vor, als sei das doch
innerhalb sehr weniger Tage passiert.

> > > Desweiteren laesst sich mit http://shellscripts.org/project/dmscripts
> > > ein Dateisystem run-time (also _nachdem_ Daten drauf sind, bitte
> > > trotzdem umount anwenden!) verschluesseln.
> > 
> > Ich habe mir das Script jetzt nicht angesehen, aber es wird dann wohl so
> > etwas ähnliches machen, wie aespipe:
> >
> > [ Beispiel ]
> 
> Prinzipiell setzt es ein /dev/mapper device auf, macht
> 
> 	dd if=/dev/discs/disc0/part1 of=/dev/mapper/foo
> 
> und loescht das /dev/mapper device wieder. Danach kann man mit dmmount.sh
> und dmumount.sh so arbeiten wie zuvor mit mount und umount.

Naja, kann man darüber streiten. Das aespipe hat jedenfalls den Vorteil, daß
man es überall dazwischenklemmen kann, wo es sowas wie ein dd von Partition
und nach Partition gibt. Das sollte dann selbst unter Windows mittels cygwin
z. B. laufen. (Ich glaube mich zu erinnern, daß die Sourcen von aespipe ANSI
C sind; jedenfalls "ziemlich dolle" zu allem möglichen kpmpatibel/baut
nahezu überall.) Ist sicherlich Geschmackssache, was man jetzt als "besser"/
"vorteilhafter" bezeichnen möchte.

> > Wo legst du den verwendeten Algorithmus, die Schlüssellänge, Offsets,
> > Salt, Itercount u. d. g. fest?
> 
> Klingt nach nem guten Feature Request. Koennte man als Parameter mit
> uebernehmen.

Wie sieht es bei dm-crypt eigentlich mit fstab aus? Die ganzen Parameter,
bis hin zum gpg-Verschlüsselten Keyfile werden bei loop-AES in der Options-
Spalte übergeben, sodaß, falls dort user(s) mit angeben ist, auch ein
normales "mount /mnt/crypt..." reicht, dito für auto-Mount und swap. (Für
die erweiterten Parameter - der Kram, der vom alten in-kernel cryptoloop
kommt, reicht nicht aus - werden natürlich {,u}mount, swapo{n,ff} gepatcht.)

> Desweiteren gibt es da noch LUKS:
> 
> 	http://luks.endorphin.org/

Von LUKS hab ich auch schonmal gehört, weiß aber noch nicht wirklich, was
ich davon halten soll.

Ich glaube, in der nächsten Version der loop-AES README kommt ein Beispiel
hinein, wie man ganz auf Partitionstabellen o. ä. verzichten kann. Alle
relevanten Daten (siehe offset= Mount-Option) kann z. B. in die fstab oder,
falls ein Script die zugrundeliegenden loops per losetup aufsetzt, dann
dahinein.

> > OSS besser ist.) Im übrigen möchte ich noch daran erinnern, daß auch
> > Jörg Schilling (cdrecord u. a.) gerne viel über Design-Schwächen im
> > Linux-Kernel erzählt. :)
> 
> Ich moechte mich jetzt lieber nicht ueber Joerg unterhalten. Es fliegt
> schon genug Flamebait rum :-)

:^) Ich erinnere mich da an einen Mittwoch (?) Abend vor dem CLT2006 in der
c-base...

Aber hast du das jetzt als Geflame aufgefaßt? Das sollte es eigentlich nicht
sein. Vielleicht habe ich ja auch einen ganz falschen Eindruck von loop-AES,
weil ich zu wenig von den Machern der anderen Systemen und den jeweiligen
"Fangemeinden" drumherum gelesen habe?

Grüße,
 Mike

PS: Warum sind meine Umlaute und ß (sz) bei dir eigentlich Fragezeichen? Ich
habe gerade nochmal nachgeschaut, aber mein mutt hat richtigerweise
Content-Type: text/plain; charset=iso-8859-1
gesetzt. Liegt es vielleicht an
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by gnu.in-berlin.de id
k5EB ?
(Gut, daß ich mir nochmal 'ne Kopie von der ML schicken lasse.) Denn bei mir:
Content-Transfer-Encoding: quoted-printable