Dotaz: Používat při šifrování disku HW šifrování AES na NVMe disku nebo na CPU?

[LarryL]

Všiml jsem si, že spousta z vás tady na fóru používá šifrování disku. Co si vzpomínám, tak téměř vždy se jednalo o šifrování za pomocí nějakého nástroje v Linux (např. dm-crypt) a tudíž využítí šifrování za pomocí AES-NI v CPU. Takže se chci zeptat jestli někdo využíváte 256-bit AES encryption controller přímo na disku, což nabízí např. Crucial nebo Kingston. Vyplatí se koupit takový SSD/NVMe disk?

---

---

Odpovědi

[X]

Logicky by se nad tim dalo uvazovat v pripade zeleza, ktere nema podporu hardware akcelerace a je pozadavek na sifrovani, ale jako velky problem vidim nulovou kontrolu nad samotnym sifrovanim..

[LarryL]

No právě, tak jsem to pochopil, že to je celý šifrovací engine uvnitř disku a jak se bude šifrovat určuje výrobce disku (firmware).

[PetebLazar]

Není většina SSD nativně šifrovaných "FullDiskEncryption" (data jsou do jejich flash pamětí standardně ukládána šifrovaně, bezpečné vymazaní SSD spočívá ve vytvoření nových klíčů/smazání starých)? Problémem je bezpečné uložení použitých klíčů, jedna z použitých technik snad využívala při bootu zadané ATA password k jejich za(de)šifrování. Výrobci jsou skoupí na popis správy klíčů, takže se této metodě asi moc nedůvěřuje a dává se navzory případnému výkonostnímu dopadu přednost SW řešením.

[LarryL]

Není většina SSD nativně šifrovaných "FullDiskEncryption" (data jsou do jejich flash pamětí standardně ukládána šifrovaně, bezpečné vymazaní SSD spočívá ve vytvoření nových klíčů/smazání starých)?

Myslím, že všechny to nemají, třeba u WD jsem to neviděl, pokud jde o interní SSD. I kdyby to SSD disky měly, tak je rozumné odlehčit CPU a přenechat šifrování na samotném disku?

[PetebLazar]

U modelu CL SN720 ve specifikacích WDC podporu SED/Opal deklaruje. https://www.westerndigital.com/products/commercial-internal-drives/cl-sn720-sn520-nvme-ssd

[LarryL]

To je nějaká lepší řada (for Commercial & Industrial Applications), ale běžná řada např. WD SN550 nebo WD_Black SN750 HW šifrování nemá.

Kdyby jsi se měl rozhodnout sám za sebe, tak bys do takového způsobu šifrování (na desktopu) šel nebo bys raději šifroval klasicky přes CPU?

[PetebLazar]

Před lety 2010+ jsem využíval na ntb int. šifrování vycházející ze zmíněného ATA-password (můj BIOS snad podporoval hesla delší než 8 znaků, což tehdy nebylo pravidlem). Jak čas ukázal nešlo asi o zcela ideální řešení. I tak se mi podařilo po opuštění tohoto ntb za cca půl roku zapomenout heslo (na novém ntb jsem přešel na kombinaci BitLocker SSD C:\ a TrueCrypt HDD D:\) a z SSD původního ntb (Crucial MX300) se stal brick (ani PSID Revert nepomohl).

Zkušenost s moderními SED technikami nemám, místo výkonostního dopadu čistě SW řešení by mne zajímal například vliv (SED/SW) na TRIM. Před zápisem dat se snad musí všechny buňky flash paměti nastavit na 0(či 1) a nevím nakolik takový sektor je slučitelný se šifrovaným diskem (při šifrování na nižší úrovni než FS).

[LarryL]

Dík za info. Zatím z toho mám pocit, že SED je přednachystané řešení hlavně pro lidi, kteří neumí nebo nechtějí nastavovat svoje vlastní šifrování disku. Takže asi proto to většina lidí tady na fóru nepoužívá, protože si šifrování nastavit skoro všichni umí.

[LarryL]

... např. kdyby někdo provozoval linux jako audio nahrávací server kde je potřeba co nejnižší latence (třeba s real-time kernelem) nebo několik VM (jejichž image disky by byly uložené na šifrovaných discích), tak jestli to nějak ovlivní latenci když přenecháme práci s šifrováním na samotném SSD/NVMe nebo zda počítání AES v CPU je tak zanedbatelné, že to na latenci nemá vliv.

[PetebLazar]

Dnesni CPU maji vykon AES-NI instrukcí nekde mezi 1-2GB/s na jádro, takze (de)šifrování streamů v řádu MB/s asi nebude představovat velkou výzvu.

[Petr Fiedler]

~$ cryptsetup benchmark 
# Testy jsou počítány jen z práce s pamětí (žádné I/O úložiště).
PBKDF2-sha1      3360820 iterací za sekundu pro 256bitový klíč
PBKDF2-sha256    5915802 iterací za sekundu pro 256bitový klíč
PBKDF2-sha512    2475976 iterací za sekundu pro 256bitový klíč
PBKDF2-ripemd160 1209430 iterací za sekundu pro 256bitový klíč
PBKDF2-whirlpool  921420 iterací za sekundu pro 256bitový klíč
argon2i      12 iterací, 1048576 paměti, 4 souběžných vláken (procesorů) pro 256bitový klíč (požadován čas 2000 ms)
argon2id     12 iterací, 1048576 paměti, 4 souběžných vláken (procesorů) pro 256bitový klíč (požadován čas 2000 ms)
#    Algoritmus |      Klíč |       Šifrování |     Dešifrování
        aes-cbc        128b      1561,9 MiB/s      6851,2 MiB/s
    serpent-cbc        128b       151,7 MiB/s      1075,6 MiB/s
    twofish-cbc        128b       299,2 MiB/s       548,1 MiB/s
        aes-cbc        256b      1168,9 MiB/s      5495,8 MiB/s
    serpent-cbc        256b       151,7 MiB/s      1075,5 MiB/s
    twofish-cbc        256b       299,0 MiB/s       547,7 MiB/s
        aes-xts        256b      5469,6 MiB/s      5464,6 MiB/s
    serpent-xts        256b       971,1 MiB/s       954,9 MiB/s
    twofish-xts        256b       514,6 MiB/s       523,8 MiB/s
        aes-xts        512b      4601,7 MiB/s      4625,7 MiB/s
    serpent-xts        512b       969,0 MiB/s       954,6 MiB/s
    twofish-xts        512b       514,0 MiB/s       524,3 MiB/s

