Truecrypt-granskning hittar inga bakdörrar

Permalänk
Melding Plague

Truecrypt-granskning hittar inga bakdörrar

Det populära krypteringsprogrammet Truecrypt innehåller inga bakdörrar eller andra avsiktliga svagheter, men däremot förekommer både buggar och slarvfel.

Läs artikeln

Visa signatur

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa kan leda till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Permalänk
Medlem

Truecrypt är väl snart en standard för de som vill skydda sin data, så det välkomnas med all form av granskning. Hoppas man hittar nått i algoritmerna som kan åtgärdas. Många har antagit säkerhetshål av varierande betydelse under många år, så om dessa rättas eller helt enkelt påvisas så är det ett steg i rätt riktning givetvis.

Permalänk
Medlem

Granskarna

Som i alla sådana sammanhang så glömmer man lätt att fråga vem som granskar granskarna?

Permalänk
Medlem

Är så sjukt nöjd med Truecrypt att det nästan blir löjligt.

Permalänk
Medlem

Kör det hemma på alla diskar och kommer förhoppningsvis skydda en vid eventuell stöld så ingen kommer åt datan.

Visa signatur

CPU: 5600X| Mobo: AORUS X570 itx|Minne: 32GB Corsair Vengeance PRO 4000Mhz|GPU: Asus TUF 3080 OC |Chassi: CM NR200P|SSD: Samsung 850 EVO 500GB, 2xSamsung 970 EVO 1TB|PSU: NZXT 650W
Mus: Razer Basilisk|Tangentbord: Corsair K70|Skärm: LG27GP850

Permalänk
Medlem

Tja kört det ett bra tag, oftast för att hantera och skydda känsliga backuper, speciellt då jag behöver ha en hel del av backuperna offsite och de innehåller en hel del känslig data.

Funkar hyfsat med rsync att synka iväg dom offsite med, inte precis världens optimalaste men det funkar för min del, blir också lättare att handskas med en fil istället för miljontals.

Visa signatur

Speldator: Ryzen 7800X3D, 64GB DDR5, RTX 3070
Server: i7-8700k, 32GB DDR4, RTX2080
Steam deck + de fiesta konsoller.

Permalänk
Medlem
Skrivet av rmd:

Hoppas man hittar nått i algoritmerna som kan åtgärdas.

Det finns 4 problem av kategorin 'mellan', och 4 problem av kategorin 'låg'. (Och de går att fixa)

En av buggarna, och den mest alvarliga, är kryptografisk;
den metod som används för att generera krypto nyckeln för snabb (vilket i krypto == dålig), och gör programmet betydligt mer sårbart för brute-force än vad det borde vara.

Därefter finns det lite annan typ av kritik, såsom användningen av extremt gammla build verktyg, till exempel Visual C++ 1.52 - som släpptes 1993 (nuvarande version är Visual C++ 12) - samt bristen av stöd för teknik som ASLR och DEP/NX.

