Titkosítás, melyik, hogyan, miért, stb...

Gentoo

Volt valaha ez a szál: https://hup.hu/node/147118, meg még megannyi itt a titkosításról. Szinte mind végigolvastam és mint mindig, van ezerféle megoldás, vélemény. A kérdés: van ma még létjogosultsága a Truecryptnek? Van valami más ami megoldja a linkelt topic kérdését ( truecrypt loader egy USB flashdrive-on, a laptop MBR-jében semmi, a HDD partíció meg üresnek látszódott)? Azt tudom, hogy a mai napig sokan használják még a legutolsó verziót (esküsznek rá, hogy a mai napig sem tud egyik sem a nyomába érni), de tényleg nem tud egyetlen másik sem annyi mindent? Gentoo-hoz van layman overlay Truecrypttel, de már rég nem lehet telepíteni a függőségek miatt. Kíváncsi vagyok, hogy mivel lehetne teljes értékűen kiváltani? (tudom, luks vagy veracrypt, viszont ezek egyike sem tud mindent amit a truecrypt)

  • 1261 megtekintés

( dotnetlinux | 2021. 01. 04., h – 07:52 )

Mivel macska-egér harc van az adatok ellopasa-vedelme harcban, ez olyan mint a vitamin. Az egyik 2000mg, a másik 125mg, de mégis mindentől (is) véd. Annyi előnyös van, hogy tájékozott vagy nem pedig marketing vezérelt, a védelme így jobb. De nincs 100%.

( zrubi v | 2021. 01. 04., h – 09:11 )

szvsz a linkelt topikban szereplő 'elvárásokat' eleve lehetetlen teljesíteni....

Régen volt a TrueCrypt, amivel meg lehetett oldani a rejtett partícióról való boot-olást ( truecrypt loader egy USB flashdrive-on, a laptop MBR-jében semmi, a HDD partíció meg üresnek látszódott).

Ez eleve értelmetlen.

Egészen biztosan NEM látszódhatott üresnek az a HDD. maximum laikusok számára.

 

Nekem olyan megoldás kellene hozzá, ami "plausible deniability"-t ad.

Ilyen egyszerűen NEM létezik.

Lehet hogy a szomszéd pistike, vagy tolvaj aki ellopja nem látja hogy azon volt-e valami, de egy hozzáértő egészen biztosan....

 

A titkosítás szép dolog, de nagyon sok specializált fajtája van, ebből fakadóan is: egyik sem jó mindenre is.

Ahhoz hogy értelmes, és hasznos választ kapj, meg kellene fogalmaznod pontosan mit is akarsz megvalósítani.

 

szerintem.

zrubi.hu

Valójában csak érdeklődöm, nincs konkrét megvalósítási igény. Volt már tervben, hogy ismerkedem ezzel, de most realizálódott. Öreg barátom esküszik a Truecryptre (szerintem még nátha ellen is :D ) és pár napja megint volt egy beszélgetésünk erről (is). 

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Volt már tervben, hogy ismerkedem ezzel, de most realizálódott.

Jó nagy fába vágtad a fejszéd ;)

 

De ha tényleg érdekel, akkor az irányok gyakorlati szempontból:

- levelezés titkosítása PGP, S/MIME

- Block device (LUKS, dm-crypt, Bitlocker, Truecrypt, Veracrypt, etc)

- TCP/UDP stream (SSH, TLS, IPSec)

Ezek kapcsán: PKI, Certificate Authority, SSL Certificate

 

Ezek a gyakorlati megoldások pedig a következő elmeket (általában többet is egyszerre) használják:

 

- Hash

pl MD5, SHA1, SHA-*, SHAKE-*

- Symmetric

pl: DES, 3DES, AES, Blowfis,etc

- Asymmetric

pl: RSA, ElGamal, Elliptic Curve,

- Quantum :)

 

Ha ezekre a kulcsszavakra keresel, akkor biztosan találsz több tanévre való anyagot az interneten ;)

Ha meg már eljutottál odáig, hogy meg tudsz fogalmazni egy vagy több kontkér kérdést, akkor kapsz majd rá választ is

(jó sokfélét :)