Audio server, ani šifrované VM's neprovozuji, ale mám tento NVMe šifrovaný pomocí aes-xts 512 b klíč a je to opravdu rychlé. Pokud by tě zajímal nějaký test, tak napiš co a jak a dám ti sem pak výstup.

[LarryL]

Vypadá to, že tvůj NVMe taky patří mezi ty co nepodporují hardwarové šifrování (SED), ale jak se dívám na ty čísla, tak to znamená, že když tvůj NVMe umí sekvenčně číst 5000 MB/s a dešifrování umí jen 4625,7 MiB/s (= 4850 MB/s), tak dešifrování je úzké hrdlo? Maximální rychlost sekvenčního čtení asi není nic co bys využil každý den, ale přece jen mne to hned zarazilo. Mně ukazuje příkaz cryptsetup benchmark cca poloviční hodnoty u dešifrování aes-xts, ale SSD nemám tak rychlé, aby to mohlo brzdit sekvenční čtení.

[lertimir]

stačilo by i AES-128 a to má rychlost pře 5000MB/s. Používat na v zásadě domácí ochranu šifrováním AES-256 je možná přestřelené. Na šifru i po 20 letech výzkumu je pouze (co vím) útok Bogdanov, Khovratovich, Rechberger, který by složitost v plných roundech snižuje na 126, 188,9 a 254,3 bitů pro 128, 192 a 256 bitové klíče. Tedy přímo na šifru klíč se útočit nedá (i 126 bitů je přes 10^37 což pro pole o miliardě zařízení s miliardou pokusů za sekundu dá pořád 3*10^11 let a to již dávno nebude slunce.) A útoky postranními kanály se dají podobně provádět jak pro AES-128 tak i AES-256 a záleží na implementaci. já všude používám AES-128 (v cryptsetup je délka klíče uváděna dvojnásobná)

[Jendа]

Proč je u audio nahrávacího serveru potřeba co nejnižší latence?

I u audio zpracovávajícího (za běhu) serveru by mi to přišlo divné, ale asi bych uvěřil, že latence disku nějak rozbije i latenci zvukovek.

[Peter Golis]

Bubeník by ti na to krásne odpovedal, a veľmi šťavnato. Bubeníci neznášajú rozsynchronizovanú latenciu pri nahrávaní. A ani to nemusia byť frekvenční rúbači.

[Grétina zapařená pipina]

Jen pro kontext: dneska se RAM běžně počítá na desítky GB...

rozsynchronizovanú latenciu pri nahrávaní

Na latenci disku až tak moc nezáleží, protože není problém udržet data (i hodně dat) v paměti a na disk je zapsat ve chvíli, kdy se mu to hodí.

Stejně bys ten systém neškáloval tak, abys rychlost disku využíval kolem 100 % -- budeš tam mít dost velkou rezervu, takže nebude problém data zapisovat v intervalech, dávkách.

Pro toho bubeníka bude daleko důležitější, jak je napsaný ten software a co se děje v RAM a na CPU, jestli se tam signál z různých zdrojů správně poskládá... než to, kdy se nakonec výsledek zapíše na disk.

[Peter Golis]

S tým bubeníkom som rozoberal rozšírenie počtu mikrofónov pomocou USB zvukoviek. Na starobu mu zomieral stroj s FireWire kde to malo použiteľnú latenciu, a USB2 zvukovky stoja za ... Nakoniec to vyriešil nejakým HW midi snímačom na bubny keďže chcel búchať do klasického dreva. Samotné profesionálne SW to už majú riešené v pohode.

Ale to bol len príklad prečo ide pri hudbe o latenciu. Že je to v prípade zápisu na NVMe (aj s enkrypciou, a diskovou cache v RAM) trošku mimo, to je jasné. To je už za hranicou fyziologického ovládania svalov. To by musel niekto rozoberať šum twistu.

[LarryL]

Že je to v prípade zápisu na NVMe (aj s enkrypciou, a diskovou cache v RAM) trošku mimo, to je jasné.

Můj dotaz směřoval k tomu jestli šifrování v CPU nemůže na CPU vytvořit nějakou latenci, která by se ve výsledku projevila při zpracování audio dat (při přesunu z CPU do RAM). Jasně, že těch audio dat bude tak málo, že to CPU v pohodě zvládně, ale přece jen je to nějaká úloha na CPU, která neustále probíhá na pozadí (i přesto, že šifrování/dešifrování počítá samostatná část CPU).

Audio server byl jen takový náhodný příklad jestli je to zrovna situace kdy člověk dá přednost šifrováním dat přímo na disku (SED), právě proto aby odlehčil CPU a ve výsledku by získal o 1 ms menší latenci při živém nahrávání audia.

[Peter Golis]

Reagoval som na Jendovu otázku: Proč je u audio nahrávacího serveru potřeba co nejnižší latence?
Presnejšie povedané na dôležitosť najnižšej latencie. Latencia AES-NI/Via-Padlock pri SW enkrypcii disku sa pri tom maličkom prietoku dát nemá na NVMe/SSD ako prejaviť. Teda pokiaľ človek nezvučí orchester na športovom štadióne, ale tam už nebude používať riešenie zbúchané na kolene. Tam sa už rieši aj ozvena a rýchlosť zvuku.

[Jendа]

Aha, takže on otevřel nijak nesynchronizované USB zvukovky, začal z nich najednou číst data a doufal, že to dobře dopadne? Tak to spíš divím že to nějak fungovalo .

[Peter Golis]

Ono to nejako dopadlo. A ako som spomínal, tak to bolo dosť rozsynchronizované. Až k nepoužieľnosti. Holt, latencia na USB-2 je dosť strašná.

[Grétina zapařená pipina]

Proto se dělají vícekanálové zvukovky - nic jiného v podstatě nemá smysl. JACK např. doporučuje pracovat vždy jen s jednou zvukovkou a nesnažit se jich víc spojovat dohromady, protože to prostě dost dobře nejde.

A ta vícekanálová zvukovka to řeší na úrovni hardwaru a do počítače posílá vícekanálové vzorky, které se už nerozpadnou, nerozsynchronizují... Nějaká latence na USB mezi zvukovkou a počítačem ti pak ani moc nevadí.

[Peter Golis]

To by som si pozrel koľko zvukoviek na trhu má vstupy pre malú kapelu (2x spev, 2x sólovka, 1x basgitara, 1x klávesy (či akordeón alebo iný doplnkový nástroj) a 6x bubon, činely nerátam). Dá sa to nahrávať mono cez jediný mobil, ale pracovať s takým mixom vyzneje ako selfíčko z kúpelne.

[Heron]

