Schönen guten Tag Freunde der Elektronik! Um meine 8 Tb (ca. 7450 Gb) Platte zu verschlüsseln unter Linux mit LUKS, habe ich deren Inhalt auf 3 kleinere, verschlüsselte Platten kopiert. Die 3 Kleinen weisen ganz korrekt insgesamt 7332 Gb auf, auf der 8 Tb Platte waren nur noch gut 100 Gb frei. Diese konnte ich nun neu formatieren und verschlüsseln. Dann die 3 kleinen Platten rüberkopiert auf die 8er. Allerdings war diese schon bei etwa 6900 Gb voll, es fehlen etwa gut 500 Gb Speicherplatz!Benötigt die Verschlüsselung Speicher, etwa etwa 7 %, was mir neu wäre? Auch Google schweigt sich darüber aus. Beste Grüße Uwe
Scotty60 schrieb: > Benötigt die Verschlüsselung Speicher, > etwa etwa 7 %, Nein. Hast du vielleicht ein anders Dateisystem oder andere mount-flags verwendet?
Wenn es sich um eine ext* FS Variante handelt und Du die Dateien als User schreibst fehlen Dir ggf. der root reserved space von 5% --> tune2fs -l /dev/sda1 | grep 'Reserved block count'
ich hatte das gleiche "Problem": Beitrag "Linux EXT-4 (3,2): 5% für root" PS: Wie lange dauert es so eine riesige Festplatte zu verschlüsseln | Container anzulegen?
Also da fallen mir spontan und unabhängig vom OS nur 2 Gründe ein. 1.) Die Blockgröße Bei Windows z.b. nennt der Formatbefehl das "Größe der Zuordnungseinheiten". Parameter a:512 z.b. Diese Größe würde ich mal vergleichen. 2.) Der Grundsätzliche Platz für die Verwaltung. Sehr stark abhängig von Pkt. 1.
Hallo Uwe,
der Verlust an freiem Speicherplatz wird verursacht durch den Wasserkopf
der Dateisysteme.
Die LUKS-Verschlüsselung erhöht den Speicherbedarf für Deine Daten
nicht.
Allerdings benötigt der zusätzlich erforderlich LUKS-Header mit seinen
Keyslots benötigt aufgrund der Verteilung der Schlüsselinformation auf
mehrere anti-forensische Streifen ("stripes") Speicherbedarf in der
Größenordnung von geschätzt ein paar MBytes.
Hallo Rudolph,
ich kenne die Details von LUKS nicht. Wenn der Prozessor schnell genug
ist, dann erhältst Du die benötigte Zeit durch Division des
Festplattenspeicherplatzes durch die Geschwindigkeit der Festplatte.
Mit Geschwindigkeit ist hier die nachhaltige Dauerübertragungsrate
gemeint, nicht die "Burst"-Geschwindigkeit.
:
Bearbeitet durch User
Hallo Rudolph! Von einer Verlangsamung durch Verschlüsselung habe ich nichts gemerkt. Mit und ohne Verschlüsselung lag die Übertragungsrate bei 100 Mb/s. Danke für den Tipp! Mit den 5% und Root schaue ich mir mal an, besonders wie man die 5 % freigibt! Quelle und Ziel waren immer ext4 Partitionen. Gruß Uwe
Verschlüsselte 30 GB eMMC mit LUKS/ext4: Disk-Partition: 58519552 Blöcke df -B512: 55351176 Blöcke, 56% belegt Ergibt 95% nutzbare Kapazität Unverschlüsselte 60 GB Mikro-SD mit ext4: Disk-Partition: 125040640 Blöcke df -B512: 122553992 Blöcke, 52% belegt Ergibt 98% nutzbare Kapazität
:
Bearbeitet durch User
Hallo schlaumeier, inhaltlich hast Du ausnahmsweise mal Recht. Der Verschnitt beträgt bei Gleichverteilung der Dateilängen im Durchschnitt einen halben Cluster. Die obigen 6% Verschnitt würden sich ergeben, wenn alle Dateien nicht mehr als 10 Cluster hätten. Das ist sehr unwahrscheinlich. Musik, Videos und Software brauchen ein Vielfaches davon. Tendenziell gehen aber klinere Partitionen mit kleineren Clustern einher. Der Verschnitt fällt also typischerweise.
Scotty60 schrieb: > Von einer Verlangsamung durch Verschlüsselung habe ich nichts gemerkt. Hängt auch vom Prozessor ab, d.h. ob er die AES Befehle kennt: > grep aes /proc/cpuinfo Im unteren Segment von Intels Mainstream-Prozessoren, z.B. den Pentiums, fehlt AES oft. Die Atoms unterstützen es jedoch. Während der Prozessor auch ohne AES oft in der Lage ist, den Durchsatz einer HDD mehr oder minder zu erreichen, sollte man bei einer SSD nicht damit rechnen.
:
Bearbeitet durch User
A. Klaasen schrieb: > --> tune2fs -l /dev/sda1 | grep 'Reserved block count' hallo A.Klaasen! Der sudo tune2fs -m0 /dev/sdc1 Befehl ergibt eine Fehlermeldung, die ich nicht verstehe: tune2fs: Bad magic number in super-block while trying to open /dev/sdc1 /dev/sdc1 contains a crypto_LUKS file system Gruß Uwe
Peter M. schrieb: > Tendenziell gehen aber klinere Partitionen mit kleineren Clustern > einher. JA. Dabei gibt es nur ein Problem. Hast du viele kleine Dateien so lohnen sich auch kleinere Cluster. Der Nachteil ist, das die Verwaltung immer schlimmer wird, was bedeutet du hast wie oben schon erwähnt ein "Wasserkopf an Verwaltung". Hast du größere Cluster ist der "Wasserkopf" nicht ganz so dick. Wenn man sich nicht explizit darum kümmert, legt das Formatier-System diese Clustergröße im Verhältnis zur Größe der Festplatte fest. Weshalb ich halt zu den Gedanken kam, das durch die kleiner Festplatte die Clustergröße sich geändert hat. Man darf dabei nicht vergessen, das ein Cluster nur von EINER Datei verwendet werden darf. Einfach gesagt : Bei z.b. einer Clustergröße von 32 KB kann eine 10 Bytes Datei mal eben 32 KB Festplattenplatz fressen. Ich habe mal vor eine kleinen Ewigkeit bei einer 170 MB ESDI-Platte den Cluster von 8 k auf 2 K geändert und hatte da da nur kleine JPG-Bilder drauf waren, 30 % mehr Speicherplatz. ;)
Scotty60 schrieb: > Der sudo tune2fs -m0 /dev/sdc1 Befehl ergibt eine Fehlermeldung, die ich > nicht verstehe: > > tune2fs: Bad magic number in super-block while trying to open /dev/sdc1 > /dev/sdc1 contains a crypto_LUKS file system Was gibt es daran nicht zu verstehen? Du versuchst, den einhüllenden Crypto-Container zu tunen. Du musst aber das Filesystem IM Container tunen.
Hallo A. Klaasen! Was mir generell komisch vorkam beim Anlegen der Verschlüsselung mit LUKS: Vorher hatte ich ich die Platte als ext4 formatiert. Nach Luks Verschlüsselung war das FS weg, d.h. beim Einbinden nach Eingabe der Passpgrase verschwand die Platte aus der Dateiverwaltung Thunar. Erst eine erneute Formatierung mit ext4 ließ sie sichtbar werden. Mache ich da was falsch? Gruß Uwe
Peter M. schrieb: > Tendenziell gehen aber klinere Partitionen mit kleineren Clustern > einher. Das hängt vom Filesystem ab, so trifft das beispielsweise auf FAT-Varianten zu. Für normale Linux-Filesysteme wie ext4 ist das aber untypisch, ebenso für Standard-NTFS. Noch eine verschlüsselte Disk, diesmal 7,3 TiB LUKS/ext4: Disk-Partition: 15628048384 Blöcke df -B512: 15502725976 Blöcke Ergibt 99% nutzbare Kapazität Da ext4 selbst nicht verschlüsselt und auf ein Blockdevice fester Grösse aufsetzt, kann der Overhead durch LUKS nicht von der aktuellen Belegung des Filesystems abhängig sein.
:
Bearbeitet durch User
Rudolph schrieb: > PS: Wie lange dauert es so eine riesige Festplatte zu verschlüsseln | > Container anzulegen? Das verschlüsseln dauert gar nicht, weil zu dem Zeitpunkt des Anlegens gar nichts verschlüsselt wird. Es wird ein Blockdevice angelegt, das zwischen den Schichten "physisches Blockdevice" (oder Partitions Blockdevice was nochmal eine Schicht wäre), und "Dateisystem" sitzt, und beim Schreiben/Lesen durch diese Schichten hindurch die Ver- und Entschlüsselung leistet. Die Verschlüsselung der Daten findet also erst statt wenn sie auf die Verschlüsselte Platte kopiert werden - und da heutige CPU's (z.b. dank AES-NI) deutlich schneller verschlüsseln als Platten Schreiben, macht sich das auch nicht zeitlich bemerkbar - es entsteht nur eine etwas höhere Systemlast. Bei m.2 PCIe SSDs sieht das allerdings schon wieder anders aus, da liegt die Schreibleistung (bei mir) nur bei ~1000MB/s anstatt ~3000MB/s. Siehe:
1 | # cryptsetup benchmark |
2 | # Die Tests sind nur annähernd genau, da sie nicht auf den Datenträger zugreifen. |
3 | PBKDF2-sha1 2162012 Iterationen pro Sekunde für 256-Bit-Schlüssel |
4 | PBKDF2-sha256 3792318 Iterationen pro Sekunde für 256-Bit-Schlüssel |
5 | PBKDF2-sha512 1413175 Iterationen pro Sekunde für 256-Bit-Schlüssel |
6 | PBKDF2-ripemd160 815377 Iterationen pro Sekunde für 256-Bit-Schlüssel |
7 | PBKDF2-whirlpool 611771 Iterationen pro Sekunde für 256-Bit-Schlüssel |
8 | argon2i 5 Iterationen, 1048576 Speicher, 4 parallele Threads (CPUs) für 256-Bit-Schlüssel (Zieldauer 2000 Millisekunden) |
9 | argon2id 5 Iterationen, 1048576 Speicher, 4 parallele Threads (CPUs) für 256-Bit-Schlüssel (Zieldauer 2000 Millisekunden) |
10 | # Algorithmus | Schlüssel | Verschlüsselung | Entschlüsselung |
11 | aes-cbc 128b 1078,4 MiB/s 3133,3 MiB/s |
12 | serpent-cbc 128b 95,9 MiB/s 372,7 MiB/s |
13 | twofish-cbc 128b 187,5 MiB/s 374,8 MiB/s |
14 | aes-cbc 256b 843,6 MiB/s 2845,3 MiB/s |
15 | serpent-cbc 256b 98,3 MiB/s 368,8 MiB/s |
16 | twofish-cbc 256b 191,0 MiB/s 368,3 MiB/s |
17 | aes-xts 256b 1635,4 MiB/s 1634,5 MiB/s |
18 | serpent-xts 256b 363,1 MiB/s 357,3 MiB/s |
19 | twofish-xts 256b 370,5 MiB/s 367,2 MiB/s |
20 | aes-xts 512b 1453,9 MiB/s 1458,4 MiB/s |
21 | serpent-xts 512b 364,1 MiB/s 362,8 MiB/s |
22 | twofish-xts 512b 375,2 MiB/s 370,0 MiB/s |
ALLERDINGS... seufz... Wenn die zu verschlüsselnde Platte schon mal unverschlüsselte Daten gesehen hat, wäre es schlau sie vorm verschlüsseln einmal mit Datenmüll voll zu schreiben. Das dauert dann, je nach Anbindung (USB2/3/3.x SATA) gerne mal einen Tag (afair 16h bei mir das letzte Mal). Das Tool der Wahl wäre dabei
1 | # shred -fvn1 /dev/<DEVICE> |
Zurück zum TO - Das Problem dürften, und das wurde ja auch schon geschrieben, die standardmäßig reaservierten 5% Plattenplatz sein. Bekommt man mit "tune2fs -m0 /dev/<DEVICE>" nach dem formatieren weg, zumindest bei ext4. Schön das ich auch nochmal hier hin geschrieben habe ^^ Vielleicht noch etwas anderes. Da verschlüsselte Datenträger vor Eingabe des Schlüssels keinen Zugriff aufs Dateisystem zulassen, können z.b. Dateimanager nicht das Disklabel auslesen und man sieht immer nur sowas wie "8TB verschlüsselter Datenträger" - ärgerlich wenn man >1 im System hat, oder externe verschlüsselte Disks anstöpselt. Abhilfe schafft da eine UDEV Regel die z.b. der Seriennummer einer Platte einen Namen zuweist.
1 | # cat /etc/udev/rules.d/99-encryped.drives.rules |
2 | KERNEL=="sd*", ENV{ID_FS_UUID}=="ffffffff-ffff-ffff-ffff-fffffffffff1", ENV{ID_FS_LABEL}="OPEN Daten-Backup", ENV{ID_FS_LABEL_ENC}="Encrypted Daten-Backup"
|
3 | KERNEL=="sd*", ENV{ID_FS_UUID}=="ffffffff-ffff-ffff-ffff-fffffffffff0", ENV{ID_FS_LABEL}="OPEN Daten", ENV{ID_FS_LABEL_ENC}="Encrypted Daten"
|
Die UUIDs bekommt man über "lsblk" heraus.
Christobal M. schrieb: > # cryptsetup benchmark Intel N3350: aes-cbc 128b 401,4 MiB/s 792,7 MiB/s AMD N36L: aes-cbc 128b 76.0 MiB/s 85.0 MiB/s Der Intel-Atom hat also keine Probleme mit dem Durchsatz seiner eMMC, aber der AMD-Fileserver erreicht mangels AES-Unterstützung der CPU nicht den potentiellen Durchsatz der 8 TB Disk.
Christobal M. schrieb: > Das verschlüsseln dauert gar nicht Ach so, dann ist da die Idee anders als bei Containern unter Truecrypt | Veracrypt. Ich wollte mit Veracrypt mal einen 3TB großen Container auf einer USB-Festplatte anlegen und die Fortschrittsanzeige zeigte mir irgendwas mit XY-Stunden. Einen Tag warten warten, wollte ich dann doch nicht ;-) Und so geheim sind meine Daten nun wirklich nicht.
Sicher ist sicher. Bei LUKS kann man zwar darauf verzichten, den alten Inhalt zu plätten. Auf die Funktion als verschlüsseltem Filesystem hat das keinen Einfluss. Aber jemand, der direkt auf die Disk zugreift, kann dann den vorherigen Inhalt rausfischen, sofern noch nicht überschrieben. LUKS geht als typisches Linux Baukastensystem davon aus, dass der Anwender entsprechend der eigenen Anforderungen ein bestimmtes Prozedere entsprechend der Anleitungen einhält. Veracypt hingegen verlässt sich darauf lieber nicht.
:
Bearbeitet durch User
Rudolph schrieb: > Ich wollte mit Veracrypt mal einen 3TB großen Container auf einer > USB-Festplatte anlegen und die Fortschrittsanzeige zeigte mir irgendwas > mit XY-Stunden. Einen Tag warten warten, wollte ich dann doch nicht ;-) > > Und so geheim sind meine Daten nun wirklich nicht. Ich wage mal zu bezweifeln das du 3 TB an reinen Daten hast. Also gibt es ein Lösung. Du legst ein Container NUR für deine DATEN = Geistige Ergüsse an, und den Rest ganz normal auf die Platte. Diese Technik wird bei jeden Baumarkt-PC angewandt der 2 Laufwerke hat. Bloß logoweis ohne Verschlüsselung.
Hallo Rudolph! Die Daten müssen nicht geheim sein! Aber schon Mails können ausreichen, wenn du als Regimegner eine Hausdurchsuchung hast. Da werden aus diesen Mails und gefundenen Wordpress-Beiträgen schnell 400 Seiten Anklageschriften, so erlebt bei einem Freund. Gruß Uwe
Schlaumaier schrieb: > Ich habe mal vor eine kleinen Ewigkeit bei einer 170 MB ESDI-Platte den > Cluster von 8 k auf 2 K geändert und hatte da da nur kleine JPG-Bilder > drauf waren, 30 % mehr Speicherplatz. ;) Einige Filesysteme sind in der Lage, sehr kleine Files in des Inodes selbst unterzubringen (z.B. neuere ext4). Oder sie können den ungenutzten Rest von Clustern anderweitig nutzen: https://en.wikipedia.org/wiki/Block_suballocation
:
Bearbeitet durch User
(prx) A. K. schrieb: > Einige Filesysteme sind in der Lage, sehr kleine Files in des Inodes > selbst unterzubringen (z.B. neuere ext4). Oder sie können den > ungenutzten Rest von Clustern anderweitig nutzen: Ui. Wusste ich nicht. Hier lernst Mann (ich) sogar was dazu. Danke für die Info. Leider 25 Jahre zu spät. Heutzutage wo ich 6 TB für < 100 Euro bekomme, kommt diese Technik aber leider m.M.n. viel zu spät.
Schlaumaier schrieb: > kommt diese Technik aber leider m.M.n. viel zu spät. Ganz so neu ist die Suballocation von Clustern nicht. So wird das beispielsweise schon von ReiserFS (2001) und dem BSD FFS unterstützt. https://en.wikipedia.org/wiki/Comparison_of_file_systems#Allocation_and_layout_policies
:
Bearbeitet durch User
(prx) A. K. schrieb: > Ganz so neu ist die Suballocation von Clustern nicht. So wird das > beispielsweise schon von ReiserFS (2001) und dem BSD FFS unterstützt. OK. ich oute mich mal. Ich bin Windows-verseucht. SORRY.
Weil es noch nicht genannt wurde: Sparse-Dateien. Die meisten Linux-Dateisysteme unterstützen die, wenn aber beim Kopieren die Lücken nicht extra behandelt werden[1], passen die Daten auf einmal nicht mehr auf das Ziel-System. S. https://de.wikipedia.org/wiki/Sparse-Datei#Probleme_bei_der_Verwendung [1] War früher ein echtes Problem, da kein Kopierprogramm die unterstützt hatte. Insb Backups flogen regelmäßig auf die Schnauze, weil irgendein Scherzbold ne riesen Sparse-Datei in seinem Home-Verzeichnis angelegt hat. Gnu-cp kennt das inzw, ich empfinde die aber immer noch als Misfeature.
Schlaumaier schrieb: >> Ganz so neu ist die Suballocation von Clustern nicht. So wird das >> beispielsweise schon von ReiserFS (2001) und dem BSD FFS unterstützt. > > OK. ich oute mich mal. Ich bin Windows-verseucht. SORRY. NTFS: "[...], it is possible for an NTFS volume to contain more files on a volume than there are clusters. For example, a 74.5 GB partition NTFS formats with 19,543,064 clusters of 4 KB. Subtracting system files (a 64 MB log file, a 2,442,888-byte Bitmap file, and about 25 clusters of fixed overhead) leaves 19,526,158 clusters free for files and indices. Since there are four MFT records per cluster, this volume theoretically could hold almost 4 × 19,526,158= 78,104,632 resident files." Frag mich aber nicht ob schon immer oder ob reine Theorie. https://en.wikipedia.org/wiki/NTFS
:
Bearbeitet durch User
Hallo A. K., (prx) A. K. schrieb: > NTFS: "[...], it is possible for an NTFS volume to contain more files on > a volume than there are clusters. For example, a 74.5 GB partition NTFS > formats with 19,543,064 clusters of 4 KB. Subtracting system files (a 64 > MB log file, a 2,442,888-byte Bitmap file, and about 25 clusters of > fixed overhead) leaves 19,526,158 clusters free for files and indices. > Since there are four MFT records per cluster, this volume theoretically > could hold almost 4 × 19,526,158= 78,104,632 resident files." > > Frag mich aber nicht ob schon immer oder ob reine Theorie. > https://en.wikipedia.org/wiki/NTFS Ja, "schon immer" und nicht nur "reine Theorie". Das Verhalten ist aber meines Erachtens bedeutungslos. Bei einer typischen Clustergröße unter NTFS von 4096 passen 4 MFT-Einträge in einen Cluster. Bei einer Größe von weniger als 1024 abzüglich statischer Verwaltungsinformationen zu Beginn des MFT-Eintrags passen kleine Dateien in die MFT. Das ist nett für die Konfigurationsdateien eines Betriebssystem oder kleine Quellcode-Dateien. Typischerweise entfällt der größte Teil des Speichervolumens auf Fotos, Videos, Musik und Software. Da kommt der Vorteil gar nicht zum Tragen.
Hallo Schlaumeier, Schlaumaier schrieb: > Hast du viele kleine Dateien so lohnen sich auch kleinere Cluster. Der > Nachteil ist, das die Verwaltung immer schlimmer wird, was bedeutet du > hast wie oben schon erwähnt ein "Wasserkopf an Verwaltung". > > Hast du größere Cluster ist der "Wasserkopf" nicht ganz so dick. Nein, das gilt nicht pauschal. Das trifft nur auf FAT-artige Dateisystem zu, wo eine Halbierung der Clustergröße zu einer Verdoppelung der FAT-Länge führt. Unter NTFS werden die Cluster einer Datei als Liste von Elementen der Form (Cluster, Anzahl von aufeinanderfolgenden Clustern) geführt. Damit passt typischerweise eine nicht defragmentierte Datei komplett in den MFT-Eintrag. Da ändert sich nichts durch eine Halbierung der Cluster-Größe. Nur bei Defragmentierung wächst der Beschreibungsaufwand, weil ja eine defragmentierte Datei vereinfacht schlimmstenfalls [Dateilänge/Clustergröße] verschiedene nicht zusammenhängende Cluster benötigt. Jeder davon benötigt einen Listeneintrag. Schlaumaier schrieb: > Einfach gesagt : Bei z.b. einer Clustergröße von 32 KB kann eine 10 > Bytes Datei mal eben 32 KB Festplattenplatz fressen. Nein, bei NTFS passen diese 10 Byte in den MFT-Eintrag. Das korrekte Beispiel wäre hier eine Dateilänge von 32KB + 10 Byte gewesen. Die würden dann zwei Cluster benötigen, da die MFT bei dieser Dateilänge meines Wissens den verblieben Speicherplatz im MFT-Eintrag nicht nutzt.
foobar schrieb: > ich empfinde die [sparse files] aber immer noch als Misfeature. oh, ganz im Gegenteil. QEMU images (speziell von Windows-Gästen) sind schon sehr cool, vor allem weil Windows das thin provisioning (erstaunlicherweise) sehr gut unterstützt.
Peter M. schrieb: > to contain more files Manche "Datei-Krümel", die früher ganze Cluster blockiert haben, wurden seit Zip-Zeiten etwas sinnvoller zusammengefasst. So gesehen sind die heutigen Klimmzüge eher Stolperfallen beim Backup/Restore.
>> ich empfinde die [sparse files] aber immer noch als Misfeature. > > oh, ganz im Gegenteil. QEMU images (speziell von Windows-Gästen) sind > schon sehr cool, Mal schauen, ob du das immer noch cool findest, wenn dein Gast auf einmal ein Disk-Full bekommt ;-)
foobar schrieb: >>> ich empfinde die [sparse files] aber immer noch als Misfeature. >> >> oh, ganz im Gegenteil. QEMU images (speziell von Windows-Gästen) sind >> schon sehr cool, > > Mal schauen, ob du das immer noch cool findest, wenn dein Gast auf > einmal ein Disk-Full bekommt ;-) Ich hab nicht einen Gast, ich hab viele Gäste (Kundenumgebungen). Es ist einfach nett, wenn nach dem Übertragen eines 100GB Datebank-Dumps (entzippen in ein Temp-File und dann Dump einspielen) das Image kurzfristig 100GB mehr braucht, nach Löschen der temporären Datei aber wieder zur ursprünglichen Größe zurückkehrt (ohne dass man irgendwas tun müsste) Im Übrigen ist "thin provisioning" heutzutage gang und gäbe, die Vorteile überwiegen bei Weitem.
foobar schrieb: > Mal schauen, ob du das immer noch cool findest, wenn dein Gast auf > einmal ein Disk-Full bekommt ;-) Modern Times. Gewöhn dich dran, oder ziehe als Tramp deine Wege. Sparse Files sind nur ein Teil dieses Spiels. Bei komprimierenden Filesystemen kann das ähnlich laufen, wenn du ein File mit Zufallsdaten überschreibst, ohne die formale Länge zu ändern. Und wenn ein Filesystem gleiche Daten vieler Files zusammenfasst, kann das beispielsweise bei vielen ähnlichen virtuellen Maschinen enorm Platz einsparen. Abhilfe: Platzüberwachung.
:
Bearbeitet durch User
oszi40 schrieb: > Manche "Datei-Krümel", die früher ganze Cluster blockiert haben, wurden > seit Zip-Zeiten etwas sinnvoller zusammengefasst. So gesehen sind die > heutigen Klimmzüge eher Stolperfallen beim Backup/Restore. ZIP Dateien sind in dieser Rolle Klimmzüge, um Probleme zu lösen, die eigentlich vom Filesystem selbst gelöst werden sollten.
(prx) A. K. schrieb: > um Probleme zu lösen, die eigentlich vom Filesystem > selbst gelöst werden sollten. Ein kaputte Zip-Datei ist schneller ersetzt als ein ganzes krankes Dateisystem von einigen TB. Frage ist immer ob in 20 Jahren noch einer dieses heutige Dateisystem problemlos verwenden kann. Bei Immobilien beträgt die Archvierungspflicht z.B. 100 Jahre!
oszi40 schrieb: > Bei Immobilien beträgt die Archvierungspflicht z.B. 100 Jahre! Und was genau hilft dir dabei die ZIP Datei? Die auf einem Medium liegt, das du in 100 Jahren ziemlich sicher nicht lesen kannst oder dessen Filesystem kaputt ist.
:
Bearbeitet durch User
Apropos: Wie oft vernichtet ihr so eure Filesysteme, ohne dass dies von der Hardware provoziert wurde? Mein Eindruck ist, dass Filesysteme heutzutage ziemlich stabil sind, so lange ihnen der Teppich nicht drunter weggezogen wird.
(prx) A. K. schrieb: > Apropos: Wie oft vernichtet ihr so eure Filesysteme, ohne dass > dies von > der Hardware provoziert wurde? Mein Eindruck ist, dass Filesysteme > heutzutage ziemlich stabil sind, so lange ihnen der Teppich nicht > drunter weggezogen wird. Das ist wirklich selten, aber tatsächlich hatte ich vor ein paar Wochen mal einen Dateisystemschaden - nach fsck einige hundert Dateien in lost+found, viele davon mit (afaik) Inode-Nummer als Dateinamen. Ärgerlich, aber dank Backup kein Problem.
Christobal M. schrieb: > viele davon mit (afaik) Inode-Nummer als Dateinamen. Das macht viel Spaß, wenn die Namen weg sind und das Backup krank. Deswegen bin ich mir nicht sicher, ob verschlüsselte Backup-Daten immer die beste Idee sind (solange man keinen Hausbesuch bekommt).
(prx) A. K. schrieb: > Apropos: Wie oft vernichtet ihr so eure Filesysteme, ohne dass dies von > der Hardware provoziert wurde? Mein Eindruck ist, dass Filesysteme > heutzutage ziemlich stabil sind, so lange ihnen der Teppich nicht > drunter weggezogen wird. Das hast du wirklich schön gesagt! Und eine 8TB Platte, wo 500GB nicht mehr draufpassen? Die ist doch auch ohne die 500GB schon voll. Man geht nicht ans Limit. oszi40 schrieb: > ich mir nicht sicher, ob verschlüsselte Backup-Daten immer > die beste Idee sind (solange man keinen Hausbesuch bekommt). Macht sowieso mehr Probleme als Nutzen. Wenn der richtige "Hausbesuch" kommt, für den ist so eine einfache Verschlüsselung kein Problem.
(prx) A. K. schrieb: > Und was genau hilft dir dabei die ZIP Datei? Die auf einem Medium liegt, > das du in 100 Jahren ziemlich sicher nicht lesen kannst oder dessen > Filesystem kaputt ist. es gibt Luxus-Blueray nach Militär-Standart (was immer das ist) wo der Hersteller eine Lebensdauer von 100 Jahren verspricht. Was man davon halten mag ist eine andere Sache. ABER. Das Problem was ich sehe ist das ZIP-Format. Das kennt in 100 Jahren keine Sau. Ergo ist die einzige Sinnvolle Lösung die Daten so einfach wie möglich zu archivieren. Und vor allen Dingen auf den Datenträger eine Text-Datei mit der Dokumentation des Formates zu machen.
Peter M. schrieb: > Hallo Uwe, > > der Verlust an freiem Speicherplatz wird verursacht durch den Wasserkopf > der Dateisysteme. > Die LUKS-Verschlüsselung erhöht den Speicherbedarf für Deine Daten > nicht. > Allerdings benötigt der zusätzlich erforderlich LUKS-Header mit seinen > Keyslots benötigt aufgrund der Verteilung der Schlüsselinformation auf > mehrere anti-forensische Streifen ("stripes") Speicherbedarf in der > Größenordnung von geschätzt ein paar MBytes. Wenn du das Passwort meinst mit dem man Zugang zu den verschlüsselten Daten gelangt, das wird nur ein einziges mal auf der Platte an einem einzigen Ort gespeichert. Redundanz hat man hier bei LULS leider nicht eingeplant. Ein Bitfehler auf dieser Stelle könnte also dazu führen, dass du nie wieder an die Daten auf der Platte rankommst. Deswegen wird empfohlen ein zweites Passwort anzulegen, das minimiert die Gefahr ein bisschen. Bis zu 8 PW sind möglich.
(prx) A. K. schrieb: > Scotty60 schrieb: >> Von einer Verlangsamung durch Verschlüsselung habe ich nichts gemerkt. > > Hängt auch vom Prozessor ab, d.h. ob er die AES Befehle kennt: >> grep aes /proc/cpuinfo > > Im unteren Segment von Intels Mainstream-Prozessoren, z.B. den Pentiums, > fehlt AES oft. Das sind eher die Celerons. Mein Intel Pentium G4500 hat AES. https://ark.intel.com/content/www/de/de/ark/products/90730/intel-pentium-processor-g4500-3m-cache-3-50-ghz.html
michael_ schrieb: > oszi40 schrieb: >> ich mir nicht sicher, ob verschlüsselte Backup-Daten immer >> die beste Idee sind (solange man keinen Hausbesuch bekommt). > > Macht sowieso mehr Probleme als Nutzen. > Wenn der richtige "Hausbesuch" kommt, für den ist so eine einfache > Verschlüsselung kein Problem. Das ist mal wieder so etwas dummes von dir. Auch ein Staat knackt kein AES 256. Und wenn er es könnte, könnte er es z.B. bei einer Anklage gegen dich, nicht gegen dich verwenden, da es dann bekannt werden würde, dass er gegen AES 256 ein mathematisches Verfahren kennt, um leichter an die Daten zu kommen.
(prx) A. K. schrieb: > Während der Prozessor > auch ohne AES oft in der Lage ist, den Durchsatz einer HDD mehr oder > minder zu erreichen, sollte man bei einer SSD nicht damit rechnen. Eines habe ich noch vergessen. Man muss aber auch dazu sagen, dass beim Linux Kernel die AES Funktion des Kernels meines Wissens nach nicht mehr verwendet wird, da der AES Funktion in den CPUs nicht mehr vertraut wird.
Nano schrieb: > Man muss aber auch dazu sagen, dass beim Linux Kernel die AES Funktion > des Kernels meines Wissens nach nicht mehr verwendet wird, da der AES > Funktion in den CPUs nicht mehr vertraut wir Hast du dazu Details? Auf die Schnelle finde ich nur ein Side Channel Problem namens PLATYPUS.
Wozu verschlüsselt mein seine Platte? Um sicherzustellen, das bei einem Defekt alles futsch ist?
oder geht es dabei um die gleiche Paranoia wie warum man kein Whatsapp etc nutzen sollte? Ich frage mich was viele so für Geheime Daten haben...oder geht es um die P*rnosammlung die dir so unendlich unangenehm wäre wenn es jemand sieht? Meinst du derjenige hat keine?
Paula P. schrieb: > Wozu verschlüsselt mein seine Platte? > Um sicherzustellen, das bei einem Defekt alles futsch ist? Das ist mit ein Grund, warum ich meinen Kram verschlüssele, ja. Um sicherzustellen, dass der Anbieter, dem ich den Datenträger schicke, um die Gewährleistung in Anspruch zu nehmen, keinen Unsinn damit treibt. Ist ja durchaus schon mehr als einmal vorgekommen, dass als „defekt“ deklarierte HDDs auf ebay und Co. aufgetaucht sind, und nach Beheben des Defekts tiefe Einblicke in das Leben oder das Geschäft des Vorbesitzers erlaubt haben. Schlaumaier schrieb: > es gibt Luxus-Blueray nach Militär-Standart (was immer das ist) wo der > Hersteller eine Lebensdauer von 100 Jahren verspricht. Genau, was auch immer ein(e?) Standart ist. Falls du dich auf M-Disc beziehst: das M steht für Millenniata (ursprünglicher Hersteller) oder Millenial (dessen Bezeichnung dafür), nicht für Militär. Wie kommt man auf sowas?
:
Bearbeitet durch User
"tiefe Einblicke in das Leben oder das Geschäft des Vorbesitzers erlaubt haben. " ganz toll...wen interessierts. Da ist von vielen einfach eine Art Hobby
Paula P. schrieb: > Wozu verschlüsselt mein seine Platte? > Um sicherzustellen, das bei einem Defekt alles futsch ist? Um sicherzustellen das nach einem Hardwaredefekt "alles futsch" ist macht der Profi keine Backups - das ist erprobt wirksam. Paula P. schrieb: > oder geht es dabei um die gleiche Paranoia wie warum man kein Whatsapp > etc nutzen sollte? > Ich frage mich was viele so für Geheime Daten haben...oder geht es um > die P*rnosammlung die dir so unendlich unangenehm wäre wenn es jemand > sieht? > Meinst du derjenige hat keine? Im Fall einer P*rnosammlung muss ein Gericht nur "feststellen" das sich Jugend- oder Anscheinsp*rnografie in der Sammlung befindet und du hast richtig Ärger am Hals. Müssen nicht mal reale Filme oder Fotos sein, Zeichnungen reichen (Stichwort... Lolicon so weit ich mich erinnere) - zu dem Thema gibts viel aus der Zeit wo Flinten-Uschi, damals noch Zensursula, Familienministerin war und der Bevölkerung durch ihr "DIE KINDER!!" Gekreische Tinnitus bescherte. Und eine Hausdurchsuchung hat man auch schnell am Hals - einen Internetanschluss zu besitzen reicht (youtube: 23c3 Sie haben das Recht zu schweigen). Oder im Falle meiner Hausdurchsuchung ein Zettel der in der Strasse gefunden wird in der du wohnst. Fazit: Verschlüsselung ist immer sinnvoll, P*rnosammlung, Filmesammlung, Musiksammlung, selbst produzierte Daten - egal.
Paula P. schrieb: > oder geht es dabei um die gleiche Paranoia wie warum man kein Whatsapp > etc nutzen sollte? Wenn du dein Notebook ausschließlich zu Hause verwendest, ist das anders zu bewerten, als wenn es leicht in andere Hände fallen könnte. Es geht nicht nur um Staatsorgane. Auch andere könnten neugierig sein, wenn die Gelegenheit in den Schoss fällt.
:
Bearbeitet durch User
Paula P. schrieb: > lächerlich, paranoiden Rumgespinne Gibt eigentlich nur zwei Möglichkeiten: entweder, du hälst dich in ’ner Traumwelt auf, wo Leute nicht versuchen, Kapital aus allem zu schlagen, das Kapital verspricht, oder du hast ein (vielleicht berufliches?) Interesse daran, dass Leute ihre Daten nicht schützen. Was trifft auf dich zu? Vielleicht hast du ja auch noch einen anderen Grund gegen Verschlüsselung anzuführen? Performance ist’s in Zeiten von Hardwareverschlüsselung ja nicht mehr, und ein Fehler auf dem Datenträger wirkt sich in beiden Szenarien (verschlüsselt oder unverschlüsselt) auch nicht sonderlich unterschiedlich aus. Der zusätzliche Platzbedarf durch die Verschlüsselung ist marginal (einige Megabyte – für die Jüngeren unter uns: 1MB sind 0,000001TB – für Verwaltungsinformationen, und selbst die kann man einsparen, wenn man wirklich will). Der einzige praktische Unterschied ist also: in einem Fall kann jeder auf die Daten zugreifen, im anderen nicht. Was für ein Interesse kann also jemand haben, Leute, die Wert auf Privatsphäre legen, zu verunglimpfen und ins Lächerliche zu ziehen? Bitte erkläre dich.
:
Bearbeitet durch User
Nano schrieb: > Eines habe ich noch vergessen. > Man muss aber auch dazu sagen, dass beim Linux Kernel die AES Funktion > des Kernels meines Wissens nach nicht mehr verwendet wird, da der AES > Funktion in den CPUs nicht mehr vertraut wird. Wenn dem so wäre hätte ich das gemerkt. Mit den AES Funktionen in der CPU erreiche ich die 500MB/s der SSD beim kopieren. Beim alten Athlon II 64 X3 waren bei 40MB/s bei verschlüsselten Laufwerken Schluss. Beim noch älteren Athlon 64 X2 und Centrino Duo waren es eher um die 20MB/s. Mehr als ~80 bekäme also auch ein aktueller Ryzen in Software (single Thread) nicht hin. Richtig ist, dass mal ein Patch abgelehnt wurde, der als einzige Quelle für Zufallszahlen den Harwarezufallszahlgenerator in der CPU verwenden wollte: https://www.heise.de/security/meldung/NSA-Affaere-Generatoren-fuer-Zufallszahlen-unter-der-Lupe-1953716.html
(prx) A. K. schrieb: > Mit einschlägigen Filmen kriegst du auch 8TB voll. Natürlich. Mein privates Videoarchiv ist knapp 4TB groß. Und sehr vieles davon stammt noch aus Zeiten, als man einen Spielfilm noch auf eine oder zwei CDs(!!) gequetscht hat. Warum? Weil seitdem kaum noch was an Filmen kam, was es wert gewesen wäre, Aufnahme in mein Archiv zu finden. Naja, ab und an bekomme ich einen Film aus dem Bestand mal in besserer Qualität aus dem TV geliefert. Aber: die Zensur-Schnitte bewegen mich recht regelmäßig dazu, dann doch lieber das Original in vergleichsweise sehr lausiger Bildqualität zu behalten... An die mangelnde Bildqualität kann man sich halt viel einfacher gewöhnen als an die wüsten bis völlig pervers sinnvernichtenden Zensur-Schnitte. Zumindest, wenn man das Original kennt...
michael_ schrieb: > Solche Filme braucht man aber nicht verschlüsseln! Tja, ist aber ein Verstoß gegen Kopierschutz und damit kann man dich am .... packen. (wenn man will.)
Beitrag #6544417 wurde von einem Moderator gelöscht.
Beitrag #6544420 wurde von einem Moderator gelöscht.
ich sehe es so schrieb: > Tja, ist aber ein Verstoß gegen Kopierschutz und damit kann man dich am > .... packen. > > (wenn man will.) Nö! Nur wenn du sie weiterverkaufst oder hochladen tust.
Verschlüsslung macht auch neugierig. Ein Dozent hat vor Jahren einige sinnlose Dateien verschlüsselt ins Netz gestellt und den Zugriff überwacht. Sie waren fleißig wie die Bienen diese Datei herunterzuladen. Nützliche Daten, die auch dort waren wollten sie nicht! :-) So gesehen ist verschlüsseln lustig. Anders herum ist natürlich ärgerlich einen Garantiefall einer Festplatte zu haben, die dann später wieder mit Daten bei eb*y auftaucht...
ja, wie gesagt, für viele ist es einfach Hobby. Ob verschlüsselt oder nicht
ich sehe es so schrieb: > Tja, ist aber ein Verstoß gegen Kopierschutz Nein, ist es nicht. Damals(tm) war die Privatkopie noch uneingeschränkt möglich. Und für Späteres gilt: Man darf einen "wirksamen" Kopierschutz nicht umgehen. Aber wie "wirksam" ist denn ein Kopierschutz, den man umgehen kann? Nach meiner Meinung (und den Gesetzen der formalen Logik): keiner. Grundsatzurteile dazu gibt es bis heute nicht. Immer, wenn sowas drohte, hat die Content-Mafia entweder gekniffen oder einen Deal gemacht. Das Ziel war ganz offensichtlich FUD. Ja keine höchstricherlich sanktonierte klare Rechtsauslegung zulassen, denn das hätte das Abzock-Geschäft in der gesetzgeberischen Grauzone endgültig beendet. Man merkt speziell bei diesen Gesetzen/Novellen, dass mehrheitlich Juristen neben der Judikative (wo das normal ist) auch Legislative und Exekutive beherrschen. Und die schnibbeln halt ungern die Brust ab, an der sie saugen...
Paula P. schrieb: > ja, wie gesagt, für viele ist es einfach Hobby. Ob verschlüsselt oder > nicht Ja, perverse Spanner gab’s auch früher schon. Mit Verschlüsselung bringt’s dann wenigstens einen Anspruch in deren „Hobby“. In diesem Sinne: Paula, gib doch mal bitte Login/Passwort für deine am häufigsten genutzten Mailaccounts. Ich will sehen, ob dieses „Hobby“ nicht auch was für mich sein könnte. Deiner Darstellung nach dürfte ja nix dagegensprechen, oder setzt du für dich andere Maßstäbe an, als für Andere?
:
Bearbeitet durch User
Das Passwort klautet master, überwiegen in Foren gentutz etc. überall wo es mir wurscht ist
Paula P. schrieb: > Das Passwort klautet master Oje, an der white-supremacy-Vergangenheitbewältigung müssen wir aber noch arbeiten, gelle?
Paula P. schrieb: > Das Passwort klautet master, überwiegen in Foren gentutz etc. überall wo > es mir wurscht ist Ich benötige nun die Stellen samt Passwörtern, an denen es dir nicht „wurscht“ wäre. Deiner eigenen Darstellung nach dürfte es solche ja gar nicht geben – aber auf der anderen Seite hättest du die Einschränkung ja nicht gemacht, wenn es solche nicht gäbe. Kann’s etwa sein, dass du genau weißt, dass du dich nicht an deinen eigenen Maßstäben für andere messen lassen kannst? Oder was hält dich ab, die Karten auf den Tisch zu packen und die Hose runterzulassen – dich also identifizierbar und durchsuchbar zu machen, wie du es offensichtlich okay findest, wenn es andere betrifft? Große Worte können sie alle …
(prx) A. K. schrieb: > Nano schrieb: >> Man muss aber auch dazu sagen, dass beim Linux Kernel die AES Funktion >> des Kernels meines Wissens nach nicht mehr verwendet wird, da der AES >> Funktion in den CPUs nicht mehr vertraut wir > > Hast du dazu Details? Auf die Schnelle finde ich nur ein Side Channel > Problem namens PLATYPUS. Das habe ich nur beiläufig mal in einem Bericht über AFAIK eine neue Kernelversion gelesen, da gab es nach Snowden so glaube ich sogar auch eine Diskussion auf der LKML. Näher verfolgt habe ich das aber nicht. Vielleicht ging es aber auch nur um einzelne Teilfunktionen dieser Funktion. FreeBSD nutzt die Hardwarefunktion glaube ich noch.
Paula P. schrieb: > Wozu verschlüsselt mein seine Platte? > Um sicherzustellen, das bei einem Defekt alles futsch ist? Damit du bspw. die defekte Platte innerhalb der Garantiezeit zum Hersteller schicken kannst um eine funktionstüchtige refurbished Platte zu erhalten ohne aber Gefahr zu laufen, dass der Hersteller deine Daten ausließt. Was er bei unverschlüsselten Platten durchaus könnte, wenn bspw. nur der Controller kaputt wäre. Hat man die Platte nicht verschlüsselt, dann bleibt man auf dem Schaden sitzen und muss sich ne neue Platte kaufen, wenn man nicht möchte, das Dritte die Daten lesen können.
Paula P. schrieb: > oder geht es dabei um die gleiche Paranoia wie warum man kein Whatsapp > etc nutzen sollte? Whatsapp sollst du nicht nutzen, weil du dich durch die Nutzung juristisch Angreifbar ja sogar strafbar machst. Denn du brauchst die Einwilligung von allen Personen in deinem telefonischen Adressbuch, dass du deren Telefonnummer (und gegebenenfalls sonstige Daten) zu whatsapp hochladen darfst. Denn genau diese Einwilligung gibst du gegenüber Whatsapp durch die Nutzung von Whatsapp. Wenn die dann nicht auch Whatsapp nutzen, landen plötzlich Leute die mit Facebook nichts zu tun haben wollen in deren Datenbank und diesen Verstoß gegen die Persönlichkeitsrechte hast du dann zu verantworten. Die Nutzung von WhatsApp ist somit illegal. Solltest du dich also bspw. mal von einer Freundin trennen, die Whatsapp nicht nutzt, während sie weiß, dass du es nutzt und ihre Nummer in deinem telefonischen Adressbuch steht, dann kann sie dir einen Strick drehen und Anzeige gegen dich erstatten. Nur so als Beispiel. Oder ein Geschäftskollege, mit dem du dich verkracht hast. Oder ehemaliger Kumpel usw.. > Ich frage mich was viele so für Geheime Daten haben... Es sind halt nicht deine Daten, sondern die von Dritten die du zu Facebook hochlädts und das ohne, dass du deren Einverständniserklärung eingeholt hast, was du aber tun müsstest.
Malte _. schrieb: > Richtig ist, dass mal ein Patch abgelehnt wurde, der als einzige Quelle > für Zufallszahlen den Harwarezufallszahlgenerator in der CPU verwenden > wollte: > https://www.heise.de/security/meldung/NSA-Affaere-Generatoren-fuer-Zufallszahlen-unter-der-Lupe-1953716.html Ah okay, dann wird es das wohl gewesen sein. Ist schon länger her.
Paula P. schrieb: > Das Passwort klautet master, überwiegen in Foren gentutz etc. überall wo > es mir wurscht ist Na dann lade doch deine Accountdaten zu all diesen Foren mal auf bugmenot hoch, damit auch andere etwas davon haben. Ich stoß manchmal auf Foren, wo ich gerne etwas fragen möchte, aber mich nicht registrieren möchte. Da wäre dein Zugang schon praktisch.
Nano schrieb: > Whatsapp sollst du nicht nutzen, weil du dich durch die Nutzung > juristisch Angreifbar ja sogar strafbar machst. Wenn darauf Gefängnis steht, dann brauch man Deutschland nur zu überdachen. Was mich wundert, dass die Abmahner dieses Feld noch nicht beackern.
Manfred schrieb: > Was mich wundert, dass die Abmahner dieses Feld noch nicht beackern. Vielleicht, weil es Blödsinn ist?
"Na dann lade doch deine Accountdaten zu all diesen Foren mal auf bugmenot hoch, damit auch andere etwas davon haben." Dz versteht den Unterschied offenbar nicht, ob ich eine Festülatte mit diesen Daten in Fremde Hände geraten lassen oder ich diese Daten in einem Forum veröffentliche wo es von mehreren 100 Personen gesehen wird.. Und da liegt das Problem, du übertreibst maßlos oder hältst dich und deine Daten für wichtiger als sie es wirklich sind
" Was mich wundert, dass die Abmahner dieses Feld noch nicht beackern. Vielleicht, weil es Blödsinn ist?" nicht nur vielleicht;-)
Paula P. schrieb: > Dz versteht den Unterschied offenbar nicht, ob ich eine Festülatte mit > diesen Daten in Fremde Hände geraten lassen oder ich diese Daten in > einem Forum veröffentliche wo es von mehreren 100 Personen gesehen > wird. Ja, schick sie einfach mir alleine. Dann besteht kein Unterschied zu deiner Festylatte mit den ganzen Daten mehr. Du kannst mir natürlich auch deine Festülatte schicken. Wie gesagt: große Reden können sie alle schwingen. Wenn’s dann aber darum geht, dazu zu stehen, wird’s immer ganz schnell dunkel. Wirst du eine Ausnahme sein? Ich denke nicht …
MaWin schrieb: > Manfred schrieb: >> Was mich wundert, dass die Abmahner dieses Feld noch nicht beackern. > > Vielleicht, weil es Blödsinn ist? Das weiß ein Jurist besser als du: https://www.youtube.com/watch?v=f_xmQBzQe3I Warum passiert es eigentlich immer dir, dass du so viel Halbwissen von dir lässt?
Nano schrieb: > Das weiß ein Jurist besser als du: Nur weil ein Jurist irgendetwas behauptet, ist das noch lange nicht wahr.
MaWin schrieb: > Nano schrieb: >> Das weiß ein Jurist besser als du: > > Nur weil ein Jurist irgendetwas behauptet, ist das noch lange nicht > wahr. In dem Fall schon.
Nano schrieb: > In dem Fall schon. Weil? Wo sind denn die richterlichen Entscheidungen zum Thema? Erst dann ist es festgelegt.
MaWin schrieb: > Nano schrieb: >> In dem Fall schon. > > Weil? > > Wo sind denn die richterlichen Entscheidungen zum Thema? > Erst dann ist es festgelegt. Es steht in der Videobeschreibung: "Das AG Bad Hersfeld hatte daher schon 2017 einer Mutter auferlegt, von jedem einzelnen Kontakt im Smartphone-Adressbuch ihres Sohnes eine schriftliche Einwilligung vorzulegen. Inzwischen ist im Datenschutzrecht die DSGVO in Kraft getreten. Die Rechtslage hat sich aber letztendlich nicht verändert. " AG steht hier übrigens nicht für Aktiengesellschaft, sondern für Amtsgericht. Hättest du bspw. von mir, der ich kein Whatsapp Nutzer bin, meine Telefonnummer in deinem telefonischem Adressbuch in deinem Handy, dann müsstest du von mir eine schriftliche Einwilligung einholen, bevor du Whatsapp nutzt. Hast du diese nicht, dann hätte ich bei einem Verstoß gegen meine Datenschutzrechte durch deinen Upload meiner Daten an Whatsapp die Möglichkeit rechtlich gegen dich vorzugehen.
ähm...also..erst mal ist das Rechtsfeld nicht so einfach wie einige glaube..Es gibt nicht schwarz und weiss. Oft reicht ein einzige Satz aus um alles zu entkräften. Und wenn deine Festplatte kaputt ist warst du auch nicht in der Lage irgendwelche Daten zu löschen.. Du redest hier von einem Normalbürger..hier geht vieles nach besten wissen und Absicht. @Jack V gibs auf, du verstehst den Unterscheid einfach nicht. Es sit ein Unterschied ob einer Jäger und Sammler ist oder ob sich einer aus einem Forum einen Spaß erlaubt um zu beweisen das er recht hat... Abgesehen davon weiß du vom Ebayer gar nichts du hast 0 Kontakt zu ihm du hast nicht vorher in einem Forum mit ihm Kontakt gehabt etc pp. Ich werde jetzt nicht mehr weiter auf deinen Unsinn eingehen, sicher deine Platte wie du willst und lebe deine Paranoia.
Paula P. schrieb: > @Jack V gibs auf, du verstehst den Unterscheid einfach nicht. > Es sit ein Unterschied ob einer Jäger und Sammler ist oder ob sich einer > aus einem Forum einen Spaß erlaubt um zu beweisen das er recht hat. Und worin genau besteht der Unterschied zwischen dem Szenario, in dem einer meine Accounts mit Daten kompromittiert, die ich ihm in einem Forum gegeben habe, und dem Szenario, in dem einer meine Accounts mit Daten kompromittiert, die er auf einem Datenträger bei ebay gefunden hat, für mich? Du behauptest, es wäre kein Problem für dich, wenn ein Dritter zusammen mit deinen Datenträgern auch gleich noch Zugriff auf alle Daten darauf bekommen würde. Aber wenn es auf einem anderen Weg geschieht, ist’s auf einmal ein Problem für dich. Siehst du deinen Widerspruch selbst, oder muss ich das noch weiter ausführen? Paula P. schrieb: > Ich werde jetzt nicht mehr weiter auf deinen Unsinn eingehen Hätte mich ja auch arg gewundert, wenn den großen Worten noch was gefolgt wäre. Wäre zumindest untypisch gewesen – und Leute mit einer solchen Einstellung kenne ich mittlerweile zur Genüge: „Was soll jemand mit deinen Daten denn anfangen? Hast du was zu verbergen?“ → „Was, du willst mal eben in meine Daten schauen? Unerhört! Niemals!“
:
Bearbeitet durch User
Scotty60 schrieb: > Hallo A. Klaasen! > > Was mir generell komisch vorkam beim Anlegen der Verschlüsselung mit > LUKS: > Vorher hatte ich ich die Platte als ext4 formatiert. Nach Luks > Verschlüsselung war das FS weg, d.h. beim Einbinden nach Eingabe der > Passpgrase verschwand die Platte aus der Dateiverwaltung Thunar. Erst > eine erneute Formatierung mit ext4 ließ sie sichtbar werden. Mache ich > da was falsch? > Gruß > > Uwe Es ist zwar inzwischen etwas Wasser die Elbe heruntergeflossen, aber ich widme mich nochmals kurz diesem Beitrag, der anscheinend nur mir Sorgen macht. Leider wird hier viel zu sehr auf Nichtigekeiten herumgeritten, als Leuten bei einer nachvollziehbaren Aufgabe zu helfen. Zur Frage: Ja, natürlich verschwindet dann das Dateisystem auf deiner Partition oder Festplatte nah dem formatieren per Luks. Luks aktiviert ja da nicht nur irgenwas, sondern legt innerhalb des Blockdevices einen weiteren Header rein und beschreibt damit wiederum ein enthaltenen Blockdevice. Sozusagen hast Du dann eine Partition in der Partition. Auf diesen inneren Blockdevice greift man dann per Devicemapper zu. Ich hoffe, also Du hast mit cryptsetup deine Partition /dev/sdxY verschlüsselt (cryptsetup luksFormat /dev/sdxY) und geöffnet (cryptsetup luksOpen /dev/sdxY <luksname>). Danach kann man das verschlüsselte Blockdevice per /dev/mapper/<luksname> ansprechen, also Dateisystem formatieren und einhängen. Alles geklärt? War das Dir klar? Wenn nicht: Bitte lies Dir zu diesem wichtigen Thema die zahlreichen Howtos durch! Kann ich Dir nur ans Herz legen. Wenn ja: Schönen Sonntag noch!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.