zrubi.hu

Olyan van, hogy a szakérő számára is "üresnek" látszik. Nem üres abban az értelemben, hogy nem csupa nullával van teleírva, de üres abban az értelemben, hogy semmilyen módszerrel nem különböztethető meg random számok halmazától. Gyakorlatilag minden valamirevaló titkosítás ilyen.

A plauzible deiability lényege az, hogyha nagyon vernek, hogy mondd meg a jelszót tudsz egy olyan jelszót mondani amivel értelmes adat jön elő, de nem az, amit titkolni akarsz. A legegyszerűbb megvalósítása az, hogy a device üres helyét nem valódi véletlenszámokkal töltik fel, hanem titkosnak látszó adatok titkosított változatával. Ha ennek a jelszavát mondod meg lehet, hogy a verőember megelégszik ezzel.
A probléma csak az, hogy a TrueCryptről lehet tudni, hogy van ilyen lehetőség amit vagy bekapcsolsz vagy nem. Tehát ha mondasz is egy jelszót a verőembernek amitől előjönnek fájlok nem fogja abbahagyni a tevékenységét, mert hátha van egy második réteg is, akkor van a gáz, ha nem állítottál ilyet be, mert már nincs mit mondani.
Szerintem a legjobb megoldás a szteganográfia. Ha a titkos információk nem véletlen adatokban vannak elrejtve hanem mondjuk nyaralásról szóló képeken egyes pixelek színeinek utolsó bitjének a zajában. Ha valahol véletlen bitsorozatot találnak gyanús, hogy az valamilyen titkosított adat ha képeket, videokat az nem gyanús.

Olyan van, hogy a szakérő számára is "üresnek" látszik. Nem üres abban az értelemben, hogy nem csupa nullával van teleírva, de üres abban az értelemben, hogy semmilyen módszerrel nem különböztethető meg random számok halmazától. Gyakorlatilag minden valamirevaló titkosítás ilyen.

Éppen ezért minden valamire való szakember azt fogja mondani egy véltelenszerű adatokkal teleírt diszkre, hogy

- valószínüleg titkosított adatokat tartalmaz

- vagy pededánsan teleírták random adattal :)

De semmiképp nem mondja, hogy ezen nem volt/van semmi. Mert az nagyon nem valószínü.

 

szerintem.

zrubi.hu

Vagy volt valami amit random adatok felülírásával töröltek. A lényeg, hogy nem bizonyítható, hogy van rajta adat. Nyilván nem úgy kell titkolózni, hogy az egész lemezen csak random adat van. Ha valaki komolyan akarja csinálni simán bootol egy operációs rendszer és van rajta néhány nagyobb fájl random adatokkal. Mondjuk legyen a neve background_radiation.bin és ha van egy GM számlálód is akkor már az a valószínűbb, hogy véletlen számok.

nagyon light verziója ennek, hogy beavatkozás nélkül mondjuk bootol egy fake rendszer, kisebb beavatkozással (pendrive jelenléte, BIOS boot menüben választás, ilyenek) pedig a valóban használt rendszer.

 

Ezt szvsz simán bejön egy esgzerű rendőr, biztonsági őr, vagy reptéri check-nél is.

De ahol már testi erőszakot alkalmaznak, ott teljesen mindegy, mert az IT megoldások azellen nem védenek.

 

szerintem.

zrubi.hu

( sigellef | 2021. 01. 04., h – 13:17 )

Érdemes megfontolni, hogy nem elég-e csak fájlok szintjén titkosítani. Ami olyan, összetömörítem, titkosítom, aztán mehet a vakvilágba, vagy pendrive-ra.

openssl rc4 -k jelszo -in file.tar.gz -out file.tar.gz.rc4 -p -nosalt

openssl rc4 -k jelszo -in file.tar.gz.rc4 -out file.tar.gz -p -nosalt

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

- az RC4-et jobb nem használni

- ha nem írod felül a nyílt fájlt, akkor elérhető marad a lemezen (SSD esetén nem egyértelmű)

- egy nem technikai ember nem feltétlenül akár fájlonként titkosítani: sokkal egyszerűbb az egész notebookot titkosítani

