Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 181 reacties
Submitter: Freeaqingme

Een van de veronderstelde ontwikkelaars van TrueCrypt zou het geen goed idee vinden dat er een fork wordt gemaakt van TrueCrypt. Vanaf nul beginnen zal niet heel veel meer werk kosten dan het leren kennen en begrijpen van de code, stelt hij of zij.

TrueCryptDe anonieme, veronderstelde TrueCrypt-ontwikkelaar deed zijn uitlatingen in een e-mailwisseling met Matthew Green, docent cryptografie aan een Amerikaanse universiteit. "Ik denk niet dat het forken van TrueCrypt een goed idee zal zijn", schrijft de ontwikkelaar. "Het compleet herschrijven van de broncode is iets wat we al langer wilden doen."

De ontwikkelaars van TrueCrypt waarschuwden gebruikers van de versleutelsoftware eind mei dat ze de software beter niet meer konden gebruiken. Misschien zitten er beveiligingslekken in de software. Bovendien werd tegelijkertijd een nieuwe versie van de software geïntroduceerd die enkel nog de mogelijkheid biedt om al versleutelde bestanden te ontsleutelen, zodat gebruikers nog bij hun bestanden kunnen komen. Het versleutelen van bestanden wordt niet meer ondersteund.

Het is nog steeds niet duidelijk waarom de software offline is gehaald, maar sinds de waarschuwing van de TrueCrypt-ontwikkelaars gaan er stemmen op om de software te forken. Volgens de anonieme TrueCrypt-ontwikkelaar is vanaf nul beginnen beter. "Dat zal niet heel veel meer werk kosten dan het leren kennen en begrijpen van alle delen van de TrueCrypt-broncode." Daarbij heeft de ontwikkelaar er geen problemen mee als de broncode van TrueCrypt als referentie wordt gebruikt.

Moderatie-faq Wijzig weergave

Reacties (181)

Het herschrijven is waarschijnlijk hoe dan ook een goed idee, omdat de huidige code alleen gecompileerd kan worden met een inmiddels verouderde compiler die bovendien zelf niet open-source is.

Redenen waarom de ontwikkelaars zelf de interesse zouden hebben kunnen verloren zijn reeds uitgebreid genoemd (http://bradkovach.com/201...tom-of-a-greater-problem/) en daar kan ik me prima in vinden.

Zoals ik eerder al zei; wellicht willen ze geen fork, maar dit is hun manier om het project over te dragen aan de community. Het advies om over te stappen naar BitLocker lijkt me eigenlijk sarcastisch en verwijzend bedoeld: "als dit project niet verder gaat, dan is BitLocker je enige alternatief".
Het herschrijven is waarschijnlijk hoe dan ook een goed idee, omdat de huidige code alleen gecompileerd kan worden met een inmiddels verouderde compiler die bovendien zelf niet open-source is.
Welke compiler heb je het dan over? Er is een Linux versie van True Crypt en het zou mij echt enorm verbazen als die NIET met een GCC compiler is gebouwd. Is er überhaupt nog wel een andere compiler voor Linux in de omloop, want voor zolang ik met kan herinneren is het altijd al een GCC compiler geweest.

Als ik goed gelezen heb zou voor Windows een MSVC++ 1.5 compiler zijn gebruikt. Maar als je het voor Linux kan bouwen lijkt het me niet zo'n groot probleem om het met Cygwin te bouwen of met MSYS (maar dan ben je wel afhankelijk van de Windows runtime libraries - dus niet open source zoals Cygwin libgcc).

Daarnaast is de Microsoft compiler zo oud dat de kans dat daarmee geknoeid is minimaal is, dat was in 1993 nog helemaal niet aan de orde. Ik denk eerder dat die schoon is van achterdeurtjes dan een nieuwe. En veel C libraries waren nog plat C of assembly en veel ruimte voor achterdeurjes was er ook niet want dat zou je meteen gemerkt hebben aan de performance op de toenmalige processors.

Blijft over de low level code voor bootloader maar dat zal meer werk zijn op het niveau masm. En echt elk statement wordt gewoon een x86 instructie, oude compiler/assembler of niet dus ook daar weinig ruimte.

Hou je over bugs, maar dat heeft niets met de gebruikte compiler te maken.
Als Cygwin of MSYS echt opties waren geweest, ben ik er vrij zeker van dat hier wel meer onderzoek naar was gedaan. Misschien dat iemand met meer verstand hiervan er een licht over kan schijnen, maar mijn gevoel zegt me dat het niet zo simpel is.

Persoonlijk ben ik niet erg bang voor NSA-achtig geknoei aan de MSVC++ compiler, maar denk ook aan eventuele bugs in de compiler zelf, of onverwacht gedrag. Ik denk dat je voor veilige encryptie een bijzonder goed idee moet hebben van hoe de compiler zijn werk doet, om zeker te weten dat er een zo veilig mogelijke binary uit komt. En bij die oude closed source MSVC++ compiler lijkt me dat moeilijker dan bij een recente open-source compiler.

Het is verder altijd helder geweest dat TC een product was dat zich in principe helemaal op Windows richtte. De Linux-source was meer bijzaak. Er zijn intussen ook voldoende alternatieven op Linux om TC-containers te gebruiken.
Persoonlijk ben ik niet erg bang voor NSA-achtig geknoei aan de MSVC++ compiler, maar denk ook aan eventuele bugs in de compiler zelf, of onverwacht gedrag. Ik denk dat je voor veilige encryptie een bijzonder goed idee moet hebben van hoe de compiler zijn werk doet, om zeker te weten dat er een zo veilig mogelijke binary uit komt. En bij die oude closed source MSVC++ compiler lijkt me dat moeilijker dan bij een recente open-source compiler.
Dat zou ik niet te hard zeggen. Juist moderne compilers kunnen de code heftig verbouwen bij het optimaliseren. Zoals dat in het rapport van de lopende audit staat is er bijvoorbeeld een risico dat de compiler een "memset" weg optimaliseerd omdat zelfde geheugenruimte toch weer wordt overschreven en die "memset' dus feitelijk wat de compiler betreft overbodig is.

Ik denk dat juist een oude compiler veel minder van dit soort trucs heeft en just de geschreven code veel meer naar de letter volgt. Een moderne compiler is juist veel moeilijker te doorgronden door dat soort optimalisaties. Dus vanwege security kun je beter die oude compiler gebruiken, je zou zelfs de assembly code kunnen auditen want die is meestal goed te volgen met de C code er naast.
Ik denk dat juist een oude compiler veel minder van dit soort trucs heeft en just de geschreven code veel meer naar de letter volgt. Een moderne compiler is juist veel moeilijker te doorgronden door dat soort optimalisaties. Dus vanwege security kun je beter die oude compiler gebruiken, je zou zelfs de assembly code kunnen auditen want die is meestal goed te volgen met de C code er naast.
Of je kunt ook gewoon optimalisaties uitzetten.
Ik denk dat je voor veilige encryptie een bijzonder goed idee moet hebben van hoe de compiler zijn werk doet, om zeker te weten dat er een zo veilig mogelijke binary uit komt. En bij die oude closed source MSVC++ compiler lijkt me dat moeilijker dan bij een recente open-source compiler.
Daarbij is dan vooropgesteld dat je de waarschijnlijk gigantisch ingewikkelde broncode van de compiler kunt lezen en begrijpen. Een applicatie schrijven, en de broncode ervan een poos later nog steeds begrijpen, is lastig voor menig programmeur, maar een compiler is wel even andere koek.
Ik kan me goed voorstellen dat mensen niet naar buiten komen met details over wat er mis is, aangezien er nogal wat met truecrypt versleuteld is en een eventuele gevoeligheid publiceren zonder een patch mogelijkheid te bieden knap asociaal is.

Wat ook in die link staat, truecrypt is een hobby project van een team dat niemand kent. Dat team zegt "we houden ermee op", whatever de reden; vanaf dat moment kun je geen uitspraken van het oude team vertrouwen, want, A je weet niet of de uitspraak echt van het team komt en B je weet niet of er meer dan één kamp in dat team is.

Het enige wat je weet; dat project is niet meer te vertrouwen - mijns inziens een wonder dat het überhaupt vertrouwd werd. Of je het nu wel of niet een fork gaat noemen, je zult alle code onder de loupe moeten leggen om eventuele zwakke punten te herkennen. Als je dat moet doen is de bestaande code wellicht eerder een blok aan je been dan een hulp.

Of dat punt mbt bitlocker sarcastisch is bedoeld weet vrijwel niemand, het is in ieder geval de waarheid.
ik denk dat je de fout niet moet zoeken in de code "an sich", maar eerder in het design.
Het is wel een sterk punt. Met het leren van een broncode/begrijpen duurt langer dan zelf ontwikkelen. Ook weet je zeker dat je alles zelf beter onder controle hebt.
zo sterk is het niet eens, van nul beginnen betekend dat je om sneller iets werkbaars te hebben weer met de zelfde shizzle begint waardoor je dezelfde legacy problemen krijgt soms kun je dan bijna beter een bestaand project hbben en daar steeds delen uit herschrijven totdat je na x versies het meeste wel zo'n beetje herschreven hebt... om dan vervolgens weer door te gaan ontwikkelen...

je cloned (en verbeterd) dan eerder software dan dat je die echt zelf ontwikkeld...
Ja, maar wederom is hier niet duidelijk WAAROM niet? Net zoals bij het plotse offline halen van de software wordt hier niks mee beantwoord.
Het doet vermoeden dat er toch echt duidelijk iets mis mee is en waarschijnlijk is men bang dat dat ontdekt wordt. Of het is toch zodanig goed dat ze van een niet nadere te noemen instantie het dringende advies gehad hebben om het te doen.

Wat het ook is, dat zullen we nooit horen.

Toch denk ik dat opnieuw beginnen beter is, tenzij je van te voren heel goed je code hebt gedefineerd en systematisch werkt. Oude code kunnen makkelijk fouten insluipen, onoverzichtelijk worden of gewoon weg compacter/beter gecode worden. Heb zelf toch ook al mee gemaakt dat ondanks zorgvuldig plannen opnieuw beginnen beter en uiteindelijk sneller was (zowel de code als het evt. vinden van ondefineerbare fouten)
Wat het ook is, dat zullen we nooit horen.
Dat weten we nog niet. Phase 2 van het Open Crypto Audit project loopt nog. In Phase 1 is een code-review gedaan, daar zijn een aantal ( 8 ) vulnerabilities uitgekomen, maar heel erg spannend zijn die niet. Het rapport daarvan kan je downloaden op bovengenoemde site.

Phase 2 checkt voornamelijk op crypto algorithmes en eventuele weakness daarin (cryptanalysis). Dat zou nog best iets op kunnen leveren. Wanneer dit klaar is, is nog onduidelijk.

http://istruecryptauditedyet.com/

[Reactie gewijzigd door EnigmA-X op 17 juni 2014 11:36]

Inderdaad, je gaat bijna denken dat een van de ontwikkelaars er een soort backdoor in heeft gebouwd (danwel voor zichzelf, of een overheids instantie)
Dit was toch al onderzocht door een aantal onderzoekers? Dat er geen backdoors in zaten, maar wel een aantal programmeerfouten.

Maar wel raar dat er geen reden wordt gegeven, het lijkt er steeds meer op dat de druk van ee overheidsinstantie teveel is geworden voor de ontwikkelaars dat ze het offline hebben gehaald. En vanwaar die druk? Waarschijnlijk omdat er geen backdoor in zit en het niet/moeilijk te kraken is voor de overheid. Dan maar offline halen, zodat mensen andere tools gaan gebruiken welke wel te kraken zijn of waar wel een backdoor in zit.

Het zijn aannames, maar ik ben er eigenlijk wel van overtuigd dat er niks mis is met TrueCrypt.

[Reactie gewijzigd door evildeeds op 17 juni 2014 11:27]

Je gaat dus volledig uit van de resultaten van 1 onderzoek. Ik ben daar toch heel wat voorzichtiger mee.
Sterker, ik vertrouw Truecrypt niet meer, er is wat aan de hand maar de makers kunnen of willen niet exact aangeven dat er wat mis is. Maar dat er wat mis is, willen ze wel laten weten.
Daarbij geven ze aan dat de code als referentie kan worden gebruikt. Hiermee sluit je jouw argument uit dat 'ze' dit doen omdat Truecrypt onkraakbaar is en ze mensen willen overhalen om makkelijker te kraken software te gebruiken.
Sterker, ik vertrouw Truecrypt niet meer...
Helemaal weten doen we het niet, maar het zou ook kunnen zijn dat de krachten achter het stoppen van TrueCrypt juist willen dat wij de software niet meer vertrouwen. Ik kan me voorstellen dat TrueCrypt voor veel overheden een doorn in het oog is, simpelweg omdat het misschien té goed zijn werk doet en het héél lastig is om een door TrueCrypt versleutelde container te kraken?

De versleuteling wordt niet gegeneerd door een key-generator, maar door willekeurige muisbewegingen. Dat maakt dat elke versleuteling uniek is. Zoiets kraken lijkt mij een stuk lastiger dan een random key die is aangemaakt door zo'n programmaatje: immers is een random key niet zo oneindig als een willekeurige muisbeweging waarmee de versleuteling wordt gegenereerd.

Maar anyway: wat hier allemaal achter steekt weten we niet, maar ik houd er wèl rekening mee dat sommige partijen er wel belang bij hebben dat wij TrueCrypt, of een fork daarvan, wantrouwen. Het komt ze niet slecht uit in ieder geval....

[Reactie gewijzigd door Qalo op 17 juni 2014 12:58]

Het spijt me, maar ik moet hier even wat aan corrigeren.

1. Er zijn voor elk platform equivalenten van TrueCrypt te vinden die conceptueel nauwelijks verschillen en technisch zeker niet minder zijn. BitLocker, FileVault en dm-crypt zijn ook beproefde programma's die net zo min door forensische organisaties gekraakt kunnen worden.

2. Omdat je je muis moet bewegen bij het genereren van je TrueCrypt-key is het niet meteen een "willekeuriger" sleutel dan anderen. Andere encryptieprogramma's gebruiken de entropiepool van je besturingssysteem die niet alleen worden bijgevuld door de willekeur van je muisbewegingen, maar ook de aanslag van je toetsen en de willekeurige timing van interrupts in je CPU. Het is best goed dat ze entropie met je muis verzamelen, maar de claim dat dat een betere key zou opleveren is volstrekte onzin.

3. Denk niet als een crypto nerd. Het is bijzonder onwaarschijnlijk dat technische details van TrueCrypt een motivatie zijn voor dergelijke zaken.

[Reactie gewijzigd door DCK op 17 juni 2014 13:38]

Nou sorry, ik vertrouw TrueCrypt wel wat meer dan Microsoft met Bitlocker. Grote kans dat daar gewoon een backdoor in zit.
Je vertrouwen in truecrypt is echter volslagen irrationeel want je weet niet eens wie de ontwikkelaats zijn die truecrypt hebben gebouwd.
Dat kan de NSA zelf wel geweest zijn of de russische geheime dienst

[Reactie gewijzigd door 80466 op 17 juni 2014 14:23]

Daarom ben ik ook best blij met de code review die nu wordt gedaan en met de reviews die al zijn gedaan. Wat dat betreft is het vertrouwen in pakketten die dat onmogelijk maken een stuk irrationeler.
Let wel dat het vinden van backdoors in cryptografische software echt ontzettend moeilijk is. Het is niet een extra if-statement, buffer-overrun of zoiets dat je vrij eenvoudig ziet. Het kunnen zwakheden zijn in crypto-tabellen die maar heel lastig zijn te vinden. Ook bij een flinke review van de code kunnen er dergelijke backdoors in blijven zitten.

Om cryptografische software te reviewen moet het exacte algoritme gereviewd worden door crypto-experts (en dat is knap lastig). Verder kunnen er backdoors/bugs zitten in de software zelf. Die moeten door ervaren programmeurs worden bekeken.

Eigenlijk kun je alleen maar aantonen dat er een gat zit in cryptografische software. Aantonen dat het goed is, is vrijwel onmogelijk.
In dat geval kan je dus beter stoppen met cryptografische beveiliging van je gegevens. Je weet tenslotte bij geen enkel product of het dan echt veilig is. Zelfs bij een perfecte review, want zelfs een crypto-expert heeft wel eens een slechte dag.
Als de NSA (of welke andere geheime dienst) achter TreuCrypt zou zitten, waarom zouden ze dan nu opeens ophouden met de ontwikkeling?

TrueCrypt word (ondertussen werd?) door heel veel mensen gebruikt. Als het ontwikkeld zou zijn door een geheime dienst, dan zou die dienst dus ook toegang hebben tot de versleutelde bestanden. Dan gaan ze echt niet opeens stoppen en op deze manier het vertrouwen in de tool saboteren. Dat is absoluut niet in hun belang.

Nee, dan acht ik het heel wat waarschijnlijker dat de NSA (of een andere overheidsorganisatie) juist druk op de ontwikkelaar(s) heeft uitgeoefend om ze te laten stoppen. Dat is ook meteen de enige reden die ik kan bedenken waarom de ontwikkelaar(s) niet gewoon vertellen waarom ze nou precies stoppen met de ontwikkeling. Er zou misschien een fout in de tool zitten... Nou en, los die dan op. Dat is toch geen reden om te stoppen... En als je dan toch wilt stoppen, vertel dan wat de fout is, zodat iemand anders hem op kan lossen.
Als de NSA (of welke andere geheime dienst) achter TreuCrypt zou zitten, waarom zouden ze dan nu opeens ophouden met de ontwikkeling?
Vanwege de audit op de code bijvoorbeeld.

Nieuwe code toevoegingen op de geaudite codebasis zullen veel scherper bekeken worden en sneller verdenkingen oproepen als ze gemaakt zijn om een zwakke plek te introduceren.

Zelfs als vinden ze nu geen zwakke code of backdoors dan nog heeft het verder ontwikkelen weinig zin.
Vanwege de audit op de code bijvoorbeeld.
Geweldig, het plot gaat nog dieper dan ik had gehoopt.

De audit is volgens mij begonnen, nadat jouw NSA er de brui aan had gegeven. Maar misschien was er een ongeluk met veel drank, een tijdmachine en een elastiekje. ;)

