Seagate krypterar hårddiskar

Precis rätt i tiden. Kommer antagligen bli en storsäljare!

Åh, intressant.

Riktigt smart att bara skriva in nyckeln vid boot.
Blir ju helt osynligt för användaren i övrigt.

Kan passa ganska bra som disk för fildelning, ifall några konstaplar skulle få för sig att göra en husrannsakan och beslagta disken, då har de inget att hämta

Kan man ju fundera på. Om det nu inte är så att de läser av disken rent mekaniskt.

... och då kommer de bara se krypterad data

Problemet med sådana här lösningar är om det finns någon key escrow-mekanism som vid tidigare hårdvaru-diskkrypteringar från bl.a just seagate. En korrekt lösning ska inte lagra vare sig nyckel, lösenord eller hash någonstans utan bara derivera nyckeln via hash från lösenordet...

Kanon. Nu med nya antipiratlagen har man ju blivit lite mer paranoid även om detta kanske känns lite väl att ta i.

Det beror naturligtvis på vad man värdesätter. Prestanda eller säkerhet? I sak finns inget som hindrar att hårdvarukryptering är varken sämre eller bättre än mjukvarudito. Skillnaden är bara hur väl specad och öppen produkten är. Givet att öppna lösningar används och själva implementationen är öppen så är hårdvarukryptering antagligen att föredra baserat på prestanda.

I praktiken har seagate hittills inte visat totalt öppenhet över hur krypteringen fungerar, vilket är problem. Att det är AES räcker inte, implementationen är precis lika viktig som algoritmen.

Själv föredrar jag open source-mjukvarukryptering som finns för både linux och windows. TrueCrypt använder jag t.ex. på windowsmaskinerna. Öppen mjukvara, standardiserade algoritmer och inga "hemligheter" förutom lösenordet förstås. Inga hemliga vrår för key escrow eller liknande.

Hur mycket prestanda förlust märker man av om man kör men hela hårddisken krypterad med Truecrypt?

Är man tillräckligt paranoid så kör man truecrypt ovanpå en sådan här. Hittas en svaghet i den ena så har man alltid den andre att falla tillbaka på.

Inte mycket. Framförallt som hårddiskgränssnittet är betydligt långsammare än CPU och båda kan arbeta parallellt. Flaskhalsen är redan hårddisken själv, DMA och gränssnitt. Det man förlorar är alltså inte främst hårddiskprestanda utan högre CPU-load. Detta är förstås viktigt om CPU arbetar kraftigt och skriver/läser mycket data linjärt från disken samtidigt.

Visst, det kan man göra. Men Truecrypt i sig tillåter redan kaskad-kopplad kryptering så att man kan lägga säg TwoFish över AES över Serpent osv. Om seagatedisken har t.ex AES blir det tårta på tårta. Visst, man parerar eventuella hål i själva implementationen av AES på disken, men å andra sidan, har man sådana är produkten säkerhetsmässigt "trasig" från början.

Jag kör allt krypterat (utom OS).
Spel och program, rakt över. Prestanda-förlusterna är inte så stora. Inget jag märker av (sålänge du har skaplig prestanda i burken i övrigt med processor etc).

Man ska aldrig köra kryptering som inte är open-source. T.ex. är krypteringen som MICROS~1 använder i Windows ett hån. MICROS~1, NSA och annan makt (högbetalande industri-lobbyister?) ska enligt uppgift kunna knalla in direkt.
Är det inte Open-source kör jag det inte.
Hårdvarukryptering i all ära, men visar de inte hur det går till är det inte intressant, då kan de enkelt ge bort backdoors till vem som helst.

Kaskad-kryptering ser jag som over-kill. Att brute-force:a en 256-bitare är inte praktiskt genomförbart (idag).

Helt riktigt, båda påståendena. Men syftet med kaskadkryptering är givetvis inte i första hand att undvika brute-force (även om även detta blir svårare), utan att förhindra att ett fel i en algoritm genast gör dina data osäkra.

Hade brute-force varit ett reellt hot och det enda hotet hade vilken kryptering som helst med tillräcklig blockstorlek (bits) dugt. Faran är inte brute-force, utan matematiska luckor som kan upptäckas i framtiden.

För alla rimliga praktiska syften räcker det givetvis med AES och endast AES, men man får faktiskt ett hypotetiskt extra skyddslager med kaskad-kryptering (om det görs rätt).

Edit: Själva möjligheten till flera algoritmer och kaskader är något som gör TrueCrypt väldigt säkert. Nämligen lagras ingen stans någonting om vilken algoritm som används. När man mountar en TC-partition går programmet igenom alla möjliga kombinationer tills den hittar strängen "TRUE" i första blocket. Detta gör att den som försöker brute-forca måste brute-forca AES, Serpent, TwoFish, AES-Serpent, AES-TwoFish, AES-Serpent-TwoFish, Serpent-TwoFish, osv, osv. Detta är orsaken till att det tar ett par sekunder att mounta en volym. När väl strängen "TRUE" funnits vet TC om vilken algoritm eller algoritmkombination som används och behöver inte längre pröva sig fram vid läs och skriv.

Så kaskad ökar säkerheten även indirekt genom att blotta möjligheten finns.

Får man sämre prestanda i TrueCrypt om man kaskadkrypterar än om man bara kör med AES?

Absolut, med AES (snabbast) får jag på denna dator ~70 MB/s.
Twofish (näst-snabbast) ~65 MB/s.
Serpent ~33 MB/s
AES + Twofish ger ~34 MB/s
(skillnaden mellan läs och skriv är i värsta fall ett par MB/s)

