cryptsetup -> stärkster Algorithmus

Alles rund um sicherheitsrelevante Fragen und Probleme.
Antworten
mod3

cryptsetup -> stärkster Algorithmus

Beitrag von mod3 » 12.01.2017 21:12:08

Hallo,

ich habe mich mal wieder etwas mit dem Thema cryptsetup beschäftigt (das letzte Mal vor etwa 4 Jahren).
Scheinbar wird nun aes-xts statt aes-cbc standardmäßig verwendet.
Da ich vieles bei Google lese und noch unsicher bin: Welcher Algorithmus ist denn nun empfehlenswert?
Ich habe testweise mal eine Festplatte mit folgendem Befehl verschlüsselt:

Code: Alles auswählen

cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 luksFormat /dev/sdd
Dazu habe ich ein >100-stelliges Passwort verwendet.

Mal theoretisch: Ist das sicher? Für mich ist immer wichtig, den momentan besten/stärksten Algorithmus zu verwenden.
Interessanterweise läuft aes-xts auf meinem Xeon laut benchmark deutlich schneller als aes-cbc, das wäre ein netter Nebeneffekt.

Benutzeravatar
spiralnebelverdreher
Beiträge: 1294
Registriert: 23.12.2005 22:29:03
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Frankfurt am Main

Re: cryptsetup -> stärkster Algorithmus

Beitrag von spiralnebelverdreher » 12.01.2017 21:51:27

mod3 hat geschrieben:Hallo,

ich habe mich mal wieder etwas mit dem Thema cryptsetup beschäftigt (das letzte Mal vor etwa 4 Jahren).
Scheinbar wird nun aes-xts statt aes-cbc standardmäßig verwendet.
Da ich vieles bei Google lese und noch unsicher bin: Welcher Algorithmus ist denn nun empfehlenswert?
Ich habe testweise mal eine Festplatte mit folgendem Befehl verschlüsselt:

Code: Alles auswählen

cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 luksFormat /dev/sdd
Dazu habe ich ein >100-stelliges Passwort verwendet.
Mal theoretisch: Ist das sicher? Für mich ist immer wichtig, den momentan besten/stärksten Algorithmus zu verwenden.
Interessanterweise läuft aes-xts auf meinem Xeon laut benchmark deutlich schneller als aes-cbc, das wäre ein netter Nebeneffekt.
Sicher gegen welchen Angriff? Sicher für welchen Zeitraum? Und welche Mittel (Spezialhardware, Budget, Rechenleistung, ...) hat dein angenommener Gegner? Und du bist sicher, dass ein entschlossener Gegner dich nicht einfach mit Methoden a la Guantanamo in wenigen Wochen weichklopft und du dein 100stelliges Passwort "freiwillig" bekannt gibst?

Du kannst dich ja mal über Details schlau machen, bei der europ. Agentur für Netzwerk- und Informationssicherheit (falls du denen traust):
ENISA, “Algorithms, Key Size and Parameters Report. 2013 Recommendations,” 2013.
https://www.enisa.europa.eu/activities/ ... ers-report
https://www.enisa.europa.eu/publication ... eport-2014
oder beim deutschen BSI, beim amerikanischen NIST (falls du denen traust) oder bei der entsprechenden russischen Organisation (falls du denen traust)

Benutzeravatar
gehrke
Beiträge: 151
Registriert: 02.01.2015 09:15:41

Re: cryptsetup -> stärkster Algorithmus

Beitrag von gehrke » 12.01.2017 22:08:26

mod3 hat geschrieben:Scheinbar wird nun aes-xts statt aes-cbc standardmäßig verwendet.
https://www.heise.de/security/artikel/E ... 72199.html
http://www.youtube.com/watch?v=PpUrMk3g_og (Angriff auf die Freiheit von Ilija Trojanow / Juli Zeh) - let’s encrypt

mod3

Re: cryptsetup -> stärkster Algorithmus

Beitrag von mod3 » 12.01.2017 23:44:43

Klar, gegen derlei Angriffe ist man nie gewappnet. Mir geht's vor allem darum, dass ein Datenträger, der mir gestohlen wurde, nicht in einigen Jahren plötzlich entschlüsselbar ist.
Daher möchte ich möglichst nen Algorithmus nutzen, der im Augenblick als sicher gilt. Dass sich das alles mal ändern kann ist klar...

