Despite Project's Demise, Amazon Web Services Continues To Use TrueCrypt 75
An anonymous reader writes with an article at InfoWorld that points out that TrueCrypt may have melted down as a project, but hasn't disappeared altogether: Importing and exporting data from Amazon Simple Storage Service still requires TrueCrypt, two weeks after the encryption software was discontinued ... Amazon.com did not immediately respond to an inquiry seeking information on whether it plans to support other data encryption technologies for the AWS import/export feature aside from TrueCrypt in the future.
Infrastructure can be complex to upgrade; how long is reasonable?
If it ain't broke? (Score:5, Insightful)
Why not use it until you HAVE to find an alternative. I mean the audit of 7.1a is not even done yet.
software != fruit
Re: (Score:1)
software != fruit
Tell that to Apple.
Re:If it ain't broke? (Score:4, Interesting)
The group currently doing the security audit announced their full intent to continue the project. So it hasn't "melted down" any more than MySQL did. Just somebody else taking the reins.
(Just to clarify, I meant MariaDB. I don't count Oracle as "taking the reins". That was more like a stampede over a cliff.)
No, PostgreSQL is the replacement for Oracle DB (Score:1)
No, PostgreSQL is the replacement for Oracle DB. The replacement for MySQL is MariaDB.
Re: (Score:2, Insightful)
Because there are probably known vulnerabilities actively being exploited by government agencies that they were told not to fix.
Of course if you're using AWS you're almost certainly subject to NSA surveillance anyway, so... it's not any better or worse than them spying on it through other channels.
Still, considering the situation with truecrypt was announced with 0 warning and no trivial alternatives to migrate infrastructure to I would think people are more or less stuck with it for a few months.
Re:And the problem is? (Score:5, Interesting)
If you're using AWS, your data is unencrypted on their end ANYWAY. Or at least, they have to hold the decryption keys in a way that lets them decrypt it, so its irrelevant to encrypt it unless you just enjoy wasting CPU cycles.
The truecrypt container is only useful when transferring data between your end and the Amazon servers if you're not using an encrypted channel to start with for the transfer.
Considering the situation with truecrypt, ... well, theres nothing really useful to discuss since the only thing known is they stopped maintaining it in a OMGDRAMA sort of way.
You're allowed to retain the keys (Score:2)
If you're using AWS, your data is unencrypted on their end ANYWAY. Or at least, they have to hold the decryption keys in a way that lets them decrypt it, so its irrelevant to encrypt it unless you just enjoy wasting CPU cycles.
Not if you encrypt your data prior to sending it to AWS.
But yes, if you use AWS's encrypt/decrypt service, then they retain the keys by necessity. That buys you having your data encrypted at rest, which may have some value for certain compliance-type use cases, but other than that, it doesn't buy you much.
Amazon's continued use is a good sign ... (Score:4, Interesting)
Because there are probably known vulnerabilities actively being exploited by government agencies that they were told not to fix.
The TrueCrypt project is not dead, it is open source. It merely has lost its original developers.
An audit of the source code is underway. They are using the source for the last full featured create/read/write version released prior to the current read-only version. I believe they have confirmed the source matches the public binaries and that there are no backdoors. They are currently studying it for vulnerabilities and exploits. When they are finished this audited source code will provide that basis for continued work on the project.
Amazon's continued use is a good sign. Perhaps Amazon and other interested commercial entities will support future work on the project. Much like various commercial entities support the majority of the work on the Linux kernel.
Re: And the problem is? (Score:2)
Here's the thing about gov't software conspiracies: they use the same software! There is no "special" government version of WIndows or OpenSSL. It's all COTS. If the NSA was exploiting vulnerabilities that left themselves and other agencies exposed, then that's extremely irresponsible, but just foolish as well. I'm not saying it's never happened, but it's not a sustainable policy.
Re: (Score:2)
Re: (Score:2)
The NSA has deliberately weakened NIST encryption standards multiple times. There are multiple security products available, and they may well be running patched versions of something like trucrypt.
Re: (Score:2)
Care to list those "multiple times"?
Re: (Score:2)
DES (shortened key length) and Dual_EC_DRBG (terrible RNG) most recently are the ones I recall of the top of my head.
Re: (Score:2)
That is stupid. The government cannot prevent them from doing maintenance on their product. What more likely happens is that the release-signing key was compromised by the forces of evil and any _newer_ release than 7.1a may be a government trojan and the project team published that in the only means that the totalitarian machine left them.
Re: (Score:1)
That's your interpretation. Another interpretation would be that the NSA is spreading FUD over Truecrypt because it's widely used and they haven't been able to break it. At least it's open source and being audited and now belongs to an active open community instead of some secretive circle that couldn't handle the complexity or was threatened into giving it up.
AWS Email (Score:5, Informative)
13 hours ago, Amazon / AWS sent out the following email:
Dear Amazon S3 Customer,
Amazon S3 now supports server side encryption with customer-provided keys (SSE-C), a new encryption option for Amazon S3. When using SSE-C, Amazon S3 encrypts your objects with the custom encryption keys that you provide. Since Amazon S3 performs the encryption for you, you get the benefits of using your encryption keys without the cost of writing or executing your own encryption code.
Until now, in order to use your own encryption keys, you needed to encrypt your data client-side prior to uploading them to Amazon S3. With SSE-C, you now have the option to securely store your data using keys that you manage, without having to build client-side encryption infrastructure.
To use SSE-C, simply include your custom encryption key in your upload request, and Amazon S3 encrypts the object using that key and securely stores the encrypted data at rest. Similarly, to retrieve an encrypted object, provide your custom encryption key, and Amazon S3 decrypts the object as part of the retrieval. Amazon S3 doesn't store your encryption key anywhere; the key is immediately discarded after S3 completes your requests.
You can learn how to use SSE-C today by visiting "Using SSE with Customer-provided Keys" in the Amazon S3 Developer Guide.
Sincerely,
The Amazon S3 Team
Re:AWS Email (Score:4, Insightful)
Gee. Send the data in the clear along with an encryption key so it's stored at the remote site in an encrypted form. There's no way that a NLS will allow for the interception and disclosure of the key is there?
Frankly, that "solution" is a rather poor one at best and far too likely to give the customer a sense of security while in reality their data is totally accessible.
Re:AWS Email (Score:5, Interesting)
With truecrypt images, you give them your public key and have authorized their private key to decrypt. With this situation, you send them cleartext data and a private key; they encrypt your private key against theirs, and then encrypt your data against your private key.
So with the first setup, you've got a chain of reputation, segmentation of authority, and only encrypted data going over the wire. In the second setup, you've got no chain of reputation, only a partial segmentation of authority, credentials in memory on the public system, and cleartext on the wire.
So this isn't about the data being decrypted as much as it is about the security of the data in transit, and the security of the credentials used to secure the data.
Think of it this way: in both cases, in order to publish data the publisher needs access to the private key. In one case, that private key is held in private by the author. In the other case, it is held on a public system, and is accessible by anyone able to scrape memory or by anyone with access to the AWS corporate key.
Re: (Score:1)
This "chain of reputation" stuff doesn't work the way you think it does. All of that can be faked out by a man-in-the-middle who can read the truecrypt image and then choose to pass along the original data or substitute their own. As long you rely on amazon to do the decryption for you, they can theoretically do that man-in-the-middle attack.
None of that applies to NSLs either.
Re: (Score:2)
So, as the email said, just "encrypt your data client-side prior to uploading them to Amazon S3"
It's not about in transit or use (Score:2)
This encryption is about protecting data against theft of storage, or accidental loss of unwiped storage due to for instance upgrading hardware by Amazon and disks not being wiped/destroyed before they are sent off to be recycled. At the time that you are actually working with your data, it will be unencrypted and the keys to unencrypt will have to be on their systems. That means there is no way you can have your processing in the cloud happening without working with unencrypted data.
By not having Amazon u
Re: (Score:2)
It is fine that they introduced it. It protects against very specific things:
a) S3 data in there to stay, probably for many decades. To me it is a difference if all S3 data is unencrypted if there is a bug in the system at some point, or a new insitutional requirement in the future, or just the data which is accessed during the unfixed bug or after the change in laws.
b) One more layer of safety is never bad. You can use this to transport the key safely to the system of the user and the rest of the requests
Re: (Score:2)
Security is always a trade-off. Anyone who gives a shit about whether or not AWS has access to the plaintext will encrypt the data prior to transmitting it to AWS.
The use case where I could see SSE-C being helpful is where a customer has a lot of data to encrypt, and the security requirements are minimal. Rather than the customer using their own CPU resources to perform the encryption/decryption, the customer can offload that work to AWS's servers.
Another potential use case is one where the customer was ori
Re: (Score:1)
Does anyone else think this doesn't make any sense?
So, you give them the key to encrypt your data with, and they couldn't possibly store that key, intercept it or otherwise save it somewhere for later?
This is pretty much how all of the cloud providers operate though, the moment you hand over the keys to an intermediary its over.
Re: (Score:3)
Amazon should just distribute it (Score:2)
Just provide a locally hosted "Amazon Edition" of TrueCrypt for the purpose of setting up import/exports. It's still great software... and sure as heck better than sending data unencrypted.
Why should one move from truecrypt 7.1a? (Score:2, Insightful)
Truecrypt code remains available and currently available 7.1a online exactly matches ones I downloaded over past 2-3 years now and then. It is still good (tho the "7.2" version that was recently put out is crippled and should be ignored.)
It can be obtained at https://www.grc.com/misc/truecrypt/truecrypt.htm
and matches exactly the ones downloaded over time.
The code is being formally reviewed (still) and is likely to be picked up by others. Unfortunately one does not make money
sellig cryptodisk software (I tr
Re: (Score:1)
Corporations have needed crypto too ... (Score:3)
Was it needed in 1979?, only ones I could guess who needed that kind of cryptodisk software would have been governments at most?
Corporations need it too. Especially larger ones. Keep in mind that the famous Enigma machines of WW2 were derived from commercial crypto hardware developed for the commercial market, so that corporate headquarters could have secure communications with regional offices, people negotiating contracts at remote locations, etc.
A lot of espionage is industrial in nature.
Re: (Score:2)
Jesus Christ, Gibson's writing hasn't changed in fifteen years.
What's the web equivalent of "chewing the scenery?"
Re: (Score:1)
Unfortunately one does not make money selling cryptodisk software (I tried when I published some back in 1979)
You should have tried selling cryptoperfocards software back then, disks were not in wide use.
Sorry, not gonna move to a MS solution (Score:3)
Yeah, sure, use bitlocker as sourceforge says.... because MS totally doesn't open backdoors for the NSA that makes goatse jealous. *snort*
http://truecrypt.ch/ [truecrypt.ch]
Re: (Score:2)
...
If MS wanted to 'backdoor' you, they wouldn't bother fucking with BitLocker, they'd just do it for ALL VOLUMES, which would catch your mounted TrueCrypt volumes as well.
If you're using TrueCrypt on Windows, BitLocker is indeed 'just as good' until a flaw is found. They don't NEED a backdoor in BitLocker, they own the kernel which is the place where you would actually want the back door if you were going to do it. TrueCrypt can't save you from a kernel module/driver/service that wants to see all data to
Re: (Score:2)
Re: (Score:2)
Wait... you meant encryption.
Never mind.
Re: (Score:2)
*Sigh* can you share just one of those backdoors? Or are you just spouting bullshit?
Two weeks!? Unacceptable!! (Score:1)
Seriously, Amazon.com should have evaluated, selected, and implemented a new encryption system in 24 hours! I am OUTRAGED! /sarcasm
Shit doesn't happen immediately...
More NSA sponsored anti-Truecrypt FUD (Score:5, Interesting)
Truecrypt has been the no.1 target for the NSA and GCHQ for the longest time now. Truecrypt implements encryption in the ONLY way that makes sense- known state-of-the-art mathematical algorithms used against the simplest file system driver emulation, allowing encrypted data to simply exists in monolithic data blocks. No different from Ram Disk and zip-folder technologies, with an encryption front-end. A NIGHTMARE for the full surveillance programs of the NSA/GCHQ.
Remember, Truecrypt is of no consequence for TARGETED victims of the security apparatus. If you are a true, named, subject of State surveillance, covert cameras, keyloggers, and other simple, cheap hardware solutions will be used to disable your attempts at encryption in the first place. The 'problem' with Truecrypt is that as its use spreads, large amounts of online data go 'DARK' for the security apparatus. The use of Truecrypt is like refusing to connect the NSA designed Kinect2 spy platform to your Xbox One console.
But, you argue, even so the numbers of Truecrypt users were never going to be THAT significant? Well, while this is kind of true, the reaction to Snowden's revelations was an ever growing general concern about the visibility of private data. Sheeple were rightly learning to absolutely distrust all solutions from corporations- and pressure was growing to create more publicly friendly equivalents to systems like Truecrypt. To consider a parallel, take Ad-Block. Large numbers of people ONLY began using Ad-Block, because the online ad business, even on the largest web-sites, adopted the most abusive, anti-user practices imaginable. Of late, the most mainstream sites have all been responsible for using browser exploits to deliver illegal trojan code package to unsuspecting users. And when people complain, these disgusting companies all say "don't blame us, blame the ad-serving services we use".
The consequence of the 'Wild West' of online ads is more people want to block the whole damned industry (and rightfully so). And the same now applies to encryption. More and more people want to fight back against the obscenity of the FULL SURVEILLANCE society. And the NSA wants these people to fight with 'weapons' the NSA has already ensured are useless.
It does NOT matter that Truecrypt 'could' have minor, unusual 'vulnerabilities'. All software falls into that category. What matters is that Truecrypt protected files are the greatest pain-in-the-ass for the NSA. Do not let Slashdot's NSA sponsored content tell you otherwise.
Re: (Score:3, Funny)
Re: (Score:2)
Truecrypt has been the no.1 target for the NSA and GCHQ for the longest time now.
Cite?
I suspect that Truecrypt is secure, but we don't actually have any reason to believe that it doesn't contain one or more weaknesses that give the NSA ready access to Truecrypt volumes. And even if it is secure, we don't have any specific reason to believe it's their number one target.
Re: (Score:2)
Nice comment, until the end when you found it mandatory to take a shot at Slashdot's reporting as anti-Truecrypt advocacy.
Giveth us all a break.
Re: (Score:2)
Or maybe TrueCrypt is really compromised and your post is NSA-sponsored, in an effort to get people to feel secure using TrueCrypt when really the NSA can read it all.
Hmmm.... We really don't know.
Re: (Score:2)
Does that matter when we are all perhaps living in a computer simulation? We really don't know that either...
Must have been an NSL (Score:2)
The results are likely to negative for the USA -- think of Americans travelling in Asia, with laptops on which the data is encrypted using systems which are likely to have backdoors.
That's why the defenders of the NSA are wrong -- even if you accept the privacy violations, the net result is reduction in security. Even with
Re: (Score:2)
On Windows, BitLocker is just as secure as TrueCrypt. Well, assuming there are no massive unintended flaws in BitLocker.
If you want to get around BitLocker, you don't bother exploiting BitLocker, you just install a kernel driver that filters ALL read/writes to volumes, this would be just as effective against TrueCrypt as it is against BitLocker.
MS doesn't need to provide a back door for BitLocker, a back door for mounted volume IO is FAR more useful since it leaves BitLocker untainted and it would catch an
Re: (Score:2)
Just to clarify your statement above -- you are saying that neither TrueCrypt nor Bitlocker is secure on Windows and both can easily be compromised on Windows?
Re: (Score:2)
On Windows you don't even need to do that. Detours [microsoft.com] gives you the ability to intercept any API call you'd like. Hook the appropriate file I/O calls, and you're done, no compromised drivers needed. Of course, there are ways to determine that the calls have been detoured, but there
Re: (Score:2)
On Windows, BitLocker is just as secure as TrueCrypt. Well, assuming there are no massive unintended flaws in BitLocker.
Consiring that MS tends to release software with "unintended" flaws numbering in the thousands, that eases my mind about the security of bitlocker.
Re: (Score:2)
Or an intended back door. You seem to be envisioning an "evil maid" scenario, where the NSA/FBI/whatever installs software on your computer that monitors it as you use it. In that case, no, nothing's secure. In the case where the LEOs have your hard disk, and are trying to read it, having a way to monitor disk reads/writes is useless. What is useful is a way to crack the encryption w
What is the alternative? (Score:4)
TrueCrypt was trusted because the source code is/was open source, the binaries could be checked, it used respected algorithms, and had few flaws. Yes, there was minor fixes that could be done to make it more secure, and there are methods to defeat the keys (Flash freezing the ram chips in the computer to preserve the stored keys is one). But TrueCrypt reigned supreme with the cost-reputation-cryptostrength score.
Of course, according the (canary) Truecrypt homepage it recommends BitLocker by Microsoft, which few people take seriously. Microsoft recently peeked at its employees private hotmail account, and is known to include features in its OS to make NSA happy as well as copyright holders.
What alternative is there to TrueCrypt?
Re: (Score:2)
Gotta say, LUKS has worked for me since like forever. There's something else for OSX but I don't know what it is. The *only* advantage Truecrypt has over these, (except plausible deniability which is very useful), is being cross-platform.
Re: (Score:2)
He's talking about re-crypting the data on disk, not taking a backup copy of the (encrypted or decrypted) master key.
In other words, if any of the more important bits are lifted by someone (presumably someone who knows your passphrase to decrypt them, or they wouldn't be much use at all) you can't just re-key the store. You change your passphrase, they can still access the data with that master key. Need to create a whole new store now.
Stick a fork in it (Score:2)
So the old project is done. Stick a fork in it, grab the source, and spin another.
TCnext - the TrueCrypt fork (Score:2)
You guys are aware that TCnext exists, a new effort to keep the software alive based in Switzerland.
You can get there via truecrypt .ch
The source code for TrueCrypt 7.1a is available for download, and there are various forums where we're discussing the implementation, how to proceed, where to take the project, future audits, and so on.
Last, the general consensus is that 7.1a is "safe enough for our current needs based on what we know". Many of us in that community also feel the 7.2 shutdown in a hurry was
Re: (Score:2)
You guys are aware that TCnext exists, a new effort to keep the software alive based in Switzerland.
You can get there via truecrypt .ch
Hmmm. How do we know that people behind TCnext aren't the NSA?
Re: (Score:2)
We don't - beyond peer reviewed code, and they're on board with continuing the independent audits and such.
Contribute to the project and find out -- let's weed them feds out!
Cheers!
Re: (Score:2)
Sorry - one more thing: there are also known (based on pre-existing signatures) binaries ready for download, if that's your cup 'o tea. So, given where the audit is (to which I'm also a financial supporter) and what we know... OKi for now, let's keep the project alive.
"You can't stop the signal, Mal."
Re: (Score:2)
TrueCrypt 7 Rocks (Score:1)