Slashdot Mirror
512-bit RSA Key Cracked.
Alec Muffett writes "
On Thursday, a small team of people (including myself) announced the
world's first factorisation of a 512-bit RSA encryption key (aka:
RSA-155) - considerably bigger than the RSA-129 challenge of several
years ago, and this time performed by a small
cabal of numbercrunchers, just to see if it could be done in secret.
There are
press releases and
announcements available, as well as considerable discussion in sci.crypt.
" Read on for what Alec has to say on the matter.
This is a significant advance because such 512-bit length keys are
routinely used in (possibly ill-advised?) transaction protocols for some important
financial institutions (read: some serious $$$$$$$ may be at risk in
the near future) - and moreover, as a factoring contributor, I can state that I
personally have now been offered the use of additional hardware which
could take the 6 or 7 months spent sieving for results, and reduce the
time by a factor of some 40% to 60%.
What this trouble is about, however, is security. Not national security, but information security. On most UNIX systems, passwords are stored as 56-bit DES, and there's always a way that one can somehow get the password file, from which point it's almost always painfully simple to get a root shell. From there they can access any information on the servers, and if it's encrypted - and 512-bit RSA is pretty standard for such sensitive information - it's not too hard to crack that anymore, either.
I still feel comfortable in sending my credit card information to online retailers who use 64-bit RSA and the like. There's just too much information out there for someone to effectively snatch my info, and it's certainly more secure than using a phone or mail or whatever to send that information to them. What I'm concerned about is the information when it's on the other server.
As has been stated before, 1024-bit RSA and 128-bit blowfish are still plenty secure, and likely will be for a long time. I'm not concerned about my ssh connections being cracked. And, honestly, I'm not too concerned if someone else gets my bank information, since banks have insurance for my money (up to $10,000 anyway) and although it'd be a hassle for me, it's the one stealing the money who would eventually suffer, not me.
But my privacy isn't really something I clutch with my big guns blazing. It's a false premise anyway. I mean, hell, I even give Too Much Information on my slashdot user info, and anyone on the various MUCKs I'm on would have an easy time to find out anything they want about me. That coupled with many websearches and the like would easily find plenty of dirt on me, things I've done or said in the past I'm ashamed of but which I've pretty much put behind me, since it was before I decided to grow up instead of being a trite little punk hacker wannabe.
Though if you do find out enough, there's no reason to use it against me; after all, I do deserve my privacy.
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
But the BIG difference here is that 512-bit keys have been thought safe against all but (perhaps) Major World Governments, until now. What happens when some terrorists finally cotton to this, and realize that with some intelligent cracking, they could very well jeopardize the stability of, oh, say, the US dollar as a currency. An awful lot of bank transactions are secured with 512-bit keys, and (no reference here-- if anyone has real numbers, please contribute!) I believe something like 95% of US currency exists only as bits in computers.
So now, the situation is not that "someone will steal your credit card number," but that someone could potentially steal (or render worthless and nonexistent) >= 50% of all US dollars. That scares me. It ought to scare you too.
And obNote to those not residing in the US, or handling US currency on a daily basis:
There is no K5 cabal.
I am not the real rusty.
Unfortunatly, you are generally incorrect. You have suggested that one might enhance security by 'playing games' with the order and value of significant bytes of the message. Unfortunatly, this does little to enhance the security of the message. If one were to crack the key for such a message, (not knowing about the added measures) he would recieve a garbled answer, granted. Unfortunatly, de-garbling the message would only take man-hours (pencil and paper). It is no more complex than reverse-engineering the ICQ protocol. Simple attacks like dictionary files and statictical analysis of the generated char set would inevitably yield answers. Additionally, both sides of the encrypted transaction would have to know the mangling rules, and the other side of the transaction MAY NOT BE SECURE. Hence such measures are not terribly better than a public, well-known standard. Don't worry about looking like a super-model in an AI lab. (Inferior to the machine). I once wrote an in-house encryption routine that 'skipped' the DES routine around based on the text of my source. I figured since no one could reproduce my source (comments, etc) exactly, and there would be only ONE copy in existance, it would be relativly secure. It took two of my coworkers only a week to crack it (No binary, just a stream of encrypted messages in a known language), based on a distant known predessor and a shell script running on a DX4-75.
.sig: Now legally binding!
WARNING U.S. GOVERNMENT COMPUTER If not authorized to access this system, disconnect now. YOU SHOULD HAVE NO EXPECTATION OF PRIVACY By continuing, you consent to your keystrokes and data content being monitored.
The rules differ between systems, but every one that I have used has some punishment for unapproved system usage. Since the article said that they did this in secret, I assume that their work falls into the unapproved category. Although, SARA's website seems to indicate a fairly open view of their system. Who knows. I certainly wouldn't risk doing it on US systems that I have access to.
neutrino
History has the relation to truth that theology has to religion-i.e. none to speak of. - Lazarus Long
My PC would've helped, I guess it has to go on doing boring rc5-64 instead..
I'll bet US gov. will still maintain their stance on export of encryption technology.
Ahh - My eye!
The doctor said I'm not supposed to get Slashdot in it!
The announcement at RSA.
The top of the most active thread on sci.crypt at DejaNews
--
"L'IT c'est moi!"
Go here - http://www.salon.com/news/feature/1999/08/23/priso ns/index.html (No deep linking here, boss - just an URL)
Yeah, yeah, not everyone uses Linux or a UNIX with /dev/random. Well, for those people hard-up enough to use a system without such niceties, perhaps they can get a soundcard, a white-noise generator, and a textfile with pi to 1 million digits, Huffman-compressed. Total cost: $7 ($5 for the soundcard, $2 for a cheap AM radio with a headphone jack).
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
Perhaps I'm going to make myself look even more stupid, but here goes. If you are going to do encryption for one-on-one communications (like not in a web browser, and not on a large scale), I can't imagine much benefit from following a well-known standard. It would seem to be quite the contrary.
Onto the key subject, if they are factoring the public key, part of the answer would seem to be to contort the public key format you are using for your private communications.
Mangled keys, mangled messages -- that adds up to a non-standard format and you can throw in a non-standard delivery method (like not through SSL port #s). Hey, you're not going to be automatically scanned, decoded, and archived. Someone would have to decide that you are worth enough attention to pour the man hours and the money into figuring out your own private encryption standard. And if you aren't the only one contorting the standard in weird ways, if you aren't big fish, you are going to have some decent privacy.
I guess what I'm trying to say here is that if someone is using a web browser and server with 'heavy encryption' in order to send sensitive information, it can be considered 'light encryption' because the message format and delivery method is very predictable and can automatically be intercepted, decoded, and stored. If you are taking PGP keys and messages, contorting those around, sprinking the bits here and there in a mis-mash of things like GIFs and WAVs, and putting it on your web site or sending them via IRC, it'll take a lot of effort to put things back together.
True, not many are going to go to that extreme. But if those mega-encryption breakers are out there, they're going to be looking for messages that follow the standard delivery methods, and they're going to be geared for cracking messages following the standard encryption method.
The battle shouldn't be made in the key size. It should be made in the algorithm itself and the flow of data.
Advice from an encryption idiot. Take it FWIW.
> You have suggested that one might enhance
> security by 'playing games' with the order
> and value of significant bytes of the message.
> Unfortunatly, this does little to enhance
> the security of the message. If one were to
> crack the key for such a message, (not knowing
> about the added measures) he would recieve > garbled answer, granted.
I suppose part of it is at what point you contort the message. If you confuse the message before encrypting (not encrypting plain text), and then contort it again once it is in encrypted form, a third party would have a much tougher time than if just the plain-text or the encypted-text version wasn't the norm. Even more so if you've played how with the logic of the DES routine itself... not just played with the output. (Stupid side questions... is the source for DES or RSA encryption available? Is there any open-source encryption methods?)
I'm probably barking up the wrong tree by giving these specific examples. Let me ask a more fundemental question. From an outsider's point of view, the race in encryption so far seems to be centered around the number of keys. It started out as a low number, and it has been creeping up and up ever since.
If this is the case, why is the battle being waged on the number of keys? Are people making significant progress in (strengthening) the encryption methods themselves?
That caught my eye as well, the statement about 2GB of RAM. That couldn't have been the deciding factor for using the Cray. A simple Sun E450 (workgroup server) with 4GB RAM is not an outrageous configuration and not all that expensive.
:)
How do you know so much about the Cray?
Is it possible to go well beyond the current standard key sizes for encryption into something more vastly to decode (using "smart" techniques or brute hacking)?
Instead of using 512 bit encryption keys, is there a technical limitation (memory, computational time) that prevents, say, the use of 1Mbit keys? If so, at what point is a middle-of-the-road PC no longer able to produce and decode messages at a reasonable rate for real-time encryption and decryption?
Some things to ponder while reading this:
* The 2GB of RAM needed to diagonalize the giant matrix just isn't quite as frightening and impressive as it was a couple of years ago...
* This algorithm is massively parallelizable...
... and it was done entirely in software. Small silicon units for the various subunits could quite easily be combined into a single machine, along with giant RAM banks with good shared memory access. This would not be horribly expensive on corporate or government scales.
Quick conclusion: If 512-bit numbers can be factored in 7 months of essentially downtime using software implementations on a parallel virtual machine, you can bet quite safely that much larger keys can be factored by several different groups who don't ordinarily write press releases about it.
Second thought: Which means that the brouhaha about exporting RSA is very likely a smokescreen to keep people thinking of it as a secure system.
Final thought: Given this, don't trust anything that needs to be really secure - defined as "anything someone who already has the financial resources needed to build a custom machine like this would want to know" to 512 bits, or 1024 bits. Or, most likely, 2048. Even assuming that "they" have no fundamental advances in number theory hidden away (which there's fair reason to believe) the keys we considered virtually impregnable a few years ago are now totally vulnerable.
aack...
Reading the sci.crypt FAQ's it gives you tips on cracking encrypted text.
One of those is by using information you know that's contained in the encrypted text, which is very simple to get.
On the web, it's simple. Take amazon.com for example, everybody sends the same static information, but different dynamic information.
Static being 'CC#:', 'Full Name:', 'Address:', 'Phone Number:', etc. and dynamic being what follows these.
So right there you have _that much_ information, and when you think about it you can get most of those things I listed above.
If the person is targetted, it's even simpler. I know I write my address the same on-line as i do on snail mail. My full name can be on my return address. Phone number is no sweat. Credit card number is one of the few things the cracker needs.
Not to mention how unsecure lots of web sales sites are. BEFORE YOU SEND YOUR CREDIT CARD NUMBER TO A WEB SITE READ THE WEB PAGES' SOURCE CODE TO SEE HOW IT'S HANDLED.. This is very good practice.
I've seen countless times sites with https saving order forms in text files that are chmod'd wrong. Even some that are E-Mail'd. One of the most secure ways is to be put into a database, they might even be encrypted to boot.
fou aje oym asoyf ueyf jaffaq afset su!6j!/\ op 'ua>|7!>| ppn7
This is not so unexpected, given current computing power.
In Schneier's "Advanced Cryptography" he makes estimates on the amount of computer power needed to factor various size numbers. The estimatetd that using the General Number Field Sieve, it would take 30,000 mips-years to do the factoring of a 512 bit number (it took 6,000 mips-years). He also postulated that the NSA might have a much more efficient algorithm (that works at the same speed as the more specialized Special Number Field Sieve) that would do the job in under 200 hours. The number here, 6,000 mips years is in between these numbers, and completely expected. Anyone risking hundreds of millions of dollars on security the can be broken for less than that (i.e. 512 bit keys) deserves to lose their money.
What is safe? For comparison, the General Sieve would take
2*10^8 mips-years to factor a 768 bit number
and
3*10^11 mips-years to factor a 1024 bit number
IF a way to run this as fast as a special sieve is discovered these numbers become
100,000 mips-years
and
3*10^7 mips-years respectively.
Dedicated hardware sieves _could possibly_ do these today.
This result doesn't change the basic conclusion that 1024 bits is, for individuals, safe for the near future. For governments and banks etc. public keys of at least 2048 bits should be used.
It all depeds on how valuable your information is, how important performance is, and how long you want your data to be safe for.
Schneier also makes the useful remark that all predictions of the future are bunkum and shouldn't be trusted.
Not true. This is true for symetric algorithms, such as DES, but even a simple factoring algorithm (try all odd numbers up to the square root of the number) runs is sqrt(2^n)=2^(n/2). That would mean that every two bits doubled the time it takes to crack.
I read somewhere that with state of the art factoring algorithms, it takes 10 bits to double the time-to-crack for RSA. Of course, that still puts RSA-1024 at 2^50 times stronger than RSA-512, but I can see 728 bit keys cracked within a decade.
Keep in mind that the cracking rate for RSA benefits not from just faster computers, but better algorithms.
.. of course, everyone should have one of these in their basement..
http://www.fourmilab.ch/hotbits/
a bit of an over reaction?
1) Who has every considered 512 bit RSA secure? It's been on the export list precisely because it is not considered secure. This article states 25 years ago it was considered virtually unbreakable. 25 years ago computers were barely around! The first personal computer was the MITS Altair 8800, released at the end of 1974 (25 years ago). Anything other than XOR would have seemed virtually impossible to crack with that!
In 1974, IBM's fastest mainframe ran at ~1-2MIPS.
2) You can't "steal" credit card numbers, like you can steal cash. If you had every number under the sun, there is no way you could spend it without getting caught. Many sysadmins have access to millions of credit card numbers. If that really translated to a billion dollars they would be living in the Bahamas. Credit cards numbers != currency.
3) The cost of breaking a single SSL message would not be worth the cost gained by getting a credit card number. Each connection has a different key and there is no way to know if there is actually anything useful in the message until you break it. Just because someone makes a SSL connection doesn't mean there is anything valuable in the data. If you pick a SSL message at random and spend 3 months cracking it, chances are you'll come up with an banner ad image.
4) The internet isn't as insecure as people make it out to be, even without encryption. The government can't monitor most of the internet traffic, how is someone else supposed to collect all of the data to crack? Sure you can break into random machines here and there and do some small time sniffing, but nothing wide spread. It's not like you can take a laptop out to a fiber line somewhere and splice it in... you'd have to setup a big data center. If you could tap into a backbone, you'd *have* to use filters to reduce your data set size, but with encryption this is impossible. Even 64 bit RSA would be secure for this reason.
5) Cracking 512 bit RSA with plaintext available is not the same as breaking a SSL message. It's much much hard to break SSL (see below for a description of the SSL connection algorithm).
6) All banks that I know of offering online banking, either a) require 1024 bit RSA, or b) don't allow the transfer of money to an outside account (unless you count bill-payment systems).
---SSL connection description---
For the initial connection, when a client wishes to establish a secure connection, it sends a CLIENT-HELLO message, including a challenge, along with information on the cryptographic systems it is willing or able to support. The server responds with a SERVER-HELLO message, which is connection id, its key certificate, and information about the cryptosystems it supports. The client is responsible for choosing a cryptosystem it shares with the server.
The client then verifies the server's public key, and responds with a CLIENT-MASTER-KEY message, which is a randomly generated master key, encrypted or partially encrypted with the servers public key. The client then sends a CLIENT-FINISHED message. This includes the connection-id, encrypted with the client-write-key. (All these keys are explained separately, in the next section.) The server then sends a SERVER-VERIFY, verifying its identity by responding with the challenge, encrypted with the server write key. The server got its server-write-key sent to it by the client, encrypted with the server's public key. The server thus must have the appropriate private key to decrypt the CLIENT-MASTER-KEY message, thus obtaining the master-key, from which it can produce the server-write-key
-- Virtual Windows Project
See, the thing is, /dev/random is a hardware randomizer. It just takes random factors from a whole bunch of devices which have nondeterministic behavior, such as the serial ports (it's not predictable when the mouse will be moved or when a modem will get or send some data) and the soundcard (it's generally not predictable when a sound will be played or what will be in the buffer). All this true-random data is thrown together pseudo-randomly; although the combination can only be pseudo-random, as it is in software, the data that's being combined is true-random.
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
That's 6 to 7 million MIPS months; that is, the time it would take on a single 1MIPS processor. Hint: most (new) consumer systems these days are well over 250 MIPS by any sane metric. And as everyone on Slashdot is so quick to point out, you can always beowulf systems together.
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
Oops, sorry, wasn't paying attention that time. Go figure. :)
---
"'Is not a quine' is not a quine" is a quine.
"'Is not a quine' is not a quine" is a quine.
Quine "quine?
I was curious about the statement that an essential step that needed 2GB of RAM was performed on a Cray. What was that step and why did it require a Cray, i.e., will the prevalence of machines with a lot of RAM (I have many friends who have sprung for 4 128MB DIMMs and I expect that within 18 months 512MB DIMMs will be within reason, allowing you, bios and chipset permitting, to put 2GB of RAM on a very standard x86 mobo) make this thing trivial, or was the issue more one of internal bandwidth, which x86s (SGIs apart) generally do not have. I find this interesting because I have routinely followed the Power and PPC development at IBM with some interest in the bandwidth, assuming that IBM gets its collective ass in gear at some point (the S70A, for instance, while delightful to work with, is about three years too late and it shows in a number of ways, right down to the 32MB DIMMs on the cards). Alphas, while an architecture I am not as familiar with by a long shot, seem to offer the same bandwidth advantages and are moving into consumer space at a decent clip. Will the need for a Cray in this sort of thing be eliminated in 18 months if you can swing a dual Alpha with 32GB of RAM (assuming 2GB DIMMs)? I would be interested in comments on this. I know that I should be posting to the comp.arch groups, but why not ask here, too?
More info is here from CWI. It took them between 3.5 ad 3.7 months (I've seen both numbers). But here's the stats on what the used:
"Sieving was done on about 160 175-400 MHz SGI and Sun workstations, on 8 300 MHz SGI Origin 2000 processors, on about 120 300-450 MHz Pentium II PCs, and on 4 500 MHz Digital/Compaq boxes. The total amount of CPU-time spent on sieving was 35.7 CPU years estimated to be equivalent to approximately 8000 mips years. Calendar time for sieving was 3 1/2 months."
"(L: using lattice sieving code from Arjen K. Lenstra C: using line sieving code from CWI)
20.1 % (3057 CPU days) Alec Muffett (L at Sun Microsystems Professional Services, Camberley, UK)
17.5 % (2092 CPU days) Paul Leyland (L,C at Microsoft, Cambridge, UK)
14.6 % (1819) Peter L. Montgomery, Stefania Cavallar (C,L at CWI, Amsterdam)
13.6 % (2222) Bruce Dodson (L,C at Lehigh University, Bethlehem, PA, USA)
13.0 % (1801) Francois Morain and Gerard Guillerm (L,C at Ecole Polytechnique, Palaiseau, France)
6.4 % (576) Joel Marchand (L,C at Ecole Polytechnique/CNRS, Palaiseau, France)
5.0 % (737) Arjen K. Lenstra (L at Citibank, Parsippany, NJ, USA and Univ. of Sydney, Australia)
4.5 % (252) Paul Zimmermann (C at Inria Lorraine and Loria, Nancy, France)
4.0 % (366) Jeff Gilchrist (L at Entrust Technologies Ltd., Ottawa, Canada)
0.65 % (62) Karen Aardal (L at Utrecht University, The Netherlands)
0.56 % (47) Chris and Craig Putnam (L at ?)
Calendar time for the sieving was 3.7 months.
The relations were collected at CWI and required 3.7 Gbytes of disk space."
Quoted material from the link provided at the begining.
- AMW
the cracking method is (mostly) occupied by two stages; throwing a pile of cpus at sieving numbers out of the range 0 to 1,000,000,000; these numbers can be identified by their obeying an interesting mathematical relationship.
after that (several month) stage is over, the sieved values are collated into a huge (several million) element sparse array, tweaked to trim off excess crap and shrink it a bit, and then the cray chews on it for a couple of weeks making loops out of the data and reducing it further.
after that, there's a couple of day's worth of experiamental crunching, and the result popped out.
it's just the way the method works; the sieving is embarassingly scalable, but the array reduction needs a machine with a single, huge system image.
- alec
Hasta, Malachi
"Life is all about strategy, mathematics and psychological perceptiveness."
You mangle your key, you mangle the algorithm. This will create weaknesses and make it that much easier to break in a cryptanalysis attack.
Now by "contorting and breaking" messages and/or keys, there's a technique called "chaffing" that does something similar. Hides your truth in loads of bullshit, and a key will tell you which is which. You can even use this trick with the message in plaintext. Basically it's like agreeing beforehand that only the middle line in this message is useful:
your CO's order
attack at dawn
has been rescinded
(Okay, not quite useful since they'd still be alert at dawn after that anyhow, but you get the idea).
BTW, remember that RSA is almost never used to encrypt the content of a message, it's just too slow. It's just used to encrypt the exchange of a key for a symmetric cipher like DES. It's still the weakest link, and little consolation if your attacker monitored you from the start (which you do have to assume), but there are replacements for that link. Not to mention that Twinkle could probably generate keys it would take itself eons to break.
Makes me wonder what percentage of my memory and HD are going to be taken up by crypto overhead in the future though.
I've finally had it: until slashdot gets article moderation, I am not coming back.
I'm not sure that the important (ie limiting) factor here is the bandwidth nor even the amount of memory. The system that they quote as using, a Cray C916, is a computer that is no longer offered by SGI. It is a vector computing solution which has been succeeded by the T90 series. These systems only come in configurations of up to 32 processors, which is remarkable, but not compared to the real high end solutions (T3E and Origin 2000). I imagine that the statement about 2 Gigs of RAM was because that was the minimum space that the problem could reside in, but the true use of the Cray was the fact that for Polynomial searches, the paralleled vector processors are ideal for the job. The real possibility lies in the fact that a T932 could be used to do the same work in approximately 1/4 to 1/8 the time. If a group had access to a single T932 to do the Polynomial portion and a T3E for the rest, there is the possibility that they could do a similar factorization in under a week. If the reward was large enough (bank transactions) the cost of the hardware is easily covered. Hmm, large keys seem terribly desirable, no?
neutrino
History has the relation to truth that theology has to religion-i.e. none to speak of. - Lazarus Long
Looking for a dummy-level explanation, because it certainly isn't what my dictionary says about it;)
And what related technologies?
Thanks for any insight,
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Seymour Cray's final product involved the fastest switching technology ever activated in a super computer, which was then coupled into a massively parallel computing system. The Cray-3/Super Scalable System had a revolutionary GaAs control processor with potentially tens of millions of computing memory elements. This system (an adaptation of the original GaAs Cray-3) was financed by the NSA. Seymour Cray accepted this funding in a last-ditch effort to save his company and when I visited the Colorado Springs office, I was actually given the impression by one of their executives that they had a working model and would consider commercial sale of the device. Cray Computer Corporation went bankrupt shortly thereafter in the first business failure of Cray's phenomenal career. About a year later, Cray was killed in a jeeping accident. Having cut my teeth on his machines at the CDC/Urbana PLATO project, I knew Cray was unhappy with the direction his technology had been taken by "the spook shops" from before the day he left CDC to found Cray Research on his farm in in Wisconsin.
Recent revelations of RSA's vulnerability come as no surprise. The NSA, despite the fact that it is run by unaccountable bureaucrats embedded in a dough ball of Federal funding, is probably far beyond a cabal of private hackers in their capabilities.
Lest hackers and civil libertarians get the idea that now is the time for civil disobedience in protest of regulations against unlimited key sizes, you should probably be aware that Federal officials are so embolden by their lack of accountability that some of them have slipped up and are explicitly threatening suspects with prisoner gang rape. Given the prevalence of HIV infection in the prison systems, and the efficiency with which the virus is transmitted during gang rape, such threats amount to murderous sexual sadism as punishment for civil disobedience. In one of the most outrageous examples, Assistant U.S. attorney Gordon Zubrod from Harrisburg, PA made the following statement in a broadcast statement to 3 suspects who fled to Canada (this statement was captured for the public record during a Canadian Broadcasting Corporation interview):
"You're going to be the boyfriend of a very bad man if you wait out your extradition."
If you think the use of murderous sexual sadism against protesters who engage in civil disobedience is unrealistic, or somehow so low risk as to be inconsequential, you should read Torture In The American Gulag before taking any personal risks.
Seastead this.
I'm dumb. I screwed up my last post...
Anyhow:
I'm just shaking in my boots. It's so frightening to me that a cracker with a cluster of 30 computers to spare for a period of 7 months can get all of my secret credit card information. It's much more frightening than that scary person at the gas station who processes my credit card everytime I fill up with gas.
Face it, there is no such thing as privacy, even with encryption. It's all just an *illusion* of privacy. I wouldn't be surprised if the NSA already knew how to crack 1024-bit RSA keys. Encryption, like any form of computer security, is not the process of making you invincible, it's just making it more difficult for someone to crack your information/system/network/whatever.
I'll admit, I'm clueless on encryption. But I keep seeing something here that confuses me. It seems that they always have the roadmap of what is necessary to decrypt a message. It's just a matter of finding a clever approach to it, or finding massive horsepower.
What this points to, at least to me, is that when people are encrypting messages, they are using a pre-set published standard which describes how the message is going to be laid out. (Well, they would have to be, for any browser with encryption to seem to be able to send encrypted messages back and forth with various web servers.)
If someone really wanted to encrypt a message, instead of throwing more keys at it, why don't they change the order of some of the bytes, the values of others, and pad in a large number of random or semi-random digits?
If a massive key-cracker exists and works, it is going to plow right through someone running with a published encryption standard. But it'll stop dead cold on something like that. (But it might just be like waving a red flag, drawing attention.)
Is this generally correct, or am I way off-base here?