@gefunke: Ok, aber das bezieht sich ja nur auf aes-cbc? Den ich ohnehin nicht mehr einsetze?

mod3

Re: cryptsetup -> stärkster Algorithmus

Beitrag von mod3 » 13.01.2017 10:56:42

Ergänzende Frage: Was nimmt man am besten als keyfile? Ich habe jetzt einfach mal 4 4096bit-SSH-Keys erzeugt und sie in eine einzelne Datei geschrieben.
Oder nimmt man besser z.B. ein mehrere MB großes Bild?

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: cryptsetup -> stärkster Algorithmus

Beitrag von MSfree » 13.01.2017 11:26:28

mod3 hat geschrieben:Mir geht's vor allem darum, dass ein Datenträger, der mir gestohlen wurde, nicht in einigen Jahren plötzlich entschlüsselbar ist.
Daher möchte ich möglichst nen Algorithmus nutzen, der im Augenblick als sicher gilt. Dass sich das alles mal ändern kann ist klar...
Ob ein Algorithmus nicht knackbar ist, stellt sich praktisch immer zu spät heraus (siehe WLAN WEP). Von daher könnte sich jeder Algorithmus in Zukunft als knackbar herausstellen. Deine verschlüsselte, geklaute Platte ist also potentiell in Zukunft entschlüsselbar.

Benutzeravatar
spiralnebelverdreher
Beiträge: 1294
Registriert: 23.12.2005 22:29:03
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Frankfurt am Main

Re: cryptsetup -> stärkster Algorithmus

Beitrag von spiralnebelverdreher » 13.01.2017 12:15:34

mod3 hat geschrieben:Ergänzende Frage: Was nimmt man am besten als keyfile? Ich habe jetzt einfach mal 4 4096bit-SSH-Keys erzeugt und sie in eine einzelne Datei geschrieben.
Oder nimmt man besser z.B. ein mehrere MB großes Bild?
Wenn deine key-size 512 (byte) ist, dann wird ein längerer Keyfile gekürzt.
From a key file: It will be cropped to the size given by -s. If there is insufficient key material in the key file, cryptsetup will quit with an error.
Quelle: https://linux.die.net/man/8/cryptsetup

Ein große Bilddatei nutzt also nichts und wird eventuell (wegen strukturierter Information am Anfang oder Ende) sogar deutlich schlechter sein als 512 byte aus der Zufallsquelle erzeugt.

Benutzeravatar
spiralnebelverdreher
Beiträge: 1294
Registriert: 23.12.2005 22:29:03
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Frankfurt am Main

Re: cryptsetup -> stärkster Algorithmus

Beitrag von spiralnebelverdreher » 13.01.2017 13:30:41

mod3 hat geschrieben:Ergänzende Frage: Was nimmt man am besten als keyfile?
Mal ne dumme Frage: Wieso keyfile statt Passwort? Und wie / wo bewahrst du dieses auf?

wanne
Moderator
Beiträge: 7448
Registriert: 24.05.2010 12:39:42

Re: cryptsetup -> stärkster Algorithmus

Beitrag von wanne » 13.01.2017 14:42:47

mod3 hat geschrieben:Interessanterweise läuft aes-xts auf meinem Xeon laut benchmark deutlich schneller als aes-cbc, das wäre ein netter Nebeneffekt.
Rein theoretisch könnte XTS oder CTR deutlich schneller sein als CBC. Ich habe das nicht feststellen können.
Dir sollte vor allem klar sein:

-c aes-cbc-essiv:sha256 -s 256 nutzt AES-256
-c aes-xts-plain64 -s 256 nutzt AES-128
=> Vergleichen kannst du -c aes-xts-plain64 -s 256 mit -c aes-cbc-essiv:sha256 -s 128 (AES-128)
oder -c aes-xts-plain64 -s 512 mit -c aes-cbc-essiv:sha256 -s 256 (AES-256)
spiralnebelverdreher hat geschrieben:Quelle: https://linux.die.net/man/8/cryptsetup
Die Quelle, die selbst kein vernünftiges TLS kann ist leider schlicht falsch.
--key-file nutzt intern die gleiche Funktion wie Passphrase und damit gilt:
After that the read data will be hashed with the default hash or the hash given by --hash and the result will be cropped to the keysize given by -s
mod3 hat geschrieben:Was nimmt man am besten als keyfile?
Am besten nimmst du das: head -c16 /dev/random für -s 128 und head -c 32 /dev/random für -s 256 Da das auch der Algorithmus ist, den cryptsetup intern verwendet, wäre sowieso alles verloren, wenn der Kaput wäre:
MSfree hat geschrieben:Ob ein Algorithmus nicht knackbar ist, stellt sich praktisch immer zu spät heraus (siehe WLAN WEP). Von daher könnte sich jeder Algorithmus in Zukunft als knackbar herausstellen. Deine verschlüsselte, geklaute Platte ist also potentiell in Zukunft entschlüsselbar.
Prinzipiell hast du natürlich recht.
Aber prinzipiell galt RC4 schon damals (obwohl es da noch nicht geknackt wurde) als etwas, das man eher nicht benutzt, weil eher wudu als wissenschaftliche Kryptografie. Nur halt wunderbar schnell. (Deswegen ja auch der Streit WPA (weiter RC4 und damit auch auf alter Hardware flott) vs. RSN/WPA2 (AES-256)) Und beim keysceduling hätte jeder der nur ansatzweise ne Anfängervorlesung Verschlüsslung gehört hat die Hände überm Kopf zusammen geschlagen.
Von den viel zu kurzen Keylängen wollen wir gar nicht erst anfangen. Auch wenn damals standard PCs noch eine weile gebraucht haben, will man da eigentlich immer etwas großzügig sein. Ein mal *2 falls jemand was schnelleres wie Brute force findet. +32Bit damit es auch noch nach moors LAW in 50 Jahren tut. Und nochmal +10Bit, weil ja auch welche mit potenterer Hardware als einem PC kommen könnte.
Womit wir da wären:
mod3 hat geschrieben:Für mich ist immer wichtig, den momentan besten/stärksten Algorithmus zu verwenden.
AES ist absolut state of the art, und dank Hardwareunterstützung fast überall wahnsinnig schnell.
Trotzdem gelten camellia oder serpent als etwas sicherer. Daneben gibt es noch twofish für die Aluhüte, die niemand außer Bruce Schneier glauben, dass er keine Backdoors eingebaut hat.
Aber bevor man irgend was knackt kann man da natürlich nichts genaueres sagen.

Zum Modus:
LUKS besitzt keinen MAC, weswegen Manipulationen nie sicher festgestellt werden können. XTS versucht manipulationen zu erschweren. Defakto ist das aber halt verlorene Liebesmühe: Wenn jemand die möglichkeit hat, auf deine Platte zu schreiben bist du gefickt, und solltest sie nicht mehr verwenden. (Uder zumindest damit rechnen, dass die Manipuliert wurden (Sprich auf jeden Fall keine Programme mehr von ausführen, oder gar betriebssysteme Starten.)) => Schaden tut es nichts, nutzen ist wohl aber auch eher gering.
CBC funktioniert so für Festplattenverschlüsselung nicht. Deswegen macht dm-crypt da einige modifikationen, die dann Wartemark angriffe zulassen. (Sprich das wiedererkennen von bekannten Daten auch nach der verschlüsselung.) Das versucht man mit ESS dann wieder auszubügeln. Wie gut das funktioniert gibt es streit.
Vermutlich schon aber es ist halt ein komplexes konstrukt.
CTR erlaubt, wie jeder streamcipher bei langem Beobachten festzustellen, welche Änderungen passieren. Kann also ein Angreifer überlange zeit beobachte, welcher Block wann wie aussah, kann er feststellen, wo sich wann was geändert hat. Möglicherweise bei SSDs relevant, wo der gleiche Sektor vielleicht in mehreren Versionen existiert. (Siehe dazu auch die Problematik beim Löschen von Daten.) Auf HDDs eher irelevant, weil ein Angreifer ja eher selten zwei mal die gleiche Platte zu Gesicht bekommt.

Kurz: Ultraparanoia: -c camellia-xts-plain64 -s 512, -c aes-ctr -s 128 bietet deutlich mehr Performance und ist vermutlich ähnlich gut.
rot: Moderator wanne spricht, default: User wanne spricht.

mod3

Re: cryptsetup -> stärkster Algorithmus

Beitrag von mod3 » 13.01.2017 16:12:01

wanne, ich danke für deinen ausführlichen Input!