Slutligen så är källkods kvaliten underkänd och håller inte måttet av vad som förväntas av säkerhets orienterade problem. Några brister här skulle kunna resultera i säkerhets problem mot programmet.

  • Signed / unsigned mismatches

  • Inconsistent integer variable types

  • Lack of integer overflow protections / checks

  • Use of deprecated, insecure string APIs

  • Suppression of compiler warnings (detta gav oss Apple's GoToFail förra månaden)

  • Use of Zw APIs

Permalänk
Skrivet av Glam:

Som i alla sådana sammanhang så glömmer man lätt att fråga vem som granskar granskarna?

Är rapporten av godtagbar kvalitet så är resultatet så utförligt att vem som helst med tillräcklig kompetens som läser rapporten ska kunna granska den, och med tanke på vilka som beställt den så lär den ju bli öppet tillgänglig för alla. Det är nog bara en tidsfråga så kan du själv sätta igång och granska..

Permalänk
Medlem

Intressant..

Har mina lösenord i en folder krypterad med AES-Twofish-Serpent samt lösenordet för den är långt och komplicerat och tog en lång tid att komma ihåg (har det enbart i huvudet), det känns iaf lite säkrare så.

Kör AES men algoritmen RIPEMD-160 för lagringsdiskarna men är lite nyfiken då mina kunskaper kring detta är minst sagt dåliga. Borde jag offra lite hastighet och köra med nån bättre krypterings algoritm?

Permalänk
Inaktiv

Plot twist: Open Crypto Audit Project jobbar för NSA.

Permalänk
Medlem

Det finns även följande rapport sedan tidigare:
https://www.privacy-cd.org/downloads/truecrypt_7.0a-analysis-...

Jag har inte läst iSEC:s rapport ännu, men den ovan länkade ställer sig frågande till TrueCrypt:s färdigkompilerade paket, dvs. de exe-filer som tillhandahålls för Windows. Rapporten menar att den tillgängliga källkoden inte ser ut att innehålla någon bakdörr, men att man inte kan säkerställa att TrueCrypt-binärer kompilerade av tredje part inte innehåller någon bakdörr.

TrueCrypt:s diskformat har ett misstänksamt utrymme i slutet av dess header på 65024 bytes som åtminstone enligt rapporten beskrivs som något som hade kunnat användas för en master-backdoor-key eller dylikt. Den publika källkoden innehåller inte funktionalitet för det, men det hade en färdigkompilerad version av programmet kunnat göra -- du kan inte veta vad som har stoppats i en sådan version -- du kan inte veta om det är baserat på samma kod som den publika källkoden.

Desto mer intressant blir detta fält i headern då "The Linux version of TrueCrypt sets these bytes to zero whereas the Windows version sets them to random values." -- ett sätt att dölja en kryptonyckel om en sådan stoppas in i efterhand? En kryptonyckel hade också sett ut som random values...

TL;DR: Även om TrueCrypt får massa creds i samband med rapporter som säger att källkoden inte innehåller bakdörrar, skulle ändå de flesta TrueCrypt-användare åka dit ifall den distribuerade Windows-installeraren innehöll en bakdörrad variant av TrueCrypt.

Sweclockers: Länka till ovan länkade rapport också, IMO.

Permalänk
Medlem
Skrivet av eXale:

Det finns 4 problem av kategorin 'mellan', och 4 problem av kategorin 'låg'. (Och de går att fixa)

En av buggarna, och den mest alvarliga, är kryptografisk;
den metod som används för att generera krypto nyckeln för snabb (vilket i krypto == dålig), och gör programmet betydligt mer sårbart för brute-force än vad det borde vara.

Därefter finns det lite annan typ av kritik, såsom användningen av extremt gammla build verktyg, till exempel Visual C++ 1.52 - som släpptes 1993 (nuvarande version är Visual C++ 12) - samt bristen av stöd för teknik som ASLR och DEP/NX.

Slutligen så är källkods kvaliten underkänd och håller inte måttet av vad som förväntas av säkerhets orienterade problem. Några brister här skulle kunna resultera i säkerhets problem mot programmet.

  • Signed / unsigned mismatches

  • Inconsistent integer variable types

  • Lack of integer overflow protections / checks

  • Use of deprecated, insecure string APIs

  • Suppression of compiler warnings (detta gav oss Apple's GoToFail förra månaden)

  • Use of Zw APIs

Tycker bristerna känns lite märkliga. Om man har intresset för open scource, och göra ett bra krypteringsprogram tillgängligt för allmänheten gratis - borde inte kvalitén nästan vara hög prioritet?
De open-source-nissar jag känner, och många andra programmerare går alltid efter att göra allt så smidigt, bra, och ibland "flashigt"(dvs lösa ett problem på ett snyggt sätt) som möjligt. Halva nöjet med open source är ju att få koden så bra som möjligt? Annars blir man ju bashad i 99% av alla forum...

Vet inte hur pass mycket de anonyma utvecklarna lägger ner på truecrypt men det känns som att de inte prioriterar det eller bara helt enkelt är lata.

Visa signatur

PNY Geforce 2080 TI 2250/8200Mhz @550W (Galax HOF bios) | I7 9700K @ 5,1Ghz | Asus Rog Strix Z390-F Gaming | 32Gb 3200Mhz | Samsung 970 Pro M2.SSD | 540mm Radiator Custom loop | Valve Index

Permalänk
Skrivet av Glam:

Som i alla sådana sammanhang så glömmer man lätt att fråga vem som granskar granskarna?

Väldigt bra sagt! Ungefär som med journalisterna när dom säger "Vi granskar politikerna och staten" jaha, vem granskar journalisterna då? En bra idé kan ju annars vara att notera vilka som sponsrat programmet.

Skrivet av MrNeikter:

Plot twist: Open Crypto Audit Project jobbar för NSA.

Det där har jag hört tidigare faktiskt men har det någonsin blivit bevisat? Om mitt namn var Usama Bin-Laden och dom lyckades lägga rabarberna på min laptop (truecrypted) så skulle dom möjligtvis kunna ha resurser. Men vilken vanlig random människa som helst behöver ju inte direkt oroa sig.

Visa signatur

Många datoranvändare underskattar virus och överskattar sina egna kunskaper medan andra är omedvetna om problemet med virus. Den nonchalans som finns idag beror på ett stort antal faktorer, folk tycker virusskydd är dyrt, besvärligt och sölar ned prestandan. Något som däremot är dyrt, besvärligt och slöar ned prestandan är en infekterad dator, som dessutom förstör för alla andra på nätet. - Pedrag Mitrovic, IT-Säkerhet (2010)

Permalänk
Medlem
Skrivet av eXale:

Därefter finns det lite annan typ av kritik, såsom användningen av extremt gammla build verktyg, till exempel Visual C++ 1.52 - som släpptes 1993 (nuvarande version är Visual C++ 12)

Jag kan tänka mig varför: för att kompilera bootsekorkoden (bootloadern), eftersom det inte går att kompilera till 16-bit efter VC 1.52 så vitt jag vet. Jag var tvungen att gräva fram just VC 1.52 när jag skrev bootsektorkod senast. Åtminstone med MS produkter.

Jag skänkte för övrigt en relativt ordentlig slant till det här projektet, så det är mycket intressant att se hur det går.

Visa signatur

5950X, 3090

Permalänk
Keeper of Traditions
Skrivet av Glam:

Som i alla sådana sammanhang så glömmer man lätt att fråga vem som granskar granskarna?

Och vem granskar granskarna av granskarna egentligen?

Visa signatur

|| Intel 8700K || Asus RTX 4070 TI Super TUF || Samsung 750 EVO 500GB & Kingston A2000 1TB & Samsung 960 EVO 250GB || Corsair RM 850x || Antec P183 || Asus G-Sync RoG Swift PG279Q || Dell XPS 15 || Thinkpad X220

The Force is like Duct Tape, it has a light side, a dark side, and holds the universe together.

Permalänk
Medlem
Skrivet av Dunder:

Och vem granskar granskarna av granskarna egentligen?

Och vem granskar granskarna av granskarna utav granskarna då?

Nejmen vi kan väl anta att de gör ett bra jobb

Permalänk
Inaktiv

Vilken är den mest effektiva metoden att kryptera med TrueCrypt?

Permalänk
Medlem
Skrivet av RzrTrek:

Vilken är den mest effektiva metoden att kryptera med TrueCrypt?

Om du inte bara krypterar för att ha backuper eller annat för T.e.x hosting på annan plats, eller för att dina syskon/vänner ska komma åt det, så bör du kryptera allt, inklusive systemdisk.

När det gäller format o.s.v. så är det helt upp till dig och hur paranoid du är. I Teorin är alla säkra men som alltid när det gäller kryptering, desto långsammare desto bättre.

Visa signatur

Speldator: Ryzen 7800X3D, 64GB DDR5, RTX 3070
Server: i7-8700k, 32GB DDR4, RTX2080
Steam deck + de fiesta konsoller.

Permalänk
Medlem
Skrivet av pixnion:

Det finns även följande rapport sedan tidigare:
https://www.privacy-cd.org/downloads/truecrypt_7.0a-analysis-...

Jag har inte läst iSEC:s rapport ännu, men den ovan länkade ställer sig frågande till TrueCrypt:s färdigkompilerade paket, dvs. de exe-filer som tillhandahålls för Windows. Rapporten menar att den tillgängliga källkoden inte ser ut att innehålla någon bakdörr, men att man inte kan säkerställa att TrueCrypt-binärer kompilerade av tredje part inte innehåller någon bakdörr.

TrueCrypt:s diskformat har ett misstänksamt utrymme i slutet av dess header på 65024 bytes som åtminstone enligt rapporten beskrivs som något som hade kunnat användas för en master-backdoor-key eller dylikt. Den publika källkoden innehåller inte funktionalitet för det, men det hade en färdigkompilerad version av programmet kunnat göra -- du kan inte veta vad som har stoppats i en sådan version -- du kan inte veta om det är baserat på samma kod som den publika källkoden.

Desto mer intressant blir detta fält i headern då "The Linux version of TrueCrypt sets these bytes to zero whereas the Windows version sets them to random values." -- ett sätt att dölja en kryptonyckel om en sådan stoppas in i efterhand? En kryptonyckel hade också sett ut som random values...

TL;DR: Även om TrueCrypt får massa creds i samband med rapporter som säger att källkoden inte innehåller bakdörrar, skulle ändå de flesta TrueCrypt-användare åka dit ifall den distribuerade Windows-installeraren innehöll en bakdörrad variant av TrueCrypt.

Sweclockers: Länka till ovan länkade rapport också, IMO.

https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries...

Permalänk
Medlem
Skrivet av pixnion:

Det finns även följande rapport sedan tidigare:
https://www.privacy-cd.org/downloads/truecrypt_7.0a-analysis-...

Jag har inte läst iSEC:s rapport ännu, men den ovan länkade ställer sig frågande till TrueCrypt:s färdigkompilerade paket, dvs. de exe-filer som tillhandahålls för Windows. Rapporten menar att den tillgängliga källkoden inte ser ut att innehålla någon bakdörr, men att man inte kan säkerställa att TrueCrypt-binärer kompilerade av tredje part inte innehåller någon bakdörr.

TrueCrypt:s diskformat har ett misstänksamt utrymme i slutet av dess header på 65024 bytes som åtminstone enligt rapporten beskrivs som något som hade kunnat användas för en master-backdoor-key eller dylikt. Den publika källkoden innehåller inte funktionalitet för det, men det hade en färdigkompilerad version av programmet kunnat göra -- du kan inte veta vad som har stoppats i en sådan version -- du kan inte veta om det är baserat på samma kod som den publika källkoden.

Desto mer intressant blir detta fält i headern då "The Linux version of TrueCrypt sets these bytes to zero whereas the Windows version sets them to random values." -- ett sätt att dölja en kryptonyckel om en sådan stoppas in i efterhand? En kryptonyckel hade också sett ut som random values...

TL;DR: Även om TrueCrypt får massa creds i samband med rapporter som säger att källkoden inte innehåller bakdörrar, skulle ändå de flesta TrueCrypt-användare åka dit ifall den distribuerade Windows-installeraren innehöll en bakdörrad variant av TrueCrypt.

Sweclockers: Länka till ovan länkade rapport också, IMO.

Kul att du tar upp detta, men att Windows-versionen skriver skräp och att Linux-versionen skriver nollvärden i nyallokerat minne behöver inte ha någonting med TrueCrypt att göra. Det skulle ju vara som att säga att Release builds kompilerade i Visual Studios kompilator har bakdörrar bara för att de inte memsettar minnet innan det returneras från operativsystemet.

Hade ju varit mer intressant ifall de förkompilerade Windows-binärerna faktiskt skrev skräp och de man kompilerar från källkoden inte gör det; som tur är så är inte fallet så.

Här finns en beskrivning av hur man gör för att kompilera eländet själv.

Personligen tycker jag det är en bra diskussion men likväl löjligt uppblåst. Hela Windows är "förkompilerat" och folk använder förmodligen förkompilerade PHP, Apache och Git/Subversion också. Och vill man dra det långt kan man ifrågasätta hur säkert det är att använda en kompilator som man inte kompilerat själv.

Lade till länk till Xaviers artikel om hur man kompilerar TrueCrypt från källkoden
Permalänk
Medlem

Intressant! Ska spana in.

Skrivet av Curik:

Kul att du tar upp detta, men att Windows-versionen skriver skräp och att Linux-versionen skriver nollvärden i nyallokerat minne behöver inte ha någonting med TrueCrypt att göra. Det skulle ju vara som att säga att Release builds kompilerade i Visual Studios kompilator har bakdörrar bara för att de inte memsettar minnet innan det returneras från operativsystemet.

Hade ju varit mer intressant ifall de förkompilerade Windows-binärerna faktiskt skrev skräp och de man kompilerar från källkoden inte gör det; som tur är så är inte fallet så.

Detta handlar om data skriven till själva volymheadern som är placerad på disk dock! Här beskriver TC:s sida diskformatet, och även det "reserverade" blocket som startar på offset 512.

Skrivet av Curik:

Här finns en beskrivning av hur man gör för att kompilera eländet själv.

Samma som Kyroz länkade ser det ut som, yes.

Skrivet av Curik:

Personligen tycker jag det är en bra diskussion men likväl löjlig. Hela Windows är "förkompilerat" och folk använder förmodligen förkompilerade PHP, Apache och Git/Subversion också. Och vill man dra det långt kan man ifrågasätta hur säkert det är att använda en kompilator som man inte kompilerat själv.

Agreed, därför man inte sitter med Windows för något vettigt ändå.

Permalänk

Någon som har koll på om Bitlocker är bra eller om de finns bakvägar? Jag vet att de fanns för många år sen som nu är täppta men 100% säker kan man inte vara eller?

Visa signatur

EMS Design Webbyrå i Stockholm:
http://www.emsdesign.se
Inet Fraktfritt
https://www.inet.se/artikel/6101343/
"Citera för svar/respons"

Permalänk
Medlem
Skrivet av pixnion:

Detta handlar om data skriven till själva volymheadern som är placerad på disk dock! Här beskriver TC:s sida diskformatet, och även det "reserverade" blocket som startar på offset 512.

Vad har det med saken att göra att den är placerad på disk? Någon eller något måste skriva den där också, och källkoden som ansvarar för det går att granska och kompilera precis som övriga TC går att granska och kompilera.

Skrivet av pixnion:

Agreed, därför man inte sitter med Windows för något vettigt ändå.

Haha, jaha! Du var ett open-source troll utan några egentliga kunskaper. Det var ju inte så otippat med tanke på dina svar iofs. Tack för illusionen av en diskussion, och glöm aldrig Heartbleed min kära vän!

Permalänk
Inaktiv

själv har jag ingen personlig data på HD som jag inte bryr mig så mycket om. kör Oldskool crypt på alla lösen, penna och en svart bok

Permalänk
Medlem
Skrivet av Glam:

Som i alla sådana sammanhang så glömmer man lätt att fråga vem som granskar granskarna?

Du, du väljer om du tror på dem eller inte.

Permalänk
Medlem
Skrivet av Curik:

Vad har det med saken att göra att den är placerad på disk? Någon eller något måste skriva den där också, och källkoden som ansvarar för det går att granska och kompilera precis som övriga TC går att granska och kompilera.

Men varför finns egentligen en skillnad där Linux-versionen skriver nullbytes (men krypterade), medan Windows-versionen skriver random bytes (också krypterade)? Att volym-headern skrivs på det sättet i Windows hade ju helt klart förenklat för en bakdörrad TC-version, där det hade kunnat finnas både en "användar-nyckel" och någon slags "backdoor-nyckel" - det hade helt enkelt blivit lätt som en plätt att gömma en sådan nyckel, och inspektion av volymheadern hade inte visat på något fuffens då det hade sett ut precis som vanligt.

Men jag har läst igenom exe-jämförelsen nu och det ser ju helt klart ut som att deras färdigkompilerade versioner är harmlösa, så det är ju good news. Hade varit kul att få reda på varför denna skillnad mellan Windows- och Linux-versionen finns dock.

Skrivet av Curik:

Haha, jaha! Du var ett open-source troll utan några egentliga kunskaper. Det var ju inte så otippat med tanke på dina svar iofs. Tack för illusionen av en diskussion, och glöm aldrig Heartbleed min kära vän!

Ska jag ens svara på detta? Kanske lite för het på gröten med att både troll- och dumförklara mig...?

Typo
Permalänk

Kör TrueCrypt på alla mina diskar/SSD'r och kommer alltid göra't...

Visa signatur

Mitt kärnkraftverk
|Asus PRIME-B350-PLUS|PH-TC14PE_OR|Ryzen 5 1400@3890MHz|Vega 56@Vega64bios |Corsair 2x4GB 3200MHz|Corsair TX 650w Bronze|CM Storm Enforcer|AOC G2460PF / 24"144Hz FreeSync|

Permalänk
Medlem
Skrivet av Ytbehandlad:

Kör TrueCrypt på alla mina diskar/SSD'r och kommer alltid göra't...

Även jag kör TC och är nöjd, men jag kan dock inte gå i god för att jag alltid kommer att göra det...kommer något bättre så byter jag direkt...

Permalänk
Medlem
Skrivet av ericsundell2:

Någon som har koll på om Bitlocker är bra eller om de finns bakvägar? Jag vet att de fanns för många år sen som nu är täppta men 100% säker kan man inte vara eller?

Finns inga kända sådana i alla fall. Frågan du ska ställa dig är vad du skyddar din data ifrån. Bitlocker kan vara tillräckligt skydd beroende på vad du försöker skydda dig ifrån. T.ex. vanlig stöld? Tja bitlocker funka klockrent.

Visa signatur

Speldator: Ryzen 7800X3D, 64GB DDR5, RTX 3070
Server: i7-8700k, 32GB DDR4, RTX2080
Steam deck + de fiesta konsoller.

Permalänk
Medlem
Skrivet av MugiMugi:

Tja kört det ett bra tag, oftast för att hantera och skydda känsliga backuper, speciellt då jag behöver ha en hel del av backuperna offsite och de innehåller en hel del känslig data.

Funkar hyfsat med rsync att synka iväg dom offsite med, inte precis världens optimalaste men det funkar för min del, blir också lättare att handskas med en fil istället för miljontals.

Eh?

Hur kan detta vara optimalt eller ens smart?
Man kör krypterade volymer på båda ställena som skyddar datat. Men när du skall synka datat så kör du mot volymen och tunnlar över datat till andra volymen som givetvis är öppnade vid tillfällena - mellan parterna! Det betyder att om en txt fil ändras så slipper du skicka volymen i fråga utan bara just den txt-filen!
Rsync är ytterst kompetent.