Slashdot Mirror
Plausible Deniability From Rockstar Cryptographers
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."
This thing sounds great, but before it is really useful it needs to be out there in sufficient numbers. I hope that distros will start installing it by default on their default gaim version.
Treehugger? Treehugger... Treehugger!
I really want a cryptosystem where I can enter, say, two different plaintexts (of similar length, I imagine) and then there are two keys: the private key, and the decoy key.
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?
Wonderful stuff if it does everything it is supposed to do. I can't wait to check it out.
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?
Not sure for _who_, but it's great.
;) Any place you need to be able to say "I didn't say that" later - where woulkd that be except a courtroom???
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.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
Comment removed based on user account deletion
What stops your correspondent from sending your messages to something like Stamper before you publish the temporary key? After the temporary key is published it will be possible to forge messages signed by that key, but it won't be possible without the collaboration of the timestamping service to forge messages signed by that key and dated before it's publication.
Is for folks in Law Firms. An option like this can permit a lawyer to communicate over the internet with a client in a secure way (because getting my client to go through the process of encrypting stuff with GPG is unlikely at best) ... but where intercepted be useless as evidence in court.
I gotta have it.
Trying to use sarcasm in text-based forums does not work.
What I would like to see is some kind of encrypted, p2p, email/IM replacement that doesn't rely on centralized servers. I realise what I've said is redundant -- P2P that doesn't rely on servers, but I'm trying to be clear. Messages would get routed through webs of trust, and if you lose your keys, you can have your new keys signed by people you know in real life. This would totally eliminate spam and ensure privacy and authentication for communcations.
Computers are useless. They can only give you answers.
-- Pablo Picasso
This is weak for the following reason:
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.
Messages sent _before_ transmitting the temporary session key are presumed to be authentic, while messages sent _after_ the temporary session key could have been forged. Not insurmountabe, but something to think about.
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?
My rights don't need management.
What about traffic analysis? What does it matter if you can deny it, when it's obvious that OTR traffic went from your IP to another?
The US government is at war with it's own citizens, that's the biggest reason for technology like this is set to become so pervasive.
With Stamper he can prove he received a message before a certain time. What he can't prove is that he hadn't already got the signing key at this time (as nobody will certify the time of the publication of the key). So while he knows these messages were sent by you, he can't prove it to anyone else, as he could have gotten the signing key first, then generated the messages and then send first the messages to Stamper and the key afterwards.
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. :-(
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.
I tried to compile it on Suse 9.1 and it crapped all over itself.
Anyone gotten it to run compile/run on Suse 9.1?
Wow, that was an interesting and clever paper. At the very end of the paper though they consider the situation with email. In particular the question is asked if an encryption system which works for an asynchronos system like email but doesn't allow outsiders to prove authorship is possible.
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
If you liked this thought maybe you would find my blog nice too:
Encrypting (using block ciphers) on modern CPUs is fast compared to disk I/O.
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.
One of the things that's particularly endemic to the Slashdot community is the "black/white" point of view - the idea that something is secure, or not, it's white or it's black.
_ Election%20Night.htm)
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, 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.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I'd imagine it's set up so you automatically give the key to the person you were corresponding with. So there's every possibility they could have written the message (supposedly from you) themselves.
I am trolling