Encryption Key Retrieval Method Invented 218
try67 writes "ZDNet has this article discussing a method developed by several scientists (including Adi Shamir - the S in RSA, the guy who later found a way to crack RSA, GSM alg. cracker, and all-around very cool guy) of finding and stealing encryption keys from servers. The key's randomness seems to be what's giving them away." This is an interesting piece, but why do people continually feel that my credit card number is the most valuable piece of information I own? There's more than e-commerce at stake, people.
Hyped problem? (Score:1)
If someone has access to the filesystem with the key, that's the problem that should be fixed.
Of course, if you website is not secured, slapping SSL on top if it won't help.
ancient news (Score:1)
Second of all, this was reported almost a year and a half ago (Sept 22, 1998)
http://www.nciph er.com/products/files/papers/anguilla/keyhide2.pd
Re:A threat (Score:1)
Shit, he's on to us. Okay, I admit it, I was in on the decision. Me, Rupert Murdoch, Ted Turner, and a half dozen other media biggies had convened a meeting. We were in a dimly lit room, each resting in a leather-upholstered chair, smoking cigars, drinking cognac, and trying to answer the question: "How can we stick it to the geeks?" We spent hours debating the issue. We considered dozens of solutions - chain gangs, death camps, insanely high taxes on twinkies and Jolt, but none of these things really seemed satisfying. Finally, Ted had an idea: we would begin using the word "hacker" to refer to computer criminals, until it had thoroughly negative connotations in the ears of the public. Everyone praised the elegance of this plan, and thus, the matter was settled.
Re:An Old Problem (Score:1)
Re:There is an easy solution to this (Score:1)
The bigger issue I see (and thought about alot during some fairly large e-commerce projects I worked on) is SSL certificate compromise, and what that could do to a business long-term. These certificates don't expire all that often. Once one is compromised, that should make the domain name they are associated with useless for e-commerce until the compromised certificate expires. If you have alot of money invested in branding your domain name, this can be a very big deal (imagine amazon.com getting their certifcate compromised, for example).
Now, all the big boys do protect their certificates like the formula for coke. But what about those aspiring web sites? A hacker could gather up certificates for many of these sites, wait for one of them to become the next e-bay (it seems you only have to wait a few months these days), and then start masqerading as them on the web, successfully, because they have that site's certificate. While they won't likely steal much before being found out, that e-company is RUINED in a day!
Moral: If you don't mind that your domain name may have to change (or go unused for a few years) after a compromise of your server, go ahead and put your SSL keys right there on the server (in memory or disk, its just a matter of degrees of difficulty after that). If you think that domain name is valuable to you, invest in some crypto hardware. You'll sleep better.
The sound of money (Score:2)
mp3 the sound of money:
mpg123
the RIAA way:
mpg123
Making a cach advance:
cat
Fraudulant use:
cat
Using windows:
su
watch cat
Windows 2000 promotions:
ln -s
cat
Re:Easy Solution (Score:2)
Interest (Score:1)
Having a credit card number stolen is a worry, but not a great one. The price of the stolen goods goes into creating those high interest rates (along with greed) because the individual card holders usually refuse to pay for unauthorized purchases. If a customer's card gets cancelled over it, there are plenty of other credit card companies to step in for the old one.
Don't panic (Score:2)
http://www.nciph er.com/products/files/papers/anguilla/keyhide2.pd
appears to be a better search algorithm for finding keys in already-compromised media. Anyone relying on a strange filename or a full disk to hide their RSA keys now has even more need to worry
This is not a new "break", it just make security-through-obscurity even less obscure/secure.
Re:Who cares about cDc? (Score:2)
Oh, and I don't suppose you'd know about those 500+ textfiles they've written (dating since circa 1984, since those aren't mentioned on CNN.
The NSA key in Lotus Notes is a back door. (Score:2)
I have been paying close attention.
--
This algorithm has been known abut for a while (Score:4)
By the way, Adi Shamir (and Ron Rivest, for that matter) have done a *lot* more crypto work than just RSA. Shamir is one of the inventors of differential cryptanalysis (along with Eli Biham).
--
Big deal (Score:2)
Storing secret keys on an accessable server is stupid anyway. If someone roots the box, they'll just use your software to do the decrypting for them.
The correct procedure is to store the public key on the web server, and have it send the encrypted data to a private server behind a secondary firewall. THAT server is the one with the secret keys. The second firewall should choke off all but the port used to transfer the data.
The same people who will be deeply worried about this will freely hand their card to a waiter (who will disappear for several minutes before returning with card and reciept) or read out the number for a phone order and won't think twice about it.
So what? (Score:1)
I wish I could still moderate... (Score:1)
Personally I believe you are fighting a loosing battle. The hacker community doesn't want to be labeled like criminals, so they try to push a new usage and a new word cracker. Obviously the population as a whole and mass media didn't accept this, despite the rant campains and possibly some write-ins to the journalists. I do still believe that criminal should be an adjective for hacker, where hacker really shouldn't be an assumed criminal, so I do agree on that point.
This Is A Non Hack (Score:2)
What's been discovered is a method of, independant of the file system and various configuration files, extracting a key based on the difference between that key and the surrounding ambient randomness.
Independant of the file system?
How, exactly, is the web server supposed to retrieve the private key without a file call? Perhaps it should reference a specific block on the hard drive, and read x bytes from that location? Oh, oops, now we've got a "big deal" of a security breach in our web server configuration files.
When I first read this, I had assumed they discovered a method by which the private key could be divined by remote interrogation of the server side provided challenge. That's not what they discovered. They found a way that, given a hard drive with every single file cataconcated together with no indexing system available, they could still find zones likely(but not guaranteed) to represent private keys.
Anyone here have a hard drive like that?
This is *cool*, from a geek sense. I appreciate the value of the research. But it's so far from a big deal, it's ridiculous. It's one thing to say that shared servers increase the risk of having your private key stolen--I'd *hope* that the keys of one customer are isolated from the owners of another--but this specific worry is just...inaccurate. Cool tech, but not something to have your blood pressure increase over.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
This is bad... (Score:3)
Think for a moment. Say you had a fleet of ultra-quiet submarines. You know that your enemy can track them if my looking for unusually quiet spots. So, what do you do?
The answer: surround their fleet. Cancel out the ambient noise, so the quiet spots can't be picked out. It's the opposite of creating noise to cover noisy submarines.
Therefore, one answer would seem to be the creation of many "dummy" keys on the server. They're generated just like the "real" key is, so they're just as random. Thelocation of the "real" key then becomes a closely-guarded secret, of course, as much so as the machine's root password.
Consider that the strongest keys out there are only 4K. This means that creating 1000 dummies only wastes four megs of space; in an age where it's hard to find drives less than twenty times that size this isn't really that much of a space-waster.
The best solution would be a completely-encrypted filesystem. Then there would be no way to tell the key from any other data, and even if you could it would be useless. Are there any good fully-encrypted filesystems out there yet? Linux-compatibility would be a plus...
Cracked RSA? (Score:1)
___
OK, OK ... (Score:1)
All a hacker would have to do, Hopcroft said, is set up an account with an Internet service provider hosting a company's Web site, "go into that server and root around looking for the keys of other companies. With [the key] there is no way for me to be distinguished from a legitimate business owner."
OK, that's funny. I hope that any ISP that leaves secret keys around w/ out proper permissions (ones denying Joe-Other-User from my critical information) and w/out a properly long passphrase (in the case of SSL certificates) would not even be in business. Private Keys are something that you keep properly protected. And if someone gains root access you are screwed. They will find the key, not because of the randomness, but because they now have complete control of the system. Once someone gains root access, there is not much you CAN do to prevent them from getting the key.
Re:Why not just look for the credit card numbers.. (Score:1)
There is an easy solution to this (Score:1)
You also must introduce randomness to the credit card data before encrypting, because the regularity of credit card numbers allows a cracker to make a known-plaintext attack.
I've been dealing with security and encryption with e-commerse for about two years. Anyone who would set up a system like that discussed in the article is a rank amateur and a fool.
The article is a bunch of bullshit.
Re:There is an easy solution to this (Score:1)
The article appears (at least to me) to be refering to public key encryption, such as used in PGP. These protocols make use of asymetric algorithms, which require two unique keys - a public and private. You can encrypt messages with either key, but you cannot derive on key from the other.
The key to security here is having only the public key available on a system connected to the Internet. While you still must guard against sideband attacks, this makes a brut force attack against the crypto infeasable.
Yes, I am suggesting that the data is re-encrypted and passed to a secured vault server. And yes, it is a very, very good idea.
How is this different from what the cDc does? (Score:4)
When a group of respected scientists point out a security vulnerability, they're the good guys, for pointing out a vulnerability that 'hackers' might exploit.
Well, I guess that's fair.
It often is (Score:2)
All in all, if you have some piece of plastic that can hand out your money, you should know the liability rules and what protection you have on that piece of plastic.
Cheers,
Ben
Consumers are not really at risk here (Score:3)
This is why credit card companies put so much energy into keeping profiles of consumers, and will yank your card as soon as you no longer fit your profile. It is also why banks love debit cards - since they are drawn directly on your bank account, there is no limit on your liability risk.
Just another right that people have and don't appreciate...
Cheers,
Be
A threat (Score:1)
TomG
Re:A threat (Score:1)
Re:A threat (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:I wish I could still moderate... (Score:1)
TomG
Re:A promise (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:I wish I could still moderate... (Score:1)
TomG
Re:A threat (Score:1)
Re:A threat (Score:1)
TomG
Re:A promise (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:What's sauce for the goose... (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:A tirade. (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:A threat (Score:1)
TomG
Re:A threat (Score:1)
Re:I wish I could still moderate... (Score:1)
TomG
Re:Check cards bad (Score:1)
I've had to tell my bank twice that they do NOT have my permission to issue a credit card that comes out of my account.
I don't know where the idea came from the "check cards" are in any way superior to credit cards... it's completely wrong. A check card is both more risky for the reason you state, and more expensive because you pay right now, not 30 days later with no interest.
Re:Easy Solution (Score:1)
Use a credit card, you will out $50 (at most, generally 0) if it is stolen, and your house payment won't bounce.
Re:e-com vs. phone order (Score:3)
Think about it. You're just handing your actual credit card to someone you've barely met. They may take it across the street and buy a TV for all you know, or they may just decide to keep it.
Re:Check cards bad (Score:1)
Re:Easy Solution (Score:3)
An Old Problem (Score:5)
why steal the key? (Score:1)
As you have root access (you can read the key, can't you?), let the server decrypt it for you, and then send you the information that you want. This would uncomplicate things greatly, as you don't have to spend any of your own time decrypting/parsing the info.
Then, once you have the info that you want, have it send the stuff to you in a packet that appears to be, say, a spoofed SSL packet going to a client who's coincidentally wandering around the site looking at stuff at the time, and thus get all the CC numbers you want without anyone knowing, given that the packets that your hack on the server sends you look normal, you don't use it too much on one server, you clean up your footprints, make it look like your attempt failed (ie, continuing to look for other holes), and tell no one.
bogus security model (Score:3)
If you want your keys to be secure, the system that keeps them has to be physically secure and secure against unauthorized logins because at some point, the system will have the plain text keys in memory somewhere.
Of course, the whole thing is an attempt by nCipher to drum up business--they want to sell their "nCipher hardware". If you use a cryptographic accelerator that also performs the key management, you are a bit safer, because most of the time, the keys are available only inside the accelerator, a device that is probably harder to "break into" than the whole server. But nCipher's solution is still vulnerable because you communicate with the encryption box over the web and the web client you use could be attacked.
The best security for your keys is likely to be achieved by using a crypto accelerator for which the key is entered physically at the box (e.g., via a SmartCard or keyboard), or for which you physically connect the box to another, non-networked computer while performing key management functions. Lots of products besides nCipher's are capable of that.
Re:An EASIER METHOD to GRAB encryption keys... (Score:2)
But two things pop into mind right now.
#1 - is that of course things are going to mess up if the systems are insecure in the first place.
#2 - this whole thing was brought to ZDNETs attention by a company that clames to have hardware solution for this "problem"... Does that say anything to you? Maybe this was more of that companies advertising effort and less of its general research.
So really... who cares, is what i think. If the servers ARE secured, then the keys aer safe. If they aren't, well then, the keys could have been subsitituted... It's just how pararnoid do you want to be?
Re:Another way? (Score:2)
Re:This is bad... (Score:2)
So far as your encryped filesystem goes... NTFS 5.0... unless, of course, it's been cracked already
Question (Score:2)
Likewise... I doubt (and hope that not) many of the major e-commerce sites keep their complete key pair on the same machine... Likely, they'll have a cluster of webserves with read only access to the products database, and write only to the orders database. those machines don't need to know what the data that they're passing back and forth is, they just need to get it from the server to the client.
Re:[OT]Is it time for Slashdot to quit beng a ".or (Score:1)
Re:Q: e-com vs. phone order? A: cyberterrorism (Score:1)
a) The banks do not cover the charges in most cases and especially not in cases where a magnetic swipe is not take (i.e. ecommerce and phone orders ). In these cases if it's the merchant ends up eating the cost of the charge because the bank takes the money back.
b) The banks/processors get a small fee for every transaction on top of the percentage. They keep the fee and the percentage whiel dinging the merchant for the entire cost of the charge when they only deposit the net amount after fees. This fee is around 12 cents a transactions for Visa + approx 3%. So assuming someone stole a million cards and ran just one transaction on it. Visa just made $120,000.00 off of fraud and that's not even taking into consideration the percentage.
c) On top of the fee to run the transaction there is normally a fee for handling the fraud process (known as a chargeback). A low for this fee in the market is $5.00 and I've seen it as high as $15.00 per charge. Which would mean as much as $15 million in revenue off the fraudulent charge.
d) Before most chargebacks mentioned above are run a retrieval request is also issued. This is normaly also a $5.00 - $15.00 cost.
The only time the credit card companies are risking anything is if the merchant goes out of business. Which is highly unlikely since most people who steal cards spread there fraudulent activity around.
So frankly I don't think the card companies have any incentive to solve the problem. Merchants are always the people left holding the bag.
There is no discovery here (Score:2)
The key is to keep people from getting access to the server - not to claim that there's something wrong with the infrastructure because it's possible to compromise something outside of it.
Re:There is no discovery here (Score:2)
Motivation behind this "discovery" (Score:2)
Translation: nCipher decided to make you paranoid about storing your decryption key anyone on your hard disk, so you'd store it with nCipher's hardware solution instead. *Very* thoughtful of them.-(
If I understand this "vunerability" correctly, the approach is to read every block on the hard disk, looking for sequences that are unusually random. Is this supposed to be more effective than looking for strings around the words "decryption key"?-|
Excuse me? (Score:2)
One piece disturbs me:
All a hacker would have to do, Hopcroft said,
is set up an account with an Internet service
provider hosting a company's Web site, "go into
that server and root around looking for the keys
of other companies. With [the key] there is no
way for me to be distinguished from a legitimate
business owner."
Is it just me, or isn't this another "well duh". If you have shotty administration and security you are going to have "hackers" breaking in and "root[ing] around". The only revelation that this article seems to make is that poor administration, poor implementation, and shotty security go hand in hand. Anyone who has been in the ISP or hosting business knows this for a fact.
It all comes down to 'buyer beware' - and if the consumer doesn't heed that then they are at fault.
Re:Consumers liability problems (Score:2)
scaremongering (Score:1)
Please people, actually read the stories that are posted and don't just accept some bloke interpretation. This story wasn't worth posting.
Thank you.
Jonathan.
Re:SO avoid the randomness? (Score:1)
Re:This is real (Score:1)
Re:This is bad... (Score:1)
Linux can encrypt filesystems (entire disks if you want). Check http://www.kerneli.org/ [kerneli.org] for more information and the required patches.
Re:YEAH RIGHT! WHAT A SCAM (Score:1)
Even if the memory is in actual memory, there are tools to scan the memory itself, all you need is the correct rigths.
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
I don't think that this is not as bad as it looks. (Score:3)
The vulnability described is a way to scan memory and finding a private key in the middle of it. Since most servers, even the NT ones :-), have strict security on who can run and who can access memory this would be no problem for most of the server.
The major problem I see is the virtual servers that hold many sites into a single machine. Every site owner have access to run programs in the machine, if those sites are not properly secured one site owner could be able to exploit some known hole to be able to scan memory is search for other site owner's keys.
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
Re:Information wants to be free (Score:1)
Certainly hard to find a key through what looks like valid executable binary code...
Re:Easy Solution (Score:2)
This is just evidence that you are probably no safer giving out your credit card info over the internet than you are safe from getting mugged in a large city.
This is a very good point. Just as I wouldn't stop going into the city and carrying cash just because I might get mugged doesn't mean that I might stop using credit cards online because I might have my credit information stolen.
Oh, wait. This wasn't your point at all. Sorry
Not a problem (Score:4)
As I'm reading this article, they are saying that once into a web server, it is easy to search for a key because it is more random then any other data on the disk. Wish I could get paid for these kinds of revelations.
The solution: don't let anyone into your web server in the first place. I would consider the web server compromised and the keys invalid if someone got in and was able to snoop where the keys were located. Even if you do allow shell access to the web server (a bad idea in my opinion), put the keys in a root read-only directory! I believe the setup instructions for mod_ssl says to set your SSL key as 400, therefore only root can read it.
This article is irresponsible. They make it sound as if your credit card is already at stake, not just after someone has broken into a web server and stole keys. It is not news that encrypted data is at stake after someone has stole the private key.
e-com vs. phone order (Score:4)
Plus, in both cases you don't know if the credit card information is being STORED properly. I've seen plenty of discount e-com setups that will have a fancy site certificate making it look secure. Then when the form is submited a plain text email gets sent to some email address so that someone can manually punch it in.
Re:Easy Solution (Score:1)
I've never seen one even offered for better than about 12%. Unless you're counting those deceptive ads that say 3% APR!!*
*For 3 months
Re:Easy Solution (Score:2)
reprocussions (Score:4)
Re:Consumers are not really at risk here (Score:2)
Not always true. Many banks now restrict your liability to $50 even on a check card (I know mine does), and just as with credit cards, many times will waive the entire liability.
If they insisted on holding you fully responsible for those debts, they would eventually lose customers. And to most businesses, that's a bad thing.
Is this news? (Score:5)
The fact that encryption keys can be found in data by looking for strings with higher entropy then usual is not new. I have heard it several times, and I believe that this was how the "NSA_key" thing in the Win2K source code was discovered (remember that, MS let NSA authenticate their own crypto modules and people started screaming backdoor). If I'm not wrong, its even mentioned in 'Applied Cryptography'.
The article says "root around looking for the keys", which I read as getting root to the server (I mean, who is going to keep code that contains crypto keys globally readable?) and that isn't exactly easy to begin with. And if your hosting server gets rooted your sort of fucked anyways...
As far as the big deal over Credit Card numbers is concerned, I couldn't agree more. I don't know about you people, but I operate under the assumption that my credit card number is always in the hands of others. I mean, the security of a credit card number rests on the fact that "no one can remember 20 digits." Obscurity would be an infinite step up.
Credit card numbers can be stolen by anyone who you shop at, anyone who goes through those shops or your trash, anyone who (with a little memorization training) is able to read your card, etc ad infinum. The whole system is based on the fact that credit cards numbers can be stolen but that its cheaper for the companies to take the loss then implement a smarter system. If that doesn't fit you shoe, then there is always cash...
-
We cannot reason ourselves out of our basic irrationality. All we can do is learn the art of being irrational in a reasonable way.
bogus article (Score:5)
/. should post articles of higher quality than this. This article is very clearly nothing more an ad for a company with a dumb product (I say dumb because there should be a better argument for its usage other than this):
Everyone here should know that "security through obscurity" is a foolish and invalid method of security. This article is particularly annoying with its "submarine" and "cold war" analogies as well as its mention of "increasing hacker ingenuity", as though finding a big file of encryption keys open to all users on a server is some high tech stealth technique from a Harrison Ford movie or something.
Re:Easy Solution (Score:2)
About 10 years ago I worked for Radio Shack, there was a POS update to remove the name and address on a credit card recipt. Just imagine how much someone must have had to cause the update, hell, the only thing missing was a social security number.
The only time I've been a victim of fraud was when I applyed for a mortgage, a month later someone was ordering Lands End and shipping it to Camden.
Information wants to be free (Score:2)
It seems to me that it should be possible to interleave the bits of the keys with a large quantity of non-random data, thereby masking its high information content. The trick of course is making the algorithm for which bits are real impossible to brute force. Unlike a one-time pad at least, only the server would need to know, e-commerce customers wouldn't.
If I read the article correctly... (Score:5)
Well, duh! Once I'm in, you have big problems. So, DON'T LET ME IN
It is not as though this is a new means to attack a server and gain access, just a way, once you have access, to find what you want.
And, if you store a bunch of data in compressed format (which also looks pretty random), then the search will be confused.
"The sky is falling! The sky is falling!" Any modern journalist.
Re:So keep your keys ASCII armored (Score:2)
Great, then some skript kiddie will use a tool to look for big-ish files filled with 1s and 0s (no other characters), and some st00pid news server will report it as another "huge hack."
---
Another psuedo-hack (Score:5)
Method #1:
* Crack into a highly secure server, likely behind a firewall (details left out, this part is easy)
* Apply heuristics and a random number searching algorithm on the hard drive (heuristics + classic compression algorithms such as LZW will work here)
* Use the keys to monitor transactions with this server and obtain credit card numbers
* Use credit card numbers to purchase online pron
Method #2:
* Get job at local store for approx. 1 hour
* Obtain tools: pen, paper, or a good memory
* Use tools to store credit card numbers
* Use credit card numbers to purchase online pron
The opening of this new method, number one (1), could be a serious threat to e-commerce. It makes e-commerce almost 1% as dangerous as physical world purchases! I know I'll never type https:// again and feel safe. I'm doing my purchases with complete safety: over the phone.
These guys know there stuff, where's the proof? (Score:3)
Alex Van Someren, president of nCipher in Cambridge, England, said the discovery of a method for retrieving encryption keys revolves around research conducted by his brother Nicko, chief technology officer and co-founder of nCipher, and Adi Shamir of the Weizmann Institute in Israel, co-inventor of the RSA encryption system, the base for much current encryption technology.
This story reads pretty credible, but I have to wonder where the proof is. The article does draw an interesting analogy about submarines making themselvs more and more quiet untill the only way to "hear" them was to search for the "hole" in the water. They say that this same kind of aproach was used to find keys.
This tmethidology seems logical, but it's implementation soes not. Does the reasercher point to his finished work?
_________________________
Re:Consumers are not really at risk here (Score:2)
It is also why banks love debit cards - since they are drawn directly on your bank account, there is no limit on your liability risk.
BZZZT! Wrong....
I used to work for a small retailer who did some mail order business. About once or twice a year we'd get scammed with a credit card. The customer would complain, and guess who got stiffed for $300? My store did. Not VISA, not Mastercard. They had no control over the transaction, and thus why should they bear responsibility?
This is the reason why many mail-order outfits do not ship goods to places other than the card's billing address... The card issuer controls that address, so it is slightly secure.
-cwk.
Re:SO avoid the randomness? (Score:2)
Re:Consumers are not really at risk here (Score:2)
Re:A threat (Score:3)
A hacker IS a computer criminal. Why? Because that's what most people mean when they say it. Words mean whatever people understand them to mean. There is no Official Definitive Dictionary of the English Language somewhere which inscribes in stone the true definition of a word.
Language eveolves and changes. Just as the geek culture took words from "standard" English and changed their meaning, the non-geeks took one of our words and changed it's meaning. We don't own the langauge any more than they do; their definition of the word is no more incorrect than ours.
Yeah, I know. Off-topic. -1
Re:Easy Solution (Score:3)
- Most people can get credit cards with 9.9% interest or less.
- Smart people pay no interest. They pay their credit card bills every month.
- The safest means of commerce is to give your credit card info out over the internet.
The safest means of commerce? Yes. You carry $100 on the street and get mugged, you lose $100 (as well as possibly your health or your life). If someone uses your credit card, however, you are liable for *at most* $50 in charges so long as you let the credit card company know.Furthermore, transmitting your CC# via SSL is more secure than giving it to a waiter or saying it over the phone.
SO avoid the randomness? (Score:2)
Original paper here. (Score:2)
Now we actually now what this is about. As far as I am concerned, the interesting application would be if No Such Agency sifted communications channels of a planet to find the keys. They can afford to do it if it's computationally cheap enough.
Re:Another psuedo-hack (Score:2)
So keep your keys ASCII armored (Score:4)