(gelöst) truecrypt, container löschen

[guennid]

Ich experimentiere mit truecrypt. Ich finde keine Information, wie man einen damit eingerichteten einfachen Conainer wieder löscht. Ich denke ja, dass ein Löschen der Datei genügen sollte, würde aber gerne sicher gehen. Um Missverständnisse zu vermeiden: Es geht nicht um das Deinstallieren von truecrypt, nur darum, einen testweise erzeugten Container wieder loszuwerden.

Grüße, Günther

[DeletedUserReAsG]

Wenn der Container ’ne Datei ist, diese löschen. Vorher ggf. das Filesystem aushängen, falls eingehängt. Kann sonst seltsame Effekte geben.

OT: warum Truecrypt (welches ja nun nicht mehr weiterentwickelt wird, was bei Sicherheitskram nicht optimal ist), statt dm_crypt/LUKS?

[guennid]

Wenn der Container ’ne Datei ist, diese löschen. Vorher ggf. das Filesystem aushängen, falls eingehängt.

Danke!! Ich hatte es ja gehofft, aber ich vertraue niemand .

OT
Reine Gewohnheit, du weißt, ich alter Sack verlasse ungern eingetretene Pfade.
Darüber hinaus zwei Dinge:
1. Nach Allem, was ich im Laufe der Jahre darüber gelesen habe, wurde das Teil nie geknackt, woraus ich mal dickköpfig schließe, dass es besonders sicher ist.
2. Sportlicher Ehrgeiz, es reizt mich herauszubekommen, wie ich das Teil ohne sudo und ohne udev ans Laufen kriege.

Wenn ich's weiß, beschäftige ich mich vielleicht mal mit dm-crypt. Dass truecrypt tot ist, ist halt schon ein Argument.

[Lord_Carlos]

Gibt auch noch VeraCrypt, welches auf TrueCrypt bassiert.

Ich wuerde Vera/TrueCrypt nur benutzten wenn man auch von Windows die Kontainer oeffnen will.
dm-crypt ist top und auch relativ einfach. Wenn man erstmal alles eingerichtet hat muss man sich ja nur den Befehl zum oeffnen und schliessen merken, und der steht normal auch in der Bashhistory.

[guennid]

dm-crypt ist top und auch relativ einfach.

Mag sein. Ich habe gerade mal ein wenig rumgestöbert und muss sagen, die mir dabei über den Weg gelaufenen Anleitungen sind es nicht. Das alte Lied: Fachwissen haben und Fachwissen laienverständlich erklären sind zwei paar Schuh. Aber was nicht ist, kann ja noch werden.

Eins nach dem anderen.

Ich werde keine Partitionen oder ganze Platten verschlüsseln. Ich will nur eine verschlüsselte Containerdatei, sonst nichts.

Grüße, Günther

[TomL]

Das alte Lied: Fachwissen haben und Fachwissen laienverständlich erklären sind zwei paar Schuh.

Das ist das alte Problem, über das ich auch oft stolpere und schließlich ratlos zurückbleibe.....

[DeletedUserReAsG]

Ich habe gerade mal ein wenig rumgestöbert und muss sagen, die mir dabei über den Weg gelaufenen Anleitungen sind es nicht.

Code: Alles auswählen

$ dd if=/dev/zero of=cont.img bs=1M count=50
50+0 Datensätze ein
50+0 Datensätze aus
52428800 bytes (52 MB, 50 MiB) copied, 0,0944611 s, 555 MB/s
$ su
Passwort: 
# cryptsetup luksFormat cont.img 

WARNING!
========
Hiermit werden die Daten auf »cont.img« unwiderruflich überschrieben.

Are you sure? (Type uppercase yes): YES
Passphrase eingeben: 
Passphrase bestätigen: 
# cryptsetup luksOpen cont.img container
Geben Sie die Passphrase für »cont.img« ein: 
# mkfs.ext4 /dev/mapper/container 
mke2fs 1.43.7 (16-Oct-2017)
Ein Dateisystem mit 49152 (1k) Blöcken und 12288 Inodes wird erzeugt.
UUID des Dateisystems: 0bce47b0-a8ea-49e9-9e05-cb96cb482dc9
Superblock-Sicherungskopien gespeichert in den Blöcken: 
        8193, 24577, 40961

beim Anfordern von Speicher für die Gruppentabellen: erledigt                        
Inode-Tabellen werden geschrieben: erledigt                        
Das Journal (4096 Blöcke) wird angelegt: erledigt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden
geschrieben: erledigt

# mount /dev/mapper/container /mnt/
# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop0         7:0    0    50M  0 loop  
└─container 254:0    0    48M  0 crypt /mnt
[…]

# umount /mnt 
# cryptsetup remove container
# rm  cont.img

… ist tatsächlich nicht soo schwierig. Wenn man’s allerdings ohne UID0 machen will, wird’s komplex. Das ist nicht vorgesehen.

[guennid]

UID0

?

[guennid]