To by som si pozrel koľko zvukoviek na trhu má vstupy pre malú kapelu (2x spev, 2x sólovka, 1x basgitara, 1x klávesy (či akordeón alebo iný doplnkový nástroj) a 6x bubon, činely nerátam).

Rychlej dotaz na google našel třeba toto: Roland UA-1610 STUDIO-CAPTURE 16-input, 10-output Hi-speed USB Audio Interface

[Peter Golis]

Cca 900USD. To už radšej ojazdený mixpult, ako sa to v takýchto prípadoch robí.

[Heron]

Cca 900USD.

A? K tomu mixáku stejně nějakou zvukárnu budeš potřebovat a stejně za ní (minimálně jeden) pár set dolarů dáš. Záleží, co to je za mixák, jestli jen dvoukanálový výstup, potom ti stačí jeden stereo line-in vstup, ale v tom případě se nemusíme bavit o vícekanálových zvukovkách.

Navíc cena do 20tis Kč za 16 kanálů mi vůbec nepřijde přestřelená. Vlastně naopak (když si vezmu ceny čtyř nebo šesti kanálových zvukovek).

[PetebLazar]

Myslím, že například v tomto je to vše integrováno. https://www.muziker.cz/soundcraft-signature-12mtk

[Peter Golis]

Prekrásne, a za cca polovičnú cenu.

Ď.

[PetebLazar]

Japonský Roland má asi větší zvuk než čínský Soundcraft.

[Heron]

Na první pohled to vypadá jako kopírka Behringeru. (Což je německá kopírka tak nějak všech.)

[PetebLazar]

Tak MTK řada má snad nahrávání kanálů zvlášť (ten odkazovaný model 14in/12out USB až 48kHz/24b), což asi má svůj půvab. Ty Behringery snad mají pouze 2 IN/OUT USB(48kHz/16b).

Vypadá to, že v PC se to MTK tváří jako šest(sedm?) zvukovek, tak to bude asi radost. https://www.soundcraft.com/zh/product_documents/soundcraft_signaturemtk_recordingguide-pdf

[Jendа]

Normální rádiové transceivery mají vstup a výstup pro synchronizaci a dá se jich tak zapojit víc spolu. To se u lepších zvukovek nedělá?

[Jendа]

Stále to nechápu (což je teda u tvých příspěvků běžné). Když má zvukovka dostatečně velký buffer, do kterého nahrává, tak je přece jedno, jestli se z něj data vyberou a zapíšou na disk za 1 nebo za 100 ms - dokud se to děje dostatečně často na to, aby buffer nepřetekl.

To je jak ti audiofilové, co tvrdí, že při přehrávání může počítač nějak ovlivnit jitter samplů - jako kdyby v počítači byl 48000x za sekundu interrupt, který by vložil do DA převodníku další vzorek. A nechápou, že takhle to nefunguje (a ani nemůže, požadovaný jitter je řádově kratší než je délka vzorku a na PCčku fakt neuděláš časování pod mikrosekundu), zvukovka má vlastní hodiny, a sama si tahá data z paměti, kde dostala najednou veliký chunk (a než ho spotřebuje, už je tam připravený další).

Kdy je potřeba nízká latence je, když má počítač zvuk nahrát, nějak zpracovat (mixování, ekvalizér…) a realtime přehrát (protože jde třeba o nějaké ozvučování sálu živou hudbou). Ale to nebyl tazatelův případ.

[LarryL]

RT kernel bývá v Ubuntu Studio a AV Linux. Zas takový odborník na tohle nejsem, ale řeší se to.

Tady jsem narazil na pokus patentovat "method of encrypting/decrypting audio data without adding substantial latency", takže profesionální hudebníci latenci asi řeší hodně.

[Jendа]

RT kernel bývá v Ubuntu Studio a AV Linux.

Ano, pro realtime zpracování. Ne pro nahrávání. Nebo jinak: co přesně se ti děje při nahrávání za problémy s latencí počítače?

[LarryL]

Neděje se mi žádný problém. Byl to jen příklad jestli může u nahrávacího serveru (midi, živé hraní, živý equalizér, cokoliv) dávat smysl pořídit si disk s HW šifrováním (SED) - jak jsem rozepsal výše. Nebo jestli žádná technická výhoda SED disků neexistuje a celé je to jen o pohodlnosti, aby člověk nemusel složitě nastavovat šifrování např. pomocí dm-crypt.

[PetebLazar]

U zvukových dat asi půjde o relativně malé objemy dat (při 32channel/384KHz/32bit jde v PCM o cca 50MB/s), při opravdu náročných zápisech ve x00MB/s když dojde SLC-cache i oTRIMované bloky, může se SSD v zápisu odmčet i na řádově sekundy. Možná volit lepší SSD bez SLC-cache (NVMe Samsung 970Pro?).

http://www.monitos.cz/tmp/Kingston_A400_240gb_dd.png

http://www.monitos.cz/tmp/Corsair_MP510_960GB_dd.png

http://www.monitos.cz/tmp/samsung_evo_960_500g_nvme.png

[PetebLazar]

Chybny odkaz. Nejtragičtější levné SSD co jsem měl tu čest. Zápis klesl na 20MB/s, za to by asi se stydel i nejpomalejší HDD z tohoto milenia.

http://www.monitos.cz/tmp/Kingston_A400_240gb_dd.png

[LarryL]

Původní MP510 je dobré NVMe, ale jsem alergický na "podvůdky" když výrobce něco změní, tím zhorší kvalitu a prodává to pořád pod stejným názvem. Corsair nabízí MP510B s horšími parametry, bohužel to i na svém webu nabízí pod názvem MP510:

Současná (méně kvalitní) verze MP510

Původní verze MP510

Pořádně otři brýle, abys tam viděl to malé "béčko" v sériovém čísle.

Podobně se zachovalo Adata u XPG SX8200, kde dali pomalejší řadič (jestli si dobře vzpomínám). A výměna TLC za QLC u Crucial P2 je už úplně do nebe volající.

Tyhle značky, ať už by měly sebelepší NVMe/SSD u mne většinou končí.

[Petr Fiedler]

A kdo to dneska nedělá?

[LarryL]

U WD, Intelu, Kingstonu, Samsungu a zřejmě i dalších jsem to nezaznemenal. Nevadí mi, že výrobci vypadne nějaký dodavatel a musí použít náhradní součástku, ale nesmí se při tom zásadně snížit vlastnosti výrobku. A pokud nemají na výběr a jsou nuceni kvůli náhradní součástce snížit kvalitu výrobku, tak to mají prodávat pod jiným názvem.

