Plausible Deniability From Rockstar Cryptographers 358
J. Karl Rove writes "Nikita Borisov and Ian Goldberg
(of many, many other projects) have released
Off the Record Messaging
for
Gaim.
Encrypt an IM, prove (at the
time) that it came from you, and deny it later. The
authentication works only when the message is sent; anybody
can forge all the messages he wants afterwards (toolkit included).
Captured or archived messages prove nothing. And forward
secrecy means Big Brother can't read your messages even if
he wiretaps you AND grabs your computer later on. All the gooey goodness
of crypto, with none of the consequences!
They have a
protocol
spec, source
code, and Debian
and Fedora
binaries."
I hope the distros will do their part (Score:5, Interesting)
Re:I hope the distros will do their part (Score:3, Interesting)
"Your honor, there is no way to prove that this message came from my client or was forged by the investigators who used to beat him up in gym class."
I guess then it would just turn into a matter of your word vs. theirs.
Any lawyers out there?
Re:I hope the distros will do their part (Score:1, Interesting)
Oh geat, then I can trade warez, cracks, credit-cards, underage porn, sate secrets, [name something highly illegal here] and nobody will be able to prove that i've done it.
I must say the mathmatical theory behind it seems fairly sound, kudos to them for a truly innovative idea.
No doubt every paranoid delusional security consultant out there will be saying 'Ah Hah! But __THEY__ have a backdoor...' Akin to the secret 'NSA' keys distributed with Microsoft(r)(tm) Windows(r)(tm)(we break thumbs). But I see this as a great advance in personal security that will (possibly) spawn a whole new era in security services and applications.
What we have to think seriously about is, what happens when this becomes widespread? We all know that spammers follow new technology and trends, so then they will (possibly) be able to send you hundereds of spam emails a day, and then deny that they ever did..?
-- :)
Have you ever left your cluster on overnight to generate 1073741824bit RSA keys.. If so - your officially a paranoid geek
how about dual-plaintext messages? (Score:5, Interesting)
If required to give up "your private key" then give up the decoy key. The decoy plaintexts decrypts, and you're done. The real plaintext is still hidden away.
Does anything like this exist?
Excellent! (Score:5, Interesting)
I've often wondered about this when it comes to forensics testimony. For example, even if you have my computer with some incriminating evidence on there, how can you prove beyond reasonable doubt that I put it there? I would think that unless you have a video tape of me typing the incriminating evidence on the keyboard, and can prove that the tape was made at the time in question and is unaltered, is the only way to prove anything.
Computers can be programmed to do anything at anytime, including carrying on a "conversation". You can also easily create an incriminating e-mail message that looks like it was sent, but it never was. Ditto log files, etc. For example, Apache log files are text: it would be trivial to create a script that spoofed a log file with your IP address as the incriminating info...but then how does the plaintiff prove that isn't how it was created?
This is great... (Score:4, Interesting)
I can see some people having huge use for this, drug dealers, chat room stalkers, and of course all communications between an executive and their broker
I can't think of any good reason for _me_ to use it tho. Maybe I'm just not shadey enough.
Comment removed (Score:5, Interesting)
Re:how about dual-plaintext messages? (Score:4, Interesting)
Its called 'steganography'
What you do is you have a huge stash of embarassing hardcore porn, say 'bukkake bloopers 2000'
You use steganography to hide your real naughtyness inside those images and encrypt the image archive.
When someone insists that you decrypt it, you naturally get really embarassed but finally relent.
They see what you are 'hiding' and maybe laugh in your face; but they don't detect the stegged content (which would, presumably, be *far* worse than 'bukkake bloopers 2000' but what *that* could be I cannot imagine).
Re:I wonder (Score:5, Interesting)
One Really Good Use (Score:4, Interesting)
I gotta have it.
This is great! (Score:4, Interesting)
Re:how about dual-plaintext messages? (Score:4, Interesting)
Re:how about dual-plaintext messages? (Score:1, Interesting)
Re:how about dual-plaintext messages? (Score:4, Interesting)
Re:how about dual-plaintext messages? (Score:2, Interesting)
1. use the decoy D plaintext as a One Time Pad (yes, OTPs are inconvenient and need to be transmitted secretely too) and encrypt your plaintext P with it. This gives ciphertext C. C = f(P,D)=f(D,P)
2. when "they" require you to give up your key, give them the message you wanted to hide from them. Cross your fingers they don't look at that OTP. When they decrypt the ciphertext with the key, they will get the decoy message. Just hope for them not to look at the key you gave them. Social engineer them to just decrypt without looking at it. P=f^-1(C,D); but also D=f^-1(C,P), (cipher algo f was chosen to respond to this law, and must be given to the authorities.
Apart from this very dangerous method, I don't think there is a way to create a cipher that would transmit a innocent and a less innocent message together without getting a ciphertext with an Quantity of Information not higher than either messages. In fact, OTP methods *do* transmit more information than the payload, ie the OTP has to be transmitted too.
Hacked in 1 minute (Score:1, Interesting)
The 'feature' of allowing numerous forgeries after the first packet is proved authentic is a weakness. All you need to do is intercept a packet, hold it and analyze it, forge your own message and send it first, then send the old packet, which will bounce as a forgery.
try again.
Re:how about dual-plaintext messages? (Score:1, Interesting)
Timing Could be an Issue (Score:2, Interesting)
Re:how about dual-plaintext messages? (Score:3, Interesting)
http://groups-beta.google.com/group/sci.crypt/msg
Potential problem with this (Score:3, Interesting)
1. Receive message from your boss insisting you carry out some risky or unwise instructions.
2. * Disaster *
3. Boss disavows his earlier orders. Guess who is the fall guy?
Re:how about dual-plaintext messages? (Score:5, Interesting)
Rubberhose was a plausibly-deniable disk encryption system which allowed you to create 2 distinct encrypted file systems which occupied the same disk space.
One would be the decoy and have harmless boring info, the other would be the "real" file system.
If you were compelled to give up the passphrase to the filesystem, you could give up the decoy passphrase.
The implementation was tricky, because neither file system could "know" about the other, otherwise, an enemy would know you were hiding the "real" file system and could imprison or torture you into giving up the passphrase.
Since the stakes were high, Rubberhose had features to thwart forensic disk-surface analysis. A percentage of disk blocks from both file systems would be randomly repositioned on the drive, to ensure that the more heavily used "real" file system didn't stand out in any statistical way.
I'd love to see something similar revived.
-Sean
Traffic analysis (Score:1, Interesting)
Re:Slashdot is criminally irresponsible posting th (Score:1, Interesting)
Re:how about dual-plaintext messages? (Score:3, Interesting)
with the current administration be careful what you use as the containing data for the purposes of stenography. If the container becomes illegal then you have a real problem.
Re:I wonder (Score:4, Interesting)
Re:This is great! (Score:4, Interesting)
Well why not go looking for them then, rather than writing it on slashdot. Many exist. Even something like InvisibleNet's IIP (invisible IRC proxy) would do lots of what you want, Konspire2B would do more, there are more encrypted P2P and chat tools than you can shake a stick at, plus protocols that offer what you want with many different clients. Or go all the way and try GNUNet [ovmj.org] (replacement for freenet) and such like.
People are always posting "oh if only there was a distributed deniable torrented video blogging system with a pseudononymous web-of-trust [sourceforge.net]" or something, yet I never see you on my Konspire2B client. Just download the damn things and see what they do, some of the apps are really quite cool.
Re:Deniable until they look at your swap partition (Score:2, Interesting)
Why not, instead, make a plugin for gaim that specifies pages as in-memory only, without paging to disk. I'm pretty sure Linux supports this, and other OSes probably do as well. Memory is getting cheaper these days, and it's probably worth the extra cost to keep everything in memory, especially if you're talking about illegal activities. (And why are you performing such activities unless they're paying well enough that you can afford the extra RAM?)
See, temp files on disk can be cracked with enough computing power, if someone in the CIA is really pissed at you and has your computer. But if it's in memory and never gets placed on a disk, you're in the clear...
But no matter what you do, the safety of this is only as strong as the weakest link in the chain. Suppose you're talking to someone about a notorious crime you've just commited. You tell them all the details, and they have proof that it's you at the time of the conversation. This is obviously someone you trust, or you wouldn't tell them all this stuff. But what happens? Unbeknownst to either of you, the DEA has installed a bug in his computer that essentially videotapes everything that goes to the display. Now, you've got videotape evidence of everything you've said, plus proof that it was really you at the time it was videotaped. Encryption shmencryption, you'll be behind bars.
Therefore, don't commit crimes. If you do, don't talk about it. If you do, make darn sure that nobody's listening. And be prepared to pay for your crime, because with your luck, you'll probably get caught.
Ok, so it's not crimes you're talking about, it's this girl you're seeing that you don't want your parents to know about, because you know she's a troublemaker... Substitute "sex" for "crime" above, and substitute "parents" for "police"... By the way, when she gets pregnant, they WILL find out. :-(
Re:how about dual-plaintext messages? (Score:3, Interesting)
The burden of proof (Score:3, Interesting)
In a criminal case, your old messages would be a legitimate starting point for an investigation and likely enough on their own to justify a search. To get a warrant, the police don't have to prove you sent the incriminating messages, they just have to persuade a judge that it is reasonable to suppose that you did.
Suse?? (Score:3, Interesting)
Anyone gotten it to run compile/run on Suse 9.1?
Is this expanded problem solveable? (Score:4, Interesting)
The solution proposed is to use ring signatures which only permit proof that one of the parties to the communication (secret) wrote the message. As the authors note this solution still suffers from the defect that a third party who manages to obtain the plaintext of a message can still prove that it was created by one of the participants. This can be partially protected against by encrypting the signature part of the message (assuming the message itself was not already so encrypted) to the recipient but if the recipients private keys are ever comprimised (a subpeona, confiscation of computer by law enforcement) this protection vanishes.
The authors contend that no system using a non-interactive protocol can both provide authentication to the parties involved but resist proof of authorship by at least one of the parties in the case of key comprimise. I don't believe this is correct and while I can not provide a full system which demonstrates this property I can provide a sketch of how one might work and it would be an intriguing problem to design a cryptographic system with these properties.
Suppose at some time t0 Bob creates a public private key pair together with time stamp attesting to the time of creation. This time stamp, and the key itself could be authenticated by Bob signing with his conventional non-repuditory long-lived key. Let us call the key parts Public and Private. Suppose also that we can discover a one way function S with an associated function (not necessarily one-way) P with the following property. If we apply the one way function S to Private and the function P to Public we create a new public/private key-pair, i.e., S(Private) is the private key associated with public key P(Public). If we could find such suitable functions we could design a cryptosystem with the requisite properties.
Every time a fixed interval of time passes, say an hour, Bob applies the one-way function S to Private storing the new result and forgetting the original key. Thus after 1 hour Bob has the key S(Private) after two hours S(S(Private)) and so forth. Now when Alice chooses to send Bob a message she chooses for what period of time Bob is capable of authenticating that message. If she thinks he will read it immediatly she might choose an hour, if he is out of town perhaps a week. After composing the message Alice computes some sort of signature/authentication (Ring signature etc..). Now alice computes the number of hours that will have passed between the creation time stamp of Bob's public key and the time her authentication period ends. She then applies the function P to Public once for every hour and uses the result to encrypt her signature. She then appends the encrypted signature, and the unencrypted time it will expire to the message and sends it to Bob. If the communication is to be secret she could then encrypt the entire message authentican and all with her favorite encryption scheme.
So long as Bob recieves the message from Alice before the authentican period has ended he has no trouble decrypting the authenticating signature. Bob simply computes the number of hours from the current time until the authentication period ends, applies S to Private that many times (not forgetting the current value of private in this case) and uses the result to decrypt Alice's authentication since the properties of the functions guarantee this is the corresponding private key to the public key alice used for encryption. Once decrypted the signature authenticates Alice's message and then is discarded by Bob (If a ring signature is used Bob can create the same signature at any time if he has the message plaintext so has no incentive to keep the decrypted signature).
However, once the
Re:Deniable until they look at your swap partition (Score:1, Interesting)
It's useful when you want everything to be secure, not just specific things done by a specific piece of software.
There is a standard system call for forcing memory to be in-memory only, it's called mlock(2), but it requires privileges and can fail. It's not a good thing for programs to rely on. If enough programs use it, the system will start behaving pretty badly.
Another simple alternative to encrypted swap, if you have enough RAM, is not to have any swap.
Shades of grey (Score:3, Interesting)
But that's not how security is! It's all shades of grey, and the darker the shade of grey, the worse off things are.
Nothing is ever bulletproof, and seldom is anything ever wide-ass open to the world. It's somewhere in between.
I have a remote-desktop package integrated with one of my apps. It makes for very easy tech support, and I've got it built right into the menu system of my most popular application [effortlessis.com], so that customers using my software package have access to instantaneous, high-quality tech support.
To prevent users from popping up on my development system anytime they have a question, I put a password in place. It requires a small, 4-digit numeric code, and it changes every day.
By slashdot standards, this is terrible security. It's numeric. No letters, just numbers. The code changes every day, but only based on the day of year. It can easily be predicted, if one has any understanding of the underlying, otherwise very simple algorithm used to guess these numbers.
Anybody with a packet sniffer could crack it with one support session.
But, in this case, it really doesn't matter. The worst that will happen is that your computer's desktop will appear on my screen without my Windows VM.
You could DOS me with 10,000 VM screens, but it would take a very short amount of time for me to block the port number for the VPN and kill that.
So, what's the purpose for improving security? It's secure enough. And that's the point. Many people around here will have a cow if something is potentially crackable, while sitting behind physical locks that can be compromised with an expired credit card.
Gosh! Somebody could pull out their credit card, slide it through the gap between the door and the jamb, and break into your home!
In a black/white world, your home would only be considered safe if it had 1/4 inch steel plate exterior, and locks that the NSA would have serious trouble with.
In the real (shades of grey) world, a deadbolt and a solid-core door is usually good enough, and people live with the odds. Heck, even in the worst ranked neighborhood, you have about a 3.5 to 4 percent chance of getting burgled in a given year. (http://www.ojp.usdoj.gov/bjs/glance/burg.htm) I almost never lock my back door, and I've never had a problem with it.
That's good enough security for most, as evidenced by the fact that the most important issue was national security or "the war in Iraq" in the recent election. (http://www.rasmussenreports.com/Issue%20Clusters
Notice that individual household crime isn't even on the list (unless you include the 6% "domestic issues", despite the relative insecurity of the average home.
Brought home to me by the book "Secrets and Lies" by Bruce Schneier, this world is not a black and white world. Relative risk must be evaluated, and the equation must be brought to something we can all live with.
PS: Link to sites with A tags appears to be broken on slashdot. I tried numerous times to post links to the aforementioned sites and could not do so.
Re:a little information would be nice (Score:3, Interesting)