Ach so! Das letzte Zeichen ist eine Null!

[TomL]

Günther, mir fehlt in Deinem Beispiel das eindeutige Cryptsetup und der Luks-Format.... mit anderen Worten, ich habe keine Ahnung, was da default passiert und ob da eine "gute" Verschlüsselung gewählt wurde. Aber ich bin mir ziemlich sicher, dass Du das gerne bewusst vorgeben möchtest.

[guennid]

Der Code stammt von niemand. Gespeichert ist er hier, aber wie ich schon sagte, erst mal experimentiere ich mit truecrypt.

[DeletedUserReAsG]

Wenn du vom Default abweichende Algos haben willst, kannst du das natürlich mitgeben. Ich selbst gehe mal davon aus, dass die Defaults passend gewählt sind. Zu beachten wäre: wenn man sich nicht damit auskennt, kann man auch schnell mal die Verschlüsselung schwächen, wenn man irgendwo gefundene (in uralten Tutorials oder Blogs, z.B.) Optionen mitgibt.

[TomL]

Ich selbst gehe mal davon aus, dass die Defaults passend gewählt sind.

Ja, das wird wohl üblicherweise so stimmen. Nur hier in diesem Fall habe ich das anders verstanden.... und zwar, weil XTS den Schlüssel halbiert, kann bei der Verschlüsselung mit einer Keysize von 256 letztendlich AES128 rauskommen, wenn man eigentlich AES256 erwartet. Insofern würde ich lieber Cipher und Keysize direkt vorgeben, um sicher zu sein, dass auch wirklich AES256 verwendet wird.

@Günther, ich schließe mich einigen Meinungen hier an.... ich selber würde truecrypt heute nicht mehr verwenden. Soweit ich mich erinnere, haben sich damals die Entwickler aufgrund einer äußeren Einwirkung zum künftigen Truecrypt-Weg aus dem Project zurückgezogen. Einer der Entwickler muss sich damals zu der Frage, ob Truecrypt sicher ist, so ähnlich geäußert haben "Bis zur letzten Version war es das." Das wurde als unausgesprochener Hinweis gedeutet, dass es in der künftigen Version nicht mehr sicher ist. Da gab es dann zuhauf Backdoor-Gerüchte. Und auch wenn heute Audits das Gegenteil behaupten, ich hätte kein Vertrauen mehr in truecrypt und würde unbedingt auf LUKS setzen.

[guennid]

"Bis zur letzten Version war es das." Das wurde als unausgesprochener Hinweis gedeutet, dass es in der künftigen Version nicht mehr sicher ist.

Soweit ich erinnere, gingen die Spekulationen über die Gründe der Einstellung des Projektes dahin, dass es eben wegen wegen der "äußeren Einwirkungen" eingestellt wurde. Die letzte Version VOR den vermuteten oder tatsächlichen "Einwirkungen" war 7.1a. Die habe ich hier. Aber das ist alles sehr spekulativ und ich würde auf die Sicherheit von truecrypt nicht wetten wollen.

Aber ok, machen wir weiter, obwohl die eigentliche Frage von niemand beantwortet wurde:
Ich hänge zur Zeit an /dev/mapper/truecrypt. Ich kann den container (als root) offenbar anlegen, aber es endet damit, dass er meldet:

Code: Alles auswählen

Error: Datei oder Verzeichnis nicht gefunden:
/dev/mapper/truecrypt1

Die Containerdatei (volume im truecrypt-Sprech) ist in etwa der der gewählten Größe und am gewählten Ort vorhanden.

Ich vermute, hier kommt das fehlende udev ins Spiel.

[DeletedUserReAsG]

Nein, udev hat damit nichts zu tun. Es wäre hilfreich zu wissen, wobei genau diese Meldung kommt, und was du bis dahin getan hast.

[guennid]

Es wäre hilfreich zu wissen, wobei genau diese Meldung kommt, und was du bis dahin getan hast.

Kommt, aber später. Ich muss jetzt raus Schnee schippen, bevor es dunkel wird.

[guennid]

Also erstmal. Es gibt kein Debian-Paket, ich habe also mittels truecrypt-eigenem shellscript installiert.
Der Kernel 4.9 ist selbstkompiliert (Debian-Kernel-Image läuft nicht ohne udev)
Der Versuch, das volume zu erstellen, lief nur nur auf echter Konsole.
loop ist fest im Kern, dm_crypt und dm_mod laufen als Module.
Kommando zum Erstellen des Volumes:

Code: Alles auswählen

# truecrypt -c /pad/zum/Volume

Ich konnte nicht alles aufschreiben, da die Meldungen sukzessiv vom Bildschirm verschwanden und ich keine Möglichkeit kenne, hier ein interaktives Kommando aufzuzeichnen. Hier der Rest: pastebin/?mode=view&s=40087

Das volume ist vorhanden.

[DeletedUserReAsG]