[PetebLazar]

Kingston byl první(jeden z prvních) co s tím začal. https://diit.cz/clanek/pomaly-kingston-ssdnow-v300

[LarryL]

Zajímavé, to jsem nevěděl. Je to už 7 let starý článek, tak buď se z toho Kingston poučil a už to nedělá, anebo je potřeba ho ze seznamu seriózních výrobců také vyškrtnout.

[PetebLazar]

Samsung zase tvrdošíjně označuje i své TLC SSD jako MLC a někde hlouběji ve specifikacích se zmiňuje, že je to MLC 3-bit/cell vlastně TLC (e-shopy si s tím často nědelají hlavu a použijí u TLC SSD Samsungu pouze MLC bez počtu bitů). Ano MLC Multi-Level-Cell jsou jak MLC(2-bit/cell),TLC(3-bit/cell),QLC(4-bit/cell), ale nejistota označení by neměla vést k matení mákazníka. Místo, aby Samsung ctil originální "de-facto" význam MLC (pro 2-bity/cell), pokračuje v této šarádě (snad jako jediný). Na jeho obranu je zase třeba říct, že jako poslední skutečné MLC (2-bity/cell) dodává v comsumer třídě na trh.

[LarryL]

Samsung zase tvrdošíjně označuje i své TLC SSD jako MLC a někde hlouběji ve specifikacích se zmiňuje, že je to MLC 3-bit/cell vlastně TLC

Není to zas tak hluboko, že bys musel jít do datasheatu. Přímo na webu uvádí: "Paměť: Samsung V-NAND 3-bit MLC". To nepovažuji za takový problém. Třeba u CZC mají správně TLC. Důležité je jestli třeba to zmíněné Samsung Evo má pořád stejné vlastnosti po celou dobu kdy je Samsung dodává na trh. Pokud ano, tak je pro mě Samsung seriozni výrobce.

[PetebLazar]

Tak tomu dříve nebylo. I Samsung to měl dříve až na druhé detailní straně (typ použitých pamětí). Alza na odkazu výše má jen MLC. Myslím, že se v docela HW orientuji a i mě to před pár lety trvalo rok (jedno/dvě SSD) než mi to došlo.

[PetebLazar]

A je zajímavé, že generaci QVO 870 přitom nemají problém nazývat QLC (QVO 860 to bylo ještě MLC 4bit). Pokud je někde pouze MLC, pak to řekne s jistotou asi pouze jediné. Že SSD není SLC, z čehož by ho dneska asi nikdo ani nepodezíral.

[LarryL]

Ale když si na Alze překlikneš na 1TB, tak tam už mají správně TLC, takže MLC u 500GB verze beru jako překlep Alzy. U TS-bohemky nebo Heuréce mají taky správně TLC. Nevidím to jako problém výrobce. Zkrátka jen prodejce, který tahá feedy přímo od výrobce, tak musí mít podmínku: if 3-bit MLC then TLC.

Jako on to má Samsung vlastně dobře, jen se vymyká zaběhlým zvyklostem. Kdyby na začátku místo MLC (multi-level cell) vytvořili název DLC (double-level cell), tak by se mohlo pokračovat TLC (triple), QLC (quad), ale tím, že se použilo MLC, tak je pro TLC naprosto správný název "3-Bit MLC". O DLC a 3-Bit MLC se zmiňuje i wikipedie:

1. Single-Level Cell or SLC (1 bit per cell)

2. Multi-Level Cell or MLC (2 bits per cell) alternatively Double-Level Cell or DLC

3. Triple-Level Cell or TLC (3 bits per cell) or 3-Bit MLC

4. Quad-Level Cell or QLC (4 bits per cell)

5. Penta-Level Cell or PLC (5 bits per cell) – currently in development

[PetebLazar]

Všechna non-SLC jsou MLC. Jde o to, že dokud nevzniklo první TLC nikdo u MLC SSD počet bitu/cell neuváděl. V podvědomí tak MLC znamenalo SSD s 2-bity/cell. To se následně stalo základem možných omylů. Samotná zkratka MLC od vzniku prvního TLC neposkytuje dostatečnou informaci a je zcela zbytečnou a plně ji nahrazuje údaj počtu bitů/cell. MLC 3-bit je ekvivaletni "hemenexu s vejcem a šunkou".

[LarryL]

Jde o to, že dokud nevzniklo první TLC nikdo u MLC SSD počet bitu/cell neuváděl.

Jenomže když vzniklo první TLC tak to nebylo TLC, ale právě "3-bit/cell MLC". Samsung byl první kdo přišel s 3-bity na buňku, takže on byl ten kdo stanovoval terminologii a rozhodl se pro "3-bit/cell MLC". Nebylo to tak, že někdo ostatní vymyslel TLC a Samsung chtěl být rebel nebo dokonce podvodník a začal tomu říkat 3-bit MLC. Samsung si prostě jel svoji terminologii, kterou sám nastolil a ostatní to začali nazývat TLC.

Trochu mi to připomíná situaci kdy AMD přišlo s AMD64 a Intel tomu říkal x86_64.

Každopádně tahle rozdílná terminologie není ten podvod o kterém naše diskuze začala a to, že výrobce uvede na trh kvalitní produkt, recenze jsou výborné, prodeje se rozjedou a pak pod stejným názvem začne prodávat šmejd.

[Petr Fiedler]

Každopádně tahle rozdílná terminologie není ten podvod o kterém naše diskuze začala a to, že výrobce uvede na trh kvalitní produkt, recenze jsou výborné, prodeje se rozjedou a pak pod stejným názvem začne prodávat šmejd.

BTW: tohoto jsem si všiml třeba i u routerů. První verze je super, v2 už má třeba místo 2x USB jen 1x USB a v3 má ještě k tomu slabší antény, nebo menší paměť.

[Petr Fiedler]

I když dohledat to asi (vždy?) jde.

[LarryL]

Pokud by v názvu byl alespoň dodatek "v2", tak to pořád ještě jde. Horší když název zůstane úplně stejný.

[j]

Ve vehiklech se tomu rika facelift .... ;D. A funguje to presne stejne. V tomhle pripade to ovsem dotahli k dokonalosti, protoze v letaccich s vysmatyma rodinkama se doctes, ze "karoserie byla odlehcena" === to co predtim bylo neznicitelny zarucene praskne a tak podobne.

Jeste legracnejsi je trebas aktualni info o tom ze fabie prestanou delat jako kombi ... duvod je jednoduchej. Lidi to kupovali.

Pripadne zradlo, muzu jmenovat trebas ... piskoty nebo lentilky.