Die Frage zu den Keyfiles war theoretischer Natur, weil ich mich immer schon gefragt hab, wie das genau funktioniert.
Aber in dem Fall kann man ja z.B. wirklich einen SSH-Key erstellen und diesen als Keyfile verwenden.

Wenn ich das richtig sehe, kann ich mich mit dem von mir gewählten Algorithmus ja erstmal sicher fühlen.
Natürlich immer unter Berücksichtigung einiger Rahmenbedingungen ;-)

dufty2
Beiträge: 1709
Registriert: 22.12.2013 16:41:16

Re: cryptsetup -> stärkster Algorithmus

Beitrag von dufty2 » 14.01.2017 07:35:46

Hast Du auch noch einen Mac oder Windows? Was verwenden Bitlocker & Co?
Wie schaut es mit Deinem Händies aus? NAS? USB-Sticks?

mod3

Re: cryptsetup -> stärkster Algorithmus

Beitrag von mod3 » 14.01.2017 10:04:33

Habe nur Linux-Rechner, die alle brav verschlüsselt sind ;-)
Auf meinem Handy ist nix wichtiges und das funkt auch fröhlich in einem eigenen VLAN vor sich hin.


Ergänzende Frage:
Ich habe testweise mal ein altes Laptop voll-verschlüsselt, das geht über die Funktionen des Installers ja sehr praktisch.
Nun möchte ich die Systemplatte aber mit einem Keyfile verschlüsseln und dieses Keyfile auf einem ebenfalls verschlüsselten USB-Stick ablegen.
Wie kann ich diesen Stick beim Booten mounten und von diesem dann das Keyfile lesen? Also wie der generelle luksOpen-Befehl aussehen muss etc. ist klar.
Nur liest das System ja momentan nur das Passwort für meine verschlüsselte /-Partition, aber nicht das für meinen Stick.

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: cryptsetup -> stärkster Algorithmus

Beitrag von breakthewall » 18.01.2017 02:56:15

wanne hat geschrieben: AES ist absolut state of the art, und dank Hardwareunterstützung fast überall wahnsinnig schnell.
Trotzdem gelten camellia oder serpent als etwas sicherer. Daneben gibt es noch twofish für die Aluhüte, die niemand außer Bruce Schneier glauben, dass er keine Backdoors eingebaut hat.
Aber bevor man irgend was knackt kann man da natürlich nichts genaueres sagen.
Nicht zu vergessen, dass Rijndael alias AES, damals nur aufgrund der Einfachheit und Geschwindigkeit auserkoren wurde, nicht weil es der sicherste Kandidat gewesen ist. Wirklich unheimlich vertrauenswürdig. Und genau jene Einfachheit im mathematischen Aufbau macht AES problematisch. Denn die Angriffsformen sind bereits so weit optimiert worden, dass AES mit entsprechender Rechenleistung garantiert geknackt werden kann. Nicht das Passwort sondern der Algorithmus selbst. Das wird zwar noch eine Weile dauern, ist jedoch wenig ermutigend AES auf lange Sicht zu vertrauen. Ebenso ist die Implementierung von AES in proprietärer Hardware, ein ganz besonderes Argument gegen AES.

Hinsichtlich der Sicherheitsmarge war Serpent stets der massivste Kandidat, dicht gefolgt von Twofish. Doch was dieser Aluhut-Kommentar soll, bleibt wohl ein Geheimnis. Schon mal was davon gehört, dass jegliche Algorithmen quelloffen sind? Mal davon abgesehen, dass sie alle schon über 10 Jahre lang einschlägig analysiert wurden. Selbst der Blowfish-Algorithmus von Bruce Schneier, der 23 Jahre alt ist, ist heute immer noch nicht geknackt.
wanne hat geschrieben: Zum Modus:
LUKS besitzt keinen MAC, weswegen Manipulationen nie sicher festgestellt werden können. XTS versucht manipulationen zu erschweren. Defakto ist das aber halt verlorene Liebesmühe: Wenn jemand die möglichkeit hat, auf deine Platte zu schreiben bist du gefickt, und solltest sie nicht mehr verwenden. (Uder zumindest damit rechnen, dass die Manipuliert wurden (Sprich auf jeden Fall keine Programme mehr von ausführen, oder gar betriebssysteme Starten.)) => Schaden tut es nichts, nutzen ist wohl aber auch eher gering.
Schon mal bemerkt, dass Manipulationen am Ciphertext mit einem modernen Verschlüsselungsalgorithmus im XTS-Modus, nur defekte Datensätze zurück lässt? Zweites Problem: Woher weiß denn ein Angreifer, wo und was genau an Daten gespeichert ist? Glaskugel? Einfach mal selbst testen und Bereiche auf einem LUKS/dm-crypt verschlüsselten Volume verändern. Entweder werden gewisse Datensätze völlig defekt sein, oder das LUKS-Volume lässt sich im ungünstigsten Fall gar nicht mehr öffnen. Wo hier der Gewinn sein soll, liegt wohl in den Sternen.