Gek genoeg denk ik dat de NSA beter een CS project zou zijn gestart. De meeste gebruikers van TrueCrypt gaven toch al niet om de licentie. Dat had het audit risico een stuk kleiner gemaakt.

Maar deze ga ik noteren voor mijn filmscript... ;)
jouw NSA
Sinds wanneer is de nsa van mij?
Ik bedoel het denkbeeldige NSA in het hAliversum. :+ Maar nu stop ik er echt mee, want het benadert het absolute absurde dat ik hier nog op in ga.
Ik noem maar de makkelijkste optie. Er zijn talrijke alternatieven. Het is je goed recht om organisaties wel of niet te vertrouwen, maar ik vertrouw Microsoft er wel op een systeem te leveren dat niet gekraakt kan worden door dieven en journalisten.
Als je de alternatieven dan nader gaat bekijken zie dat de meeste afvallen. En dat je al gauw naar dure business software zal moeten uitwijken, waarvan der meeste in de VS gevestigd zijn.

Er zijn denk ik voldoende rare dingen aan de hand ook de bij de anderen, als ik dit soort dingen lees:

"The FreeOTFE website is unreachable as of June 2013 and the domain name is now registered by a new owner. "

http://en.wikipedia.org/wiki/FreeOTFE

[Reactie gewijzigd door fevenhuis op 18 juni 2014 00:42]

Sinds de laatste release (4 jaar geleden) is er ook geen spoor van de auteur meer te vinden. Eerst was de hosting verlopen en later was het domein verlopen omdat ze gewoon niet meer betaald werden. Het domein is gewoon gesquat.

Wikipedia: FreeOTFE: Anyone know if the author is still alive?

[Reactie gewijzigd door Redsandro op 17 juni 2014 19:13]

...maar ik vertrouw Microsoft er wel op een systeem te leveren dat niet gekraakt kan worden door dieven en journalisten
Ik wil niet vervelend doen, maar hiermee neem je de twijfel natuurlijk niet weg. Aannames zijn geen feiten, dus geen zekerheid dat het ook écht zo is. En controleren kun je het niet, want je kunt de broncode niet inzien van Microsoft producten.

Ik mag door jou wel als zijnde een "crypto nerd" worden bestempeld, maar liever dát dan een onbegrenste vertrouwen in een Amerikaans softwarebedrijf die door zijn eigen overheid verplicht wordt mee te werken aan de door hen opgestelde Patriot Act.

Maar daar gaat het nog niet eens om: waar het wèl om gaat: hoe zit het nu écht met dat hele TrueCrypt verhaal? Ik lees allerlei theorieën erover, maar.... wat is waarheid?

[Reactie gewijzigd door Qalo op 17 juni 2014 18:01]