Azaz fájl szintű titkosítás akkor lehet jó megoldás, ha a továbbító csatorna nem védett (ez lehet egy pendrive is).

Rájöttek valami gyengeségére így könnyen törhető. Sok protokollból ki is szedték/tiltották emlékeim szerint.

Általánosan AES a válasz a kérdésedre, kulcshossz attól függően, hogy mire szeretnéd használni, 256 bittel nehéz mellélőni, de 128 bit is lehet jó választás.

Elég sok attackra érzékeny: https://en.m.wikipedia.org/wiki/RC4#Security

Az AES jó választás, ha elhiszed a 3-4 betűs ügynökségeknek, hogy biztonságos, én személy szerint jobban bízok David Bernsteinben, akinek a nevéhez fűződik többek között a ChaCha20, Salsa20 cipher, a Poly1305 message auth code és az EDDSA (a NaCl/libsodium library ad kb. mindent, de ma már inkább az XChaCha20Poly1305 a menő¹⁻², amiről RFC is szól). Ezek modern megoldások, és nincsen ismert gyengeségük. Vagy még senki sem publikálta :)

_____________________

¹ https://docs.rs/chacha20poly1305/0.3.0/chacha20poly1305/struct.XChaCha2…
² https://github.com/golang/crypto/blob/master/chacha20poly1305/xchacha20… a https://pkg.go.dev/golang.org/x/crypto package-ben.

Az AES-t nem ügynökségek fejlesztették ki, hanem belga kriptográfusok, eredetileg Rijndael néven futott, mikor beszálltak az AES pályázatba. Akár a ChaCha20 is lehetne a következő szabvány, pl. NgES (Nextgen Encryption Standard) a DES-t és AES-t követően.

A teljességhez az is hozzátartozik, hogy az AES is már 20+ éves, találhatnak ki még jobb teljesítményű algoritmusokat. A nehézség a bizalom kérdése: bármilyen lángelme találhat ki olyan algoritmust, ami egyszer csak összedől, mint a kártyavár (lásd RC4, amit Rivest alkotott meg). A ChaCha20 is 10+ éves, valószínűleg kellően biztonságos, de ugyanúgy nem zárható ki, hogy a megvalósításba becsúszik valami kiskapu, merthogy elméletileg hiába jó valami, ha a megvalósítással probléma van.

Wikipédia szerint: "ChaCha20 usually offers better performance than the more prevalent Advanced Encryption Standard (AES) algorithm on systems where the CPU does not feature AES acceleration (such as the AES instruction set for x86 processors), or where the software does not implement support for it. As a result, ChaCha20 is sometimes preferred over AES in certain use cases involving mobile devices, which mostly use ARM-based CPUs."

Tudom, hogy ki fejlesztette ki az AES-t, ezúttal szakemberekre bízták :-D Kb. 10 éve (akkor mág ráértem ilyesmire) végig is próbálgattam az utolsó körös algortmusokat.

Szerintem az AES (leánykori nevén Rijndael; ja igen, írod is) semmiben sem kiugróan jobb a többi finalistánál. Hogy mégis miért ezt választották? Megvan bennem az a pici kétely, hogy esetleg találtak egy olyan gyengeséget, amit nem hoztak nyilvánosságra. Ez 99,99% konteó, de csináltak az amerikaiak ennél nagyonn böszmeséget is: ismerjük a szándékosan implementált és publikált gyenge FIPS PRNG történetét.

Amúgy általában nem vagyok az AES ellen, de ha lehet választani, inkább mást (szerintem jobbat) választok. 

Igen, amúgy, pl. az RSA mellett és az ECC-vel szemben is szoktak érvelni: a prímszámokkal kapcsolatban van kb. 2500 év tapasztalatunk, az elliptikus görbékkel meg 30 vagy 40 (ami ugye nem igaz, mert pont a múltkor olvastam Jakobitól latinul az elliptikus görbékről :-D;na jó, az ECC-vel kapcsolatban igaz lehet a 40 év).