Hmm … gut, ist ‘n Truecrypt-Problem. Möglicherweise fehlen bei deinem Kernel Module – ich weiß nicht, was es braucht, ich nutze, wie angedeutet, dm_crypt/LUKS.

Ich konnte nicht alles aufschreiben, da die Meldungen sukzessiv vom Bildschirm verschwanden und ich keine Möglichkeit kenne, hier ein interaktives Kommando aufzuzeichnen

script aus bsdutils

[guennid]

Ich habe zwischenzeitlich cryptsetup installiert und komme mit deiner Anleitung klar. Danke!

Mach ich's halt damit. Ist ja auch besser im Sinne, möglichst nichts am Paketsystem vorbei.

Grüße, Günther

[ottonormal]

Hallo,

ich nutze schon seit "ewigen" Zeiten TrueCrypt 7.1a und hatte noch nie Probleme damit. Auf meinem Arbeitsrechner habe ich 3 mit TrueCrypt verschlüsselte Datenpartitionen, zusätzlich ein paar kleinere Container und ein TrueCrypt-verschlüsseltes Windows-7.
Die Datenpartitionen werden beim Starten von Debian automatisch entschlüsselt und eingehängt. Die Container werden bei Bedarf einfach per Doppelklick und Passworteingabe geöffnet.
Nach allem was ich über TrueCrypt gelesen habe, halte ich das für sicherer als das neuere VeraCrypt. Es ist doch irgendwie seltsam, TrueCrypt wurde mit sehr dubiosen Begründungen eingestellt und der Nachfolger wird ohne weitere Probleme in Umlauf gebracht und weiterentwickelt? Ich nehme eher an, dass TrueCrypt einfach ZU sicher ist/war.
So lange jedenfalls wie es funktioniert, bleibe ich dabei.

[guennid]

Ich nutze (gelegentlich) ebenfalls truecrypt seit "ewigen Zeiten". Und vielleicht hast du dann ja eine Idee, was bei diesem Eigenbau-Kern 4.9. fehlen könnte - wenn's denn an diesem Kern liegt, wie niemand vermutet (ich habe nach wie vor eher udev im Verdacht):

Code: Alles auswählen

$ lsmod
Module                  Size  Used by
nfsd                  174429  2
auth_rpcgss            30819  1 nfsd
oid_registry            1891  1 auth_rpcgss
fuse                   60607  0
snd_intel8x0           20571  0
snd_ac97_codec         77904  1 snd_intel8x0
ac97_bus                1070  1 snd_ac97_codec
snd_pcm                55215  2 snd_ac97_codec,snd_intel8x0
snd_timer              13253  1 snd_pcm
acpi_cpufreq            5986  1
processor              21881  2 acpi_cpufreq
thermal                 7003  0
ehci_pci                2959  0
uhci_hcd               16100  0
ehci_hcd               31755  1 ehci_pci
thinkpad_acpi          49636  0
nvram                   4062  1 thinkpad_acpi
snd                    32646  5 snd_ac97_codec,snd_timer,thinkpad_acpi,snd_intel8x0,snd_pcm
soundcore                756  1 snd
cfg80211              177746  0
rfkill                  7242  2 thinkpad_acpi,cfg80211
e100                   21843  0
mii                     2995  1 e100
pcspkr                  1395  0
yenta_socket           16104  0
pcmcia_rsrc             5768  1 yenta_socket
pcmcia                 24691  0
pcmcia_core             8663  3 yenta_socket,pcmcia,pcmcia_rsrc
nfsv4                  98864  0
nfs                    90442  1 nfsv4
lockd                  42689  2 nfsd,nfs
grace                   1235  2 nfsd,lockd
sunrpc                131548  6 auth_rpcgss,nfsd,nfsv4,lockd,nfs
dm_crypt               13206  0
dm_mod                 66389  1 dm_crypt

loop ist statisch einkompiliert.

Grüße, Günther

[hikaru]

Also erstmal. Es gibt kein Debian-Paket, ich habe also mittels truecrypt-eigenem shellscript installiert.

Seit Stretch gibt es zulumount-cli, mit dem sich Truecrypt-Container mounten lassen. Soweit ich es sagen kann, funktioniert das problemlos. Es gibt auch zulumount-gui aber das habe ich als zickig in Erinnerung.

Ein Feature von Truecrypt und Abkömmlingen, das ich bei Alternativen bisher vermisse sind dynamisch wachsende Container. Wenn man auf einem Datenträger mit begrenztem Speicherplatz neben anderen Daten einen Container unterbringen will von dem man aber nicht weiß wie groß der mal sein muss, dann ist dynamisches Wachstum (und mit etwas Handarbeit Schrumpfen) eine nette Sache.

[ottonormal]

Ein Feature von Truecrypt und Abkömmlingen, das ich bei Alternativen bisher vermisse sind dynamisch wachsende Container.

Ich denke, dass das auch so gewollt ist. Könnte es sonst nicht sein, dass in manchen Fällen evtl. von der Größe dynamisch wachsender Container auf den Inhalt geschlossen werden kann?