TrueCrypt forum gone? (TrueCrypt either stopped development or was hacked?)

The thing that amuses me about it, is most of the advocates of such functions spend more time bleating how they want it than it would take to install any of hundreds of secure delete programs... right click > secure delete (tiny) keyfile- job done. Overwriting headers isn't much more complex to set up in advance either.
I have doubts about the wisdom of doing so, but it isn't technically challenging.

 

thanks some great points as you said it takes much time and care I guess if one has worked out as many scenarios as possible since anything can happen and if your confident in that set up one can hope for the best !

 

Many people do not use, and do not want to use, a separate keyfile or certificate. Although it would be best to overwrite all of an encrypted container, that process can take a long time if the encrypted container is large and/or there are numerous encrypted containers that need to be destroyed and/or encrypted containers reside on a slow storage device. In order to implement your own selective, faster destruction mechanism, you must have a solid understanding of the format of the encrypted container and know precisely where certain things reside and/or repeat. How you index into the container would depend on how it is hosted on the storage device (ordinary file, ...). Depending on the context, there may also be another filesystem and/or the storage device itself that retains some sensitive information and you need some knowledge to be able to know that and deal with it correctly. I bet most users of encryption products would be challenged by this, and thus would benefit from professional developed and tested tools for accomplishing various types of destruction.

Don't forget, destruction of encrypted data for entirely legitimate and lawful purposes is a routine occurrence in many settings, especially professional ones involving security/privacy. It is required by law and/or contract in various contexts. Failing to do so [properly] can end your career, open you and/or your company up to lawsuits, etc. In fact, some decision makers won't go near an encryption solution unless it supports a rapid destruction mechanism that makes life easier for employees, that can be used to quickly accomplish remote destruction on machines they've lost control over but phone home, etc.

 

If many people don't use and don't want to use keyfiles to give them the function they want, it's their logic that is faulty, not mine.

It's like asking to have a killswitch for your car engine because you don't want to turn the ignition key back off.

If the devs don't want to provide dual mechanisms, that's up to them. and since this got triggered speaking about LUKS/dm-crypt:

So go give him a good real-world scenario. Instead of buging someone who's uninvolved with the project, even if he agrees with their reasoning.

Just don't be surprised if you get told "use keyfiles, delete the keyfile" because that's what I'd say, it's a pretty obvious solution.

I might add, I know of no regulatory body anywhere that accepts destruction of encryption keys as acceptable data destruction, secure though that may be, they all still require one or more overwrites of the data itself.

 

I don't consider "use a keyfile" an appropriate recommendation for all contexts and especially all types of users, but I can see why people would fall back on that. I personally use them for some things and don't use them for some other things.

The FAQ author appears focused on coerced scenarios...

and more specifically those cases where such an option would not work and possible result in harm coming to the user.

Note that I was not speaking about coerced scenarios. However, even when it comes to coerced scenarios there are two questions that need to be asked... 1) where might this not work, 2) where might it work. Obviously, we want to focus great attention on #1. However, we also want to take advantage of every opportunity to incrementally improve something in ways that could or might work even in just some situations. Frankly, I do think there are scenarios where such a killswitch option would actually be beneficial in the real world, but I'm not out to try to change anyone's views on that specific pattern. It is built-in support for destruction, including rapid destruction of some sort, that I think developers should consider. The bottom line is that it should be easy for users to accomplish destruction, quick where quick will suffice, extremely thorough were extremely thorough is necessary. For a thorough destruction, I'd even consider prompting the user to specify not only the container but also, optionally, a keyfile. So that through the standard interface they are used to using they could destroy it all in one swoop.

 