Sajnos az mindig benne van a pakliban, hogy valamelyik megoldásról kiderül, hogy lett ismert gyengesége. Valamelyik nap olvastam, talán a GPG leírásában, hogy a 2048 bites RSA elegendő védelmet ad akár 2040-is is... Vagy nem :-) Mert ha hirtelen nagyot fejlődik a kvantum-számítástechnika, akkor hamar át kell állnunk másra.

a megvalósításba becsúszik valami kiskapu

És ez pedig a legizgalmasabb kérdés. Ha a laptopomon titkosítok valamit, nem túl valószínű, hogy side channel attack áldozata leszek. De bizony előfordulhat más szituációkban. Ezt mérlegelni kell.

Szerintem amúgy csak idő kérdése, lesz ARM-on is hardveres AES támogatás. Reméljük.

Itt meg is említesz egy másik fontos mozzanatot a megvalósítás mellett: PRNG. Ha nem kellően véletlen a kulcs, akkor hiába alkalmazza valaki a legjobb algoritmust, az egész mehet a levesbe, hiszen akár jelentősen is lecsökkenhet a kulcstér.

A megvalósítás, kulcsgenerálás mellett az alkalmazott protokoll sem mellékes: eklatáns példa a közelmúltból a Zoom, ahol a kulcsot nem is a végpontok generálták, hanem a szerver... és mégis volt képük E2E-nek titulálni.

Ez egész jól összefoglalja a helyzetet: https://medium.com/asecuritysite-when-bob-met-alice/rijndael-v-serpent-…

Az Rijndael elsősorban azért nyert, mert szoftveresen jobb teljesítményű, mint a Serpent (ami valamivel biztonságosabb).

A leírás alapján szavazással dőlt el, hova billenjen a mérleg (a szavazókat nem találtam meg), de ne felejtsük el, hogy 2000-ben történt mindez, amikor a számítási kapacitás más szinten volt, mint ma, így a szoftveres teljesítmény valóban erős érv volt.

https://en.wikipedia.org/wiki/Advanced_Encryption_Standard_process "NIST won praises from the cryptographic community for the openness and care with which they ran the standards process. Bruce Schneier, one of the authors of the losing Twofish algorithm, wrote after the competition was over that "I have nothing but good things to say about NIST and the AES process."[10]"

Szerintem a bugoktól és az algoritmus köré épülő elemektől jobban félj :-) Elég arra gondolni, hogy PC környezetben mennyire lehet jó véletlenszámokat generálni, tipikusan "pillanat alatt".

Ha már konteó és kvantumszámítástechnika: én nem követtem a nagy publikumnak szánt felületes híreknél jobban a kvantumszámítógépeket (Google mellett talán az IBM-nek is van), de itt nem lehet valami mismásolás a valós lehetőségekről? Ezt olyan területnek érzem, ahol az ügynökségeknek komolyan érdekük, hogy titokban tartsanak bizonyos képességeket és lehetőségeket. Talán pont a Google kapcsán merült fel már korábban is, hogy fedő sztorikkal és cégeken keresztül nem kevés támogatásokat kaptak a kormányzattól bizonyos projektekhez, ez is tökéletesen idepasszol.

Félek, ha bármit is írnánk, az csak konteó lenne.

Ha én lennék az NSA (vagy KGB vagy TEK :-D), én is azt szeretném, ha a saját megoldásomat ne tudják feltörni, én viszont bárki tititkos(nak vélt) üzenetét el tudjam olvasni. A franciák törvénnyel oldják meg, ami legalább nyílt és egyenes, más meg esetleg máshogy.

A kriptográfiában szerintem nagyon nagy csapda a biztonság érzete.

Néhány gondolat illetve vélemény.

