It's cool but basically solves a problem that no longer exists. Once you've caused enough suspicion, they can simply dig up the records of all the data you've sent, both chaff and wheat, and serve you with an order to disclose your authentication key/lawfully hack you computer and obtain it without asking/apply some lead pipe cryptanalysis and get it anyway. In the end, it's no better than regular encryption, at the cost of being at least twice more inefficient.
Still, for all the crypto export nonsense, 1998 appears to have been a more innocent time:
> "But access to authentication keys is one thing that
government has long agreed that they don't want to have."
Near the bottom they mention using more than one wheat stream to achieve something like deniable encryption. If they ask you for the key, give them the one that produces innocent-looking messages.
Depends, how good are you at creative writing? I can think of a lot of messages you might send to someone that you'd want to be private that aren't nefarious plots. Weird fan fiction. Deviant porn. Messages exchanged with a secret mistress. Depending on the situation, you might even want to give them a fake copy of your nefarious plot. Include more than one extra set of messages if you like and give them whatever keys you like in whatever order is appropriate.
>In the end, it's no better than regular encryption, at the cost of being at least twice more inefficient.
He goes on to explain how to make it more efficient: If you need every "wheat" packet to reconstruct any part of the message, you can send a finite number of chaff packets (e.g. 1000) in random locations, which would make reconstructing a message of arbitrary length infeasible for an adversary that can't separate the wheat from the chaff other than by exhaustive search.
See also "Chaffinch: Confidentiality in the Face of Legal Threats" by Richard Clayton and George Danezis from University of Cambridge, which has some more plausible deniability.
I've thought about writing a Chrome plugin to do something similar. While on it would randomly chaff the low order bits of any image you upload, and would automatically add a chaff postscript to every Gmail. An adversary would have no clue which images/messages contain ciphertext, and which contain nothing but random chaff.
I'm probably misunderstanding this. The way I'm envisioning this is basically a half-dozen parallel conversations, with only one of them being the actual conversation.
Couldn't it be easily defeated with contextual analysis? I mean, if it were English sentences, the attacker could just choose a set of packets that make grammatical sense. Or in more real-world examples, you'd just choose the packets that form a valid HTTP session.
To work around this, you'd have to choose your chaff packets to flow seamlessly from one to the other, which would make chaffing a really hard problem.
Without knowing the HMAC key, the only information exposed is the length of the message. Without the HMAC key, you can't tell whether '0' or '1' (both of which are sent, for every bit in the message) is the correct bit.
The second works in a slightly different way. You take a message, and transform it into a package in such a way that one must determine the entire package contents before being able to decode any part of the package. (Rivest's proposal for such an 'All-or-Nothing Transform' can be found in [1]).
Next, you packetize that transformed package. Rivest proposes blocks of 1024 bits, but it could be anything. The point is you can't send (2^1024 - 1) 'chaff' blocks, which would be required to not leak any information about a 1024-bit message block.
But, crucially, you must determine which is the correct block for every sequence number sent. So, if one includes just one 'chaff' block for each 'wheat' block (so there is one wheat and one chaff block for each sequence number), and sends n blocks, then an attacker who doesn't know the HMAC key would need to choose the right combination of blocks of all sequence numbers--a 1 in 2^n chance--before being able to decode your message.
If one splits an all-or-nothing transformed message into at least 256 blocks and sends one 'chaff' block with each 'wheat' block, you could be pretty sure the message remains confidential. Of course, this assumes all those pesky security assumptions about the random number generator, transform, and HMAC function hold up.
If Alice's messages could all be intercepted and manipulated prior to Bob's receiving them, then yes, they could be changed without either party knowing.
Combined with asymmetric encryption of the messages, you should be able to prevent that from happening.
No. This is just a method of "securing" messages without encryption. It still requires a shared key. Replaying messages sent this way would be no different to replaying an encrypted message.
But that's rather missing the point, isn't it? The premise is "Under circumstances where encryption is not a viable option, what secure communication methods might be possible?" so responses that ignore the premise, like "just use encryption" or "just don't get into such circumstances", aren't the most salient critiques.
Two points: First, this was from 1998 - back when "exporting encryption" from the US was punishable as exporting weapons. Secondly, this is proposing a communication scheme where there is no "encryption/decryption key" for the NSA to coerce people into handing over.
Images are just the lowest hanging fruit and attract a lot of sloppy schemes. You can encode information in pretty much anything as long as you are free to choose the message.
You could even encode info in plain text by the lengths of non-whitespace characters, modulo 2. As an example, try using the so-defined scheme on the letters count of this very sentence; they're encoding, repeatingly, S.O.S.
Posts of similar length as this one are enough to send a public key using ECDH and negotiate a shared secret for use with a block or stream cypher. You could then send short messages using this shared secret inconspicuously. Shannon entropy of English is about 1.5 bits per character so you could store quite a bit if you cared to compress it well before encrypting, preferably using a shared static dictionary.
People read a book, they see a simple description of steganography, they whip up an implementation as a proof of concept, they share that code, other people think it's secure when it's not meant to be.
A solution to this is to increase the "noise floor" by bundling steganography tools with common widely distributed software, so that obviously 99+% of people and computers with steganography software would be 'innocent'.
For example, if Ubuntu default installation would create a small (10mb?) sized volume filled with random bits and install an appropriate steganography tool designed to write/read encrypted data there, then it would enable anyone to hide some arbitrary data while having a file/software setup that's not distinguishable from millions of others in any way.
"A solution to this is to increase the "noise floor" by bundling steganography tools with common widely distributed software, so that obviously 99+% of people and computers with steganography software would be 'innocent'."
Good luck with that one. As a practical matter, this is unlikely to happen; hardly anyone requires steganography as part of their security solution (the MPAA stands out due to the use of watermarking). Email and online businesses were the killer app for public key cryptography; what killer app do you see for steganography?
I don't see a killer app for that - the whole point is not that millions need it, but that all tools needed for steganography are shipped also to millions of people who don't need it.
Someone (preferably multiple organizations) should bundle steganography just because it's desperately needed for a tiny minority - doing so would not be because of a killer app but simply a service for public good, facilitating democracy, free speech, whistleblower protection, etc.
This is aligned with the stated ideals of multiple FOSS organizations, so it is feasible to assume that someone with popular widespread software (like, say, Firefox, Ubuntu or VLC) could do that for purely idealistic reasons. The software size is tiny, so the distribution overhead would be trivial while making a serious strategic change. Do it just because it can be done.
Imagine you wanted to leak something but don't want to attract attention to yourself. You could encrypt it (with the public key of the organization you want to leak to), hide it with steganography and then upload the result to some public place you know the organization would be monitoring.
If you had ready access to tools to do so you could do all that inconspicuously.
Still, for all the crypto export nonsense, 1998 appears to have been a more innocent time:
> "But access to authentication keys is one thing that government has long agreed that they don't want to have."