In non coerced scenarios, you by definition have more time, there is yet (because regulators don't accept it) no commercial case for key/header/keyfile destruction as a method, you're stuck with a full overwrite. The case for it is pretty niché, and adequately served by keyfiles and keyfile destruction, whatever your religious views about not using them, add that *most* users will want to re-use the device, and thus need to re-encrypt or wipe anyway, and the case gets even weaker, since either act destroys the data.

However, it's not me you need to persuade, the LUKS/dm-crypt team have an open public invitation on their wiki for you to go and present them your case.

I respectfully suggest you go avail yourself of it.

Edit: Also worth noting that if available, in a coerced situation under pressure, someone might use such an option without adequate thought to the consequences, and suddely the coerced situation arguments all apply.

 

I believe the operative phrase would be "cryptographic erase". An unfortunate term, as I understand, because the encrypted data is actually NOT erased/overwritten. It is merely, and supposedly, rendered sufficiently difficult to access in plaintext form due to the destruction and changing of the keys used to encrypt/decrypt it. Awhile ago we had a Truecrypt versus built-in SSD encryption discussion. At that time I did some reading, and pinged some people, and the updated impression I got is that SEDs and the use of cryptographic erase functionality had already started to become popular in various contexts.

The complex web of government, commercial, etc standards and lesser policies that apply to different contexts is definitely not something I've tried to follow. Assuming you don't foul up and mishandle something, strict environments with security departments are a blessing. However, based on some searches it appears to me that cryptographic erase approaches are being blessed (with conditions) in some of the latest revs of important standards such as http://csrc.nist.gov/publications/drafts/800-88-rev1/sp800_88_r1_draft.pdf , which in turn are frequently referenced by various other and commercial standards. AFAICT, that and some others are not fully approved yet so I'm inclined to agree with your earlier edit and more recent comment regarding that approach not being fully compliant in all contexts. However, I think that gives us indication of where things are headed.

What the LUKs/dm-crypt or whatever team thinks, what you think, what I think... that's not what is important. What's important is that people hear different points of view and arrive at their own conclusions. Even though I was basically arguing the "con" POV on cryptographic erase approaches in that earlier thread, I couldn't... can't... dismiss what I think are some uses for that type of approach and rapid destruction in general. I think I've done enough in this regard, and you've elaborated on your POV too. However, if there is something else you wish to discuss by all means feel free.

 

Oh I don't doubt cryptographic erase is coming, we're certainly not there yet, and much as NIST 800-88 is blessed and sanctified by Uncle Sam, the vast majority of people don't live there, most other places won't even accept ATA secure erase despite all the evidence it's secure, the UK and most of the EU certainly doesn't yet, we're stuck with single/multiple pass block methods, probably for some years.

I forsee a controlable cryptographic erase function in the future of most systems, but I don't see it implimented as a "nuke option" to qualify as that, it would have to be comprehensive for the entire machine, I expect to see something targetted to specific containers, partitions, or drives, buried up two levels of menu under "Advanced" with a sanity check and hectoring messages along the lines "Are you absolutely certain? This can't be undone!" combined with demands for the passcode, much as FORMAT.EXE does, but more so. Or in the case of linux, requiring root access.

Which will satisfy anyone with a legitimate use, but still leave people who've watched too much James Bond screaming for their nuke button.

 

Check your jurisdiction's laws, but in the US state of Florida, here is what "destroying evidence" #has# to include:

So all this "destroying evidence" talk is a little off base.

 

James Bond and nuke buttons, LOL... ok... Hey, don't bug me, tell these guys -

http://www.kali.org/how-to/emergency-self-destruction-luks-kali/

 

Post coffee/breakfast: Earlier, I may have but didn't meant to blur the lines between hardware based cryptographic erase and software based cryptographic erase. I think there are important differences between those two approaches, and would expect the latter to receive more opposition in various circles. It was the similarity I was thinking of. Be it hardware/firmware driven destruction of keys within a storage device, software destruction of keys in a file separate from an encrypted container, or software destruction of keys stored within an encrypted container, the aim is to make the plaintext more difficult to access during a shorter window than would be required for a more comprehensive overwrite.

 

GeekCrypt: A Secure Fork of TrueCrypt.

I received an email from the tails-support@boum.org mailing list sent by Bill Cox aka waywardgeek@gmail.com announcing the effort.

-- Tom

 

What is it with all that 'the TC license makes a fork impossible'-talk ?
No it doesn't, not even when the Debian-fundamentalists invented this problem out of thin air years ago was there a problem .
Ever since, you have been hearing this nonsense about a 'license-issue', that 'TrueCrypt is not open-source' and whatnot .
What you can not do is : Call it 'TrueCrypt' and/or use the icons, period .

 

Never been an issue with forking, the problem has always been around redistribution due to unclear and strange licence terms that never got resolved in trying to meet any of the commonly accepted open source licenses.

The big thing was not over the TrueCrypt licence for Linux distros, but some of the crypto algorithms was clearly not open source and not compatible with one another (within the same package).

From what I remember there were many minor issues over mentions of explicit license agreements, waiving of certain rights, limitations to how the source can be distributed depending if commercial or non commercial distribution, no copyright or trademark indemnity from anyone upstream.

I seem to remember that someone/people, Fedora or Debian said (after having the license reviewed by legal council) that main issue was the overall wording had legal problems and inconsistencies, which made it hard to determine if the license was actually open source or not.
This make TC potentially dangerous to redistribute regardless of being open source or not.

Cheers, Nick.

 

And just how many countries are there in the world? I respectfully suggest that level of immunity is probably almost unique to the USA. Most people live someplace else.

 

hi
Evidence destruction panic features is not James Bond syndrome at all...
The 98's CIH virus has already a kill disk function, sleeping and hiding itself in the hardware level, SecureTrayUtil, that i've used in the past as an Eraser alternative ( http://kareldjag.over-blog.com/1-categorie-69557.html ) already integrates "self destruction" option, and self destructing laptops, hard disks and smartphones (Boeing, BlackPhone) are already a reality.
More over, the Prism scandal has demonstrated that the reality is more than a James Bond fantasm...
The three letter agency has not cracked RSA, as they have used another method https://www.eff.org/deeplinks/2014/...y-experts-leave-rsa-conference-they-can-trust
And i guess thay have not cracked TrueCrypt encryption sheme too; but the recent publications of some researchers has schaken the crypto world, especially at the EuroCrypt conference a few weeks ago
http://www.sciencedaily.com/releases/2014/05/140515163739.htm (the original paper is technical) http://www2.cnrs.fr/en/2393.htm
I suggested forensic linguistic on another post, then let's try a theory:
"WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues" to "... is Not Secure As it may contain unfixed security issues"
As there is currently no absolute explanation, a Russian site has done a quick investigation about the TC devs http://news.softodrom.ru/ap/b19702.shtml
From Fort Meade to Cecland (?) is just a theory of course, as the reality might be trivial but cruel...
Now should we call Grissom, Columbo or even Maxwell Smart to helps us?

Rgds

 

@kareldjag
Are you being ironic? Your entire post reads like classic James Bond syndrome, with tinfoil hat complications.
Yes some companies have incorporated panic features, this is driven by customers wanting it, pure marketing, not common sense or logic.
Using any abandonware is not sensible as it may contain unfixed security issues
Oh Shoot, now I've done it, .. it's actually difficult to avoid to give the stated message unless you actually *think about avoiding* the sequence.
lets see ... is not safe as .. oh feck!

 

Any software can contain unfixed security issues, abandoned or not.

 

@noone_particular
This I know.
And the message could have been "not recommended as", except that triggers conspiracy theorists who own guns instead...

@kareldjag
There's nothing wrong with a fast erase feature buried in advanced features, or requiring extra (root) permissions, but hanging a "Cool" nuke button where eejits can click it is inviting disaster.. enough people destryed theitr data with TrueCrypt as it was, without adding land-mines for them to step on.

 

I propose we call it a thump button. Part nod to the EP-3E incident, part reminder that some would want to use it when they think they are about to get thumped, part reminder that you may be thumped FOR using it, part reminder that if you use it accidentally it may feel like getting thumped

 

Whatever is done.. it needs a safety catch, not a hair trigger. If it's too simple to use, people will, plus people will write malware that attempts to activate it.

 

I suspect some possibility:

The author of Truecrypt was arrested by someone.
The author told the webmaster of sourceforge that he could not change the contents of truecrypt website until he get released.
There must be someone has the power to get the webpage back to the real Truecrypt style but he/she doesn't, maybe NSA/GOV thinks the terrorists (or other countries) didn't learn the English much and they may use Bitlocker or other NSA friendly software.
Both the author and the webmaster get threaten and it's not safe for running any software in sourceforge in recent.

 

I'm thinking, from a developer's name with weird unicode characters in, and where the TrueCrypt trademark was registered (hint, people tend to register trademarks where they live), that the NSA is highly irrelevent to the former developers.

I also draw two more inferences:
1) Most conspiracy theorists live in the USA
2) Most Americans think the USA is the entire world.