Szerintem szükségtelen attól félni, hogy az NSA-nél találtak ,,valamit", ami a világ vezető kriptográfusainak elkerülte a figyelmét. Ráadásul az AES algoritmusát pont arra választották ki, hogy government szinten is azt használják titkosításra.
Amit viszont érdemes végiggondolni, hogy a befutó algoritmus kiválasztásakor nem a nyújtott ,,biztonság" volt az egyetlen szempont. Hanem pl. az implementálhatóság különböző platformokon, illetve az algoritmus CPU-szükséglete, illetve további, főleg rugalmassági szempontok.
Biztonságosnak tartom az AES-t, igaz, saját célra mást preferálok: a TwoFish-t (mert én meg Bruce Schneier rajongó vagyok). Ez pl. pont jóval CPU-intenzívebb a Rijndaelnél, ami negatívumként esett latba a kiválasztáskor.
Az AES ellenében talán azt lehetne felhozni, hogy a kiemelt szerepe miatt ehhez fejlesztenek a legintenzívebben gyorsítóhardvereket. De még ezzel együtt sem gondolom, hogy aggódni kéne a törhetősége miatt.
Ha paranoiás vagy, tegyél kaszkádba két algoritmust. A lehetetlennel határos, hogy az törhető lesz.

A modern szimmetrikus algoritmusok szerintem bárki számára törhetetlenek. Még egy NSA vagy Google bicskája is beletörik.
A számítási kapacitás fejlődése messze nem elég ahhoz, hogy egy ilyen algoritmus törése testközelbe kerüljön. De még ha így is lenne egyszer, akkor is komoly költség lesz egy ilyen manőver, így nyomós ok kell, hogy valaki pont a Te vackaiddal foglalkozzon.

A valódi kockázatot nem maguk az algoritmusok jelentik. Hanem az implementálás, ahogy valaki korábban írta is. Még a fordító optimalizációi is kitolhatnak az emberrel, olyan side-channel attackot lehetővé téve, amivel gyerekjáték meghatározni a kulcs bitjeit. Ez akár a laptopodon is valós veszély.

Ha meg akarnak csípni, nem a kriptódnak fognak nekimenni. Ott támadnak, ahol még vagy már plaintext az adat. 0day vagy malware sokkal egyszerűbb, olcsóbb és gyorsabb megoldás. És nem vagyunk híján egyiknek sem.

Így nem az algoritmus kiválasztása a legfontosabb feladat. Ott nagyon mellélőni nem tudsz.
Szerintem a luks/dm-crypt jó választás. Ha nagyon kell a cross-platform, akkor pedig a TrueCrypt folytatásának tekinthető VeraCrypt. A legutolsó TrueCrypt verzióval sincs komoly gond, néhány minor vulnerablityje derült ki úgy emlékszem, amik egyes helyzetekben jelentenek veszélyt. Ezeket a VeraCrypt-ben javították, illetve javítják amikor valami kiderül.

Határozd meg a célokat. Milyen adatot szeretnél megvédeni, kiktől, milyen szituációkban.
Ha közben ideiglenesen diszkre kerül a plaintext (pláne SSD-re), semmit nem ér az egész.
De semmit nem ér az OTFE se, ha jön a malware vagy a 0day, vagy akár csak rajtad ütnek, amikor fel van mountolva a diszk.
Olyan gépen legyen, amin nincs kifelé netkapcsolat és a diszk is csak addig legyen mountolva, amíg feltétlenül szükséges (dolgozol az adatokkal).

Nekem van egy cold diszkem a NAS-on, ami egyébként a backup is. Ezen van egy dm-crypt partíció. Csak akkor mountolom, amikor kell róla valami. A laptopomról NFS-en érem el, ha kell (jobb, mintha át kéne scp-zni és odakerülne a gépemre a plaintext). Távolról nyilván VPN-en.
Kockázatként elfogadom, hogy egy jól felépített, megtervezett támadástól ez sem véd meg. De még mindig jobb, mintha egy win10-es desktop gépen lenne mindez.
Illetve nincs rajta olyan adat, ami egy piaci szereplőnek vagy hatóságnak érne annyit, hogy ,,rám álljanak". (Személyes dolgokat és a munkám egyes területeit védem vele.)

Egy laptopnál amit hordozol pl. egészen más szempontok vannak. Ott a lopás veszélye a legnagyobb, illetve hogy külföldre utazáskor vegzálhatnak. Korábban sokat utaztam Kínába és Tajvanra. Soha nem vetettek alá ilyen jellegű ellenőrzésnek, de azért ott motoszkált bennem a gondolat, hogy mi van, ha.
Egyszer volt, hogy elvették tőlem az útlevelemet és bevittek. De egészen más érdekelte őket.
Azért ott nem vicces dolog bármilyen hatósági eljárás alá kerülni. Az ember hamar elveszíti a humorérzékét.

