# Welche Kerneloptionen für dm-crypt?

## Deadman44

Hallo Leute,

ich habe mich jetzt letztens mal an die vollständige Verschlüsselung meines Gentoo systems gewagt, da ich unter Ubuntu auch sehr zufrieden damit war. Klar unter Gentoo ist alles self made und das habe ich dann am ende auch zu spüren bekomen. Ich bin folgender Anleitung nachgegangen: http://www.kugelweiche.org/?p=160. Ich habe alles bis auf die Optionen für den Suspend modus mit hibernate script und tuxonice sources nachgemacht. Soweit so gut, habe ich mein neu verschlüsseltes System gestartet und dm-crypt spuckt mir direkt ne fehlermeldung ins gesicht.

So weit mein Linux Verständnis und meine Englisch Kenntnisse reichen bin ich mir ziemlich sicher, dass ich benötigte KErneloptionen als Modul eingebunden habe, statt sie fest zu kompilieren, da das identische (unverschlüsselte) System problemlos die verschlüsselte Festplatte öffnen kann. Bitte fragt jetzt nicht danach, welche KErneloptionen ich aktiviert habe, irgendwann bin ich aus verzweiflung nur noch nach dem Zufallsprinzip gegangen und habe alles wo nur ansatzweise ein crypt oder aes drinnnen stand fest einkompiliert. am besten wäre es, wenn ihr mir alle benötigten Punkte sagt. Denke doch mal, dass es hier jemanden gibt, der ein vollverschlüsseltes System hat.

Für andere Verschlüsselungslösungen wäre ich evtl. auch noch offen, solange sie das komplette System verschlüsseln.

Zur Fehlermeldung:

```

!!Failed to open LUKS device /dev/sda2

!!Could not find the root in /dev/sda .

Please specify another value or: press Enter for the same, type "shell" for a shell, or "q" to skip...

<Eingabe>rot (/dev/sda2) :: _

```

Vorher stand auch noch was davon, dass man den kernel prüfen soll, ob ein bestimmtes modul verfügbar wäre. Aber die Meldung ahbe ich irgendwie weg bekommen, nur bitte fragt mich nicht wie  :Wink: .

Hoffe mir kann jemand helfen

lg der tote Mann

----------

## root_tux_linux

http://de.gentoo-wiki.com/wiki/DM-Crypt <----

----------

## Deadman44

 *root_tux_linux wrote:*   

> http://de.gentoo-wiki.com/wiki/DM-Crypt <----

 

Diesen Gentoo-Wiki Eintrag hatte ich bereits gesehen und ausprobiert, leider ohne Erfolg  :Sad: .

Aber trotzdem Danke.

Die momentane Lage sieht so aus, dass egal welches Passwort ich eingebe, er immer wieder zur erneuten Passwortabfrage bittet, aber ohne jelgiche Meldung. Passwort ist aber richtig (da ich die verschlüsselte Partition auch schon unter dem parallel installierten unverschlüsselten Gentoo System entschlüsselt bzw. darauf zugegriffen habe). Nach 3 maliger "falschen" Eingabe meldet er sich wieder mit der Fehlermeldung aus meinem vorigen Post.

----------

## AmonAmarth

da du dir ja scheinbar so sicher bist das du das korrekte passwort eingegeben hast, hast du auch beachtet das du evtl. ein englisches keyboard layout beim booten hast?

----------

## zyko

Paste den Output von grep -i crypt /usr/src/linux/.config.

 *Quote:*   

> da du dir ja scheinbar so sicher bist das du das korrekte passwort eingegeben hast, hast du auch beachtet das du evtl. ein englisches keyboard layout beim booten hast?

 

Das ist ein häufiges Problem. Unter vielen Konfigurationen (baselayout-1 afair) wird das Passwort abgefragt, bevor die Keymap eingestellt wird. Du solltest bei der Wahl deiner Passwörter generell darauf achten, dass sie unter allen gängigen Keymaps funktionieren (v.a. de + en).

----------

## AmonAmarth

 *zyko wrote:*   

