Aus den Angeln hebender Reinfall bei Backup ins Internet

Da würde ich gern mehr dazu haben als die Aussage.

Denn: mehrfache Verschlüsselungen mit knackbaren Verschlüsselungen ergibt wieder eine knackbare Verschlüsselung.

Thomas Prufer

Quanten-Computing ist wie digital, nur halt mit den Zehen, also auch bis 10.

Guter Einwand. Ich sichere auf ein NAS. Das Verzeich nis mit den wichtigsten Backups wird mit einem WebDAV synchronisiert. Ich habe die Hoffnung irgendwann Glasfaser 1000/500Mbit zu bekommen und wollte dann die Synology abbauen und nur noch zum Hoster übertragen. Aber deine beispiele lassen mich das Vorhaben überdenken. Dann müsste der Trend zum zweiten Hoster gehen

Nein, wegen zwei Gründen: Die Mehrheit meiner hintereinander geschalteten Algorithmen ist auch einzeln unknackbar. Wenn als erster ein starker Krypto verwendet wird, dann liegt danach eine Byte-Folge vor, die zufällig verwürfelt ist, im Zahlenraum 0..255. Diese Folge muß vorliegen, nachdem ein darüber liegender Algorithmus geknackt wurde. Wie soll ein Angreifer wissen, wann/ob er den obersten Algorithmus geknackt hat?