Ilyen helyzetre jobb, ha úgy készülsz, hogy
- ami nem feltétlenül szükséges, ne is legyen rajta a gépeden
- ami nálad van és bármilyen okból nem akarod mutogatni, az ne csak kriptózva legyen, de eldugva is (de fontos, hogy ne kelts gyanút)
- ne becsüld alá a másik felet
- ne bukd el a bizalmat baromságokon (még ha nem is kerülsz komoly bajba, lehet, hogy soha nem kapsz többet vízumot)

Ilyen esetben jó lehet a plausible deniability, de azért gondold végig előre a szituációt.
Pl. hivatkozz rá, hogy a munkáltatód követeli meg a kriptót a céges laptopokon. És a b-jelszóval való felnyitáskor tényleg a munkáddal kapcsolatos dolgok legyenek ott, ne a Queen diszkográfia meg a Tom és Jerry hatodik évada.

Ezeken kívül persze még rengeteg szituáció és use case létezik.

( YleGreg | 2021. 01. 04., h – 16:40 )

Eloszor talaljuk ki, hogy ki ellen akarunk vedekezni. A ROT13 tok jo arra, hogy ket kisiskolas ora kozbeni levelezeset ne tudja elolvasni a tanar, de masra nem. A zip jelszava arra jo, hogy egy filecserelon a tanarnak kuldott dolgozatot ne nyithassa meg barki a vilagon, de a harombetus szolgalatok kaveszunetben kinyitjak ha akarjak. Egy Truecrypt/Veracrypt/LUKS/bitlocker titkositassal vedett vinyot ugy tudom, hogy mar ok sem tudnak feltorni, de mivel elemi erdekuk, hogy mindenki ezt gondolja, hat a fene tudja.

Egy alap LUKS a notin nem a hivatali szervek ellen valo, (nekik muszaj atadni a jelszot ha jol tudom), hanem arra, hogy ha ellopjak a vonaton, akkor mielott eladjak az aluljaroban, ne szedjek le rola a ceges titkokat, meg a csaladi fenykepeket. Max az asszony elol celszeru eldugni a kedvenc pornokepeidet egy Truecrypt kontenerbe, vagy ha tobben hasznalnak egy gepet akkor mindenkeppen, mert az eleg cinkes, ha a gyereked kerdezi meg, hogy Apa, abban a csupa X konyvtarban kik azok a meztelen nenik? Anya baratnoi?

Ha valaki attol fel, hogy kiverik belole a jelszavait, akkor valtson szakmat. 

A Veracrypt nevű fork-ot néhány éve megvizsgálták. Nem tudom most mi a helyzet vele (meg hogy 2021-ben van-e még értelme egy Truecrypt forkot használni), de az akkor talált dolgokat kijavították.

 

https://blog.quarkslab.com/resources/2016-10-17-audit-veracrypt/16-08-2…