wanne
Moderator
Beiträge: 7448
Registriert: 24.05.2010 12:39:42

Re: cryptsetup -> stärkster Algorithmus

Beitrag von wanne » 18.01.2017 08:50:57

breakthewall hat geschrieben:Und genau jene Einfachheit im mathematischen Aufbau macht AES problematisch.
Nein. Die Einfachheit ist vor allem eine Garantie gegen Backdoors. Man wollte eben nicht irgend welche magic numbers, von denen man im besten Fall nicht weiß, wozu die gut sind oder sogar zeigen kann, dass der Autor da backdoors drin verstecken kann. (Dual_EC_DRBG)
Des weiteren machen eine solche einfachen Algorithmen wahrscheinlicher, dass angriffe entweder schnell oder nie gefunden werden.
breakthewall hat geschrieben:Denn die Angriffsformen sind bereits so weit optimiert worden, dass AES mit entsprechender Rechenleistung garantiert geknackt werden kann. Nicht das Passwort sondern der Algorithmus selbst.
Was meinst du damit?
breakthewall hat geschrieben:Selbst der Blowfish-Algorithmus von Bruce Schneier, der 23 Jahre alt ist, ist heute immer noch nicht geknackt.
Ja. Wie gesagt: Bruce Schneier ist halt jemand, dem viele vertrauen. Aber der 64/128Bit-vorgänger von AES (SHARK) ist auch bis heute nicht geknackt. Und wenn du schon auf sowas wert legst musst du eigentlich MARS nehmen. (3)DES ist mittlerweile über 40Jahre alt und ungebrochen.
breakthewall hat geschrieben:Schon mal bemerkt, dass Manipulationen am Ciphertext mit einem modernen Verschlüsselungsalgorithmus im XTS-Modus, nur defekte Datensätze zurück lässt? […] Einfach mal selbst testen und Bereiche auf einem LUKS/dm-crypt verschlüsselten Volume verändern. Entweder werden gewisse Datensätze völlig defekt sein, oder das LUKS-Volume lässt sich im ungünstigsten Fall gar nicht mehr öffnen. Wo hier der Gewinn sein soll, liegt wohl in den Sternen.
Das ist halt der Unterschied zwischen breakthewall editiert ohne Verstand an seinem Volume oder jemand weiß was er macht. Ich kann dir wunderbar ext4-LUKS-Volumes editieren, ohne dass da irgend was meckert. Bei btrfs ist das dank CRCs etwas schwieriger. Aber auch die ersten Attacken gegen WEP wurde nicht, weil er RC4 verwendeten geknackt, sondern weil man gedacht hat, das CRC+Verschlüsselung so was ähnliches wie ein MAC sei. Wäre eigentlich ein ganz cooles featrure, wenn man btrfs auf SHA oder MD5 umstellen könnte. Dann wäre ich da einer meinung
breakthewall hat geschrieben:Zweites Problem: Woher weiß denn ein Angreifer, wo und was genau an Daten gespeichert ist?
Sowohl das wie auch dass einfache Änderungen zu völlig unvorhersehbaren Änderungen am Klartext führen ist auch für CBC so. Trotzdem gibt es Skripte im Netz, die in so einem Verschlüsselten Ubuntu-Volume den SSH so abändern, dass er nach keinem Passwort mehr fragt.
So als kleiner Hint: Wo so ein ext hinschreibt ist ein bisschen abschätzbar. Da braucht man keine Glaskugle sondern nur mkfs.ext4 zum testen. Und noch vorhersehbarer ist, wo so ein ubuntu-installer dann den SSH hinpackt. Wenn du jetzt ein Boolean das Falsch ist, abänderst hast du eine 1:2^32 tige Chance das das danach immernoch false ist. (Das ist so wahrscheinlich, wie dass du bei nem 6-Stlligen Passwort ne zufällige Zeichenkette eingibst und die richtig ist) Sprich das ist danach true. Leider werden noch 12Byte links oder rechts davon abgewandelt. Du solltest dir also eins suchen das beispielsweise neben einem Hilfetext steht oder sonstigen daten, die nicht weiter auffallen, wenn sie sich ändern.
(Bei CBC kannst du einzelne bits setzen (Die Chance, dass der Angriff misglückt gehen von 0.00000002328306% auf 0% runter) dafür gehen dir volle 16Byte etwas weiter vorne drauf.)
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
sbruder
Beiträge: 333
Registriert: 24.06.2016 13:54:36
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Franken