Er zijn voor elk platform equivalenten van TrueCrypt te vinden die conceptueel nauwelijks verschillen en technisch zeker niet minder zijn.
Maar er zijn maar weinig programma's die multi-platform zijn en dus ook op alle platformen te gebruiken is. Wat heb ik aan een ge-encrypteerde container met extensie A op Windows als ik diezelfde container met een ander proggie, die alleen extensie B kan openen, het dus niet kan openen/bewerken? Dáár gaat het ook mede om. BitLocker is niet te gebruiken onder Linux. En een soortgelijk programma onder Linux is op Windows weer waardeloos.

En verder: programma's zoals BitLocker encrypten een hele volume. Met TC kon je gewoon een bestand (container) aanmaken en daarin je data opslaan. Dat is een verschil...

[Reactie gewijzigd door Qalo op 17 juni 2014 17:48]

Ik zeg niet dat truecrypt makkelijk te kraken is maar kennelijk is er wel wat meer aan de hand. Ik zou staatgeheimen er niet aan toevertrouwen. Mijn eigen prive gegevens is een andere zaak omdat de risico's lager liggen. De gemiddelde dief zal mijn schijven niet kunnen lezen. Voor dat volstaat truecrypt dus.
Mijn lanceercodes voor de tientallen nukes die ik in mijn achtertuin heb staan, dat is een ander verhaal ;)

Omdat de makers van deze tool een hoger doel voor ogen hebben dan geld te verdienen met deze software vermoed ik dat er toch wat meer aan de hand is. Voor de makers zal het streven misschien kunnen zijn: 100% veilig of niets zijn.
Mijn lanceercodes voor de tientallen nukes die ik in mijn achtertuin heb staan, dat is een ander verhaal
Pas op he! De sarcasme ontdek code is bij NSA nog niet geimplementeerd!!!
Je gaat dus volledig uit van de resultaten van 1 onderzoek
Maar dat is dan toch vaak al 1 onderzoek meer dan menig closed source pakket voor encryptie.

Ik heb de indruk dat er bij TrueCrypt een beetje speelt wat ik ook zie bij bepaalde projecten bij klanten. Er zijn specialisten op bepaalde onderdelen van het systeem, die liever niet hebben dat je aan hun code komt. Je mag er wel op debuggen, maar wijzigen alleen na uitvoerig overleg.

Het is een beetje het idee van een 'kindje' wat je niet los kan laten.

Er zijn intussen echt prachtige Hollywood scenario's bedacht, maar ik denk dat het gewoon zoiets simpels is.
Maar dat is dan toch vaak al 1 onderzoek meer dan menig closed source pakket voor encryptie.
Closed source vendor laten belangrijke encryptie modules ook vaak controleren en/of auditten.
Zo zijn bijvoorbeeld de cryptografische modules van Microsoft in Windows (ook gebruikt in bitlocker) door NIST en CSEC gecontroleerd en voldoen ze aan de FIPS-140 standaard van de US en Canadese overheden.
Maar is de code waar ze de audit op laten doen de code die ze uiteindelijk uitbrengen?

Bij TrueCrypt lijkt het populair om aan alles te twijfelen, dus waarom zou ik Microsoft op haar 'vierkleurige ogen' vertrouwen?

Voor elke wilde bewering over TrueCrypt is tenslotte een even wilde bewering over bijvoorbeeld Bitlocker te bedenken.

Ik vind persoonlijk beide even onzinnig.
Zelfs truecrypt gebruikt OS calls.
Dit was toch al onderzocht door een aantal onderzoekers? Dat er geen backdoors in zaten, maar wel een aantal programmeerfouten.
Nee niet uitvoerig, er was "snel" overheen gescand om te kijken of er op het 1e gezicht wat te zien was, een gedetailleerde audit is laatst via crowd funding gefinancieerd, deze zal dus niet meer nodig zijn nu....
deze zal dus niet meer nodig zijn nu....
Dat is voor mij nog niet zo duidelijk. Er zit een verschil tussen één ontwikkelaar, die het een slecht idee lijkt en een volledig ontwikkel team dat zegt, dat het niet mag.

Dus de fork is voor mij nog niet van tafel.

Ik acht de kans wel groot dat het door gaat onder een nieuwe naam met een nieuw logo. Want dat waren volgens mij de grootste struikelpunten voor het voorzetten van Truecrypt.
De source code heeft ook geen licentie die een fork toestaat.
Nog niet, maar ik denk dat dat wel rond gaat komen uiteindelijk.
Hoezo? Truecrypt heeft zijn eigen licentie en de software behoort toe aan de organisatie die erachter zit, als een enkele developer of een klein groepje developers besluit om de code te forken, kan de organisatie hiertegen stappen ondernemen.
Dan weten we wel eindelijk wie het is/zijn.
Zou dat dan niet al ontdekt zijn aangezien truecrypt open source was?
OpenSSL is ook open source, en toch sloop daar een bug in die het hele systeem onveilig maakte (Heartbleed). TL;DR: open source betekent niet dat bugs / backdoors altijd ontdekt worden.
Dat het open-source is wil weinig zeggen, niemand heeft zin om heel veel data door te bladeren opzoek naar een backdoor die er wellicht niet eens in hoeft te zitten.

En dan schrijf ik dit stuk alleen nog maar vanuit het oogpunt dat disclaimers ook nooit doorgenomen worden, hoevaak zie je welniet dat "bedrijf x" iets heeft opgenomen in zijn disclaimer die hen, al jou data laat gebruiken. (dit word door een oplettende lezer ook pas veel vaker opgemerk terwijl dit toch duidelijke taal voor iedereen is)
Daarom moet de contractvrijheid voor consumentenproducten opgeheven worden. Het is onredelijk bezwarend om voor iedere applicatie, webshop of koopcontract specifieke en algemene contractvoorwaarden te moeten doornemen en administreren.

Er moet gewoon een wet komen die een standaardcontract voorschrijft voor diverse productgroepen. Hoe moeilijk kan het zijn? Als ik bij een supermarkt iets koop hoef ik toch ook geen verkoopvoorwaarden te lezen?
Inderdaad. Het is nog te doen als die voorwaarden bijv. max 500 woorden bevatten (< 1 A4). Maar veel hebben wel 20 of meer A4's.
Onzin. In oude code zijn ook vaak heel veel bugs en corner cases al gehandled. Al die problemen ga je in nieuwe code opnieuw tegen komen. Je begint met een stuk code dat je wil weggooien omdat het allemaal niet elegant is en vol zit met rare constructies en niet-zo-fraaie uitzonderingen. Je denkt: "dat kan allemaal veel eleganter!" en begint opnieuw. En dan kom je stap voor stap tot de ontdekking dat je ook in eigen code allerlei bugs hebt zitten en allerlei corner cases nog niet afgedekt hebt, en stap voor stap komen hetzelfde soort rare constructies en uitzonderingen weer terug in je eigen code die zo fraai en elegant begon.

Ik zeg niet dat nieuwe code niet beter kan zijn dan bestaande code, maar ik heb wel zo mijn bedenkingen bij het rücksichtloss weggooien van het oude omdat het "onoverzichtelijk" geworden is. Een refactor van bestaande code is bijna altijd een beter idee dan het "from scratch" opnieuw beginnen. Liefst met unit tests om te verifieren dat je nieuwe code geen oude problemen opnieuw introduceert.

Het verhaal van Netscape is in dit verband een goed voorbeeld.

[Reactie gewijzigd door ATS op 17 juni 2014 11:39]

Tja, alleen is de code van truecrypt WEL elegant. Ik hoor dat de kwaliteit van dat stuk software echt erg hoog ligt.. Een interessante uitleg die ik ergens las (helaas geen bron) is dat het een stel ietwat nerderige dudes zijn die nu geen zin meer hebben om hieraan te werken, maar niet willen dat 'hun' meesterwerkt stukgemaakt wordt door 'inferieure' programmeurs.. An sich niet zo'n onwaarschijnlijk idee.

Hoewel ik zelf erg voorzichtig/paranoide ben en een ingebouwde backdoor natuurlijk niet helemaal uit te sluiten valt, heb ik vertrouwen in truecrypt: ik geloof niet dat er (bekende) serieuze vulnerabilities inzitten die tot het stopzetten van de ontwikkeling hebben geleid.
Oh ja, gaan wij nu echt Gibson serieus nemen? Doe mij een lol, zeg.
Gibson voorspelde al eerder de ondergang van het internet, vanwege "Raw Sockets". Het feit dat ik hier kan posten is voldoende bewijs dat die claim bepaald niet uitkwam.
lol dat is inderdaad wel apart ja.. :-)

Maar goed, los van wat hij al eerder gezegd heeft, zijn mening over truecrypt klinkt niet onplausibel. Ik denk dat hij toch in ieder geval gedeeltelijk gelijk heeft, want zelfs een gebackdoorde truecrypt lijkt me geen echte reden om de stekker er uit te trekken. Ze zijn anoniem, en tot nu toe is er geen expert die (serieuze) issues heeft kunnen ontdekken..
Was dat niet rond de tijd van de massale worm-infecties in Windows XP? Toen je een schoon geinstalleerde PC niet direct op het internet kon aansluiten, omdat je dan binnen no-time geinfecteerd was? En was het ook niet zo dat Microsoft een tijdje later stilletjes raw sockets weer heeft uitgezet? Maar dat heeft natuurlijk allemaal niets met elkaar te maken...
Vermoedelijk is de ontwikkelaar een inwoner van de VS.
Daar kan men een brief krijgen van een overheidsinstanties met de melding dat het illegaal om de brief te publiceren of uberhaupt te zeggen dat je zo'n brief gekregen hebt.

Truecrypt werkt prima voor mij: laptop gestolen = dief heeft niks van m'n data
truecrypt werkt prima voor jouw: laptop gestolen = dief heeft niks van m'n data
klopt... tenzij natuurlijk er grote fouten zitten in de applicatie zelf. Dan is je data eigenlijk zo goed als NIET versleuteld en kan nog altijd iedereen redelijk eenvoudig aan je data.

Dus ik begrijp je redenering eigenlijk niet goed... Truecrypt is gestopt voor een reden. En die is (geloof mij) niet "omdat het een zeer goede tool was waar niets mee scheelt qua security". Er kunnen 1001 dingen mis zijn met zo'n implementatie... dus ik raad je aan iets anders te gebruiken.
Er effen van uitgaand dat Truecrypt inderdaad niet veilig is, dan is er nog altijd een hiaat in je redenering.