. 11111111111111111111111 . 5+I}5+I}5+I}5+I}5+I}5+I}5+I}5+I= . [hu0U+b-h1tCBtL`[hu0U+b-h1tCBtL`[hu0U+b-h+t= . S|WC5Fb-k.CT51\(fn\5kFuTV+;vB|xuA(Ftft0t+@;EAgb~vhu.^SJ-V(t= . Vorstehend ist erkennbar, daß trotz Verwendung des immer gleichen . Schlüssels, die Gleichartigkeit durch die dritte Stufe beseitigt ist.

Wenn also _nur_ meine selbst entwickelte Verschlüsselung verwendet wird, müssen mindestens drei Stufen hintereinander geschaltet werden. Zusätzlich würde ich unterschiedliche Schlüssel verwenden.

Wenn ich meinen Coder als Abschluß verwende, kann ein nachfolgendes Kommando 'scp -pC' gut komprimieren, weil eine stark eingeschränkte Zeichenmenge vorliegt.

Dann das bitte auch so sagen. "Vorhanden" bei sowas heisst gemeinhin lediglich "installiert", nicht "läuft".

Bitte mal Wissensstand aktualisieren: systemd existiert (jaja, die systemd Units liegen auch in /etc rum, aber das sind keine rc Skripte mehr).

Bitte was? Auf Linux sind Prozesse in eckigen Klammern in der Ausgabe von ps Kernel-Prozesse. Auf NetBSD taucht ebenfalls nur "system" so auf. FreeBSD habe ich gerade nicht zur Hand, müsste ich erst den damit Laptop ausgraben.

Und, eben getestet (falls rsyncd tatsächlich argv[0] überschreibt auf diese Weise): Nein, keine eckigen Klammern bei laufendem Daemon. Wo hast Du das gesehen?

Weniger deswegen sondern weil AES ein guter Algorithmus ist, der verschiedene Analysen gut überstanden hat. Und _deswegen_ für die US Regierung empfohlen wird.

Ah, also doch.

Merkt man ;-)

Man liest sich, Alex.

Was vermutlich u.a. daran liegt, dass die notwendige Infrastruktur, sowas ordentlich zu bauen, erheblichen u.a. finanziellen Aufwand sowie erhebliches Fachwissen erfordert. Aus der Garage heraus baut man sowas nicht auf.

Man liest sich, Alex.

Und wenn die Verschlüsselung nicht schnell geknackt werden kann, dann haut man halt solange mit dem Hammer auf die Quanten des Schlüsselinhabers bis dieser den Schlüssel rausrückt, ganz einfach.

SCNR, Alex.

Warum? Einfach die Datenmenge aufblasen? Über einen 7bit-ASCII-only Link wirst Du das ja kaum schreiben.

Kryptographie. Entropie. Genug gesagt.

Man liest sich, Alex.

Extra brut gibt es hier ohne Aufpreis.

Es reicht ein rsync-Binary irgendwo auf deinen Webspace zu legen. Dann findest du den absoluten Pfad dazu raus (pwd) und übergibst das auf deiner Seite an den rsync-Command als Paramter "--rsync-path".

Das ist alles. Es braucht keinen Daemon wenn man die rsync-Verbindung über SSH aufbaut. Dein lokales rsync führt dann via SSH ein rsync auf dem Server aus und schiebt den Datenstrom durch den SSH-Tunnel.

Gruß

Manuel

Ich weiß ja nicht wie gut so das Verhältnis zwischen dir und deinem Provider ist, aber wenn es dermaßen schlecht ist, dann würde ich einen Providerwechsel in Betracht ziehen.

Andernfalls ist das von dir analysierte Verhalten der SSH-Verbindung ein Fehler und auch als solches zu behandeln. Sprich: Mach ein Ticket beim Provider auf.

Gruß

Manuel

Am 08.09.26 um 19:00 schrieb Helmut Schellong:

Vmtl. irgendein Verbindungs-Timeout auf Netzwerk-Ebene.

Win32 kann seit Ewigkeiten mit Dateien >4GB umgehen. Das konnte OS/2 schon. Man muss halt die richtigen Funktionen aufrufen bzw. die Parameter für 64 Bit versorgen.

Marcel

Ich sagte, daß der Daemon vorhanden sei (per ps), nicht einfach nur das Kommando rsync.

Hier ist der Daemon (per ps). ... 0:00.00 /usr/local/bin/rsync --daemon --config /usr/local/etc/rsync/rsyncd.conf Eine .pkg-Inhalt konfiguriert bei der Installation, daß der Daemon immer gestartet ist. Wenn solch ein Eintrag fehlt, gibt es keinen rsync-Daemon.

Es gibt unter FreeBSD /etc mehrere Verzeichnisse, die Skripte und Conf-Dateien enthalten. Das Verzeichnis /etc/rc.d ist eines davon, darin sind tatsächlich start-stop-Skripte. systemd existiert unter FreeBSD nicht.

-rw-r--r-- 1 root wheel 5126 Jun 12 02:37 rc

-rw-r--r-- 1 root wheel 4531 Jun 12 02:37 rc.bsdextended

-rw-r--r-- 1 root wheel 1176 Jul 7 20:12 rc.conf drwxr-xr-x 2 root wheel 512 Jul 7 00:57 rc.conf.d drwxr-xr-x 2 root wheel 4096 Jul 7 01:02 rc.d

-rw-r--r-- 1 root wheel 18696 Jun 12 02:37 rc.firewall

-rw-r--r-- 1 root wheel 13712 Jun 12 02:37 rc.initdiskless

-rwxr-xr-x 1 root wheel 2239 Jun 12 02:37 rc.resume

-rw-r--r-- 1 root wheel 3340 Jun 12 02:37 rc.shutdown

-rw-r--r-- 1 root wheel 66945 Jun 12 02:37 rc.subr

-rwxr-xr-x 1 root wheel 2351 Jun 12 02:37 rc.suspend

Ich selbst brauche fstab, rc.conf, hosts, resolv.conf, defaults, ssh. Mit fallender Häufigkeit.

Ist das so tierisch wichtig?

root 0 0 0 DLs - 0:00.16 [kernel] root 1 0 1 ILs - 0:00.02 /sbin/init root 2 0 0 WL - 0:00.81 [clock] root 3 0 0 DL - 0:00.00 [crypto] root 4 0 0 DL - 0:00.19 [cam] root 5 0 0 DL - 0:00.00 [busdma] root 6 0 0 DL - 0:00.04 [rand_harvestq] root 7 0 0 DL - 0:00.00 [enc_daemon0] root 8 0 0 DL - 0:00.08 [pagedaemon] root 9 0 0 DL - 0:00.00 [vmdaemon] root 10 0 0 DL - 0:00.00 [audit] root 11 0 0 RNL - 512:12.71 [idle] root 12 0 0 WL - 0:00.24 [intr] root 13 0 0 DL - 0:00.07 [geom] root 14 0 0 DL - 0:00.79 [usb] root 15 0 0 DL - 0:00.06 [bufdaemon] root 16 0 0 DL - 0:00.00 [vnlru] root 17 0 0 DL - 0:00.01 [syncer]

Der rsync-Daemon ist vorstehend nicht dabei - ich habe mich mit dessen Position in der Ausgabe von ps halt geirrt. Weiter unten wird der ausgegeben: ... 0:00.00 /usr/local/bin/rsync --daemon --config /usr/local/etc/rsync/rsyncd.conf Dieser Daemon würde auch auf Anfragen von Außen reagieren, falls ich meinen Router entsprechend konfigurieren würde.

Ich habe mich mit den eckigen Klammern halt geirrt, weil ich ps lange nicht mehr aufrief.

Das weiß ich, denn ich habe die Berichte über die Algo-Auswahl beim NIST gelesen.

Andere gleich gute Algorithmen wurden auch getestet, ob sie zu 'schwach' sind, wie z.B. 'rc4'. 'rabbit' z.B. konnte bis heute nicht korrumpiert werden.

Ich schrieb: "Alle heute gängigen Interpreter gab es 1995 nicht." . ^^^^^^^^

Nein, ich hatte ein perl-Beispiel in mein erstes C-Buch aufgenommen. Das war jedoch 2005, nicht schon vor 1995. Der Grund: weil perl gängig und schnell war.

Python war damals sicher nicht gängig, obwohl in Fachkreisen wohl bekannt. Perl kannte ich 1995 ebenso nicht, vielleicht nur vom Namen her. Auch RUST und PHP waren damals sicherlich nicht gängig, die heute gängig sind.

Später, 2005, kannte ich perl als gängigen Interpreter. Jedoch gefällt perl mir nicht, weil ich z.B. mit der bish in ein laufendes Skript schreiben kann, mit dem laufenden Code dieses Skripts. Dies geht mit perl (wahrscheinlich) nicht, weil perl kompiliert. Während bish ein 100%-iger Interpreter ist.

Die Syntax von perl gefällt mir ebenso nicht. Sie kommt mir nicht entgegen. Ich stecke meine Energie nicht in Dinge, die mich gar nicht interessieren.

Es kann Konfusion auslösen, bei einem Angreifer, der selbstverständlich von einer gleich großen entschlüsselten Datei ausgeht.

Es gibt ein weiteres Merkmal, das mächtige Konfusion auslösen kann.

Danke für diese Informationen.

Ich glaube, daß das wie beschrieben prinzipiell funktionieren wird. Es gibt allerdings viele Details on remote, die einen konkreten Betrieb verunmöglichen können. Schrittweises Vorgehen und einige Testaktionen über einige Tage würde das schon kosten.

Es existiert allerdings ein grundlegendes Problem, das unlösbar erscheint: Ich kann doch remote nicht mehrere Verzeichnisstrukturen mit je z.B. 30000 Dateien aufbauen. Und rsync kann doch nicht auf dem Transportweg jede Datei nach meinen Bedürfnissen verschlüsseln, die im verschlüsselten Zustand dort verbleiben müssen. Während lokal keine Datei verschlüsselt ist. Wie soll rsync denn unter diesen Umständen beide Dateisysteme zwecks Synchronisation vergleichen?

Es darf kein unverschlüsseltes Byte meinen PC verlassen. Das ist durch mein _realisiertes_ Konzept bereits gewährleistet: Ich erzeuge einfach tar-Dateien (bis 8 GB), die ich gemäß meiner Bedürfnisse verschlüssele und dann per ssh-Tools nach remote transferiere. Und fertig.

Und im extrem unwahrscheinlichen Fall mache ich einfach einen Download - und fertig.

Das Verhältnis ist normal gut. Es sind halt Abbrüche bei Up-Transfers mit langer Dauer aufgetaucht.

Ja, daran hatte ich auch gedacht. Aber ich habe in NullKommaNix zwei Skripte geschrieben, die die großen Archiv-Dateien automatisch in kleinere Teildateien splitten und wieder zusammenbauen können.

Solche Tools wollte ich sowieso schon länger mal haben.

Marcel Mueller wrote on 11.09.2026 18:19:

Nein, ich muß eine Library mit 64-Bit-Funktionen verwenden. Dann machen Funktionen wie stat() und lseek() keine Probleme mehr. Eine 64-Bit-Library existiert aber nicht für den oben genannten kostenlosen 32-Bit-Compiler. Ich muß folglich eine Lösung mit einem 64-Bit-Compiler/Developmentsystem anstreben.

Der Typ off_t für die filesize in struct stat { } hat z.B. nur 32 Bit. Da kann man nichts machen. In FreeBSD-32-Bit-Systemen vor Jahrzehnten hatte off_t bereits 64 Bit.

Unter Unix habe ich solche Probleme nicht, mit gcc und clang.

U.a. aus Lizenzgründen wird sich systemd nicht in FreeBSD wiederfinden, aber es gibt durchaus Leute, die einen Nachbau davon für FreeBSD diskutieren. Mal sehen, ob jemals was daraus wird.

Naja, damit kann man auf einen Blick Kernel- von Userspace-Prozessen unter- scheiden. Und es _gibt_ Programme, die argv[0] zu Signalisierungszwecken überschreiben.

Vor allem deshalb weil PHP erst 1995 rauskam und Rust 2012.

Man liest sich, Alex.

Nein, denn Deine aufgeblähte Version verrät sich zum einen durch ihren Inhalt als solche.

Man liest sich, Alex.