Re: cryptsetup -> stärkster Algorithmus

Beitrag von sbruder » 18.01.2017 15:00:05

wanne hat geschrieben:(3)DES ist mittlerweile über 40Jahre alt und ungebrochen.
So ganz ungebrochen ist 3DES dann doch nicht [1].

[1] https://www.heise.de/security/meldung/3 ... 04994.html

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: cryptsetup -> stärkster Algorithmus

Beitrag von breakthewall » 18.01.2017 18:48:16

wanne hat geschrieben:Nein. Die Einfachheit ist vor allem eine Garantie gegen Backdoors. Man wollte eben nicht irgend welche magic numbers, von denen man im besten Fall nicht weiß, wozu die gut sind oder sogar zeigen kann, dass der Autor da backdoors drin verstecken kann. (Dual_EC_DRBG) Des weiteren machen eine solche einfachen Algorithmen wahrscheinlicher, dass angriffe entweder schnell oder nie gefunden werden.
Einfachheit ist in der Kryptografie nichts Positives, und auch keine Garantie für höhere Sicherheit. Die Vergangenheit zeigte zur Genüge, welches Schicksal einfache Verschlüsselungsformen erwartet. Wieso werden nun AES und Dual_EC_DRBG in einen Topf geworfen? Das eine hat mit dem anderen nichts zu tun. Und wie kann man bei AES von mehr Sicherheit ausgehen, und komplexeren Verschlüsselungsalgorithmen potenzielle Backdoors anlasten, nur weil man sie selbst nicht versteht? Die mathematischen Operationen dahinter sind kein Geheimnis. Auch die Spezifikationen des LUKS-Header-Formats sind nebenbei einsehbar, wenn es schon um Magic Numbers geht.
wanne hat geschrieben:Was meinst du damit?
https://de.wikipedia.org/wiki/Advanced_ ... ue-Angriff

Einfach ausgedrückt hängt die Sicherheit von AES nur noch von der Hardware ab, und ist theoretisch bereits gebrochen. Und wenn diese weiterhin derartige Leistungssprünge hinlegt, wird das in absehbarer Zeit in praktische Reichweite kommen. Das mag zwar geschätzt noch 30~ Jahre dauern, vielleicht auch mehr, aber danach ist Feierabend für AES. Denn dieser Verschlüsselungsalgorithmus hat keine weiteren Hürden aufzubieten, weil er mathematisch schlicht zu einfach designt ist.
wanne hat geschrieben:Das ist halt der Unterschied zwischen breakthewall editiert ohne Verstand an seinem Volume oder jemand weiß was er macht. Ich kann dir wunderbar ext4-LUKS-Volumes editieren, ohne dass da irgend was meckert. Bei btrfs ist das dank CRCs etwas schwieriger. Aber auch die ersten Attacken gegen WEP wurde nicht, weil er RC4 verwendeten geknackt, sondern weil man gedacht hat, das CRC+Verschlüsselung so was ähnliches wie ein MAC sei. Wäre eigentlich ein ganz cooles featrure, wenn man btrfs auf SHA oder MD5 umstellen könnte. Dann wäre ich da einer meinung
Bei allem Verständnis, aber das ist einfach Nonsens. Woher kommt denn die Information, ich würde ohne Verstand editieren? Ziemlich anmaßend. Du editierst also einen pseudo-zufälligen Ciphertext, ohne Wissen um die dahinter stehenden Datensätze, und ohne anschließende Fehler? Fakt ist jedoch, dass hier überhaupt nichts editieren werden kann, und schon gar nicht ohne essentielles Wissen, was sich wann an einer bestimmten Stelle befindet. Vor allem wenn beabsichtigt ist, dass das hinterher noch funktionieren, oder gar noch eine vorbestimmte Aktion auslösen soll. Das basiert zu 100% auf dem Zufallsprinzip, ob so eine Manipulation Erfolg hätte. Und CRC ist auch keine Verschlüsselung.
wanne hat geschrieben:Sowohl das wie auch dass einfache Änderungen zu völlig unvorhersehbaren Änderungen am Klartext führen ist auch für CBC so. Trotzdem gibt es Skripte im Netz, die in so einem Verschlüsselten Ubuntu-Volume den SSH so abändern, dass er nach keinem Passwort mehr fragt.
Der CBC-Modus ist heute nicht mehr im Einsatz. Und unter dem XTS-Modus funktioniert das nicht in dieser Art und Weise, auch wenn Manipulationen prinzipiell möglich wären. Nur wären diese generell rein blinder Natur, da man niemals vorhersehen kann, wie betreffende Daten durch den Verschlüsselungsalgorithmus gespeichert werden. Und für eine entsprechende Datenintegrität, würde sich ggf. ZFS/BTRFS anbieten, oder man bindet effektiv Dm-verity in den Startprozess mit ein um Manipulationen festzustellen. Eine andere Option wäre mit GPG und somit mit Signaturen zu arbeiten, um sensible Bereiche des Dateisystems zu verifizieren, bspw. den Linux-Kernel selbst.
wanne hat geschrieben:So als kleiner Hint: Wo so ein ext hinschreibt ist ein bisschen abschätzbar. Da braucht man keine Glaskugle sondern nur mkfs.ext4 zum testen.
Hilft ungemein wenn man nicht weiß was wann geschrieben wird.