Én ~3 éve használom a mostani gépemben (Samsung 970 EVO), semmi bajom nem volt vele: sem UEFI-vel, de szerintem a TRIM is működik (https://www.veracrypt.fr/en/Trim%20Operation.html). TPM hiánya nem zavar, úgyse használnám.

Statisztika: 99%-os állapot, 230TB olvasás, 80TB írás, közel 10e óra üzemidő.

Baj, ha kompromittálódott? Akkor most félhetek a hárombetűsöktől?

Nekem egy régi Win7 -em rendszerlemeze még azzal van titkosítva.

Ha betörnek és viszik a gépet a színes fémgyűjtő népek, akkor nekiállnak törni, merthát kompromittálódott, vagy format azt megy a gép a vaterára?

A biztonság nem nulla vagy egy, hanem egy törtszám. Bizonyos helyzetekben elég a gyengébb titkosítás is, én legalábbis egy perc időt sem áldozok azért, hogy Truecryptről mondjuk Bitlockerre váltsak a játszós gépen.

( dzsolt v | 2021. 01. 08., p – 07:25 )

Köszönöm az infókat! A konkrétum az volt, hogy beszélgettünk az öreggel aki foggal/körömmel titkosít mindent (IS) lokálban és nem értem a koncepcióját! Itt azért vannak mások is olyan véleményen, hogy a rendszert titkosítani ugyan minek és én e mellett érveltem, hogy a futó rendszer titkosítása szerintem felesleges erőforrás pocsékolás. Az egyetlen amit fel tudtam hozni példának (ahol nagyon is szükségét látnám) az a cloudokban tárolt adataink titkosítása, ezt ő nem tartotta relevánsnak, mert a cloud már a hozzáférése miatt is jól rejtett (szerinte). Hozzáteszem, MS hálózattechnikus és oktató erősen MS szemlélettel.

Személy szerint nincs olyan igazán  titkosítandó anyagom (természetesen a személyes dolgaim kivételével ami pedig nem államtitok :) ) ami indokolttá tenne egy nagyfokú titkosítást, de mondjuk a home könyvtáram (leginkább a mindenféle hozzáférési adataim (ssh, banki adatok, stb...) miatt). Ezidáig semmi fogalmam nem volt a titkosításokról és jó, hogy itt most több véleményt/leírást olvashatok. Jöhet még, követem a szálat!!!

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

a futó rendszer titkosítása szerintem felesleges erőforrás pocsékolás [...] mindenféle hozzáférési adataim (ssh, banki adatok, stb...) miatt

Én sok éve titkosított rendszeren dolgozom, de soha nem éreztem, hogy valami visszahúzna. Talán akkor lehetne érezni, ha hosszan lenne nagyon intenzív I/O és mellette CPU terhelés (például fordítás közben biztonsági mentés), de ez egyáltalán nem jellemző.

Szelektíven fájlonként titkosítani nagyon macerás lehet, mert a nyílt változat biztonságos törléséről minden esetben gondoskodni kell. Őszintén szólva nem is tudom, hogy SSD esetén ezt miként lehet normálisan megcsinálni fájl szinten. A Windows tud mappa szintű titkosítást, az talán középút lehet, de szerintem sokkal egyszerűbb mindent (teljes partíciót) titkosítani.

Az olyan fájlt, vagy adatfolyamot, ami fizikailag elhagyja a lakótered és nem tartozik mindenkire, azt titkosítani kell.

A másik része a dolognak, hogy mi az, ami el tudja hagyni fizikailag a lakótered? ( törhető wifi titkosítás, kábelekből kisugárzódó EM impulzusok)

Harmadrészt, biztos lehetsz-e benne, hogy valami zárt forrású OS, vagy egyéb szoftver, hálózati eszköz nem szivárogtat-e szándékosan adatot? ( legyen szó akár egyszerű keylog-ról... végül is itt pötyögsz be jelszazavakat, amit egy zárt rendszer szépen elrejtve visszaküldhet a szoftver/OS gyártójához.)

Végül: bármi, ami fizikailag elhagyja a lakótered, nem tudhatod, hogy pontosan hová kerül.

Cloud: biztos lehetsz benne, hogy amit oda teszel, azt a cloud üzemeltetői láthatják, ha akarják látni.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

aki foggal/körömmel titkosít mindent (IS) lokálban és nem értem a koncepcióját!

hogy a futó rendszer titkosítása szerintem felesleges erőforrás pocsékolás

 

Eleve a "full diszk" titkosításnak a mobil eszközökön van főleg létjogosultsága, mivel azokat könnyű ellopni, elhagyni.

(A gyakorlatban pedig sokkal egyszerűbb, biztonságosabb, és erőforrás kímélőbb az egész diszk titkosítása, mint a kiválasztott fájlok foldereket egyesével ki-be titkosítgatni)

Így a tolvaj (vagy a becsületes megtaláló) nem fogja tudni egykönnyen megszerezni a rajta lévő adatokat.

Persze magyarországon az átlag tolvajt nem is érdeklik az adatok - túl suttyó ahhoz - csak a hardver miatt lopják a telefont, laptopot.

Sokan elfelejtik azonban, hogy ez kizárólag *kikapcsolt állapotban "véd".