BTW: Mam trebas dell 2407WFP. U tohodle monitoru se uz pred mnoha lety resila konkretni revize, protoze ackoli slo o stejny monitor prodavany se stejnym oznacenim ve stejnym obalu, tak panel mel zcela diametralne odlisny parametry. Nedelal bych si vubec zadny iluze o soucasnym stavu.

---

Dete s tim guuglem dopice!

[PetebLazar]

Ani Samsung neměl problém první TLC SSD na světě označovat jako TLC. Důvod proč tak u pozdějších TLC modelů nečinil ví jen o sám. V kombinaci s případným lajdáctvím e-shopů pak nesou důsledky zákazníci. https://gzhls.at/blob/ldb/f/7/e/c/fdce081d4a4462c2e36048ce95c08add830e.pdf

[LarryL]

Řekl bych, že "Samsung V-NAND 3-bit MLC" je oficiální název pamětí. Možná, že to má pod tímto názvem patentované. Často uvádí "Samsung V-NAND 3-bit MLC (TLC)" a v tom tebou odkazovaném produktovém listu to zestručnil na TLC. Kdo ví, třeba někde v Korei jsou více zvyklí na 3-bit než na TLC.

[Petr Fiedler]

U HDD je zase někdy těžké zjistit, jestli se jedná o SMR, nebo CMR.

[LarryL]

WD po tom průšvihů kdy dávalo SMR do REDů, už prý bude modely se SMR řádně označovat. Řada RED PLUS by měly být bez SMR, tak uvidíme.

[Petr Fiedler]

U WD, Intelu, Kingstonu, Samsungu a zřejmě i dalších jsem to nezaznemenal.

Tak u WD to už zaznamenat můžeš.

[LarryL]

To jsou kur.y. Zrovna dnes jsem zjistil, že na německém amazonu výrazně snížili jejich cenu a myslel jsem, že to souvisí se slevovou akcí. Už to mám v košíku. Akorát mi nesedí odkaz na datasheet (v tom článku), protože odkazuje na původní verzi z roku 2019 kde ještě nebyla uvedena 2TB varianta.

[LarryL]

...vypadá, že Samsung šmejdovské praktiky nehodlá provozovat, palec nahoru. Samsung také mění součástky v SSD, ale zde to není na škodu

[Max]

Další kudla do zad, tentokrát od Samsungu:
Samsung potají vyměnil čipy v SSD 970 Evo Plus. Je dvakrát pomalejší než původní verze
Zdar Max
PS: naštěstí na Samsung kašlu, DDR paměti umí, ale SSD fakt ne (domršené firmware, nekompatibilní firmware, vadné serie apod.)

[Max]

A DPC, Crucial taky :-/.
Pomalejší nepřeznačené NVMe SSD prodává také Crucial a Samsung
Zdar Max

[LarryL]

JJ o Crucialu se to už ví delší dobu. Proběhlo už i srovnání staré a nové verze a na základě ní ho zařadili do NEdoporučovaných NVMe.

[LarryL]

V tomhle se musím Samsungu zastat. Místo Živě doporučuji raději SvetHardware.cz nebo TomsHardware.com. Oba články jsou pochvalné, ve smyslu, že takto se to má dělat když je nutné kvůli výrobním komplikacím vyměnit důležitou komponentu. Samsung při změně 970 EVO Plus udělal:

- vydal novou revizi datasheetu (kromě názvu controlleru se žádná technická specifikace nezměnila)

- změnil vzhled krabičky

- změnil Part Number

- zvýšil SLC chache ze 42 na 115GB

Mně se to zdá jako férové jednání od Samsungu. Samozřejmě, že kdyby to odlišil i nějakou drobnou změnou názvu, tak by to bylo super, ale i tak se to s jednáním WD, který SN550 změnil potichoučku, nedá srovnat. Navíc WD SN550 má SLC cache jen 12GB a pak ta rychlost hned padá oproti staré verzi SN550.

Když se podíváš i na ty naměřené hodnoty z CrystalDiskMarku (nahoře je stará revize, dole nová), tak u prázdného disku výrazně stouplo náhodné čtení. Až u zaplněného disku na 84% je náhodné čtení zhruba stejné u obou revizí. V podstatě všechny hodnoty u nové revize stouply, pouze "Read Seq1M Q1T1" trochu kleslo.

Takže, abys pocítil u nové revize nižší rychlost, tak bys musel pořád kopírovat soubory větší než 115GB. Do velikosti souboru 115GB je rychlost sekvenčního čtení i zápisu rychlejší. Tady je sekvenční a je tam i vidět ten nárust SLC cache.

Tobě nepřipadá lepší ta nová verze? Osobně bych bral novou.

naštěstí na Samsung kašlu, DDR paměti umí, ale SSD fakt ne (domršené firmware, nekompatibilní firmware, vadné serie apod.)

Považuji Samsung za nejlepšího výrobce SSD, když nepočítám Intel Optane, který se už myslím běžným smrtelníkům neprodává, jen firmám. Jakou značku NVMe/SSD považuješ za nejlepší? A u rotačních disků kupuješ jakou značku?

[PetebLazar]

Tak pak jedině volit QLC SSD, ty už snad dalšími úpravami ani zhoršít nejde.

[LarryL]

Jako proč ne? Ježek na rootu psal, že mu QLC vyhovuje a je s ním spokojený pokud má ten disk velkou cache.

Ať to nezakřikneš, ono by taky mohli neseriózní výrobci místo SLC cache začít dávat TLC cache

[PetebLazar]

Myslím, že je reálná šance časem se dočkat článku zvažujícího SSD se šindelovým zápisem z druhé ruky.

[Petr Fiedler]

Jako proč ne? Ježek na rootu psal, že mu QLC vyhovuje a je s ním spokojený pokud má ten disk velkou cache.

Životnost?

Jinak HDD WD. SSD Samsung, i když teď jej nemám, ale měl jsem a spokojenost. Ostatně jako se vším od Samsungu - RAM v NB, mobil, mikrovlnka, lednice. Ještě nikdy mě v ničem nezklamal. Naopak, jeho produkty jsou super.

[LarryL]

Životnost?

Ono to s tou životností není tak žhavé. Nedávno jsem se díval kolik má můj SSD najeto (cca 7 let intenzivně používaný jako systémový). Chvilka napětí...4TB zapsaných dat. Je to ještě stará dobrá 120GB SSD (MLC). Takže jsem ho přepsal pouze 33x. Nevím kolik TBW má papírově ten můj SSD, ale dnešní TLC udávají živostnost 600 přepisů. Takže na tuhle hodnotu se dostanu zhruba za 120 let