wanne
Moderator
Beiträge: 7448
Registriert: 24.05.2010 12:39:42

Re: cryptsetup -> stärkster Algorithmus

Beitrag von wanne » 18.01.2017 19:30:59

sbruder hat geschrieben:So ganz ungebrochen ist 3DES dann doch nicht [1].
Kein Angriff sondern lediglich zu kurze Blocklängen. Allerdings gibt es auf 3DES tasächlich Angriffe (die wurden auch von anfang an vorhergesagt) lediglich DES allein ist weitestgehend ungebrochen. Der beste Angriff macht es in 2⁴³ extrem komplexen Schritten die 2⁵⁵ bruteforce ist noch immer die schnellste Attacke.
breakthewall hat geschrieben:https://de.wikipedia.org/wiki/Advanced_ ... ue-Angriff
Der bringt dir beim brechen den Faktor 4 das macht Intel doch in einer Prozessorgeneration. Wartest du halt 2 Jahre länger – Sorry. Das ist kein vernünftiger angriff DES hatte den Faktor 512 per Desighn eingebaut.
breakthewall hat geschrieben:Das mag zwar geschätzt noch 30~ Jahre dauern, vielleicht auch mehr, aber danach ist Feierabend für AES. Denn dieser Verschlüsselungsalgorithmus hat keine weiteren Hürden aufzubieten, weil er mathematisch schlicht zu einfach designt ist.
Ich weiß nicht wie du rechnest aber selbst nach moors law brauchen wir da noch über 100 Jahre, wenn man das mit unter 1Moi. machen können will.

Bei allem Verständnis, aber das ist einfach Nonsens. Woher kommt denn die Information, ich würde ohne Verstand editieren? Ziemlich anmaßend. Du editierst also einen pseudo-zufälligen Ciphertext, ohne Wissen um die dahinter stehenden Datensätze, und ohne anschließende Fehler? Fakt ist jedoch, dass hier überhaupt nichts editieren werden kann, und schon gar nicht ohne essentielles Wissen, was sich wann an einer bestimmten Stelle befindet. Vor allem wenn beabsichtigt ist, dass das hinterher noch funktionieren, oder gar noch eine vorbestimmte Aktion auslösen soll. Das basiert zu 100% auf dem Zufallsprinzip, ob so eine Manipulation Erfolg hätte. Und CRC ist auch keine Verschlüsselung.
Das Reicht: http://www.jakoblell.com/blog/2013/12/2 ... partitions
Und dafür gab es fertige Scripte. Und solche malleability Attacken haben wiederholt Verschlüsslungen zu fall gebraucht WEP, diverse SSL-Ciphers.
Du schreibst hier ernsthaft über gefahren in AES obwohl niemand in den Letzten 50 Jahren irgend einen anerkannten symmetrischen Cipher geknackt hat, aber wischt Angriffe, die wirklich zigfach an verschiedenster Stelle vorgeführt wurden, mal kurz zur Seite, weil sie in 10s nicht in dein Hirn rein wollen.
breakthewall hat geschrieben:Der CBC-Modus ist heute nicht mehr im Einsatz. Und unter dem XTS-Modus funktioniert das nicht in dieser Art und Weise
Du hast CBC nicht richtig verstanden. Für CBC gilt weitestgehend das gleiche wie für XTS auch da hast du völlig unvorhersehbare zufällige Fehlerfortpflanzung über einen Block.
Hier das wichtige Zitat aus der oben genannten Quelle:
However, as this attack involves changing the previous ciphertext block, the previous plaintext block will also be changed to a random (and unpredictable) value.
Wie gesagt, der Angirff ist auf CBC ausgelegt. Aber mit der von mir erwähnten Abwandlung funktioniert der auch wunderbar gegen XTS. Nicht zu 100% aber eben zu 99.99999997671694%.
rot: Moderator wanne spricht, default: User wanne spricht.