Item two is also supported by them calling a national competition "The world series"

 

Regarding a destruct, disk wipe, panic button, whatever you choose to call it, I don't see that many scenarios where it would be necessary. Most would never need such a feature. For those that do, I don't see why they can't set up their own using command line. It isn't that hard to write a batch file that would lock your system down and start a wipe, especially if it launched other apps like eraser on Windows. It could be launched via keyboard shortcut or even a voice command. IMO, people who need features like that should learn to do these things for themselves instead of relying on the vendors for everything.

Maybe that's because the rest of the world already knows that it's more than just "conspiracy theories".
On the 2nd point, Americans are the most self absorbed and self centered people on the planet. I'd modify that statement to read:
Most Americans think the USA owns the entire world.

 

hi
I come here mostly to practise my english, and in some case share experience or news.
And i often post with a smile...as there is no dramma about TC, despit the real origin of this strange news.
Of course, i have never recommended any panic button as i know their limit (just try the very port/network sensible Centry with TC for instance).
Hardware solutions are more reliable, even if their use must be done with the law of each country
http://securedrives.co.uk/index.php?route=information/information&information_id=8
During the arab spring, my recommendation for a friend was not a product or encryption in particular.
In fact, as for the D Day (meeting today and tomorrow in France), the goal is to hide the right information
https://translate.google.fr/transla...ds-veille-debarquement-jean-deuve-735962.html
Or for any evidence, like the name and phone number of friends dissidents, do not use encryption, it is so easy to store the info in different places and supports for instance with a kind of encryption.
You're definitively lost if you put your security, or life in one product, one solution.
Then should we save the soldat TrueCrypt?
I guess that his life will change with no doubt.
http://privacy-pc.com/articles/a-pa...yption-is-broken-and-how-we-might-fix-it.html

Many posters involved in this toppic has not put their residence country.
And theories are not just a question of places, or hegemony.
Maybe TC, due to recent inprovements in Crypto, simply became more vulnerable to attacks?

To be continued...