Earlier quoted context omitted.
I think that's why they are quitting. They didn't want the audit to find something. But it's just a speculation like any other.
It's more likely that they were angry that the audit got a lot of funds and they didn't. In OSS often the people who do the original work get nothing and all the money goes to pundits, packagers, and consultants.
True Goodbye: ‘Using TrueCrypt Is Not Secure’
241–249 of 249 posts
Re: True Goodbye: ‘Using TrueCrypt Is Not Secure’
#242Earlier quoted context omitted.
> Not "backdoors" but it seems Microsoft stores the BitLocker decryption key, based on this leaked slide (just found on twitter): https://twitter.com/TheBlogPirate/status/471759810644283392/... . That looks dubious to me - if you were creating a slide, would you use 90-degree-rotated text? > edit: Confirmed Microsoft stores your recovery key on their servers if you're not connected to a domain: http://windows.microso…
Maybe Microsoft asks or somehow prompts the user to back up their encryption keys? I mean, a user-focused OS certainly wouldn't include such a feature, right?
Re: True Goodbye: ‘Using TrueCrypt Is Not Secure’
#243Earlier quoted context omitted.
I really don't think we need to be running to TrueCrypt alternatives quite yet. If Phase II of the audit comes back showing TrueCrypt as insecure, then it's time to start worrying about that, but given that everyone was happy to keep using TrueCrypt up until 1 day ago even though it hasn't been updated in over 2 years, I don't think there's any big rush to switch to something else even if ongoing development stops.
"given that everyone was happy to keep using TrueCrypt up until 1 day ago" The same was true for OpenSSL a few weeks ago. One of the most plausible theories is that the TrueCrypt developers found a gaping security hole (ala OpenSSL) and realised that releasing a fix for it would reveal the bug and compromise every TrueCrypt partition in existence, so they chose to kill the project rather than risk the safety of all o…
Re: True Goodbye: ‘Using TrueCrypt Is Not Secure’
#244Earlier quoted context omitted.
I'll repeat my question, which you ignored in favor of quibbling with a tangential point: What makes you think U.S. law treats makers of products any differently, assuming TrueCrypt's creators and maintainers can be identified? If you want examples of FBI surveillance untethered to the law, we can provide those. Look at the video of the public forum I hosted with Ladar (of Lavabit) in SF last fall. Look at warrantles…
I'll repeat my question, which you ignored in favor of quibbling with a tangential point: What makes you think U.S. law treats makers of products any differently, assuming TrueCrypt's creators and maintainers can be identified? Something must be wrong because this is 100% the question I believe I responded to. I will attempt so again now: * Statute gives the government the right to compel certain service providers to…
This is an interesting claim. It would be more interesting if the U.S. government publicly said its interpretation of the law is the same as yours. It has not. :)
Re: True Goodbye: ‘Using TrueCrypt Is Not Secure’
#245Re: True Goodbye: ‘Using TrueCrypt Is Not Secure’
#246Earlier quoted context omitted.
well, I can see where you're coming from, but automation changes the nature. license plates on cars wasn't a big deal, it was primarily used to identify stolen cars and track drivers breaking the law. Then automation entered the picture and it became feasible to track the movements of everyone, aggregate it in a huge database, and claim "they might be criminals later". PRISM is more of the same, they could of compell…
But here automation is only automating the hard part (doing the collection correctly and in accordance with company policies). Remember, with PRISM each and every request has to be approved by the company in question before it proceeds, which is still a manual step. So the license plate reader example doesn't apply directly; Rather it might be like a license plate reader that only works when activated by a remote mag…
Are you sure it's the later, and not the former?
Re: True Goodbye: ‘Using TrueCrypt Is Not Secure’
#247Earlier quoted context omitted.
This is a pretty confusing case, hard to make much of it, LavaBit 2 is of course a possibility. But while we're making these theories, I wanna sound my wild theory: Considering that: (1) TrueCrypt authors go to great to keep their identities hidden, and (2) it turns out TrueCrypt is not free/open software -- TrueCrypt is actually a project by some spooky 3-letter agency. But anyway, thoughts on alternatives? CiskCryp…
TrueCrypt authors go to great to keep their identities hidden I donated at least two times to them via PayPal. How anonymous could they be if they got funds via PayPal? Not very, in this day and age. I would image it's trivial for the US government to find their true names based on this fact alone.
Re: True Goodbye: ‘Using TrueCrypt Is Not Secure’
#248Earlier quoted context omitted.
You can't just post an announcement like that in the current climate of suspicion and expect everyone to just ignore the possible implications.
Alright, I'll play. How long of an explanation are the users of a free service entitled to receive before the maintainer can happily go his/her way without follow-ups? Development of Truecrypt stopped, and as it's open-source, someone else could keep hacking away on it.
Re: True Goodbye: ‘Using TrueCrypt Is Not Secure’
#249Earlier quoted context omitted.
Agreed. Only doing operations involving transferring the key to RAM when the user is present should mitigate it, perhaps with a prominent WARNING dialog showing when memory is vulnerable, and overwriting the memory locations used for the key when done.
Truth be told, if RAM is a security liability for the few seconds it takes to enter the password and derive the key, then you can't give any security guarantees whatsoever no matter what algorithm you use, scrypt, PBKDF2 or any other. It's not like you can punch the password into the CPU directly, you need to use some sort of input device which has drivers which keep state in RAM, use DMA and IRQs etc. Any attacker c…