slu
Beiträge: 2137
Registriert: 23.02.2005 23:58:47

Re: cryptsetup -> stärkster Algorithmus

Beitrag von slu » 29.06.2022 11:34:04

So ich grabe mal diesen alten Thread aus weil ich mich die Tage mit cryptsetup beschäftige und die gleiche Frage habe.

Wenn ich ein cryptsetup mit folgendem Befehl erstelle "cryptsetup -v -s 512 luksFormat /dev/sdX" kommt das raus:
Data segments:
cipher: aes-xts-plain64
[...]

Keyslots:
Key: 512 bits
Cipher: aes-xts-plain64
Cipher key: 512 bits
[...]

Die 64 steht für 64 Bit?
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

Benutzeravatar
hikaru
Moderator
Beiträge: 13559
Registriert: 09.04.2008 12:48:59

Re: cryptsetup -> stärkster Algorithmus

Beitrag von hikaru » 29.06.2022 12:59:48

slu hat geschrieben: ↑ zum Beitrag ↑
29.06.2022 11:34:04
Die 64 steht für 64 Bit?
Ja, wobei das aber nichts mit dem Cypher zu tun hat, sondern mit der Adressierung.
Ich bin nicht ganz sattelfest, aber soweit ich es verstehe, kann plain(32) zwar mehr als 2TB adressieren, dabei kommt es aber zu einer Art von Rollover/Überlauf, der prinzipiell die Sicherheit reduzieren könnte, weil sich Muster jenseits von 2TB wiederholen. plain64 löst das, bzw. verschiebt diese Grenze.

wanne
Moderator
Beiträge: 7448
Registriert: 24.05.2010 12:39:42

Re: cryptsetup -> stärkster Algorithmus

Beitrag von wanne » 29.06.2022 17:00:38

hikaru hat geschrieben: ↑ zum Beitrag ↑
29.06.2022 12:59:48
Ich bin nicht ganz sattelfest, aber soweit ich es verstehe, kann plain(32) zwar mehr als 2TB adressieren, dabei kommt es aber zu einer Art von Rollover/Überlauf, der prinzipiell die Sicherheit reduzieren könnte, weil sich Muster jenseits von 2TB wiederholen. plain64 löst das, bzw. verschiebt diese Grenze.
Ja. Gleiche Daten werden alle 2TB gleich verschlüsselt. => Man könnte patterns wiedererkennen. Sehr theoretisch da man ja ein paar viele mal 2TiB haben müsste, damit es ins Gewicht fällt. Aber warum sollte man nicht einfach 64Bit nehmen? Ich verstehe sowieso nicht so ganz warum sie nicht einfach die vollen 128Bit nehmen.
rot: Moderator wanne spricht, default: User wanne spricht.

slu
Beiträge: 2137
Registriert: 23.02.2005 23:58:47

Re: cryptsetup -> stärkster Algorithmus

Beitrag von slu » 29.06.2022 17:37:02

Vielen Dank, das hatte ich tatsächlich falsch verstanden.

Ich hab einen sehr interessanten Artikel von 2018 gefunden, so ein wenig klarer wird mir die Funktion so langsam.
https://linux-blog.anracom.com/2018/11/ ... fahrens-i/
Gruß
slu

Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.

Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER

Antworten