> Das ist ein häufiges Problem. Unter vielen Konfigurationen (baselayout-1 afair) wird das Passwort abgefragt, bevor die Keymap eingestellt wird. Du solltest bei der Wahl deiner Passwörter generell darauf achten, dass sie unter allen gängigen Keymaps funktionieren (v.a. de + en).

 

dann fällt jegliche möglichkeit sonderzeichen zu verwenden um die sicherheit zu erhöhen ja schonmal raus, ich würde dann eher empfehlen rauszufinden auf welchen tasten die genutzten sonderzeichen liegen um sie dann richtig zu drücken.

----------

## mv

 *AmonAmarth wrote:*   

> sonderzeichen zu verwenden um die sicherheit zu erhöhen

 

...und schon wieder ist mal wieder Aufklärung gefragt.   :Wink: 

Dass Sonderzeichen die Sicherheit erhöhen, ist eine weitverbreitete Fehleinschätzung. Mach das Passwort ein paar Zeichen länger statt solchen Krampf - das gibt ein Vielfaches mehr an Sicherheit, wie eine einfache Rechnung zeigt. Das wurde erst vor kurzem in einem Thread hier angesprochen (wenn auch nicht vertieft).

----------

## Deadman44

So ich habe mein Vorhaben der root-verschlüsselung fürs erste auf eis gelegt, da ich schon zu lange ohne ein funktionstüchtiges Linux System auskommen musste (und vista hinterlässt auf dauer bleibende schäden bei mir  :Wink:  ). /home-verschlüsselung wird es bei mir auf jeden fall geben, sobald ich mal daran komme benutzer anzulegen und vom /home verzeichnis gebrauch zu machen. Und dann erst mal in einer VM gucken, wie es weitergeht mit einem vollständig verschlüsseltem Gentoo-System.

Bis hierhin schon mal vielen Dank an alle, die sich die Mühe gemacht haben, und versucht haben, mir weiterzuhelfen.

 *Quote:*   

> da du dir ja scheinbar so sicher bist das du das korrekte passwort eingegeben hast, hast du auch beachtet das du evtl. ein englisches keyboard layout beim booten hast?

 

Nein diese Möglichkeit ist ausgeschlossen. Das Passwort ist nur ein reiner Buchstaben und Zahlensalat.

lg der tote Mann

----------

## ScytheMan

 *Deadman44 wrote:*   

> 
> 
>  *Quote:*   da du dir ja scheinbar so sicher bist das du das korrekte passwort eingegeben hast, hast du auch beachtet das du evtl. ein englisches keyboard layout beim booten hast? 
> 
> Nein diese Möglichkeit ist ausgeschlossen. Das Passwort ist nur ein reiner Buchstaben und Zahlensalat.
> ...

 

Dir ist aber schon bewusst, dass auf einer englischen Tastatur das Y an Z Stelle sitzt und Z an Y Stelle?

----------

## AmonAmarth

 *mv wrote:*   

>  *AmonAmarth wrote:*   sonderzeichen zu verwenden um die sicherheit zu erhöhen 
> 
> ...und schon wieder ist mal wieder Aufklärung gefragt.  
> 
> Dass Sonderzeichen die Sicherheit erhöhen, ist eine weitverbreitete Fehleinschätzung. Mach das Passwort ein paar Zeichen länger statt solchen Krampf - das gibt ein Vielfaches mehr an Sicherheit, wie eine einfache Rechnung zeigt. Das wurde erst vor kurzem in einem Thread hier angesprochen (wenn auch nicht vertieft).

 

ich kann dir nicht zustimmen, gehen wir mal von einem 10 zeichen passwort aus:

alphanumerisch (a-z, A-Z, 0-9): 26 + 26 + 10 = 62      -> 62^10 = 8,39 * 10^17

sonderzeichen: ä Ä ö Ö ü Ü ß ! " § $ % &  / ( ) = ? , . ; : - + _ # ' ` ' ~ \ ^ ° < > @ µ