[LarryL]

...u QLC vidím, že se na netu udává 200 přepisů, takže toho dosáhnu za 40 let.

[Petr Fiedler]

Teoreticky. Ale praxe je jiná. Já jsem měl 500 GB Samsung 850 EVO a po 5 letech S.M.A.R.T. ukazoval 74%. Tak si to spočítej, kdyby to byla 120ka. Ale i to je jen teorie. Tak či tak, MLC by mělo mít větší výdrž, než TLC | QLC. Mám např. tuhle flešku. Je MLC. Mám jí už ~6,5 roku. Mám na ní nainstalovaný Mint. Před zašifrováním jsem flešku přepsal náhodnými daty. Pak jsem OS párkrát i reinstaloval. 4x za rok povyšuji verzi Mintu a OS mám v režimu rw a pravidelně jej aktualizuji. Lidé tu psali, že dávat OS na flešku a ještě rw je nesmysl. Já nemám problém. MLC je za mě super. Mám i průmyslovou SD kartu MLC, (ECC ) a ~2 roky byla v RPi rw. No problemo.

[PetebLazar]

Problém TLC/QLC osobně nevidím v jejich životnosti, jako spíš nevypočitatelnosti při sustain záznamu. 4TB dat představuje cca 3 hodiny výstupu UHDp60 v DNxHR 4:4:4 12-bit, který může vzniknout klidně jen za pár hodin.

[LarryL]

Pro profesionální střihače videa to není, toho bych se taky bál, ale pro spoustu lidí může být QLC dobrá volba za rozumné peníze. I když nemám pocit, že mezi QLC a TLC je velký cenový rozdíl.

[Petr Fiedler]

jako spíš nevypočitatelnosti

V čem je TLC a QLC nevypočitatelné?

[PetebLazar]

Protože výrobce se chlubí max. rychlostí zápisu do prázdné SLC-cache, ale nikde nedefinuje minimalni trvalou rychlost po jejím zaplnění. I u posledního rotujiciho HDD se dá očekávat dejme to více než polovina maxima (s ohledem na snižující se počet sektorů na cylindr na vnitřních stopách plotny).

Už raději změňme téma, z tech všech příspěvků o TLC/QLC se mi chce objednat další NVMe Samsung 970 Pro.

[Petr Fiedler]

Gigabyte Aorus má oproti Samsung 970 Pro větší rychlosti i životnost, ale narazil jsem přesně na to, o čem jsi psal. Nedávno jsem na něm šifroval 200 GiB oddíl. Ze začátku to bylo opravdu neskutečně rychlé, ale potom to postupně padalo až to spadlo na nějakých 200 MB/s. To mě docela zklamalo.

[PetebLazar]

Myslím, že NVMe 1TB 970Pro je schopen dát trvale 2GB/s. https://cdn.mos.cms.futurecdn.net/fAPbKRzqSURe4nH5jZ2ya7-970-80.png

Někteří optimisté dokonce uvádí 2,5GB/s. https://qph.fs.quoracdn.net/main-qimg-3cf7cb8f486e50baaeef959ff4056287

Zapisuje přímo do MLC buněk (nemá SLC-cache), takže by se překvapení (u TRIMováného prostoru) asi konat nemělo.

[Petr Fiedler]

Škoda, že jsem to nevěděl dříve. Myslel jsem, že PCIe 4 na tom bude lépe, než PCIe 3.

Co myslíš tím překvapením?

[xkucf03]

V nejmenovaném obchodě se zeleným skřetem mají Samsung 970 PRO 1TB (PCIe 3.0) za vyšší cenu než Samsung 980 PRO 1TB (PCIe 4.0), což je na první pohled divné. Vysvětlení je v parametrech a v diskusi:

Dobrý deň, - prosím z akého dôvodu je 980 PRO 1TB tak výrazne lacnejší než starší model 970 PRO 1TB? Chápal by som to opačne

970 Pro používal MLC (2 bity na buňku flash paměti), 980 Pro používá TLC (3 bity na buňku). TLC má výrazně pomalejší zápis (tento disk je rychlejší díky DRAM a SLC cachím, ale pokud byste se pokusil na něj zapsat opravdu hodně dat najednou, zápis se zpomalí na nějakých 1,5 GB/s) a má výrazně kratší životnost, ale je o něco levnější.

[Petr Fiedler]

Jasně. To jsem pochopil. Zmátlo mě "u TRIMovaného prostoru".

Oběma díky za vysvětlení.

[LarryL]

A využiješ rychosti tvého AORUSu? Pokud neděláš náročné operace na zápis, tak mi přijde zbytečné kupovat tak drahé NVMe jako 970 PRO. Přijde mi (pro běžné desktopové použití) rozumější dát peníze do vyšší kapacity a místo 1TB koupit 2TB.

[Petr Fiedler]

Rychlost zápisu ani ne. Spíše rychlost čtení. Mám 2 VM's a jejich start a chod na šifrovaném NVMe je opravdu rychlý. A taky je občas zálohuji (~100 GB a ~50 GB), tak to se rychlost taky hodí. A taky mám na druhém oddílu data (~80 GB), která také občas zálohuji. Jinak na NVMe nic náročného nezapisuji/nečtu. Abych měl ale dost místa, tak jsem si na verzování záloh (OS - PC, NB, RPi, fleška) koupil 4 TB WD Black. Ostatní HDD's ani nezmiňuji. Takže místa mám dost.

[PetebLazar]

To byla dobrá volba. Samsung M.2 980 Pro bude rychlejší ve čtení díky PCIe 4.0 (rychlejšímu řadiči/pamětem?). Já svůj NVMe 970 Pro kupoval v nějaké časově omezené akci za 5999,- a to kvůli důrazu na sustain zápis (pro čtení mě jeho cca 3GB/s stačí).

U SSD před zápisem nového obsahu sektoru se údajně musí obsah všech buněk na jednu hodnotu (0?/1?) a teprve pak je možné zapsat cílový obsah (tato včasná operace šetří čas při zápisu a zvyšuje výkon). Operace TRIM určuje SSDčku, které sektory mohou být dopředu vynulovány (neobsahují z pohledu FS užitečná data).

Zde je například popsán vztah TrueCrypt a TRIM.

[xkucf03]

Na Rootu píší:

Zároveň byla SLC vyrovnávací paměť zvětšena ze 40 GB na 120 GB.

