cryptsetup -> stärkster Algorithmus

Alles rund um sicherheitsrelevante Fragen und Probleme.
Antworten
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: 2136
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: 2136
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