Op dit moment is er in het publieke domein nog altijd niemand die weet waar die security holes dan wel zitten, laat staan hoe een Truecrypt container dan gemakkelijk kan gekraakt worden. Dus tenzij je laptop gestolen wordt door iemand die hoort tot het selecte clubje rond de Truecrypt devvers, ben je echt wel beter af dat je laptop geëncrypteerd is met Truecrypt dan dat hij helemaal niet geëncrypteerd is.

Het enige risico dat je dus loopt, is dat die dief dan lang genoeg jouw laptop aan de kant legt, tot er een gegeven dag toch bekend wordt wat juist het veiligheidsprobleem met Truecrypt is. Ik denk dat er maar weinig dieven op die manier te werk zullen gaan... en ze je laptop in de eerste plaats stelen voor de hardware.

Ik zie dan zelf ook geen reden om onmiddellijk over te stappen op iets anders. De dag dat Truecrypt écht wel heel eenvoudig te ontcijferen valt, zullen we het echt wel te horen krijgen op Tweakers en elke andere tech site. En het is nu ook weer niet dat in mijn Truecrypt container zaken staan waar de NSA of het groepje rond de Truecrypt devvers iets aan hebben.
(geloof mij)
Dit is voor mij het meest overtuigende argument in elke discussie. "De Kerstman? (Geloof mij) hij bestaat! En hoera, ik heb de discussie gewonnen!" :+

Er kunnen 1001 redenen zijn waarom TrueCrypt gestopt is. Dat hoeft niet te liggen aan de implementatie.
Wat bouwers van dergelijke software moeten inbouwen is support voor externe encyptietools. Op die manier kun je je data middels verschillende encryptie-lagen beveiligen. Als er eentje lek is, dan heb je de overige lagen nog.

Dat kan nu ook wel handmatig natuurlijk, maar dat is niet gebruikersvriendelijk natuurlijk.
Misschien, misschien niet. Dit betekent natuurlijk wel dat Truecrypt makkelijker "verkeerd" te gebruiken is. Op dit moment zijn er al meerdere encryptiealgoritmes (AES, Twofish en Serpent) en meerdere pseudorandom number generators geimplementeerd, dus het is behoorlijk veilig te krijgen. Je kan gewoon een volume aanmaken dat met alledrie de algoritmes sequentieel versleuteld is..
"We zullen het nooit horen" lijkt me wat overdreven. Binnen een paar jaar weten we van de hoed en de rand omdat er iemand uit de school geklapt zal hebben.
Zou mij inderdaad ook nix verbazen als die niet nader te noemen instantie de ontwikkelaars heeft gevraagd of ze misschien een zelfde soort carrière als Julian Assange ambiëren
Opnieuw beginnen is zelden een goed idee. Joël beschreef het zo: http://www.joelonsoftware.com/articles/fog0000000069.html
Zelden, maar niet *nooit* inderdaad. Apple heeft met iOS naar mijn mening aangetoond dat opnieuw beginnen een goed idee kan zijn. Al hebben zij natuurlijk wel een bestaande basis gepakt. Maar ze hebben wel de moed gehad om hun bestaande os af te zinken en een nieuwe koers te kiezen. Een beslissing die ze geen windeieren heeft gelegd.

Het hangt altijd af van de kwaliteit van het materiaal wat dient als basis voor je ontwikkeling. Als de kosten en risico's voor onderhoud groter worden dan voor nieuwbouw, zie ik te vaak dat er vast gehouden wordt aan onderhoud. Het bekende risico heeft dan de voorkeur, ook al is het soms groter.

Ik denk daarom ook dat een audit op TrueCrypt goed is. Dat lijkt erop te duiden dat de nieuwe ontwikkelaars nadenken over deze aspecten.
Het is niet publiekelijk bekend wie het team achter TrueCrypt is. Het kan ook zijn dat het team zelf elkaar kent via internet en alleen op basis van nicks. Als men binnen het team nu 1 van de ontwikkelaars (of mensen die eerder hebben bij gedragen) verdenken van banden met een overheidsinstantie dan kan het natuurlijk zijn dat "men" de code van die bepaalde persoon niet meer 100% vertrouwd. En onderzoek + rewrite neemt natuurlijk een berg tijd inbeslag waar het team van TrueCrypt duidelijk niet overbeschikt.

TrueCrypt is op sommige punten echt verouderd, en heeft op die punten echt veel aandacht nodig om het "kloppend" te krijgen naar de hedendagse technieken.
Het team achter Truecrypt kan ook zo maar een onderdeel zijn van de Mossad of zoiets.
Ja, maar wederom is hier niet duidelijk WAAROM niet?
Staat er nochtans gewoon in:
Vanaf nul beginnen zal niet heel veel meer werk kosten dan het leren kennen en begrijpen van de code
Lezen is een kunst, blijkbaar.

Ik vind het een goed idee: je kunt oude software blijven bijtimmeren en foutjes oplossen, maar vanaf een bepaald moment wordt het gewoon goedkoper om van scratch te beginnen.
Truecrypt is 'nogal' bekend in de it wereld, om dan zo'n project ineens te stoppen roept aardig wat vragen op, dus dan is het niet gek dat we ieder antwoord van anonieme personen als zoete koek naar binnen werken maar er wat kritischer naar kijken...
Ik heb blijkbaar op iemands tenen getrapt? :X
Ik heb het helemaal niet over opnieuw beginnen of een fork maken, ik heb het over het probleem...
Zoals jij vind dat opnieuw beginnen een goed idee is, zo vind ik het een goed idee om eerst uit te zoeken waarom, en vooral of we opnieuw moeten beginnen ipv maar lukraak dingen opnieuw te schrijven...
We kunnen nu niet zeggen of een fork of opnieuw beginnen het juiste is, pas als de audit gedaan is en mensen met verstand van zaken ernaar gekeken hebben...

Overigens is het forken van software 'waar je geen drol van snapt' voor een hoop developers wel gelukt, mensen die er dus wel wat van snappen, als jij niet door andermans code kan lezen en kan begrijpen wat er staat moet jij inderdaad niet forken, maar als dat het geval is, is opnieuw beginnen net zo nutteloos...

PS: Lees voor de grap eens door de artikelen hier die over Snowden/NSA/GHCQ gaan, ik denk dat je ze nog niet hebt gezien als je zegt dat het niet blindelings vertrouwen van een veiligheids product van een wildvreemde aluhoedje gedrag is...
Of moet ik RSA weer aanhalen, die 10 miljoen kreeg om een RNG te gebruiken...

@Hieronder: Doe even rustig zeg, ben blijkbaar echt op je tenen gaan staan, het is niet mijn bedoeling om iemand hier aan te vallen, laten we dat in beide richtingen dan ook niet doen en het netjes houden.

Wat het hele NSA gedoe met Truecrypt heeft te maken? Truecrypt beveiligd dingen, NSA kraakt die dingen graag, dus als Truecrypt stopt omdat de NSA er bovenop zit is dat wel degelijk een grote zorg voor een volgend project, of dat project nou een fork of nieuw begin is, daarom is het belangrijk te weten wat de beste stap is, ipv lukraak te beginnen met programmeren, zeker bij encryptietools...

PS:
software waar je geen drol van snapt
Ik zie dat je je tinfoil erg lekker vind zitten
Als jij je alu hoedje zo graag ziet: ijver maar voor het forken van software waar je geen drol van snapt
Maar wil je FFS even bij de feiten blijven ipv met cryptobeledigingen te gaan smijten?
Mee eens, vandaar de drie quotes erboven, wil wel even duidelijk hebben wie hier aan het smijten is, mijn comments hebben te maken met waarom het belangrijk is om de plotselinge stop van Truecrypt uit te zoeken, tot zover heb jij enkel je punt herhaald...

Het is leuk als iemand zo een beest van een Truecrypt rebuild heeft met alle opties en mooie dingen eraan, maar als Truecrypt door de NSA werd gedwongen een backdoor in te bouwen bijv. dan zal de nieuwe versie alleen maar gevaarlijker worden omdat in dat geval Truecrypts developers er gewoon mee stopten, misschien dat de developers van de nieuwe versie niet stoppen en een backdoor dan ook echt inbouwen, liever weten dan aannemen als het gaat om beveiliging....

Misschien is het een signaal dat je comment gemint wordt door Tweakers, ik kan reacties op mijn post niet minnen dus van mij kreeg je ze niet, maar blijkbaar valt je toon bij meerderen verkeerd, daar kan ik verder niets aan doen.

[Reactie gewijzigd door RGAT op 17 juni 2014 16:12]

ffs
Lees voor de grap eens door de artikelen hier die over Snowden/NSA/GHCQ gaan, ik denk dat je ze nog niet hebt gezien als je zegt dat het niet blindelings vertrouwen van een veiligheids product van een wildvreemde aluhoedje gedrag is...
Of moet ik RSA weer aanhalen, die 10 miljoen kreeg om een RNG te gebruiken...
Wat heeft dit hier in godsnaam mee te maken? Geen drol. Ik heb het hier namelijk over dit artikel, en wat hierin gezegd wordt. Jij bent er blijkbaar van overtuigd dat iedereen die jouw paniekvoetbal niet volgt een achterlijk idioot is of zo? Natuurlijk heb ik alles wat jij in het wildeweg (irrelevant voor dit artikel btw) neertikte gelezen.

Maar wil je FFS even bij de feiten blijven ipv met cryptobeledigingen te gaan smijten?

Feit: TrueCrypt is waarschijnlijk lek. We weten niet wie of waarom dit de wereld heeft/is ingestuurd, maar de kans is niet gering. En ook al typ je nog zo hard 'WAAROM???', die informatie hebben we niet en we hebben geen naam/adres waar we meer informatie kunnen vragen

Feit: we weten niet wie de originele devs van Truecrypt zijn

Feit: een rewrite is netter dan een fork van onbekende code, wat jij ook beweert.

Conclusie: willen we vooruit, dan is een rewrite, op dit moment, de beste optie. Of je de bron van dit bericht nu vertrouwt of niet, gebaseerd op de feiten is dat gewoon zo, ookal had deze anonieme dev dat neit gezegd.

Maar goed. Dat ik van deze feiten uitga en nadenk over wat de beste aanpak is, ipv een pitchfork op te nemen en WAAROM ga typen in allcaps, dat maakt mij blijkbaar een ongeinformeerd schaap.

[Reactie gewijzigd door kiang op 17 juni 2014 14:07]

Je meningen als feit deponeren maken ze natuurlijk nog niet waar. Het geeft hooguit aan dat je bevooroordeeld bent. Dat is je goed recht, maar je mag ook best accepteren dat er mensen zijn die er anders over denken.