Långsammast är Serpent+Twofish+AES som ger ~17 MB/s.

(truecrypt har ett eget enkelt och smidigt benchmark-program där man kan se resultatet på jusst sin processor (vad som är snabbast kan skilja sig en del mellan olika processorer))

Detta på en Q6600 (2.4 GHz), men notera att det är en något äldre truecryptversion som körs här och som därför bara utnyttjar en kärna. Jag har inte testat det själv men nya versioner av truecrypt ska enligt dem själva skala riktigt bra och att man kan förvänta sig runt 4*prestandan på en quadcore (eller 2*prestandan på en dualcore). Kommer inte ihåg om det gällde alla algoritmer dock.

Sen är det värt att notera att köra en algoritm ovanpå en annan algoritm i vissa fall även kan vara en nackdel då deras karaktäristik kan förstärkas av varandra. Men jag har stort förtroende för jusst truecrypt och skulle något sådant vara kännt med deras val av algoritmer skulle det inte finnas som alternativ.

Ja, men återigen så om datorn ändå inte gör något speciellt CPU-vis just då förlorar man väldigt lite på grund av att flaskhalsen är gränssnittet och själva disken. Jag har kört TrueCrypt i ett antal år nu och jag minns en äldre version som hade vissa prestandaproblem när det gällde överföring från krypterad disk till annan krypterad disk. Men den prestandaförlusten försvann efter en uppgradering av TrueCrypt.

För vardagligt användande, inklusive att flytta stora filer som film eller spela upp film från disken, osv, finns inga som helst problem. Ett benchmarkprogram kan säkert hitta en förlust, men det är ingenting som man lägger märke till. Nu gled jag förvisso lite från ämnet eftersom jag inte hade kaskadkryptering.

Med TrueCrypt finns en benchmark som man kan använda just när man ska välja algoritm. Denna test utförs bara i RAM men ger ändå relativa hastigheter mellan olika krypteringsvarianter. Om t.ex. AES ger 100 MB/s i throughput i RAM så kanske en AES-Serpent-TwoFish-kaskad ger 30. Så visst förlorar man, men hur mycket som märks i praktiken vet jag inte.

Återigen är ju detta en avvägningsfråga. Filer som kräver snabb access, är det just dessa filer som måste skyddas med något så extremt som en kaskad, osv? Denna avvägning får ju var och en ta ställning till. Inget hindrar olika algoritmer på olika partitioner eller diskar. Lägg upp en kaskad på ett "supersäkert valv" för riktigt hemliga filer och kör med en enda algoritm (_ingen_ av algoritmerna i TC är svaga på något känt sätt) för bara "hemliga" filer...

Nu råkar det vara så att "kommersiella" (skulle inte öppna program kunna vara kommersiella? Ännu en myt om open source) är ofta sämre. Och dyrare, till ingen nytta. Det finns också ett rent tekniskt/vetenskapligt/matematisk principskäl till att välja öppen mjukvara. Det är öppet. Det följer Kerckhoffs princip om säkra chiffer, att inget annat än nyckeln ska vara en hemlighet. På så sätt garanterar man att det är nyckeln som gör systemet säkert. Detta gäller _även_ om den stängda mjukvaran säger sig använda AES. Att bara rätt och slätt använda rätt algoritm räcker inte.

Det är i första hand inte NSA-bakdörrar som är faran med slutna programvaror, utan det är dålig implementation som gör att vem som helst på oväntade sätt kan forcera skyddet. Genom key escrow. Genom side-channel, genom dålig nyckelhantering i allmänhet. Genom dålig pseudoslump. Alla dessa faktorer är - inför privatpersoner och företag - sällan eller aldrig behandlade och regulerade i manualer, avtal och dokumentation.

Det finns ingen anledning att välja slutna program för sin säkerhet. Inte om meningen med säkerheten är just säkerhet. Är meningen att ha ett snyggt gränssnitt, bra support, serviceavtal e.dyl, då kan såväl öppna som stängda program konkurrera, men inte när det gäller säkerhet.

Själv använder jag mina säkerhetsprogram för att jag vill ha säkerhet. Inget annat.

Edit: Att se tjuven som någon inkompetent idiot är en nidbild som kostat många data och många investeringar genom historien. Att lita till lägre säkerhet på krypteringen för att man tror att dumma skurkar utgör ytterligare ett säkerhetslager är ju närmast skrattretande. Även om datortjuven själv inte har nytta av datat kan han mycket väl ha någon i sitt kontaktnät som är det. Detta har visats om och om igen vid borttappade laptops, inbrott hos företag osv.

Gäller det en privatpersons data är bilden givetvis lite annorlunda, men säg mig varför en privatperson skulle betala för en säkerhetsprodukt som är sämre än ett öppet gratisalternativ?

Det är ett feltänk att "gradera" säkerhet så att man med flit väljer _lägre_ säkerhet än vanligt för mindre viktiga data. Att specifikt öka säkerheten vid behov är en bättre lösning.

Det finns också en annan dumdristighet, ett slags faliure-of-imagination-fel; du är faktiskt inte den bäst lämpade att avgöra värdet på dina egna data! Inte många tänker på det, men så är det faktiskt. Helt oskyldiga brev, bilder, noter, texter, vad-som-helst, kan blir mycket obehagligt i händerna på en illvillig person som verkligen vet vad han eller hon sysslar med. Glöm inte det!

Vore trevligt om de släppte öppen källkod för firmware.