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."
My foolproof encryption method (Score:4, Funny)
Just need one other thing (Score:4, Funny)
It's called Anonymous Coward (Score:2)
Re:It's called Anonymous Coward (Score:2)
Re:It's called Anonymous Coward (Score:2)
Or at least no mention of being able to anything but deny them, in the parent^3 post.
But, that is a neat idea, having /. keep the posts you ticked to post anonymously under your list of posts...
Now if you can figure out a way to submit such a request without it being summarily rejected...
Or maybe I'm just bitter...
Re:Just need one other thing (Score:3, Funny)
If anyone asks, I'll cryptographically deny this new meme.
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:2)
"Your honor, there is no way to prove that this kilo of cocaine came from my car. It's just the officers word vs. mine. Someone's framing me."
It's a matter of degree (Score:2)
To use the cocaine example, imagine that in one case, the cocaine had your prints al over it and had a picture of you holding it. In another case, there's a kilo of coke in your trunk that doesn't have any prints or any other indications that you ever saw it in your life. If you go to court for having a kilo of coke in your trunk, you'
Re:It's a matter of degree (Score:2)
Re:I hope the distros will do their part (Score:2)
Right. Because the word of a defendant at trial is worth a lot. (That's sarcasm, for the record).
The word of an officer almost always carries more weight than that of the accused. I've never seen anyone get out of a ticket for rolling through a stop sign just because the only evidence was the testimony of the cop.
I wonder (Score:4, Funny)
"Did I just say that I'd walk the dog?"
"Yes!"
"Nobody can prove that I just said that."
Re:I wonder (Score:5, Informative)
Re:I wonder (Score:5, Interesting)
Re:I wonder (Score:4, Interesting)
Re:I wonder (Score:2)
They could then collect the plain-text and log the IP address from whence it came.
Re:I wonder (Score:2)
Rockstar Cryptographers? (Score:4, Funny)
Chris Mattern
Re:Rockstar Cryptographers? (Score:2)
a little information would be nice (Score:2)
Re:a little information would be nice (Score:5, Informative)
Then, messages sent during that conversation are encrypted using disposable session keys. (128-bit AES w/SHA-1 HMAC).
Think of it as an authentication tunnel down which you send encrypted messages. The message encryption is in no way related to the authentication, and the disposable session keys mean they have no re-use value.
-Charles
Re:a little information would be nice (Score:2)
I presume this has something to do with that authentication tunnel , but I'm not really following it. Do you understand it?
Re:a little information would be nice (Score:2)
If big brother gets your MAIN key, he has no way of recreating the SESSION keys. Those are created using key info from the person you are chatting with as well. Without those, the messages are now subject to brute-force.
NOTHING is perfect. If your machine is compromised BEFORE you start the conversation, it would be possible to get everything and crack it nicely.
Hmmm...I do wonder about how hard it is comparitively to cryptanalyze ultra
Re:a little information would be nice (Score:2)
Its not explicitly mentioned, but "forward secrecy [atis.org]" implies that the session keys change at some point, though it may not change within a single communication. (If Key A and Key B always created the same SessionKey S, then compromising Key A or B would allow an attacker to reveal S (for all past sessions as well) when they talked to each other again.)
Re:a little information would be nice (Score:2)
* * *
If the MAC verifies, decrypt the message using the "receiving AES key".
Finally, check if keys need rotation:
- If the "recipient keyid" in the Data message equals our_keyid, then
he's seen the public part of our most recent DH key pair, so we
securely forget our_dh[our_keyid-1], increment our_keyid,
Re:a little information would be nice (Score:3, Informative)
The key seems to be the "disposable key" part.
With normal public-key crypto, you sign with your actual private key, and you encrypt with the recipients actual public key. This means that if someone gets hold of the recipients private key, then can decrypt the messages, and because your public key is, well, public, they can prove that you wrote the message.
In this system, you generate throw-away keys, and exchange them securely when you start communicating. After you are done communicating, you can just
Re:a little information would be nice (Score:2)
I have trouble following it myself.
Re:a little information would be nice (Score:2)
Well, there were a bunch of links, honestly I didn't follow them all. I was looking for a "how does it work" explination, not a protocol document. Now I've looked at the protocol document and all I can say is: How does it work? I'm hoping for one or two short paragraphs that can get across the basic concept, not a dozen or more screens of protocol information to try to
Re:a little information would be nice (Score:5, Informative)
Thus, I can create a key that I send to my friend. He and I discuss things, both using that key for encryption. When we've finished, we publish the key used for the conversation, and anyone can now add to the conversation. Thus, while we keep the key secret between us, we're assured of a private conversation; when we publish the key, anyone can add to it, thus giving the denability
Re:a little information would be nice (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.
Gaim should support standard compliant encryption (Score:2)
Re:Gaim should support standard compliant encrypti (Score:2)
I wonder (Score:3, Funny)
Big brother doesn't need proof (Score:5, Insightful)
Deniable until they look at your swap partition (Score:5, Insightful)
Re:Deniable until they look at your swap partition (Score:2)
If you're using gaim, chances are high that you're also using linux. There's no rational reason to be using a swap partition on a linux desktop, what with the price of RAM these days.
Re:Deniable until they look at your swap partition (Score:2)
Mac OS X 10.4(i believe) will support encrypting the swap file, and is going to use ACLs to boot. Linux is surely capable, I would assume.
WTF? (Score:3, Informative)
Besides, swap in 'nix isn't used unless you need to. Most of the time my laptop (256MB RAM) doesn't run into swap at all, so chances are I don't have to worry about that.
And as to the temp files, etc... if you do have the RAM to spare and you're really paranoid, mount a nice big 512MB ramdisk on loopback and a quick rebo
Re:Deniable until they look at your swap partition (Score:2)
Re:Deniable until they look at your swap partition (Score:5, Informative)
encrypted swap. quick and simple in linux. HOWTO (Score:3, Informative)
PS: Your computer will not operate any slower than when using plain swap. I kid you not.
PPS: this works in mandrake and suse.
make sure module cryptoloop is loaded:
> modprobe cryptoloop
assuming you want to use
>losetup -e aes256
if
Re:Deniable until they look at your swap partition (Score:2)
Worse than that, HD data overwritten is still recoverable if someone had enough cash, like say the FBI.
How to really wipe a HD [slashdot.org]
The only way to guarantee The Man can't get your data is to melt down your drive.
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?
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:how about dual-plaintext messages? (Score:4, Funny)
They see what you are 'hiding' and maybe laugh in your face
There's a joke in there somewhere, I just know it...
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:how about dual-plaintext messages? (Score:5, Funny)
Re:how about dual-plaintext messages? (Score:2)
Re:how about dual-plaintext messages? (Score:4, Interesting)
Re:how about dual-plaintext messages? (Score:2)
and such?
Re:how about dual-plaintext messages? (Score:4, Interesting)
Re:how about dual-plaintext messages? (Score:2)
With this thing on your computer, you could give them the fake key, and in a couple of days they'd figure out that you've got the phonebook userspace tools on there and realize they've been had.
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
Rubberhose Cryptanalysis (Score:2)
Re:how about dual-plaintext messages? (Score:2)
But if you are, the simplest approach is to encrypt all messages in a double-length mode. When sending an innocent message, one not requiring the double-encryption feature, it gets encrypted as usual, and gets paired with a random stream of noise data, o
Re:how about dual-plaintext messages? (Score:3, Interesting)
http://groups-beta.google.com/group/sci.crypt/msg
Re:how about dual-plaintext messages? (Score:2)
Yes. Sort of.
http://truecrypt.sourceforge.net/ [sourceforge.net]
http://www.security-forums.com/forum/viewtopic.ph
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
Re:how about dual-plaintext messages? (Score:2)
(Correct me if I'm wrong, but) one-time pads provide complete deniability, because any any encrypted message could produce any decrypted message, depending on the pad. It would be impossible to prove what your message really was.
One time pads are usually too inconvenient. There are also 'rubber-hose' proof encryption systems, where the encrypted message includes empty space. Each key provided reveals more of the decrypted message, but it i
Re:how about dual-plaintext messages? (Score:2)
Re:how about dual-plaintext messages? (Score:2)
It's called chaffing and winnowing.
Pretty much, each cypher block is signed. If, during decryption, you see an invalid signature, then you ignore that block.
Now, when you encrypt, you (randomly) multiplex the blocks of your super-secret message, several dummy messages, and many random blocks.
It's obvious that your system does this. That's why you include several dummy messages (make 'em plausible!) and also many random blocks. They can demand another key all they want, but they have no way of telling
Re:how about dual-plaintext messages? (Score:3, Interesting)
Re:how about dual-plaintext messages? (Score:3, Insightful)
An excerpt:
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?
Comment removed (Score:5, Interesting)
Re:Excellent! (Score:2)
It's called "constructive possession" (Score:2)
It's called Constructive Possession [law.com]. It's the same as when the cops find drugs stashed underneath your mattress. Because you are in control of that area, the drugs might be deemed yours. It doesn't matter that you weren't caught with drugs actually in hand (Primary Possession).
If many people have access to the computer, it may be difficult to apply construc
Re:it's called REASONABLE doubt for a reason (Score:2)
My point was that the output cannot be trusted or verified. For example, how would a prosecutor display the output of a key logger to the jury? With printouts. Those printouts could have been created in any number of ways...they are not indisputable proof of anything.
Example: a message was sent by some device at some IP address at some point in time. Where's the proof that it was me sitting at my desk typing on my computer? Why not someone sitting out in the street using my WiFi c
prosecutors don't have to prove 100% (Score:2, Insightful)
Before DNA typing, people were convicted of rape based on blood type, sometimes-foggy eyewitness accounts, supposed motive, a personality type that "fit the profile" plus lack of an alibi. Many of these people were in fact guilty. While we've come a long way with DNA, other crimes
Re:it's called REASONABLE doubt for a reason (Score:2)
Proving it MIGHT or COULD have been me != proving it WAS me.
But that isn't the standard of proof, even in criminal trials in the United States ... because as you note, it is impossible to "prove" that something happened to someone that wasn't there. The standard of proof in a criminal trial is "beyond a reasonable doubt", not "beyond all doubt". Saying "The gubmint done framed me", for instance, without compelling proof of your assertion is generally insufficient to create reasonable doubt.
For insta
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.
Re:This is great... (Score:2)
If you assume a benevolent government, then you don't need it. There are plenty of people who don't.
Re:This is great... (Score:2)
"I didn't say it. Someone else must have forged it," won't stop you from being dissapeared, but it'll go a lot further before a tribunal and get you more help from the U.S. embassy there than "Yup. It was me what done it."
Plausible "yeah right" (Score:5, Insightful)
a) created a plausible deniability capable link; and
b) intentionally released the key to said link so that someone else could impersonate you later.
Frequently all that's needed is the fact that you communicated with somebody for evidence - not the specifics of what you said. Sure maybe you just called them up and did some heavy breathing down the line - there's no proof you actually _spoke_, but any jury in the world would convict you.
Of course you work around that by creating a new link every hour to the same person, and maybe or maybe not using it - but it still shows you're in communication with them. There's no way around that.
Nice idea, but don't think your child pornography dealing down this link is going to somehow get you off the hook.
Re:Plausible "yeah right" (Score:2)
Martha Stewart went to prison based on what she communicated with her stock broker, not that she communicated with him. I'm sure both parties there would've been happy to have a bit of plausible deniability.
This is a tool with a very specific purpose, and its unsuitability for other purposes doesn't make it worthless. I can't drive a nail with a cold chisel, but that's not a f
Perl-ize this with that 25 line P2P (Score:5, Funny)
Ah... so that explains this IM conversation... (Score:3, Funny)
SBallmer: Yep, sure did. And we even explained the need for us to buy one of their licenses for unlimited computers. You know, for our in-house independent benchmarking company. You know, the whole "Get the Facts" campaign?
BillG: I see... but this SCO thing doesn't look like it's going to work. We need to go after them in even more indirect ways to avoid more antitrust sanctions. With Ashcroft gone, we may get a harder wrist-slap than last time.
SBallmer: We're already getting the puppet companies set up now. They have applied for tons of patents that could destroy Linux. We simply buy a perpetual license to all patents for a cool billion, and we're set.
BillG: How can companies apply for patents that already exist in Linux? What about prior art?
SBallmer: Don't worry, there's plenty of critical new or rewritten code since the patent applications that violates them. We've even guessed what Linux might add in the future, and patented that as well!
BillG: But if those lawsuits fail.. then what?
SBallmer: Well, we're working on getting the GPL ruled illegal. We're also going to deal a blow to all open source operating systems by our deals with bios manufacturers to only run operating systems who have paid their license to get the code signed. (Don't worry, they listen to our piles of money - if they obey us, they money keeps coming)
BillG: So, you want the computer to be like an xbox, then? We might want to start drafting legislation for mod chips to prevent people from using linux.. er.. pirated copies of windows longhorn without the subscription/expiration feature. After all, we don't want people to use windows without paying their subscriptions...
SBallmer: Already in the works. Prebought PCs will include a 3 year subscription to Longhorn Home/Crippled Edition. After this 3 years is up, the people buy a new computer rather than renewing their license (for an old computer, mind you) for another 3 years. The money from Intel and Dell is already pouring in. We can't allow mod chips because people would just use that to load the Corporate Edition.
One Really Good Use (Score:4, Interesting)
I gotta have it.
Re:One Really Good Use (Score:2)
Besides, at the end of the day, if an attorney has to "give up" his client's secrecy, the court isn't going to bother with logs and taps - they're going to ask the lawyer what he was told, and if he doesn't fess up, they'll throw his ass in jail for contempt.
OTR GAIM is not goi
holy grail of file sharing (Score:4, Funny)
This is great! (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.
So is this like... (Score:2)
2) Immidiately post your CC number to the net.
3) In amongst other potential charges, deny that you made any of them.
4) Profit!
How fsking long would it take.... (Score:2)
Timing Could be an Issue (Score:2, Interesting)
Killer! (Score:2, Funny)
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:Potential problem with this (Score:2)
What it really protects you from is the case where, later, your boss forges messages and says he sent them TO you... or forges messages he says came FROM you; in either case you can claim that the conversation had already ended and it was indeed a forgery by someone else because the key was then openly available.
It is a subtle, but impo
Re:Potential problem with this (Score:2)
This is a good thing? (Score:2)
Suse?? (Score:3, Interesting)
Anyone gotten it to run compile/run on Suse 9.1?
GAIM Encryption (Score:3, Informative)
gaim encryption [sourceforge.net] uses RSA. There's also gaim-e [sourceforge.net] which uses GPG.
I've used gaim encryption and it works very well. It requires the plugin to be installed on both ends but once that's done, it autodetects that both ends support it and enables encryption.
Oh, there's a binary available for windows and both source and packages for linux.
And, it's in portage!
emerge gaim-encryption
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
LOL, implement this in Bit-torrent and gnutella (Score:3, Insightful)
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:FP (Score:3, Funny)
Or is your FP plausibly deniable? ;)
Re:Dammit! (Score:2)
really... (Score:3, Insightful)
With that in mind i still don't see how anyone could forge any packets from me without knowing my key.