* vannak olyan kereskedelmi megoldások is, amik pl a gép lockolásakor is lezárják a diszk titkosítást,

és feloldáskor újra "nyitják" a diszket  - több kevesebb sikerrel :)

 

szóval aki úgy érzi, hogy a hardver (telefon, laptop, mobil diszk, pendrive, stb) többet ér, mit a rajta lévő adatai, annak valóban felesleges erőforrás pazarlásnak tűnhet a titkosítás....

De valójában ezek az emberek szimplán csak nincsenek tisztában az adataik értékével. - szerintem.

zrubi.hu

hogy a futó rendszer titkosítása szerintem felesleges erőforrás pocsékolás

A kevésbé mobil eszközök esetében is érdemes - amint granciázni szeretnéd az otthoni 3 TB-os diszkedet.

Mer ha nem titkosítottad, és a diszk elromlott, akkor (Te otthon) már nem tudod letörölni az esetleges érzékeny adatokat róla.

De más viszont lehet hogy simán kiolvassa, és akkor az neked nem lesz olyan jó...

Ilyen esetben is nagyon hasznos a full diszk titkosítás, hiszen az adatok eleve titkosítottak, tehát ha visszaadod gariba, akkor sem tudják ésszerű keretek között kiolvasni róla az adatokat - sokkal nyugodtabban adhatod vissza az ilyen hibás diszkeket.

persze van sok olyan céges policy, ahol eleve tilos adatokkal valaha feltöltött diszket bárkinek eladni, vagy akár garanciába visszaadni. - Esetükben nyilvánvalóan nagyságrendekkel többet ér az adat, mint a hardver amin tárolják.

Ők nagy erőfeszítések (és pénz) árán megsemmisítik (de legalábbis megpróbálják) a használt/rossz/elavult diszkeket.

zrubi.hu

Egy titkosított lemez hogy reagál egy szektorhibára?

Titkosítás nélkül ugye kiolvasható a fájltartalom, ami csak részlegesen sérült. Ha pl. csak részlegesen sérül az adat egy szektorban, mondjuk 80 byte nem stimmel, titkosított lemeznél egy pont ilyen mértékű hibánál mennyi adat nem stimmelne? Lehetne-e egyáltalán rescue módban kiolvasni bármit is?

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Hát, ebben ugyan nem mélyültem el igazán, de szvsz pontosan ugyan annyi adat veszik oda. Attól hogy titkosítva írod a dsizkre még nem lesz kisebb/nagyobb a mérete.

Hibás szektorok esetén kiolvasni is ugyan úgy a titkosított darabokat lehet - vagy épp nem lehet. Ha megvan a tikotsító kulcs, ugyan úgy ki lehet titkosítani az elérhető szektorokon lévő adatot. Titkosítatlan adatmaradékok összerakására meg van jópár 'rescue' app...  De ilyennel még egyátalán nem is próbálkoztam szóval javítson ki aki már igen.

zrubi.hu

A block chaining fájlrendszernél szerintem nem játszik, mert nem működne a véletlenszerű elérés.

https://security.stackexchange.com/questions/128197/how-robust-is-a-ver…

Veracrypt encrypts in XTS mode, which means that data corruption in one block only affects that block.

Egész részletesen: https://www.veracrypt.fr/en/Modes%20of%20Operation.html

hogy a rendszert titkosítani ugyan minek és én e mellett érveltem, hogy a futó rendszer titkosítása szerintem felesleges erőforrás pocsékolás

És utolsó érv, a gyakorlatiasság:

Biztosan sokkal több erőforrás egyesével kiválasztani, és ki-be titkosítani a szerinted érzékeny adatokat.

Ráadásul így egészen biztosan kifelejtesz valamit (tipikus: cache és tmp tárhelyek, swap) amit mégiscsak kellett volna titkosítani

szóval összességében sokkal jobban megéri az egész diszket titkosítani.

 

Ja, és nem utolsó sorban: az SSD-ről a mai tudás szerint NEM lehet hitelt érdemlően letörölni az adatokat. tehát ezeket eleve full diszk titkosítással javasolt használni.  (hint: secure erase)

 

 

szerintem.

zrubi.hu