insgesamt macht das 38 zeichen mehr.   ->   (62 + 3 :Cool: ^10 = 10^20

knapp 3 zehner potenzen sind für meinen geschmack schonmal ein argument, zudem wird jeder "hacker" oder "stasi 2.0"-mann erstmal das wörterbuch reinprügeln und danach alphanumerische passwörter per brute force durchprobieren. zudem steigt die "sicherheit" (verhältnis zwischen alphanumerisch und alphanumerisch + sonderzeichen) im verhältnis zu 1,61^x pro zeichen (wobei x die anzahl der zeichen ist).

das es zum teil ein krampf ist sonderzeichen "blind" in die tastatur zu tippen steht jetzt mal außenvor, das passwort sollte also auch mit sonderzeichen blind zu beherrschen sein! sonst kommt der nächste "schnellgucker" und schreibt es bei der eingabe mit...

----------

## xicm

Also gleich vorweg, ich hab auch erst vor kurzem angefangen mich mal mit dm-crypt und lvm zu befassen. Ich weiss deswegen nicht ob das so optimal ist was ich dir hier schreibe, aber eventuell hilft es dir ja trotzdem.

Du übergibst aber auch die Parameter richtig an den Kernel? 

```
kernel /kernel-genkernel-x86-2.6.23-tuxonice-r10 crypt_root=/dev/sda2 real_root=/dev/vg/root dolvm resume=/dev/vg/swap
```

Was du in deinen Kernel an Crypto. APIs einkompilieren musst kannst du erfahren in dem du z.B.:

```
> cryptsetup luksDump /dev/sda4

LUKS header information for /dev/sda4

Version:          1

Cipher name:      twofish

Cipher mode:      xts-plain

Hash spec:        sha1

...
```

ausführst. Die APIs dort müssen dann beim Start von dm-crypt verfügbar sein. Die generellen Sachen stehen ja am Anfang des Gentoo Wiki - Artikels über dm-crypt.

Alternative zum voll-verschlüsselten System

Was das voll verschlüsselte System angeht so... entgeht mir da etwas der immer etwas der Sinn. Besonders wenn man eine Bootpartition benutzt und nicht das gesamte Startsystem vom Rechner abkapselt. Wesentlich einfacher ist es z.B. mit 4 Partitionen. Dabei erstellt man eine Boot-Partition (sda1), eine Swap-Partition (sda2), eine Root-Partition (sda3) und eine eine für den "Rest" (sda4). sda2 und sda4 werden dabei verschlüsselt. sda4 wird dann dein PV das du dann nachher in LV für /var, /opt, /tmp, home/ und /usr aufteilst (Gibt dann auch dem LVM Systeme einen Sinn).

Erstellen der Swap-Partition:

```
> cryptsetup -c twofish -s 256 create swap /dev/sda2

> mkswap /dev/mapper/swap 
```

Vorbereiten von sda4:

```
> head -c1024 /dev/urandom > sec.key

> gpg -c --cipher-algo TWOFISH sec.key

> gpg -q --cipher-algo TWOFISH --decrypt sec.key.gpg | cryptsetup luksFormat -c twofish-xts-plain -s 256 /dev/sda4 
```

Hierbei kannst du den sec.key.pgp auf z.B. einem USB-Stick speichern, und die Datei sec.key gut entsorgen!

```
> pvcreate /dev/mapper/data

> vgcreate cvg /dev/mapper/data

> lvcreate -L30G -nhome cvg

> lvcreate -L20G -nusr cvg

> lvcreate -L20G -nvar cvg

> lvcreate -L5G -nopt cvg

> lvcreate -L50 -ntmp cvg
```

Hier natürlich die Grössen eigenen Bedürfnissen anpassen, aber lieber zu klein als zu gross... vergrössern ist einfacher als verkleinern. Jetzt kannst du auf allen LVs ein Dateisystem deiner Wahl einrichten.

```
> mkfs.jfs /dev/sda1

> mkfs.jfs /dev/sda3

> mkfs.jfs /dev/cvg/home

> mkfs.jfs /dev/cvg/usr

> mkfs.jfs /dev/cvg/var

> mkfs.jfs /dev/cvg/tmp

> mkfs.jfs /dev/cvg/opt
```

Nun alles der reihe nach zum installieren des Basissystems einhängen (z.B. /mnt/gentoo)

```
> mount /dev/sda3 /mnt/gentoo

> mkdir /mnt/gentoo/boot

> mkdir /mnt/gentoo/home

> mkdir /mnt/gentoo/usr

> mkdir /mnt/gentoo/opt

> mkdir /mnt/gentoo/var

> mkdir /mnt/gentoo/tmp

> mount /dev/sda1 /mnt/gentoo/boot

> mount /dev/cvg/home /mnt/gentoo/home

> mount /dev/cvg/usr /mnt/gentoo/usr

> mount /dev/cvg/var /mnt/gentoo/var

> mount /dev/cvg/tmp /mnt/gentoo/tmp

> mount /dev/cvg/opt /mnt/gentoo/opt
```

Nun kannst du in das System wie in der Gentooanleitung installieren. Wenn du dein System dann einrichtest must du darauf achten das LVM, DM-Crypt und gnugpg installiere sind. zudem muss gnupg mit dem USE-Flag static compiliert werden da du es benötigst bevor das /usr/bin-Dateisystem zur Verfügung steht. Zudem musst du die gpg-Dateien entweder in /usr/bin auf sda3 ablegen das später überlagert wird oder aber du kopierst sie nach /bin, das ja nicht verschlüsselt wurde. (an die /etc/fstab Einträge denken)

Weitere Einstellungen:

Zum einen muss man dafür sorgen das dm-crypt vor LVM gestartet wird, was bei mir nicht der Fall war, ich hab bei mir LVM von DM-Crypt im RC-Script abhängig gemacht weil ich:

```
# /etc/conf.d/rc:

...

RC_VOLUME_ORDER="raid evms dm dm-crypt lvm "

...

```

 vergessen hatte. Ich hatte noch keine Zeit das so wie hier beschrieben zu testen!

```
# /etc/conf.d/cryptfs

swap=swap

source='/dev/sda2'

options='-c twofish-xts-plain  -s 256 -d /dev/urandom'

target=data

source='/dev/sda4'

options="-c twofish-xts-plain -s 256"

key='/sec/sec.key.gpg:gpg'

gpg_options='-q --cipher-algo TWOFISH --decrypt'

remdev='/dev/sdb1'
```

Hier die Anpassungen vornehmen damit dm-crypt die nötige Datei finden kann. (sdb1 ist bei mir der USB-Stick)

Hmm, jetzt hab ich ja viel mehr geschrieben als ich wollte... Aber eventuell hilf es dir ja weiter. Und ich hoffe ich hab nichts vergessen zu schreiben.

Edit: Typos und -#+>

----------

## mv

 *AmonAmarth wrote:*   

> ich kann dir nicht zustimmen, gehen wir mal von einem 10 zeichen passwort aus:

 

Du ignorierst den entscheidenden Teil der Aussage: Mach das Passwort lieber ein paar Zeichen länger.

Gehen wir also von einem Sonderzeichen-Passwort der Länge 10 aus, und von mir aus 60 vs. 100 Zeichen

```
$ bc<<<60^12/100^10

21
```

(wobei hier jeweils zu "Deinen" Gunsten gerundet wird): Mit nur 2 zusätzlichen Zeichen statt dem ganzen Umstand mit Sonderzeichen hast Du also schon das 21-fache an Möglichkeiten. Realistischeres Beispiel gefällig? Beschränken wir das Passwort sogar auf Kleinbuchstaben, nehmen dafür aber drei Zeichen mehr

```
$  bc <<<26^13/10^10

248115287
```

Wir haben damit deutlich mehr als drei Zehnerpotenzen gewonnen - ca. 248115 mal mehr. Abgesehen davon, dass die Rechnung mit Sonderzeichen ohnehin nicht aufgeht, wenn man nur verschämt ein oder zwei davon einstreut - es müsste schon der größte Teil die verschiedensten abstrusen Sonderzeichen sein, was kein Mensch tippen will.

Allgemeiner: Zwei Kleinbuchstaben (676 Kombinationen) sind statistisch immer (um mehr als den Faktor 6) einem Sonderzeichen (100 Kombinationen) zu bevorzugen, und sie lassen sich mindestens genauso schnell tippen.

```
zudem wird jeder "hacker" oder "stasi 2.0"-mann erstmal das wörterbuch reinprügeln
```

Ich habe nicht geschrieben: Benutze nur ein Wort aus dem Wörterbuch. Obwohl es auch gar nicht so verkehrt ist, nur Wörter aus dem Wörterbuch zu benutzen, aber in dem Fall sollte das Passwort ein nicht zu kurzer Satz sein - daran scheitern alle brute-force-Algorithmen aufgrund der puren Anzahl der Möglichkeiten (selbst wenn eine Variante des Satzes in einer Bücherdatenbank stehen sollte, die ein brute-force-Angreifer benutzen könnte).

Edit: Natürlich sollte es nicht exakt ein Satz aus einem Buch sein, da diese natürlich durchprobiert werden.

----------

## xicm

Ich kann beide Ansätze nicht wirklich unterschreiben, zumindest nicht für sich alleinstehend, unabhängig das die Länge eines Passwortes oder aber der Zeichenpool wichtig, so ist meiner Meinung nach die wichtigste Grösse die Herkunft des Passwortes. Denn bei den Rechnungen wird vergessen das man nicht immer damit Rechnen darf das Zeichen einer Gleichverteilung unterliegen. In diesem Zusammenhang sei mal die Entropie erwähnt.

Nur als Beispiel (Ohne genauen Rechenweg):

Ein Passwort der Länge 12, bei einem Zeichenpool von 26 (Nur Kleinbuchstaben) und Gleichverteilung ergibt effektiv 26^12 = 9.54x10^16 Möglichkeiten.

dagegen:

Password der gleichen Länge und Zeichenpool, aber bei bei denen 5 Zeichen 7, 5, 3, 2, 2 mal öfters vorkommen ( Vokale z.B. damit Passwörter für einem Menschen gut einprägbar sind.) ergeben sich nur noch effektiv 24 Zeichen. 24^12 = 3.65x10^16 effektive Möglichkeiten. Und das schliesst nicht mal die gesamte Vorhersagbarkeit der z.B. deutschen Sprache ein sondern geht nur von merkbaren Passwörtern aus und liegt fern ab von Wörterbuchangriffen. Das schlimme hierbei ist auch, dass sich nicht nur oft vorkommende Zeichen Negativ auswirken sondern auch selten vorkommende (Immer darauf bedacht das die Quelle ein Mensch ist).

Wenn man etwas verschlüsselt sollte man darauf achten das alles was für andere erreichbar ist nicht durch von Menschen erdachter Passwörter direkt verschlüsselt wurde. 

Nur um mein Beispiel vom letzten Artikel zu erwähnen, dort wird das Masterpasswort von Luks mit einer Zufallszeichenkette verschlüsselt, diese Zeichenkette liegt wiederum auf einem externen Medium und ist komplett vom System unabhängig, wird aber dennoch wiederrum durch eine Verschlüsselung geschützt (Wobei hier das Passwort nicht so kritisch ist wie bei einer direkten Verschlüsselung der für andere erreichbaren Daten.). d.H. in einem Fall das jemand die Daten versucht zu entschlüsselt hat er mit einer sehr schlechten Vorhersagbarkeit der Zeichen zu kämpfen, einem sehr grossen Zeichenpool und einer langen Zeichenkette.

Neben Zeichenpool und Passwortlänge sehe ich zumindest die Quelle eines Passwortes als extrem wichtig an. Leider wird das oft sehr vernachlässigt.

----------

## zyko

Letztendlich ist brute force vermutlich keine realistische Schwachstelle bei dm_crypt+Luks, selbst wenn raffinierte Methoden (wie o.g. linguistische Algorithmen) involviert sind. Der limitierende Faktor ist hier schließlich nicht die Fähigkeit des Angreifers, möglichst viele Kombinationen zu generieren. Man muss jeden der Schlüssel auch auf den vorhandenen Datensatz anwenden, wobei durch die Eigenheiten von dm_crypt eine ganz signifikante Verzögerung entsteht. Mag sein, dass man 10^10 Passwörter pro Sekunde generieren kann, aber das übersetzt sich keinesfalls in 10^10 Tests pro Sekunde. 

Afaik gibt es keine empirische Forschung, die eine Schlussfolgerung zur Sicherheit von Passwörtern in einem realistischen Szenario nahelegt.

----------

## mv

 *xicm wrote:*   

> Denn bei den Rechnungen wird vergessen das man nicht immer damit Rechnen darf das Zeichen einer Gleichverteilung unterliegen.

 

Dem stimme ich vollkommen zu. Die Rechnung ist selbstverständlich eine dramatische Vereinfachung eines realistischen Szenarios; sie sollte nur zeigen, dass die merkwürdige Tendenz, Sonderzeichen im Passwort haben zu wollen, statistisch unsinnig ist. Wie ich in einem Halbsatz erwähnte, würde ich aber sogar behaupten, dass sogar gerade bzgl. der Benutzung von Sonderzeichen die Passworte der meisten Menschen noch mehr von der Gleichverteilung abweichen, als ohnehin schon.

 *Quote:*   

> In diesem Zusammenhang sei mal die Entropie erwähnt.

 

Was im Zusammenhang mit der Sprache noch viel gravierender sein dürfte als die Entropie, ist vermutlich die Änderung der relativen Häufigkeit im Abhängigkeit vom vorherigen Kontext (keine drei aufeinanderfolgende Vokale u.a.).

 *Quote:*   

> diese Zeichenkette liegt wiederum auf einem externen Medium und ist komplett vom System unabhängig

 

Ein solches Setting ist aber nicht für alle Systeme praktikabel - sogar für die wenigsten. Im typischen Fall eines Laptops etwa wird das externe Medium physikalisch meistens sehr nahe am Laptop sein, so dass man durchaus damit rechnen muss, beides gestohlen zu bekommen - in dem Fall ist der Schutz nur so gut, wie das Passwort, das man nur im Kopf hat. Ganz abgesehen von anderen technischen Problemen, die dabei auftreten (Ausfall eines USB-Sticks bedeutet kompletten Datenverlust bis zum Ende einer Reise u.ä.).

 *Quote:*   

> Neben Zeichenpool und Passwortlänge sehe ich zumindest die Quelle eines Passwortes als extrem wichtig an.

 

Jein: Wenn die Länge groß genug ist (sagen wir mal: 100 Zeichen oder mehr), bleibt selbst beim Herausrechnen aller Entropie/bedingten Wahrscheinlichkeiten/Wörterbücher noch genügend übrig, dass das Wort praktisch unknackbar ist - von selten dämlichen Passwörtern wie unveränderten Sätzen populärer Bücher mal abgesehen. Wer das Zitat vom Götz nimmt, kann dieses auf sich beziehen   :Laughing:  wobei selbst das vermutlich noch besser sein dürfte als ein einfaches Passwort mit 8 Zeichen, das aber so ein trügerisch sicheres Gefühl vermittelt, wenn man ein "i" durch das Sonderzeichen(!) "!" ersetzt hat...

----------

## xicm

Hmm, ich glaub wir reden uns grad ganz schön OT was den Beitrag angeht.

 *Quote:*   

> Was im Zusammenhang mit der Sprache noch viel gravierender sein dürfte als die Entropie, ist vermutlich die Änderung der relativen Häufigkeit im Abhängigkeit vom vorherigen Kontext (keine drei aufeinanderfolgende Vokale u.a.). 

  Also nicht das ich dich jetzt falsch verstehe aber, genau dieses Beispiel ist doch etwas was durch die Entropie ausgedrückt wird, sie gibt den mittleren Informationsgehalt an. Und das von dir im beschriebene stellt eine statistisch abhängige Situation dar die den Informationsgehalt eines Zeichens verändert.

Was das praktikable angeht, da hast du schon recht nur... ein 100 Zeichen langes Passwort ist auch nicht grad praktikabel... ich hab zumindest schon weit kürzere Sätze vergessen  :Wink:  (Wo wir bei Ausfallsicherheit wären). Und wenn im schlechtesten Fall (Mal vom laufenden System abgesehn.) ausgeht das beides gestohlen wird und man dann immer noch die Sicherheit eines Passwortschutzes vorfindet, dann finde ich schon das man ein Sicherheits-Plus hat, was ja unser anliegen ist.

Ausserdem hat Zyko mit dem was er sagt recht. Geht man mal davon aus das z.B. aufgezeichnet werden, was sogar recht einfach ist (von Funktastaturen mal ganz zu schweigen) so erlischt bei einer direkten Verschlüsselung ab dem Moment der Schutz, bei dem anderen System müsste man immer noch das Medium besorgen. Das kein Schutz perfekt ist muss man sicher nicht erwähnen, aber sofern es praktikabel ist würde ich immer die Lösung mit einem 2. Medium vorziehen zumal es für einen Benutzer im Verhältnis zur Sicherheit wenig Mehraufwand bedeutet.

----------

## mv

 *xicm wrote:*   

> Hmm, ich glaub wir reden uns grad ganz schön OT was den Beitrag angeht.

 

Da stimme ich Dir zu; so mathematisch wollte ich eigentlich gar nicht werden, aber nachdem Du jetzt ausdrücklich nachfragst, muss ich wohl etwas dazu sagen:

 *Quote:*   

>  *Quote:*   Was im Zusammenhang mit der Sprache noch viel gravierender sein dürfte als die Entropie, ist vermutlich die Änderung der relativen Häufigkeit im Abhängigkeit vom vorherigen Kontext (keine drei aufeinanderfolgende Vokale u.a.).   Also nicht das ich dich jetzt falsch verstehe aber, genau dieses Beispiel ist doch etwas was durch die Entropie ausgedrückt wird, sie gibt den mittleren Informationsgehalt an. Und das von dir im beschriebene stellt eine statistisch abhängige Situation dar die den Informationsgehalt eines Zeichens verändert.

  Der mathematische (informationstheoretische) Begriff "Entropie" (auf den ich mich hier bezog) ist relativ eng spezifiziert: Er berücksichtigt, grob gesprochen, nur die Häufigkeit von Zeichen (ein häufiges Zeichen hat weniger Informationsgehalt als ein seltenes), nicht aber den "Ort" eines Zeichens; er ist also quasi "statisch" definiert, nicht kontextabhängig. Mit Huffman-encoding kann man die Redundanz aufgrund dieser Entropie-Definition weitestgehend "herausfiltern"; dass Huffman-encoding bei der Kompression typischer Texte i.d.R. um ein Vielfaches schlechter ist, als andere Kompressionsmethoden, zeigt, dass die Entropie nur einen geringfügigen Teil der tatsächlichen Redundanz ausmacht.

----------

## Deadman44

 *ScytheMan wrote:*   

> 
> 
> Dir ist aber schon bewusst, dass auf einer englischen Tastatur das Y an Z Stelle sitzt und Z an Y Stelle?

 

Verdammt -.-. Ja ein Z kommt in meinem Passwort vor. Aber egal, ich bin jetzt vorerst mal ein unverschlüsseltes System am aufbauen. Werde später alles in einer VM testen und wenn ich es dann wirklich stabil umsetzen kann, dann wird auch mein root System verschlüsselt. Kann man dann vielleicht per dd später sein unverschlüsseltes System auf die verschlüsselte Partition übertragen?

lg der tote Mann

----------

## firefly

 *Deadman44 wrote:*   

>  *ScytheMan wrote:*   
> 
> Dir ist aber schon bewusst, dass auf einer englischen Tastatur das Y an Z Stelle sitzt und Z an Y Stelle? 
> 
> Verdammt -.-. Ja ein Z kommt in meinem Passwort vor. Aber egal, ich bin jetzt vorerst mal ein unverschlüsseltes System am aufbauen. Werde später alles in einer VM testen und wenn ich es dann wirklich stabil umsetzen kann, dann wird auch mein root System verschlüsselt. Kann man dann vielleicht per dd später sein unverschlüsseltes System auf die verschlüsselte Partition übertragen?
> ...

 

nicht per dd. Du kannst aber das unverschlüsselte system via cp oder rsync auf die verschlüsselte(n) Partition(en) kopieren.

----------