a to mi přijde, že by se to běžného používání prakticky nemělo dotknout. Těch 120 GB vyrovnávací paměti zaplním třeba když pojedu někam pryč a budu si do notebooku nahrávat zásobu filmů a hudby, ale za běžného provozu tolik zápisů najednou mít nebudu a disk by měl mít dost časů si ta data uklidit. Na serveru ta data asi taky nebudou přibývat takhle skokově – bude to třeba (i větší) databáze, která roste postupně a nejvíc se z ní čte.

Ale nic to nemění na faktu, že změnit zásadně parametry a prodávat to stále pod stejným názvem je celkem podraz (podobně jako u SMR disků WD Red).

[LarryL]

podobně jako u SMR disků WD Red

WD má v datasheetu méně informací než třeba Samsung, takže to bohužel dává WD možnost si to "přizpůsobovat". Třeba u WD SN550 nejsou v datasheetu uvedeny použité paměti, takže jim to asi před zákonem projde když tam místo TLC strčili QLC. Samsung má v datasheetu "3-bit MLC", takže ten tam jen tak QLC strčit nemůže.

[PetebLazar]

Myslím, že RT-kernel již v Ubuntu Studio vzdali. Teď je výchozí low-latency-kernel, který je proti RT-kernelu kompatibilní z proprietary drivers.

[LarryL]

To jsem si nevšiml. Dobré vědět.

[trubicoid2]

Jde o SED (self encrypting drives) s OPAL? Podlě mě to není špatné. Koukněte na pěkný popis od ArchLinuxu. Mají tam vyjmenované výhody i nevýhody.

[LarryL]

Ano, přečetl jsem si pár článků (i ten na arch wiki). Asi největší nevýhodou co jsem někde zahlídl bylo, že když přestane fungovat "AES controller" na disku, tak se k datům už nikdo nedostane. Na název SED jsem narazil až na arch wiki. Do té doby jsem to znal pod názvem "AES 256-bit Encryption" když jsem to občas viděl ve specifikacích nějakého SSD/NVMe a myslel jsem si, že jde jen o to, aby AES-256 nevykonával CPU, ale přímo disk, ale tak to asi není. Tzn. šifrovat pomocí dm-crypt s využitím "AES controlleru" na disku by nešlo.

[PetebLazar]

Dnes bude asi nejrozšířenější implementace TCG Opal.

https://en.m.wikipedia.org/wiki/Opal_Storage_Specification https://www.transcend-info.com/Embedded/Essay-18

[xkucf03]

Ne, protože se u mnoha výrobců a modelů ukázalo, že šifrování (které takto implementované není auditovatelné) ve skutečnosti nešifruje. Náhodný dump linků:

https://www.ru.nl/publish/pages/909275/draft-paper_1.pdf
https://spritesmods.com/?art=security
http://www.zdnet.com/article/encryption-busted-on-nist-certified-kingston-sandisk-and-verbatim-usb-flash-drives/
https://eprint.iacr.org/2015/1002.pdf

https://news.ycombinator.com/item?id=18382975

a kdybyste si mysleli že SSD jsou na tom líp: https://www.ieee-security.org/TC/SP2019/papers/310.pdf

[xkucf03]

…jestli někdo využíváte 256-bit AES encryption controller přímo na disku…

Já ne.

Protože jsou s tím dvě hromady bezpečnostních problémů a na oplátku nezíská člověk nic. Místo flexibility LUKS (několik key slotů s různými možnostmi správy klíčového materiálu, který odemkne master key) to má většinou nějaké béčkové heslo. To béčkové heslo je (no, tedy, přinejmenším donedávna bylo) navíc různě ořezávané, protože smělo mít jen (velmi malý) počet znaků, aby sho tajné služby v rozumném čase uhodly, kdyby se jim zachtělo. Pár zajímavých odkazů je (jako vždy) na ArchWiki.

Koupit takový disk se může vyplatit, na základě jeho ostatních / dalších vlastností, ale jeho vestavěnému šifrování je dobré se vyhnout. Iluze zabezpečení je horší než absence zabezpečení. LUKS funguje, akcelerace v procesorech je dnes už na znamenité úrovni a není důvod používat closed-source vestavěné šifrování neznámého typu s neznámými zranitelnostmi, které nelze aktualizovat, nezávisle auditovat atd.

[JLL]

Obvykle se v tom najde díra. Navíc je to neauditovatelné. Vzhledem k povaze dnešní "demokracie" je i pravděpodobné, že k tomu existují další klíče. Nebrat.

[LarryL]

Díky všem za odpovědi. Začíná mně zlobit disk, takže jsem si říkal jestli má cenu se při koupi dívat po disku s HW šifrováním, ale podle všech vašich odpovědí vidím, že u dostatečně výkoného CPU s AES-NI to cenu nemá. Ještě jednou dík.

[j]

Sranda ... jak se tu nikdo nazaobira jednim, pomerne podstatnym aspektem.

Ono totiz kdyz se ten disk jakoze bude sifrovat tento ... sam, tak to taky ale znamena, ze ta data, jako takova po tech kabelech uz musi posilat ... nesifrovane.

Zatimco v pripade sifrovani disku SW cestou pomoci CPU dotazi po kabelech zasifrovana data, a desifrovana se objevi az nekde v RAM, typicky v nejakym tom IO bufferu.

A pak je taky treba rict, ze to ze na disku je nekde napis ze umi data sifrovat, naprosto nic nerika o tom, jestli HW nebo SW cestou. Specielne v SOHO to velmi casto funguje PRESNE stejne, jako ... fakeraid.

---

Dete s tim guuglem dopice!

[LarryL]

Ono totiz kdyz se ten disk jakoze bude sifrovat tento ... sam, tak to taky ale znamena, ze ta data, jako takova po tech kabelech uz musi posilat ... nesifrovane.

Co z toho plyne?

A pak je taky treba rict, ze to ze na disku je nekde napis ze umi data sifrovat, naprosto nic nerika o tom, jestli HW nebo SW cestou.

Pochopil jsem to tak, že v disku, který nabízí šifrování je HW (AES čip) i SW, který tvoří, říkejme tomu třeba "encryption engine". Nebo se to dělá ještě nějak jinak?

[xkucf03]

Co z toho plyne?

Teoreticky by šlo odposlouchávat komunikaci po SATA kabelu (rádiově, na dálku). Ale stejně tak by šlo odposlouchávat komunikaci mezi CPU a RAM nebo na jiných sběrnicích, výstup na monitor, vstup z klávesnice (u těch bezdrátových je to jasné) atd. Resp. ono to za určitých okolností jde.

Pochopil jsem to tak, že v disku, který nabízí šifrování je HW (AES čip) i SW, který tvoří, říkejme tomu třeba "encryption engine". Nebo se to dělá ještě nějak jinak?

