Aby nebylo nutno nahravat cely kontejner Veracryptu, bylo by sikovne, kdyby existoval nejaky bazmek, ktery by dokazal prezentovat serii malych souboru jako jeden soubor. Clovek by vytvoril urcity pocet souboru, napriklad o velikosti urciteho nasobku alokacni jednotky a pomoci zmineneho bazmeku je podstrcil Veracryptu, ktery by pracoval s dobrym pocitem, ze ma pekny celistvy kontajner. Synchronizovany by pak byly ty male soubory.
Jedine, co jsem takoveho nasel v pouzitelnem stavu, je kombinace nbd-client / nbd-server (parametr -m). Ne moc prakticke a kdyz jsem to zkousel, byla to zrovna jedna z veci, ktere v Ubuntu nefungovaly a ktere nikdo neopravil.
Krome toho jsem nasel jakesi 2 pokusy o vytvoreni fuse FS, ktery by ukladal data jako serii bloku stejne velikosti. Bohuzel nebyly v pouzitelnem stadiu.
Eventuelne by poslouzil bazmek, ktery by dokazal prezentovat velky soubor jako serii segmentu zvolene velikosti. Tedy kontajner Veracryptu by byl v jednom souboru, kloudovemy synchronizatoru by byl prezentovan obraz kontajneru rozsekaneho na kousky.
Nejake napady, jak udelat jedno nebo druhe?
A co wedos disk: http://www.riz.cz/w5x5c - tam se dá udělat kontejner a připojit ho přímo přes CIFS (sambu). Zapisují se změny přímo do kontejneru.
Tuším že atoři Cryptomatoru slibují že Cryptomato nemá některé chyby které má encfs atd.
@Jarda_P
"..Aby nebylo nutno nahravat cely kontejner Veracryptu, bylo by sikovne, kdyby existoval nejaky bazmek, ktery by dokazal prezentovat serii malych souboru jako jeden soubor. "
Budto sem nepochopil zadani anebo znovuvynalezas kolo.
Incremental backup ma snad kazda sluzba s aspon minimalnim respektem k sobe same.
https://en.m.wikipedia.org/wiki/Tarsnap je asi to nejlepsi co je k mani, vcetne lokalniho sifrovani, rSync je taky pouzitelnej anebo snad i SpiderOak (ikdyz closed source tak podle Snowdena prej pro NSA prej celkem bolehlav.)
Kdyz sem ho zkousel a uploadoval TC kontejner tak nikdy neposilal pri zmenach celej kontejner.
Na 2.stranu je potreba si uvedomit ze DOBRY sifrovani vykazuje pomerne velkej overhead kterej vyplyva z pricipu jakym crypto funguje a kdy je ZADOUCI mit na vystupu "nahodna data" bez ohledu na velikost zmeny na vstupu. Toho se neda dosahnout 1 iteraci a tak i mala zmena vstupu se zpropaguje na vetsim poctu bitu.
Podobne jako treba hashovani=zmena 1 pismena na strance textu prekope totalne celej hash.
Castecne to vysvetluje tenhle clanek
https://pthree.org/2012/02/17/ecb-vs-cbc-encryption/
OT: zajimave napsanej clanek
http://neviditelnypes.lidovky.cz/noviny-a-trump-valka-do-uplneho-vycerpani-fgs-/p_zahranici.aspx?c=A170113_095146_p_zahranici_wag
Toho dobytka ze CNN sem videl, Trump to vyresil s prekvapivym klidem, osobne "bysom ho oknom vyhadzal a este by som ho vo vzduchu do rici nakopal" :-)