To mě zajímá. Jak uděláte transparentní šifrování na FS bez toho abyste měnil on-disk structures? Navíc FAT32 má pro podobné účely rezervované bity a popsané jejich chování, takže ve zvolené implementaci nevidím problém.
Ze byste treba zavedl novou hlavicku souboru, ktera rekne OS, ze se jedna o sifrovany obsah? Zpetna kompatibilita je zarucena. OS, kde to neni implementovano, uvidi jakysi soubor s binarnim bordelem.
Neblbni cece, to by nebyla M$ way, a dokonce by to i fungovalo. A dokonce to tak i funguje - teda pokud si nainstalujes non M$ appky ktery sifrujou jednotlivy soubory.
Stačí na to poštvat implementaci fsck, která dodržuje specifikaci. A protože ve specifikaci se říká, že bity by měly být 0 (alespoň v té vydané, jinou nikdo nikdy neviděl), tak když je najde ve stavu 1, tak je vynuluje. To bude legrace, až se takové zařízení vrátí do Windows 10 a tam budou šifrované soubory rázem nečitelné, protože nemají ty bity v 1.
Kecáte, znovu cut-paste ze specifikace: "Reserved for use by Windows NT. Set value to 0 when a file is created and never modify or look at it after that." Z čeho usuzujete, že by tyhle bity měla "implementace fsck, která dodržuje specifikaci" vynulovat?
Mno dment jako ty samo nedokaze pochopit, ze kdyz mam nastroj na opravy disku, tak bit nastavenej do 1 tam, kde ma byt 0 je jaksi presne jedna z tech chyb, ktere by bylo zahodno opravit, ze.
To by me ty imbecile zajimalo, co asi tak vsechny tyhle veci budou delat se souborem, kterej ma ten bit nastavenej widlema. Nj, POSEROU SE. Protoze je jim predlozeny cosi, co nesplnuje specifikaci.
Jeronýmku, vy ignorante, staré implementace FAT32 samozřejmě soubor nedešifrují a přečtou ho v RAW mode (tj. uvidí data v šifrovaném stavu).
Vsak to davno implementovano je, i pro widle, to jen M$ ma naprosto neschopny (nebo vsehoschopny?) trotly misto programatoru. Muzes nainstalit (i do widli) appky, ktery proste soubor zasifrujou a zadny bity na disku k tomu nepotrebujou.
Jenze to by se M$ po 30ti letech musel naucit pouzivat hlavicky souboru misto nejakych priblblych pripon.
Hlavičky souborů jsou v principu nespolehlivé. To že má soubor na nějakém offsetu pár konkrétních bytů nijak jednoznačně neurčuje jeho typ. To že soubor začíná "Return-Path:" z něj nedělá EML, to že začáná na "SQLite format 3." z něj nedělá SQLite DB file. A například v nešifrovaném souboru .bin můžu mít z mnoha důvodů klidně uložený šifrovaný JPEG ve formátu EFS. Pokud budete používat hlavičky, automaticky ho dešifrujete, a bude to zcela špatně. Podobně můžu mít těch pár bytů, podle kterých byste chtěl rozeznat šifrovaný soubor, náhodou například ve video streamu nebo JPEGu.
Jasne, protoze M$ udela sifrovanej soubor a neumi si k nemu pridat dostatecne jednoznacnou hlavicku. Vis ty trotle, ze na hlavickach je zalozenej celej internet?
Za takovou implementaci šifrování rádi opravdu nebudou, protože jak vidno, tak to není kompatibilní není.
Implementace šifrování na FAT32 je kompatibilní se všemi předchozími implementacemi FAT32, které se drží MS specifikací podle kterých měly být napsané. Jediný problém je u Sound Devices, a to díky tomu že se specifikace nedrželi.
PS: Ale MS jde o to, aby dožduchali všechny uživatele starší verze Windows do desítek a tohle je jeden z háčků. A až bude hromada věcí v cloudu (jakože s Windows 10 to posunuli o několik levelů výš), tak se budou uživatelé (čti ovečky) ovládat zase o něco snadněji. 
Cloud přináší výhody. Například můžete mít ta samá data přístupná z desktopu, notebooku i telefonu. Samozřejmě k tomu ta data musíte uložit na nějaký server, a to obnáší rizika v oblasti bezpečnosti a ochrany soukromí. Pokud vám taková rizika nestojí za přidanou hodnotu (mě rozhodně nestojí), tak data do cloudu neukládejte.
Kompatabilni zcela jiste neni, jak tu uz dobra duse dokazala experimentem, co na to rikas luliku? Hovno vid? Protoze ste mu prave zkurvili jeho zasifrovany data svoji nekompatabilni zmenou FS.
Trosku od tematu, ale som tiez zhrozeny. Neveril som tomu, ale stalo sa mi to, pod rukami sa mi resetoval Windows 10. Nemal som moznost nic urobit, len zrazu nevypinajte pocitac resetuje sa. Mac os vyhodi dotierave okno kde treba nieco stlacit a ked dorobim tak ho stlacim ale resetnut sa pod rukami to je hroza. Ak to urobi este raz tak na ten nb vratim Ubuntu.
Heh, muzu potvrdit, mel sem na tom pustenej wireshark, a po cca 2 hodinach sem prisel, a bylo to resetly
Heh, ted sem si vzpomel, existoval kdysi takovej pekne softik jeste pro DOS, a v nem byl popis assambleru, vsech funci DOSu, vsemoznych preruseni atd. Nevzpomenu si jak se to jmenovalo. Ale co si pamatuju je, ze u hromady tech funci byla poznamka, ze jde o nezdokumentovanou funkci. Byly to samozrejme ty nejzajimavejci veci, ktery M$ ve velkym pouzival a ostatnim tvrdil, ze nic takovyho neexistuje.
Nebyl to nahodou SYSMAN ?
Jop, to bude ono asi, jeste k tomu bylo neco podobnyho s podobnym nazvem.
Provedl jsem následující experiment:
1) ve Windows 10 jsem naformátoval flashku FAT32 (4 GB),
2) nakopíroval na ni soubor (log, cca 280 KB),
3) zašifroval,
4) odpojil flashku a připojil na Windows 8.1 (plně aktualizovaný).
Název souboru je obohacen sufixem .PFILE a obsah souboru je samozřejmě nečitelný (zdá se, že se tam objevila nějaká hlavička). Velikost souboru je cca o 4 KB větší.
5) vytvořil jsem adresář na flashce a zkopíroval do něj ten šifrovaný soubor,
6) prohlédl na Windows 10.
Původní soubor je bez problémů čitelný (samozřejmě za předpokladu, že uživatel disponuje příslušným klíčem). Je ale vidět, že FAT32 driver (fastfat.sys) ve Windows 8.1 dodržuje starší verzi specifikace (EFS bit je považován za reserved), takže při vytváření nového souboru nuluje reserved bity v jeho directoory entry. Tudíž zkopírovaný soubor dešifrovat nelze, neb není označen jako šifrovaný (nevím, zda by pomohlo, kdyby tak byl označen např. přímým přístupem na "disk").
Takže tak.
ByCzech:
Co se týče toho ničení dat, můžete se mrknout do zdrojových kódů ovladače fastfat, je součástí balíku Windows Driver Kit. Sice tam nebude nejaktuálnější verze, ale nemyslím, že by zapisování do struktur FS při čtení byla nějaká novinka. Samozřejmě to může být i tak, že dané zápisy provádí nějaký FS filter/minifilter nad instancní daného FS.
Diky, potvrzeni toho, co sme vsichni vedeli predem. Jinak receno, kdyz si typickej BFU bude nosit soubory na flashce, a nejakym omylem si zapne sifrovani, tak o ty soubory proste pri nejblizsi prilezitosti zcela kdekoli prijde. A i kdyz o ne nahodou neprijde, tak mu na 80% mistech kam prijde budou knicemu, protoze je nepujde precist. Eto technika ....
Tak jo, predpokladejme, ze dam na disk binarni data, kde zrovna nahodou na zacatku bude kombinace, ktera odpovida hlavicce MS sifrovaneho souboru. No, vzhledem k tomu, ze dneska par bajtu nikdo neresi, co brani MS, aby si za tu hlavicku ulozil napriklad nejakou dalsi znacku (overeni hlavicky), podle ktereho by vznikla temer jistota, ze dat jsou bud binarni bordel nebo sifrovany soubor? Diskety uz nikdo nepouziva, tak treba deset nabo i dvacet bajtu nikoho nezabije. Jaka je pravdepodobnost, ze vytvorim binarni blob, kde treba 20 bajtu bude stejnych? Krome toho v takovem souboru muze byt treba kontrolni soucet nebo se treba pozna, ze to nejde rozsifrovat. A i kdyby, tak pokud MS do toho nebude zasahovat, nic se nestane. Pokud uzivatel neni zretelne blby, tak si vsimne, ze se soubor rozsifroval jako binarni bordel a vzpomene si, ze to neni sifrovany soubor.
Cece neblbni, jeste bys moh dojit k tomu, ze kdyz uz je soubor sifrovanej, muze byt i podepsanej. Bezne se veci delaji tak, ze mas nekde nejakej identifikator, a kdyz sedi, tak se podivas na zbytek, kdyz ne, tak to neresis. Ostatne, presne stejne funguje ten tux, to ze ma neco na zacatku par bytu jeste neznamena, ze to nutne je obrazek, ale kdyz to obrazku odpovida, tak se du podivat na zbytek toho souboru. Jak nelogicke ...
Nemáme jistotu, že se jedná o identickou kopii, protože přídavné struktury pro EFS jsou neznámé, ale v zásadě souhlasím. Je to škoda.
...
Opravné pokusy jsou jen moje doměnka. Vůbec tomu tak být nemusí. Zdrojáky fastfat jsem komplexně nečetl, jen určité malé části.
... je uplne jedno co se tam deje, vysledek je z pohledu uzivatele zcela jednoznacny - prisel o data a neumi to spravit. A neumi to spravit ani M$, protoze neumi rozpoznat vlastnim systemem zasifrovanej soubor. To je vysledek doslova katastrofalni.
682 Odpovědí
121051 Zhlédnutí