wuulsoftware

Given that the UK government has just started making use of the RIPA law that allows the police to demand your decryption keys ( see http://it.slashdot.org/article.pl?sid=07/11/14/2335202 ), I have been thinking recently about how I could add some deniability into Crypto Text. The idea is that if you are forced to decrypt your text in front of the authorities or some other hostile person you would do it in a way that displayed some harmless plaintext whilst keeping your real plaintext hidden unless you decrypted it correctly.

I'm thinking of various ways in which this could be achieved, and at the moment I think that having to hold down particular key combinations (e.g. ALT + SHIFT + F8) whilst entering your passphrase is one way to go, but I would be interested to hear any other suggestions.

For example, imagine that you want to encrypt your secret formula which is X. You could enter your text normally, e.g. "The secret formula is X", but also enter the dummy plaintext e.g. "The secret formula is Y" into a different window.

What Crypto Text would do is only display the first part of the text if you held down a particular key combination selected by the user (e.g. Shift-F5) while decrypting, so that if forced to decrypt the text against your will you would just enter your passphrase normally and it would display the harmless second bit of plaintext.

I don't think this would necessarily fool an experienced and skilled cryptographer, but it would be very difficult if not impossible for the average police officer or bad guy to prove that the real text had not been decrypted.

To make sure this is implemented in a useful way I am inviting suggestions for how this can be done - key combinations are one way; another idea I had is that you would have to click the Decrypt button at exactly 37 seconds (defined by user) past the minute...there must be other ways to do this, but it would need minimize inconvenience to the user whilst providing sufficient protection so that the authorities could not easily guess the correct decryption technique.

Please feel free to post suggestions. Thanks.

I have been thinking about this a bit more and it's going to be easier said than done - the problem with things like key combinations is that Crypto Text needs to know what they are, and therefore this means the key combinations will need to be decrypted at some point - and this leaves a glaring weakness, as the authorities could simply compile a new version of Crypto Text that revealed the key combination. So I think this option is dead in the water.

One other approach I have been thinking of is the technique used by TrueCrypt and its "hidden volumes". This would work by having Crypto Text append a significant number of random bytes at the end of the ciphertext every time a file was saved. However, when you want to store a piece of "deniable" text, it would be added in place of the random bytes. Apparently it is not possible even for an experienced cryptographer to detemine whether a chunk of bytes is ciphertext or just random "noise", so this would offer complete deniability. The downside is that every file would need to be a lot bigger than at present.

On the other hand, you could quite easily achieve similar security by just saving your secret files into your c:\windows\system32 directory and giving them names like mpg4x32b.dll so that nobody would ever guess what they really contained.

I'm wondering whether this is really worth the effort - it would complicate what is at present a fairly simple program and run the risk of turning it into a buggy piece of bloatware. Need to give this a lot more thought......

Hello Wuul,

I'm glad to see that you're back using another site.

I discovered your ctext about a year back, and I've been using it ever since for text within emails as it's so simple and quick.

As you've touched on the subject of hidden text and some of the options for achieving that, I thought I'd share a few thoughts as a user.

I think all of us use applications that suit a specific purpose - if I'm doing word processing I'll use MS Word for complex documents and Textpad or Notepad++ for simpler text documents.

If I want email privacy I'll use ctext (simple, fast, one use only), and if I want privacy in documents I retain I'll use something like dscrypt (private, non-sensitive, single file storage) or TC (permanent, private, multi file / multi volume, hidden).

Basically I think it's horses for courses and ctext is ideal for simple, fast, once only email text. I think ctext is fine for what it does, as is.

I guess you need to evaluate the effort into building functionality into ctext for the gain, and to a certain extent whether it's worth re-inventing the TC, freeOTFE wheel …

Just a thought on your comment on renaming files as .dll … from memory, there are a number of apps (both forensic and general) that scan based on file type and identify files that claim to be for example, a dll, but aren't (based on info in the file), so this isn't a secure method of storage (I think Sarah Deane also has a similar piece of sw that scans and identifies possible freeotfe and other secure volumes).

The renaming approach also wouldn't carry much weight for plausible deniability as the op sys doesn't create suss dll's.

My view is that you should accept that anything encrypted can probably be identified, either definitely (with sw that leaves a signature in the file somewhere), or probably (through the use of re-naming, or a large TC volume that contains almost no data in the visible volume). If you need medium to longer term storage, get it off the pc.

But this is getting off the topic a bit.

I appreciate the work you're doing, and hope you continue.

Kind regards,
William

Hi

Thanks for your comments. I think you're right - the more features you build in to a piece of software, the more bloated and buggy it becomes, so I'll probably just leave it as it is. In one of my other posts I outlined how difficult it would be - initially I thought it would be quite simple, but it would be a big job to make this work properly and I don't plan on doing this now.

Thanks
W.