Dřív to byl myslím jen takový zámek na úrovni firmwaru, ale data na plotnách byla nešifrovaná. Novější disky by měly mít čip a data skutečně šifrovat, ale jak už tu bylo řečeno, problém je v tom, že se tomu nedá věřit a nemáš si to jak zkontrolovat, může tam být už z výroby druhý klíč, o kterém nevíš atd.

[LarryL]

Co z toho plyne?

Teoreticky by šlo odposlouchávat komunikaci po SATA kabelu (rádiově, na dálku). Ale stejně tak by šlo odposlouchávat komunikaci mezi CPU a RAM nebo na jiných sběrnicích, výstup na monitor, vstup z klávesnice (u těch bezdrátových je to jasné) atd. Resp. ono to za určitých okolností jde.

Ano, měl jsem tušení, že Jéčko míří na možnost odposlechu SATA kabelu (případně NVMe sběrnice), ale stejně tak jako tebe mne napadlo jestli není pro útočníka jednodušší si při vloupání zkopírovat celý šifrovaný disk a do PC/ntb dát HW keyloger. Pomocí něj odposlechnout heslo k zašifrovanému disku a ve výsledku má útočník všechny data z disku. Mně to teda připadá jednodušší než odposlouchávat data proudící po SATA kabelu.

[xkucf03]

Ano, měl jsem tušení, že Jéčko míří na možnost odposlechu SATA kabelu (případně NVMe sběrnice)

BTW: mám teď nový notebook s NVMe a i když je to NVMe schované pod takovým plechovým krytem (jako např. v mobilech pro RF součástky), tak při intenzivním kopírování slyším takové zvláštní bzučení. Neříkám, že by to šlo odposlouchávat mikrofonem, ale rádiově asi ano – zjevně z toho signálu leze ven dost.

stejně tak jako tebe mne napadlo jestli není pro útočníka jednodušší si při vloupání zkopírovat celý šifrovaný disk a do PC/ntb dát HW keyloger. Pomocí něj odposlechnout heslo k zašifrovanému disku a ve výsledku má útočník všechny data z disku. Mně to teda připadá jednodušší než odposlouchávat data proudící po SATA kabelu.

Vyžaduje to zásah do toho zařízení (jiné útoky jdou teoreticky udělat z vedlejší místnosti, od vedlejšího stolu v kavárně atd.), ale jinak je to určitě jednodušší a navíc tím útočník nasbírá i jiná hesla, např. k různým internetovým službám atd.

[LarryL]

Vyžaduje to zásah do toho zařízení (jiné útoky jdou teoreticky udělat z vedlejší místnosti, od vedlejšího stolu v kavárně atd.)

Předpokládám, že odposlouchávání SATA kabelu by taky znamenalo nainstalovat nějaký HW odposlech na SATA kabel nebo sběrnici a z něj na dálku (bezdrátově) sbírat data.

tak při intenzivním kopírování slyším takové zvláštní bzučení.

Jestli to není tajné, jaké je to NVMe, abych si ho taky nekoupil? Né, že bych se bál odposlouchávání, ale nechci žádné bzučáky v PC.

[Jendа]

Jestli to není tajné, jaké je to NVMe, abych si ho taky nekoupil? Né, že bych se bál odposlouchávání, ale nechci žádné bzučáky v PC.

Podle mě mu nebzučí NVMe, ale jeho napájecí zdroje někde na motherboardu.

[xkucf03]

To je možné, protože disk jsem už stihl upgradovat (WD → Samsung s vyšší kapacitou) a chová se to stejně. Ale i tak je to přinejmenším postranní kanál, kterým nějaké informace unikat můžou.

[Max]

I když je rozhodnuto, tak já doplním svůj názor. Osobně bych do šifrování v rámci disku taktéž nešel. Je to neprůhledné a mnohdy děravé.
V době magnetických disků byly celkem jednoduché techniky, jak získat k takto zašifrovanému disku PIN. Stačil program a vhodný kabel a nebyl problém si načíst fw disku a z něj vykousnout část s heslem. Myslím, že do roku 2017 nebýval problém (záleželo na modelu apod.).
Osobně si nedělám iluze, že by dnešní disky byly nerozštípnutelné. Ale jako jednoduchá věc pro full disk encryption a zamezení nějakému nuzákovi při reklamaci, aby to lousknul, to asi stačí.
Zdar Max

[PetebLazar]

Na druhou stranu jakou máme při SW šifrování jistotu, že veškeré klíče svěřené ínstrukcím AES-NI (tak výhodné pro jejich vysoký výkon) se někde v třípísmenkovém archivu neukládají a v případě potřeby se prostě všechny nevyzkouší (2^128, 2^256 jsou možná vysoká čísla, ale kolik jednotlivých klíčů AES od doby vzniku této šifry bylo celosvětově použito ... miliardy?).

[Jendа]

ale kolik jednotlivých klíčů AES od doby vzniku této šifry bylo celosvětově použito ... miliardy?

Už jsem málem napsal že v XTS módu se přece odvozuje nový klíč pro každý sektor, ale pak jsem si uvědomil jaká je to blbost . Ale třeba pro TLS spojení to tak je. Takže by procesor musel umět zjistit, který klíč je k disku (ten si zapamatuje) a který je dočasný. Ale jako mohl by si počítat, který klíč je používaný nejčastěji, ten asi bude k disku.

[Max]

Lepší je tu mít jen konspirační teorii, než reálnou možnost si vyčíst z fw heslo :).
Zdar Max

[PetebLazar]

Jen jestli vzhledem k plánovanému rozpočtu zůstalo jen u konspirační teorie, či údajném požadavku na možnost IntelME vypnout.

[k3dAR]

trochu offtopic, ale diky zkusenosti pred par tydny s kamosovym NB, obecne doporucuju zkontrolovat ze je "Intel AMT" v BIOSu vyple (to lze vypinat normalne, pokud by neslo, tak aspon zmenit IP (pro AMT, v tom biosu) z dhcp na nesmyslnou) = nektere BIOSu, resp. AMT implementace maji bug kdy jde obejit heslo...

[Max]

Těchto věcí jsem si plně vědom, sleduji ty problémy okolo Intel ME apod. věcí. Možná jsem jen někdy zbytečný optimista :).
Zdar Max

[PetebLazar]

Jestli je z dlohodobé perspektivy v tomto ohledu pro optimismus místo (DES .. zkrácení klíče, Clipper ... klíč u státu, ....). Od Henryho L. Stimsona se ušel pořádný kus cesty.