|
|
|
|
|
|
|
Das ist genau was ich will 
Im Prinzip bieten Dropbox und ich glaube auch OneDrive schon so "Sync on Demand"-Lösungen an, das geht schon in die Richtung. Aber es fällt für mich nicht in die Kategorie geil.
e/ Expandrive wirkt auch interessant auf den ersten Blick. Gibt natürlich keinen ARM-Build  .
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von B0rG* am 29.03.2020 16:10]
|
|
|
|
|
|
|
|
|
|
Seafile vielleicht auf nem privaten Server?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
Das ist genau was ich will
Im Prinzip bieten Dropbox und ich glaube auch OneDrive schon so "Sync on Demand"-Lösungen an, das geht schon in die Richtung. Aber es fällt für mich nicht in die Kategorie geil.
e/ Expandrive wirkt auch interessant auf den ersten Blick. Gibt natürlich keinen ARM-Build .
| |
Pcloud macht das. Cachesize kannst du frei einstellen, oder optional einzelne Ordner komplett Lokal syncen würde bei den üblichen Verdächtigen.
|
|
|
|
|
|
|
|
|
|
|
Schick schick. Warum verwendest du gocryptfs statt der pcloud Crypto-Lösung?
e/ Seafile werde ich mir auch nochmal genauer ansehen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von B0rG* am 29.03.2020 16:25]
|
|
|
|
|
|
|
|
|
|
Ich nutze für den Usecase einfach Syncthing.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 29.03.2020 16:31]
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
Schick schick. Warum verwendest du gocryptfs statt der pcloud Crypto-Lösung?
e/ Seafile werde ich mir auch nochmal genauer ansehen.
| |
Die pcloud-eigene Lösung ist so gnadenlos unperformant dass es scheppert und nicht auf lokal synchronisierte Ordner anwendbar. Ich hab meine Fotosammlung da drin, das verträgt sich überhaupt nicht miteinander.
Außerdem lässt sich das Passwort für gocryptfs recht komfortabel aus dem Systemkeyring lutschen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von statixx am 29.03.2020 16:41]
|
|
|
|
|
|
|
|
|
| | Zitat von FreeHawk*
sshfs + gocryptfs
Tut erstaunlich gut.
| |
https://nuetzlich.net/gocryptfs/threat_model/
liest sich halt schon wieder mit dem gedanken: "warum nicht? schade" dass der da nicht git like ein hasing durchzieht um nen trust anchor zu haben wegen "performance!!!" find ich schon wieder doof.
was da alles möglich ist ohne dass das ding schreit.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Oli
Seafile vielleicht auf nem privaten Server?
| |
seafile hab ich mir auch mal eingerichtet, das verursacht aber ein _ganz_ ganz üblies gefühlt.
die hatten ja vor ein paar jahren mal ihren krassen bug mit dem statischen crypto key oder sowas und auch wenn du dir das jetzt anschaust verursacht das eher schaudern. so ala "passwort zurücksetzen funktion" sendet(!) dir dein neues passwort als klartext in einer email... die entwickler scheinen da immer noch ganz krass die letzten 20 jahre geschlafen zu haben.
hab ich dann nur eingerichtet um mal fotos eines jungesellinnenabschieds einzusammeln und erfahrung zu sammeln, aber so ohne weiteres würd ich das glaube ich nicht mehr verwenden.
nextcloud ist mir halt direkt zu schwergewichtig "one tool, one purpose", vielleicht wirklich mal syncthing anschauen.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von [KdM]MrDeath am 29.03.2020 16:45]
|
|
|
|
|
|
|
|
|
| | | Files are segmented into 4KiB blocks. Each block gets a fresh random 128 bit IV each time it is modified. A 128-bit authentication tag (GHASH) protects each block from modifications. | |
Schlampe bitte, wer hat das denn designed. Aua. Immerhin ist AAD = File-ID || Block-No. Aber trotzdem. Nen 128 bit Random IV für jeden 4K-Block, der jemals war, ist oder sein wird, ist jetzt nicht unbedingt der Sicherheitsfaktor, den man haben will. Ein globaler Schlüssel, den man im Zusammenhang mit AES-GCM einsetzt, ebenfalls nicht.
Das sind pi mal Daumen nur 16 TB-Written pro gocryptfs...
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von csde_rats am 29.03.2020 17:03]
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
nextcloud ist mir halt direkt zu schwergewichtig "one tool, one purpose", vielleicht wirklich mal syncthing anschauen.
| |
Ich kann syncthing total empfehlen, performt super. Benutze das für so 10gb geteilt zwischen etwa 6 hosts und muss mich quasi nie drum kümmern, es funktioniert einfach. Macht aber halt lokalen Klon.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
| | | Files are segmented into 4KiB blocks. Each block gets a fresh random 128 bit IV each time it is modified. A 128-bit authentication tag (GHASH) protects each block from modifications. | |
Schlampe bitte, wer hat das denn designed. Aua. Immerhin ist AAD = File-ID || Block-No. Aber trotzdem. Nen 128 bit Random IV für jeden 4K-Block, der jemals war, ist oder sein wird, ist jetzt nicht unbedingt der Sicherheitsfaktor, den man haben will. Ein globaler Schlüssel, den man im Zusammenhang mit AES-GCM einsetzt, ebenfalls nicht.
Das sind pi mal Daumen nur 16 TB-Written pro gocryptfs...
| |
Care to elaborate? Was ist an 128 bit IV scheiße?
|
|
|
|
|
|
|
|
|
|
|
Die haben einen AES-Schlüssel fürs gesamte Dateisystem und würfeln für jeden Block einen 128-Bit IV aus. Wenn zwei Blöcke den gleichen IV haben, dann ist der XOR der Chiffrate identisch zum XOR der Klartexte, was idR ungünstig ist. Zusätzlich machst du dir damit die Authentifizierung kaputt, IIRC in Abhängigkeit von der Nachrichtenlänge. Das nächste Problem ist, dass wenn du einen 128-Bit IV in AES-GCM reinsteckst, der komprimiert wird, und zwar in 96-Bits (weil das effektiv Counter-Mode ist und der Counter halt ein Plaintextblock ist, also 128 Bits. Die oberen 96 Bits sind dein Message-spezifischer Teil, die unteren 32 Bits zählen die Blöcke in der Nachricht durch). Das ist so der andere beliebte Stolperstein, man sagt "klar, IV-Kollision ist schlecht, also nehme ich einen 128-Bit-Zähler!"; was für AES-GCM effektiv das gleiche ist wie ein zufälliger 96-Bit IV. Wenn jemand also 128 Bit IVs mit AES-GCM benutzt, selbst wenn sie zufällig sind, signalisiert das, dass sie die Konstruktion nicht verstanden haben.
Unterm Strich kann man dann ein bisschen mit Wahrscheinlichkeiten und dem Geburtstagsparadoxon rumrechnen und sich ein "p|Dinge fallen auseinander" aussuchen. Für AES-GCM sagt das NIST "unter dem gleichen Schlüssel hast du nicht mehr als 2**32 Nachrichten zu verschlüsseln". Ich hatte das mal ausgerechnet was für ein "p|Dinge fallen auseinander" das ist, ich glaube es war in etwa 1e-9 oder so.
Entsprechend 2**32 × 4 kB Blöcke = 4 Milliarden × 4 kB = 4 Giga × 4 kB = 16 TB.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von B0rG*
| | Zitat von [KdM]MrDeath
nextcloud ist mir halt direkt zu schwergewichtig "one tool, one purpose", vielleicht wirklich mal syncthing anschauen.
| |
Ich kann syncthing total empfehlen, performt super. Benutze das für so 10gb geteilt zwischen etwa 6 hosts und muss mich quasi nie drum kümmern, es funktioniert einfach. Macht aber halt lokalen Klon.
| |
"performt" steht bei mir an der stelle der kriterien halt erst auf platz 3-5... :/
aber joa, komplette kopie könnte das ding wohl wirklich vielversprechend ausschauen. aber wie ich schon auch in meinem post auf der letzten seite geschrieben hab: irgendwie erwarte ich mittlerweile ein bischen mehr.
|
|
|
|
|
|
|
|
|
|
|
Cool, danke für die Erklärung. Meine Cryptogrundlagen sind ganz schön eingestaubt merk ich gerade. 
Werd das jedenfalls im Hinterkopf behalten und ggfs die Keys mal wechseln. Das von MrDeath gepostete threat model war mir wohl bewusst, das bisher nicht. Wobei die 16tb erstmal noch ausreichend für mich klingen, ich hab bisher gut 650 GB da drin, allerdings in 4 verschiedenen gocryptfs-directories.
Immer dieser ewige tradeoff von Sicherheit und Komfort... 
Achja, Birthday Phänomen... Hm.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von statixx am 29.03.2020 19:45]
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
was ich aber wirklich noch vermisse ist etwas das den usecase das er anspricht wirklich auch erfüllt...
ich mein die daten wirklich so zu behandeln als ob sie "lokal" wären, mit optionalem caching.
| |
im prinzip - und bitte jetzt mit viel vorsicht und watte lesen - kann SMB das, seit dem es branch caching kann. also effektiv seit SMB 3 (ich meine es war 3).
vielleicht schonmal aufgefallen, wenn man auf nem windows nen share anlegt, dass man da das caching verhalten einstellen kann. das kann samba auch. also im prinzip.
genutzt habe ich das bisher nicht, weil...erm...mein samba server hängt mit 10 gbit hier zu hause am netz und von daher ist das mit dem caching eher so nicht relevant. davon abgesehen SMB over internet ist so eine sache.
im prinzip kann SMB auch durch TLS getunnelt werden oder halt durch random VPN. da sollte man nur sehr bedacht auf die potentiellen fehlerfälle vorbereitet sein. also auf das wegbrechen des VPNs oder des TLS tunnels und die damit vermutlich verbundene freie zugänglichkeit der SMB sache. samba und SMB bindet sich ja aus "legacy" gründen an ein interface und nicht an eine IP. das halt aber auch mehr oder weniger nur halbgar.
ich könnte jetzt auch noch zu nem rant über SMB ausholen, aber ich glaub das lass ich mal auf grund von fehlenden besseren alternativen. NFS ist noch grösserer kernschrott.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
...mein samba server hängt mit 10 gbit hier zu hause am netz | |
lol, bin ich hier der einzige mit ner 16mbit dsl Leitung?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von RichterSkala
| | Zitat von Traxer
...mein samba server hängt mit 10 gbit hier zu hause am netz | |
lol, bin ich hier der einzige mit ner 16mbit dsl Leitung?
| |
ich meinte damit nicht die inet leitung.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Frage an euch:
Unittests für C++? Was ist euer Liebling und weshalb?
|
|
|
|
|
|
|
|
|
|
|
Catch2, nie was anderes benutzt. Header only, modern, clion integration.
/e: Ich muss dazu sagen, dass ich eigentlich nie tests schreibe, das ist was für Leute, die Fehler machen. 
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Oli am 31.03.2020 14:17]
|
|
|
|
|
|
|
|
|
Danke. Mehr?
| | Zitat von Oli
Catch2, nie was anderes benutzt. Header only, modern, clion integration. | |
Hehe. Genau das hat mein Kollege vorgeschlagen 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Website +
Ich sollte nicht in Gefahr laufen daran gefallen zu finden 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Danke allen. Abstimmung mit Kollegem hat Catch2 ergeben.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