De bootloader van TrueCrypt is niet geweldig, maar dat maakt TrueCrypt nog niet lek. Het maakt alleen van TrueCrypt een niet toekomstbestendig pakket voor computers met EFI die graag full disk encryption willen gebruiken.

Het feit dat iemand een ontwikkelaar van TrueCrypt benaderd, betekent dat er dus in elk geval een persoon een originele ontwikkelaar kent. Via die persoon zijn ook anderen te benaderen binnen de groep. We hoeven de originele ontwikkelaars dus niet persoonlijk te kennen.

Een rewrite van code kan netter zijn, maar dat hoeft niet. Als er delen goed zijn, zou je dom zijn om die opnieuw te bouwen. Want mensenwerk, mensen maken fouten, nieuwbouw is nieuwe fouten. Dan kan je beter bestaande bewezen code hergebruiken of omwerken.

Dus laten we nu eerst eens de review afwachten voordat we de pitchforken uit het vet gaan trekken of geheime boodschappen zoeken in berichten.
Je meningen als feit deponeren maken ze natuurlijk nog niet waar.
Toon me 1 mening die ik als feit aanneem. De 3 feiten die ik aanneem om mijn conclusie te trekken zijn onmogelijk een mening te noemen.
Ik heb over al jouw 3 *vermeende* feiten een andere mening. In de praktijk is zelden iets zwart of wit, er is bijna altijd een nuance. Dat jij je absoluut zwart-wit meningen als *feit* deponeert, maakt ze al ongeloofwaardig.

Om bijvoorbeeld op je laatste *mening* terug te komen. Een fork maakt een rewrite niet onmogelijk, het maakt het alleen mogelijk om de oude goede delen te hergebruiken en de slechte delen aan te passen of zelfs weg te gooien.

Ik heb begrepen dat grote delen van de code van TrueCrypt van een uitstekende kwaliteit zijn. Dat je die om een vermeend *feit* wil weggooien, zogenaamd omdat een rewrite beter is, vind ik onverstandig. Er is een grote kans dat je nieuwe fouten introduceert, die in de bestaande code al eens plat geslagen zijn.

Kortom, er is een nuance. Iets waar jij kennelijk niet aan wil.
Je zoomt weer in op 1 iets en doet alsof ik een verborgen agenda heb of zo. Dat is neit zo. Zet even je alu af en kijk naar de combinatie van de FEITEN:

1) we weten nog altijd niet wat er mis is met truecrypt

2) we weten neit wie de devs zijn

--> dit zijn echt wel feiten. Jij kunt blijven schreeuwen dat er nuance in zit, maar als dat zo is: contacteer jij dan eens de truecrypt dev die de waarschuwing op GIT plaatste om te vragenw at er mis mee is?

Zolang je dat niet kunt, is er geen nuance: we weten NIET wat er aan te passen valt. Dan kun je nog een audit doen van de code, zelfs als je wat vind is er geen mogelijkheid te weten of dat nu de bug/flaw was waarvoor er een aarschuwing uitging.

En dat brengt ons dus weer bij feit drie: fork of rewrite? In combinatie met de eerste twee feiten betekent dit absoluut dat een rewrite hier productiever zal zijn dan een fork.


Nuanceer zoveel je wilt, als het gaat over veiligheid wil je net met zekerheden werken. Want wat zijn de opties?

Een rewrite: lijkt meer werk, maar bij elke stap is er zekerheid.

Een fork: lijkt minder werk, maar er zal NOOIT zekerheid zijn dat de exploit eruit is, tenzij je natuurlijk zoveel herschrijft dat je eigenlijk evengoed van scratch had kunnen beginnen.

In veiligheid werk je om de onbekenden te elimineren, iets wat jij blijkbaar wilt nuanceren, maar dat is extreem dom :+

[Reactie gewijzigd door kiang op 18 juni 2014 08:47]

Ik heb (een feit) geen alu hoedje op en (een feit) ik heb nergens geschreeuwd.

Je eerste feit is (een feit) een totaal ander feit dan het "feit" dat je eerst deponeerde.
Feit: TrueCrypt is waarschijnlijk lek.
is geworden
we weten nog altijd niet wat er mis is met truecrypt
Had je de laatste direct gedeponeerd, dan hadden we een totaal ander discussie gehad, want de laatste is een feit, de eerste duidelijk een mening.

Je doet net alsof een rewrite veiligheid brengt, wat in de praktijk (een feit) niet waar is, want ook nieuwe software bevat bugs.

Er zitten unfixed errors in de bootloader (een feit). Er is nog niets (een feit) dat er op wijst dat er een exploit is of gaat komen.

Maar goed, ik heb niet de indruk dat we ergens komen, dus laten we het maar eens zijn dat we het oneens zijn. Jij houdt het maar lekker bij jouw "feiten".

[Reactie gewijzigd door 125509 op 18 juni 2014 09:05]

Ik hoop dat je die zelf wel snapt, want je scheld mij iets te cryptisch.
Misschien een gag order van de NSA?
Brief van NSA: Wij willen een backdoor, als je iets over deze brief zegt ben je strafbaar. als je niet meewerkt ben je strafbaar.
TrueCrypt mensen: F-it, dan kappen we met een suffe reden en hopen dat mensen raden dat het om een gag order ging.

[Reactie gewijzigd door teek2 op 17 juni 2014 16:39]

Dan nog, het zal vast niet zo zijn dat alle truecrypt ontwikkelaars in de VS woonachtig zijn, zon gag order is alleen relevant zodra je fysiek aanwezig bent in de VS.
Enorm slecht idee natuurlijk. De huidige broncode zit best netjes in elkaar en overnieuw beginnen is vrijwel altijd een slechte zaak aangezien je geheid belangrijke zaken over het hoofd ziet of bugs introduceert die in de oorspronkelijke code al lang en breed zijn opgelost.

Het opnieuw schrijf gaat zeker wel enorm veel tijd in beslag nemen, daar is geen twijfel over. Alleen al omdat de huidige fork per direct compileerbaar is en gewoon werkt.

Maar zijn argumentatie hier is ook weer enorm slecht, dus ik vermoed dat dit in relatie staat met de dubieuze gang van zaken omtrent het abrupte beëindigen van het project.
Zijn argumentatie is dat het herschrijven van grondsafaan meer werk kost dan inlezen, begrijpen en verder gaan. En dat begrijp ik best. Jouw argument is: "Dit compileerd al, dus van hieruit verder gaan is makkelijker" en dat vind ik een bijzonder slecht argument. Dat code compileerd zegt niets over leesbaarheid, begrijpbaarheid, kwaliteit van onderliggende ideen of kwaliteit van architectuur (architectuur alsin softwarearchitectuur). Dit zou on-onderhoudbare, onbegrijpbare code kunnen zijn die toevallig wel compileerd. Wat je na een fork als eerst wil doen is inlezen en eventueel opruimen. Als alleen al het inlezen maanden kost omdat het vreselijk onduidelijke code is en je daarna moet concluderen dat de onderliggende architectuur zo slecht is dat een nieuwe feature toevoegen een regelrechte hel is, wat dan? Dan wou je dat je van grondsafaan opnieuw begonnen was. Ik denk dat de maker van Truecrypt het idee heeft dat de code zoals hij nu is zo in en in rot is dat opnieuw beginnen gewoon makkelijker is. En omdat hij zelf alle code geschreven heeft en daarop nu dus reflecteerd zou ik hem het voordeel van de twijfel willen geven.
Er was al tijden geen nieuwe versie uitgekomen, de laatste dateert van begin 2012 als ik me goed herinner. Daarbij reken ik de recent uitgebrachte manke versie niet mee natuurlijk. Het is een populair stuk software, wordt veel gebruikt en daardoor ook veel getracht te kraken. Toch zijn er geen lekken aan het licht gekomen die een bugfix release vereisen. Dat zegt toch wel iets over de kwaliteit van de code lijkt me, dat kunnen weinig andere libraries zeggen.

Natuurlijk is het jammer dat er geen nieuwe versies uitgekomen zijn met nieuwe features, zoals de EFI bootloader bijvoorbeeld. Maar dat doet niet af aan de kwaliteit van de code.

En ik denk dat de deze bron, als het überhaupt al echt een ontwikkelaar van Truecrypt is, ofwel flink gedeprimeerd is geraakt door het ontwikkelen van Truecrypt zoals al eerder gespeculeerd is en er dus zo graag mogelijk vanaf wil zijn, ofwel flink onder druk gezet wordt door instanties als de NSA die niet zo blij waren met de tot nu toe ongekraakte encryptie van Truecrypt. Daarom hecht ik niet zo veel waarde aan deze korte, onbeargumenteerde uitspraak.

Mocht er, in aanvulling op deze korte uitlating een gedetailleerd overzicht komen van deze man/vrouw waarin uitgelegd wordt waarom de code dan zo in en in slecht is dat er niet verder mee te werken is dan zal ik mijn mening over deze kwestie nog eens heroverwegen, maar er zit een naar luchtje aan de huidige gang van zaken.

[Reactie gewijzigd door MadEgg op 17 juni 2014 12:22]

ik denk eerder dat ze gestopt zijn omdat er een "fundamenteel" probleem opgedoken is in de code... Dus op zich wel goed geschreven, maar als het "design" opeens "verkeerd" blijkt, dan kan je je code gewoon niet meer aanpassen tenzij je... opnieuw begint. En kijk... dit is nu net wat ze voorstellen om te doen!
Ik kan mij geen enkele situatie indenken (met in het achterhoofd de blikken die ik op de TrueCrypt code geworpen heb) waarbij het design zo fundamenteel verkeerd is dat opnieuw beginnen sneller en doeltreffender is dan refactoren.

Design, architectuur, fundering, bibliotheken, in software kun je alles aanpassen achteraf. Het een kost meer werk dan het ander, maar elk van deze dingen is sneller te refactoren dan te herschrijven. Wederom met uitzondering van de triviale zaken als "Hello, World!", maar ook

#include <stdio.h>
printf("Hello, World!");

vervangen voor

#include <iostream>
std::cout << "Hello, World!";

is nog wel als refactoren te beschouwen. Ik heb er "Hello, World!" in ieder geval geen twee keer voor getypt.
Aangenomen wordt, is dat een van de fundamentele problemen vooral technologische vooruitgang is.

TrueCrypt kan zoals al opgemerkt niet omgaan met EFI bootloader, en de kennis om TrueCrypt hierop aan te passen is er kennelijk niet meer binnen het ontwikkelteam.

Dus niet zozeer een design probleem, maar meer een kennis probleem.

De bootloader code zou ik dan ook helemaal opnieuw ontwerpen, maar dat hoeft met andere onderdelen waarschijnlijk niet.
Ik vraag me af hoe ze, mocht je gelijk hebben dat de code in en in rot is, nog testen of dit programma lekken bevat? Vaak gaat onleesbare en moeilijke code gepaard met lekken...
Het vermoeden dat er op de achtergrond krachten aan het werk zijn die van truecrypt af willen wordt met dit bericht versterkt.
Het vermoeden dat er op de achtergrond krachten aan het werk zijn die van truecrypt af willen wordt met dit bericht versterkt.
Dat gevoel heb ik ook. Wantrouwend als ik ben zie ik dit als een mogelijke poging om TC en de makers in een kwaad daglicht te stellen. Tevens heb ik nog geen betere encrypter en dus laat ik het voorlopig zo. Hooguit met wat gecombineerde en of sterkere opties dan nu.

Het blijft een raar zaakje.
Als er basale fouten/zwakheden in de code zitten dan kan het slimmer zijn om opnieuw te beginnen en hooguit de bestaande broncode te gebruiken als een soort richtlijn, juist om geen dingen over het hoofd te zien. Zo begin je opnieuw, maar toch niet helemaal opnieuw.

Verder kan ik me goed voorstellen dat je ook juist bij het forken dingen over het hoofd ziet omdat je de code niet zo goed kent als de oorspronkelijke makers. Dus jouw argument gaat eigenlijk ook op bij de fork, maar dan net op een wat andere manier.
Uit eerdere berichtgeving blijkt dat de code helemaal niet zo goed in elkaar zit. (geen tijd om bron te zoeken dus lezers van deze reactie moeten zelf aan de slag)
Alleen zit je vandaag met het probleem dat niemand uitspraken durft doen over de legaliteit van een fork. Je mag de broncode van TC bekijken, dat betekend nog niet dat je een eigen aangepaste versie mag verspreiden.
Deze man is een held, omdat hij kan wat andere leiders niet kunnen. En dat is verlies erkennen.

En anderzijds is het een held omdat hij in een wereld waarin overheden en bedrijven steeds meer van je willen weten. Vasthoud aan een norm waarin alleen dat wat echt gesloten is goed genoeg is.
nou, erkent verlies... Hij haalt zijn software van de site en zegt dat je het beter niet kan gebruiken., maar waarom weet niemand.

Net alsof je halverwege de voetbalwedstrijd (om het actueel te houden) stopt met voetballen maar dat niemand de stand weet. Dus je weet niet of de partij heeft verloren of dat de partij heeft gewonnen.
Je beseft je hopelijk dat de enige logische verklaring is dat hij hiertoe gedwongen is?

Waarschijnlijk omdat hij, bijv. onder het mom van de patriot act, verplicht wordt een backdoor in te bouwen en zijn enige manier om dit te voorkomen is om te stoppen met ontwikkeling, en het hem verboden is hier ook maar iets over te zeggen.
Wat een belachelijke onzin. Software om je harde schijf te encrypten is geen enkel probleem voor kwaadwillende veiligheidsdiensten. Veiligheidsdiensten stelen je data als het beweegt - bij je ISP, bij clouddiensten, bij de router die ze gehackt hebben. Als ze data op je computer willen, dan stelen ze die wel terwijl je je computer thuis gebruikt. Dan heb je 1. je data voldoende ontsleuteld en 2. er waarschijnlijk niks van in de gaten.

Je harde schijf encrypten beschermt je gevoelige data bij diefstal en bij anderzinse inbeslagname. Het is een goed iets om te doen, maar het kan die mensen waar jij allemaal samenzweringen bij bedenkt aan hun reet roesten of je je harde schijf hebt versleuteld of niet.

Mensen die zo reageren doen me altijd denken aan deze XKCD.

[Reactie gewijzigd door DCK op 17 juni 2014 11:42]

Je gaat er nu van uit dat de data word geraadpleegd op een machine die überhaupt online hangt.
Je gaat er nu van uit dat de data word geraadpleegd op een machine die überhaupt online hangt.
Niet per se. Robert Mickelsons, de Letse kindermisbruiker, had zogezegd de wachtwoorden opgebiecht. Wie zegt dat zijn TrueCrypt-versleutelingen niet gewoon een backdoor hadden ? Kan hij tegenspreken dat hij zijn wachtwoorden gegeven zou hebben ?
Niet per se. Robert Mickelsons, de Letse kindermisbruiker, had zogezegd de wachtwoorden opgebiecht. Wie zegt dat zijn TrueCrypt-versleutelingen niet gewoon een backdoor hadden ? Kan hij tegenspreken dat hij zijn wachtwoorden gegeven zou hebben ?
haha, Zo gek klinkt dit nog niet eens als je bedenkt dat DEA hetzelfde deed via parallel construction, Waarin de DEA eerst via de NSA opzoek ging naar bewijs om daarna dit bewijs te recreëren op een legale manier, Aangezien data van de NSA illegaler is als het strafbare feit zei proberen te bewijzen. Ik kan mij zo voorstellen als de geheime diensten echt een backdoor hebben gevonden of gemaakt in belangrijke encryptie software, dat de overheid graag een wet zou willen hebben die mensen verplicht om het wachtwoord van de gencrypte data weg te geven. Omdat alleen dan deze special units een paralelle constructie kunnen opzetten :) Pure speculatie, Maar niet ondenkbaar.

[Reactie gewijzigd door kajdijkstra op 17 juni 2014 13:23]

Dat klopt. De inlichtingendiensten zijn vrijwel exclusief geinteresseerd in communicatie. Alleen als ze je gericht willen pakken gaan ze andere dingen doen, en als jij de inlichtingendiensten achter je aan hebt dan is je harde schijf encrypten geen noemenswaardige bescherming met het budget, de skills en de aanvalsmethoden die een inlichtingendienst tot zijn beschikking heeft.

Nieuwsgierige partijen als politie, criminele organisaties, en journalisten zijn eerder geinteresseerd in stilstaande data. Dat is waar mensen hun harde schijf voor encrypten. Ik hoop dat niemand zijn harde schijf versleutelt met de illusie om inlichtingendiensten weg te houden.
haha, grappige XKCD, nog nooit gezien
Of andersom, hij heeft een flinke som geld gekregen en een backdoor ingebouwd, en heeft daar nu spijt van. Je weet niet of de ontwikkelaar hier een winnaar of een verliezer is.
Wat je zegt is behoorlijk onwaarschijnlijk, omdat TrueCrypt uitgebreid bestudeerd wordt op dit moment en er (tot nu) niks meer is geconstateerd dan wat slordigheidjes.
Maar terug naar mijn eerste reactie, je weet nog steeds niet of het een held is omdat hij zijn verlies erkent...

Je zegt net zelf, er zitten wat slordigheden in. Nou dan is er geen fout om te erkennen.

Dus de vraag blijft waarom :)

of dat A. omdat hij gedwongen werd om een backdoor te bouwen B. hij heeft al een backdoor gebouwd maar baalt er van c. hij kijkt liever voetbal...

Weet je dus niet.

[Reactie gewijzigd door Buzzel op 17 juni 2014 11:45]

A en B zijn erg onwaarschijnlijk. Voor A geldt dat de TrueCrypt-ontwikkelaars hun roots in Oost-Europa lijken te hebben, waar de veiligheidsdiensten slechts de ambities van de despotie van de NSA hebben maar zeer waarschijnlijk niet de daadkracht om er iets mee te doen, of de motivatie ervoor (zie mijn andere reply). Ten tweede is het helemaal niet duidelijk wie deze ontwikkelaars écht zijn en of de geheime diensten aldaar dat echt weten. Voor B geldt wederom dat de audit zoiets niet aantoont.

C is erg waarschijnlijk, omdat er al jaren weinig TrueCrypt-releases waren . Zo waren ze er bijvoorbeeld in 2014 nog niet er in geslaagd waren om Windows 8 te ondersteunen. Men doet alsof ze zo "plotseling" verdwenen, maar het was voor iedereen die het ook maar een beetje volgde al lang duidelijk dat de ontwikkelaars niet meer zo gemotiveerd waren.

[Reactie gewijzigd door DCK op 17 juni 2014 12:51]

Oke, C was een grapje.

als de developer niet zo gemotiveerd meer is, waarom vragen ze dan niet of iemand anders er verder mee wil werken? Of zeggen ze; "We hebben er geen zin meer in. Dit is de final release veel plezier er mee"

maarja, ik blijf truecrypt lekker gebruiken om 1 mapje van 50kb te versleutelen.
Omdat dat niet kan. TrueCrypt is niet open source, maar eerder shared source. De licentie van de code zit zo in elkaar dat het afhankelijk van de interpretatie niet mogelijk is om de code aan te passen.

Hoewel jij scenario C een grapje vindt, en ze misschien helemaal niet van voetbal houden, lijkt het er toch echt wel behoorlijk op dat ze simpelweg de motivatie kwijt zijn. Dat is misschien een saai scenario vergeleken met al die samenzweringstheorien, maar het is wel het enige waar er aanwijzingen voor zijn.
Hoezo zou dat niet kunnen? Zelfs als de huidige licentie het niet toe zou laten, kan de auteur, die gewoon full copyright op zijn eigen code heeft, het alsnog onder een andere licentie uitbrengen. Dus dan zouden ze best de boel kunnen relicensen onder de BSD-license en zeggen: "Dag, succes ermee". Geen vuiltje aan de lucht.
Omdat dat niet kan. TrueCrypt is niet open source, maar eerder shared source. De licentie van de code zit zo in elkaar dat het afhankelijk van de interpretatie niet mogelijk is om de code aan te passen.
Inderdaad, en daar ging de vraag van Matthew Green juist over. Of de devs het nu goed zouden vinden als de code geforkt gaat worden onder een echte open source licentie (zij kunnen de licentie immers veranderen). En zoals hij ook zegt: Als ze het niet toestaan komt er toch wel een 'illegale' fork en daar heeft niemand baat bij.

Wat ik nogal vreemd vind is dat de ontwikkelaar daar totaal niet op ingaat. Hij zegt alleen dat het hem een slecht idee lijkt om technische redenen, dus nu is er nog steeds geen duidelijkheid over zo'n fork.

[Reactie gewijzigd door GekkePrutser op 17 juni 2014 18:43]

Dat is dan ook precies wat ze gezegd hebben en omdat ze er niet meer aan werken worden bugs of exploits niet gefixed en als die niet langer gefixed worden is het product niet langer betrouwbaar.

Maar ja, een leuke conspiracy bouwen is veel lekkerder, natuurlijk :D
Of de ontwikkelaars hadden er gewoon geen zin meer in. Wat ook heel logisch zou kunnen zijn omdat het project al en hele tijd stil lag.
Je weet toch: Never let the facts get in the way of a good story?
waarom weet niemand.
Omdat ze niet meer de tijd en energie hebben om het te onwikkelen. Omdat als je de software gebruikt jezelf valse veiligheid geeft vanwege alle mogelijke onbekende veiligheidslekken die erin zitten.

Dit hele mysterie wordt alleen herhaald door mensen die graag samenzweringen zien. Het hele verhaal rondom TrueCrypt is lang niet zo raar als mensen claimen.

[Reactie gewijzigd door DCK op 17 juni 2014 12:53]

Net alsof je halverwege de voetbalwedstrijd (om het actueel te houden) stopt met voetballen maar dat niemand de stand weet.
Niet dat je de stand niet weet, maar de spelers stoppen en verlaten het veld zonder duidelijk herkenbare redenen en geven die ook niet.
Een anonieme ontwikkelaar. Wie zegt dat deze man echt is wie hij is?
Je vergeet uit te leggen wat je met die vraag wil bereiken.
Waakzaamheid.
Matthew Green en deze man wisselen hun emails uit ondertekend met GPG.
Maar dat zegt nog niets over of de man met wie Matthew Green contact heeft ook daadwerkelijk één van de ontwikkelaars is van TrueCrypt. Niemand weet écht wie erachter zit. Met andere woorden: iedereen kan claimen dat hij/zij betrokken is bij TrueCrypt. Maar niemand (aanname) weet het echt...

Het is één groot schimmig verhaal rond dat TrueCrypt... :/
Het is mogelijk om te zien dat dit de developer is door hem te vragen iets te ondertekenen met dezelfde GPG-sleutel als waar de releases van TrueCrypt worden ondertekend. Dat zou aantonen dat degene waarmee gemaild wordt ook de TrueCrypt-releases publiceert (of in ieder geval die sleutels bezit). Ik meen ooit gelezen te hebben dat dat gebeurd is (zo slim is Matt Green zeker wel), maar ik kan even de bron niet meer vinden.

Heel vaak herhalen dat het één groot schimmig verhaal is maakt het niet een groot schimmig verhaal. Hou daar mee op en blijf bij de feiten. Het is best duidelijk wat er allemaal gebeurd is.
...blijf bij de feiten...
Want? Wat zijn de feiten dan? Heb je de wijsheid in pacht in dezen, en ken jij deze "feiten" wel? Ik doe aannames, dat klopt. Maar dat doe jij net zo goed. Tenzij jij insider en/of onderdeel van het verhaal bent.
Het is best duidelijk wat er allemaal gebeurd is.
O ja? Vertel het ons, de onwetenden eens precies wat er aan de hand is. Met zulke overtuigingen begeef je je wèl op glad ijs, want wat weet jij dan meer? 8)7
Net als met een huis verbouwen. Soms is het sneller om de boel volledig plat te gooien en dan met een goede basis (fundering) die op maat is, lekker verder knutselen.
Broncode roest niet, in tegenstelling tot de fundering van een huis die kan slijten, verzakken of aangetast worden door andere (al dan niet natuurlijke) verschijnselen.
Broncode roest misschien niet in de zin die jij bedoelt maar broncode word constant aan geknutseld en er is een kans dat de structuur in de code hierdoor verslechterd of zelfs verloren gaat. Bij deel I van de audit werd het volgende geconcludeerd:
Overall, the source code for both the bootloader and the Windows kernel driver did not meet expected standards for secure code. This includes issues such as lack of comments, use of insecure or deprecated functions, inconsistent variable types, and so forth. A more indepth discussion on the quality issues identified can be found in Appendix B. In contrast to the TrueCrypt source code, the online documentation available at
http://www.truecrypt.org/docs/ does a very good job at both describing TrueCrypt functionality and educating users on how to use TrueCrypt correctly. This includes recommendations to enable full disk encryption that protects the system disk, to help guard against swap, paging, and hibernation based data leaks.
Bron: Open Crypto Audit Project TrueCrypt

Dit verteld mij dus dat de broncode veel beter kan. En dat bedoeld de veronderstelde ontwikkelaar waarschijnlijk ook. Het is beter om van scratch te beginnen, met de secure coding kwaliteit als fundering, en de TrueCrypt sourcecode wel als referentie te houden.

Daarnaast werden er oude compilers en technieken gebruikt. Het gaat super veel werk kosten om zonder van scratch te beginnen de huidige codebase om te zetten naar nieuwe modernere compilers.

[Reactie gewijzigd door Rutix op 17 juni 2014 11:18]

De broncode kan ongetwijfeld beter. Dat kan vrijwel altijd.

Wat je wel hebt is software die werkt en aan een uitgebreide audit onderworpen is zodat je weet welke delen goed zijn en welke delen aandacht verdienen. Dit is ontzettend waardevolle informatie en het zou zonde zijn om die niet te gebruiken.

De bootloader refactoren is aanzienlijk minder werk dan het gheel opnieuw schrijven. En zelfs een rewrite van de bootloader is niet herschrijven van Truecrypt, maar gewoon refactoren van de bestaande Truecrypt.
Ben je een ontwikkelaar of werk je in die hoek?
Wat je impliciteerd is dat omdat het nu compiled dat het goed is en dat het ook goed werkbaar is voor refactoren, dat is natuurlijk niet waar. Het is leuk in theorie maar in de praktijk moeilijk haalbaar. Even gewoon refactoren is nooit gewoon en altijd moeilijk en al helemaal met een oude code base met oude compilers, oude technieken ect.

Er word ook niet gezegd dat de TrueCrypt source niet mag worden gebruikt, integendeel de ontwikkelaar zegt expliciet dat hij er geen moeite mee heeft als de code als referentie gebruiken.
Ja, ik ben een ontwikkelaar. Ik gooi nooit code weg. Als bij voortschrijdend inzicht blijkt dat de initieel gekozen aanpak slechts was of niet past bij de plannen voor de toekomst refactor ik de boel. Soms één functie, soms een klasse, soms een library. In bepaalde gevallen komt het er soms van om een stuk software te porten van een taal naar een andere taal die sneller is of betere tools heeft voor de gewenste functionaliteit. Ook dat is geen 'volledig herschrijven', hierbij wordt nog steeds de oorspronkelijke code gebruikt met alle haken en ogen die daarin voorzien en geanticipeerd zijn.

Ook met een oude code base kun je refactoren. Ook dit heb ik al een aantal keer meegemaakt waarbij ik bestaande code als uitgangspunt krijg welke zwaar verouderd is (door bijvoorbeeld gebruik te maken van oude versies van bibliotheken). Hierbij is een van de eerste stappen die ik neem een recente versie van de gebruikte bibliotheken installeren en de code stap voor stap doorlopen om hier gebruik van te maken.
Generics toepassen in oude Java code die nog gebruik maakt van onveilige raw containers of netjes gebruik maken van iterators doe ik vaak, aangeleverde C++ code porteer ik vaak naar C++11 om gebruik te maken.

Het kost zeker allemaal tijd maar het resultaat is een veel functioneler, stabieler en beter geheel dan als je from scratch begonnnen was.

Code anders dan een simpele "Hello World" en dingen in die trant weggooien is eeuwig zonde.
Maar ze hebben het hier totaal niet over het weggooien van de code. De oude code mag gewoon als referentie gebruikt worden.

Ik vind echter dat roepen dat het een rewrite een slecht idee is heel erg voorbarig. Deze ontwikkelaar kent de codebase als de beste en hij vind blijkbaar dat je er net zoveel tijd (misschien wel meer) tijd in zou moeten stoppen om de oude sourcecode goed te leren kennen dan als je fris opnieuw zou starten met de oude code als referentie en met goede uitgangspunten, goede coding standards ect.

Ik moet eerlijk zeggen dat ik zelf de codebase niet ken dus ik kan daarover geen uitspraak doen. Ik heb echter zelf veel ervaring met grote codebases met oude code en waar de beslissing om van scratch te beginnen een erg goede keus was. In the end is het echt een afweging die gemaakt worden op punten zoals: complexiteit, tijd, hoeveelheid werk, ect.
Ja, maar wat je op je oude fundering wilt bouwen, kan een totaal ander ontwerp zijn en dan past het niet.

Ik heb in mijn carrière al zoveel software gebouwd en aangepast en soms zijn de wijzigingen zo groot dat je alsnog hele stukken ombouwt. Broncode roest niet, maar de techniek wordt wel steeds beter. Nieuwe algoritmes, nieuwere frameworks, libraries etc.
De vergelijking met fundering gaat gewoon mank. Software heeft wel iets wat je als fundering kan beschouwen, maar deze is niet in beton gegoten, onveranderbaar. Ook de fundering kun je refactoren.
Ik heb in mijn carrière al zoveel software gebouwd en aangepast en soms zijn de wijzigingen zo groot dat je alsnog hele stukken ombouwt.
Ombouwen is refactoren, niet herschrijven. Je blijft gebruik maken van de bestaande API waar relevant terwijl je dingen die beter kunnen vervangt door betere API's, algoritmen of design patterns.
Anyway, het wil nog steeds niet zeggen dat opnieuw beginnen soms beter en sneller is dan ombouwen. Soms wel, soms niet. en dat zeg ik dus ook. Als je opnieuw beginnen altijd afwijst, heb je geen objectieve, open kijk op problemen/uitdagingen.

Absolutisme is voor religie, niet voor de flexibele geest.

[Reactie gewijzigd door LarBor op 17 juni 2014 12:05]

Ik wijs het niet altijd af, maar er moeten wel hele goede argumenten voor zijn om het recht te praten. Het is wat mij betreft echt een last resort if all else fails, en dat idee heb ik nu absoluut niet bij TrueCrypt.

Ik verzet me juist een beetje tegen de klaarblijkelijk heersende tendens dat "rerwite from scratch" een soort holy grail is voor alle problemen en per definitie betere code oplevert. De geschrokken reacties als er blijkt dat een bug die Windows 8 treft terug is de leiden naar een stuk code wat ook al in Windows 95 zat verbaas ik mij ook altijd over. If it ain't broken, don't fix it, en blijkbaar heeft dat stuk code het tot recent volgehouden zonder zichtbaar stuk te zijn. Jammer van de bug natuurlijk, maar ik vind het absoluut niet vreemd dat er nog code van Windows 95 in Windows 8 zit. Code bevat altijd bugs en dat is zeker niet per definitie gerelateerd aan hoe lang geleden het geschreven is.
Anyway, het wil nog steeds niet zeggen dat opnieuw beginnen soms beter en sneller is dan ombouwen.
Sneller al helemaal niet en wat doen we in die tussentijd met onze data. En hoe snel geven we de nieiuwe variant ons vertrouwen ?
De fundering roest ook niet. Indien gemaakt uit beton zou er wel betonrot kunnen optreden :+

Maar alle gekheid op een stokje. Eeuwig doordoen met oude code is ook geen goed idee. Kijken we bijvoorbeeld naar enkele bekende open source voorbeelden zoals een X11 dat al +20 jaar verder bouwt op dezelfde codebase of een OpenSSL dat hetzelfde doet. Bijkomend proberen deze pakketten volledig backwards compatible te zijn waardoor er zoveel oude meuk in verzeild geraakt dat niemand er aan uit kan geraken met als gevolg dat audits moeilijker worden en dat het onderhoud bijna onmogelijk word.

Of nog een mooie. Enkele jaren terug werd er in Windows een bug terug gevonden die kon misbruikt worden. Alle versies van Windows 3.1 tot en met 7 waren kwetsbaar.

Ik ben een voorstander van het hergebruik van code waar mogelijk. Maar soms moet je echt eens opnieuw durven beginnen.
Backwards compatibility is een compleet andere kwestie. Dat kan op een gegeven moment wel kwalijk worden ja.

Maar waarom zou je dan from scratch beginnen? Je kunt ook refactoren en daarbij gewoon backwards compatibility overboord gooien.

X11 is niet een goed voorbeeld. X.org doet nog steeds perfect wat het moet doen en waarvoor het gebouwd is. De realiteit is wél dat het toepassingsgebied en de gewenste functionaliteit van een display manager grondig veranderd is waarbij het client/server model ondergeschikt is geworden en het tekenen van allerlei primitives ook, waarbij alles tegenwoordig steeds meer door een compositer gedaan wordt. Dat betekent een grondige breuk met dat waar X11 voor gebouwd / ontworpen is.

Toch worden er bij dingen als Wayland niet from scratch begonnen, maar waar mogelijk worden relevante stukken code van X.org hergebruikt. Naast dat dit een hoop scheelt zorgt dit ook voor een eenvoudigere transitie en betere compatibiliteit met drivers. Wayland zou je kunnen zien als een niet-backwards-compatibile refactorization van X.org

Ik ben gruwelijk bij dat Linus Torvalds in ieder geval niet zo denkt, het zou toch wat zijn als ze om de paar jaar de kernel from scratch zouden gaan schrijven. Nee, daar wordt een hele hoop gerefactort, stukken oude code verwijderd, herschreven en gemoderniseerd maar godzijdank mieteren ze niet de hele boel weg om opnieuw te beginnen.
And The Builder said, 'If the foundation is weak, do you wail and gnash your teeth? Do you ask it to repour itself? Nay, you tear it down and begin anew. So shall it be with all My Children, whether they be Stone or Flesh.' }>
Volgens een aantal activisten zit de waarheid in de volgende (nogal vreemde) zin op de homepage:

Using TrueCrypt is not secure as it may contain unfixed security issues

Met een doodsimpele cypher:

Using TrueCrypt is not secure as it may contain unfixed security issues

Kortom: Utinsaimcusi

Met spaties: Uti nsa im cu si

Vrij vertaald uit het Latijn: If I wish to use the NSA

Kan natuurlijk een uit de hand gelopen aluhoedje theorie zijn, maar dat meerdere mensen onafhankelijk van elkaar hier op zijn gekomen zegt toch wel iets IMO...
Kan natuurlijk een uit de hand gelopen aluhoedje theorie zijn
Lijkt mij wel.
maar dat meerdere mensen onafhankelijk van elkaar hier op zijn gekomen zegt toch wel iets IMO...
Het zegt dat er meerdere mensen met ongeveer dezelfde verbeeldingskracht naar hebben gekeken.

Bij 9/11 zijn ook, onafhankelijk van elkaar, mensen tot dezelfde conclusies gekomen, die dan weer haaks stonden op conclusies die door anderen onafhankelijk van elkaar waren bedacht.
Hmm, dat idee had ik wel bij de "not secure as" als NSA, maar blijkbaar vormt de hele zin een zin in het Latijn, dat vind ik toch wel tegen het geloofwaardige aankomen, dit zou wel extreem toevallig zijn als het per ongeluk zo gekomen was, zeker omdat de eerste letters van de woorden gebruik niet heel vergezocht is.
Waarschijnlijk heeft de eerste bevinding, van "not secure as", mensen ertoe gestimuleerd om net zo lang te zoeken tot ze tot deze conclusie konden komen. Was dit niet gelukt, dan waren ze uiteindelijk wel een verklaring in bijv. fonetisch Koreaans tegen gekomen.

Kortom, ik geloof er niet is. Vooral ook omdat de originele zin geen aanleiding geeft om te denken dat er iets achter zit.

En waarschijnlijk zitten er wel meer zinnen in het bericht die met wat moeite heel spannend gemaakt kunnen worden.
Vooral ook omdat de originele zin geen aanleiding geeft om te denken dat er iets achter zit.
Feitelijk is die hele pagina gevuld met alarmbellen. Zie bijvoorbeeld de aanbeveling om vooral de crypto in Windows en OS X te gaan gebruiken. Beide oplossingen zijn closed source en je moet Apple en Microsoft maar op hun blauwe ogen geloven dat er bewust of onbewust absoluut geen backdoors zijn ingebouwd ten behoeve van forensisch onderzoek of surveillance.

Zeg dan dat je als alternatief het beste bestanden die veilig moeten worden opgeslagen op een Linux server of VM met dm-crypt/LUKS kan wegschrijven, een oplossing die wel publiekelijk geaudit kan worden en open is.

[Reactie gewijzigd door mindcrash op 17 juni 2014 15:20]

Beide oplossingen zijn closed source en je moet Apple en Microsoft maar op hun blauwe ogen geloven
Daar zit inderdaad onze fundamenteel verschillende zienswijze. Ik ben even hard bereid om TrueCrypt te vertrouwen, als dat ik bereid ben om Microsoft en Apple te vertrouwen.

Ik geloof in deze context niet in grote (populaire) samenzweringstheorieën.
Hoewel ik ook niet in samenzweringstheorieën geloof, is mijn vertrouwen in de Truecrypt open source code die op dit moment nota bene al de eerste audit positief heeft doorlopen, groter dan de closed source van bedrijven die op zijn minst een twijfelachtige samenwerking zijn aangegaan met de NSA.
Ik geloof in deze context niet in grote (populaire) samenzweringstheorieën.
Bij closed source blijft het idd geloven. Bij open source liggen de feiten op tafel. Het kan dan wel complex zijn maar iets duisters als een backdoor komt echt wel boven water. Overigens heb ik met die verstoting van Truecrypt meer het idee dat 'men' vindt dat dergelijke software het individu te moeilijk controleerbaar maakt en/of teveel macht geeft, oftwel de werkelijke digitale oorlog. We moeten niet stoppen met gebruiken omdat het te onveilig is maar omdat het te goed is.

Geen idee of er ooit al iets in Windows, OSX of een andere commerciele software-omgeving is gevonden dat erop wijst dat MS of Apple "dirty" is. Als je een dergelijk systeem achter een andere computer hangt die simpelweg alles logt en redirect zie je alles voorbij komen. Dat hoeft niet leesbaar te zijn maar uit de bestemming en de tijdstippen waarop het gebeurt moet al e.e.a. te achterhalen zijn.
Maar ja. mensen leggen zich er meestal gewoon bij neer dat een app om onduidelijke redenen internet nodig heeft of toegang tot lokale persoonlijke data. Over een OS dat regelmatig onbekende data naar een onbekende locatie stuurt maakt waarschijnlijk niemand zich druk. Een onderzoek dat het allemaal aantoont zal ook niet veel indruk maken. Ook mede omdat velen zich niet kunnen redden zonder hun Windows en eigenlijk gewoon geen keus hebben.

Een echte complottheorie is het bestaan van een non-TCP/IP implementatie voor spionage in zowel het OS, de processor+chipset en de betrokken netwerkcontrollers, dus de NIC, het modem, eventuele routers of switches en dat allemaal ook nog eens aan de andere kant van de lijn. Die theorie kan wat mij betreft gelijk de prullenbak in. Zoiets is in de praktijk niet haalbaar. Alleen al het geheimhouden van slechts het ontwerp ervan is 100% kansloos met zoveel betrokken partijen.
Bij open source liggen de feiten op tafel.
Alleen als er grondige reviews plaats vinden.

Het feit dat ik een Gouden gids heb, betekent niet dat elk nummer en naam daarin klopt, alleen omdat heel Nederland de gids *kan* controleren.
Kortom, ik geloof er niet is. Vooral ook omdat de originele zin geen aanleiding geeft om te denken dat er iets achter zit.
Tja, als het fonetisch Koreaans was had ik het inderdaad ongeloofwaardig gevonden. Latijn, Engels of Russisch (daar komt vermoedelijk de ontwikkelaar vandaan, dacht ik) is dan weer een stuk geloofwaardiger.

We zullen het nooit weten waarschijnlijk, maar dit vind ik niet vergezocht in ieder geval.
Volgens mij weten we niet wie exact de ontwikkelaars zijn. Waarom zou er niet eentje uit Azië tussen kunnen zitten? Iemand hier opperde al dat zelfs de Mossad er achter zou kunnen zitten, dus waarom dan niet Noord Korea? ;)
1 April is al geweest dit jaar.
Ik denk niet dat het forken van TrueCrypt een goed idee zal zijn
Misschien om dezelfde reden waarom de software offline gehaald is? Is de software dus toch voorzien van een NSA backdoor?
De NSA is maar één van de partijen die hier interesse in hebben natuurlijk. Stel NSA heeft nu toegang, maar door publiceren van de zwakke punten krijgt de rest van de wereld ook mogelijkheden om toegang te verschaffen. Dus niet alleen overheden, maar ook "gewone" criminelen.
Ik vraag mij af wat ik nu moet denken, zie opeens op een site de naam Veracrypt, dat blijkt dus hetzelfde te zijn dan Truecrypt qua menu etc etc alleen staat er dat de containers niet TruCrypt Compatible zijn. https://veracrypt.codeplex.com/
VeraCrypt bestaat al een poosje (een jaar volgens mij), dus zo opeens is het niet.
Kunnen we hier geen film van maken? Gaan onder tussen al zoveel verhalen rond, dat er denk ik wel een mooi film script mee te maken is.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True