512-bit RSA Key Cracked. 173
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%.
Re:Sadam here I come.. (Score:1)
It's not about privacy. (Score:3)
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.
Re:Actually... (Score:1)
LINUX stands for: Linux Inux Nux Ux X
Re:Larger keys... (Score:1)
No end to this kind of things..hope that someday it will end ??
Re:How much was power and how much was parallelize (Score:1)
Re:Danger, Will Robinson... (Score:1)
Re:How much was power and how much was parallelize (Score:1)
That is Gaussian elimination, not unlike the task to find the `row echelon form' of matrices in your linear algebra class, except that:
Cray computers are suitable for this mainly due to its technical merits that some of you have mentioned. In addition, many of the previous factoring projects also used Cray computers for this task as well, which probably means they could use existing, proven code (and they did).
More technical and mathematical details (e.g., why need Gaussian elimination, how large is the matrix) can be found in the references of the Usenet announcement.
Re:How much was power and how much was parallelize (Score:1)
Re:Oh no! (Score:3)
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:
Re:Larger keys... (Score:1)
Re:A stupid question. (Score:2)
Potential Legal Problems (Score:2)
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 [www.sara.nl] 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
Re:Oh great (Score:1)
Re:Nothing is Safe! (Score:1)
You aren't being stupid. (Score:1)
Hey noone told me (Score:2)
Nothing is Safe! (Score:1)
Re:This method does not need the message to break (Score:1)
Stick with the tested encryption methods.
-Tom
Just when you thought your data was safe... (Score:1)
Re:Oh no! (Score:1)
Was this an attempt at a troll or are you just dumb?
Of course it isn't practical now (except by the government.) However, anyone who records encrypted traffic will have no problem solving large integer problems like this on a group of workstations in a few years and can then crack the data. Given that a lot of information will be as important years from now as it is today, do you understand the problem?
Won't change anything, though. (Score:2)
What's next? (Score:1)
Oh great (Score:1)
Patrick Barrett
Yebyen@adelphia.net
Re:Oh no! (Score:1)
Some related links (Score:2)
The top [deja.com] of the most active thread on sci.crypt at DejaNews
--
Rape as a disciplinary tactic in prisons (Score:2)
So? (Score:1)
But seriously, who needs ultra-strong encryption, anyway, besides governments and maybe buisnesses? I'm opposed to encryption controls and all that, but don't flatter yourself by thinking the government is so interested in you that it will spend months/years trying to crack your PGP key.
(that was directed at the alarmists who will probably be coming out of the woodwork any second now.....)
Re:Oh great (Score:2)
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.
Re:This method does not need the message to break (Score:2)
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.
Re:How much was power and how much was parallelize (Score:1)
1024 processors on one chip), would also be ideal?
Re:Potential Legal Problems (Score:1)
Re:A stupid question. (Score:2)
> 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. (Score:2)
How do you know so much about the Cray?
Re:Danger, Will Robinson... (Score:1)
In fact, it's not. At all. The sieving is done in parallel, but the actual matrix caclulations require one massive machine to do. Crays are nice because that's what they were designed to do. Simply tossing 2gig of ram into a dec alpha won't help you process the sparse matrix.
--Dan
Re:Actually... (Score:1)
and, unlike criminal court, you are guilty until you prove yourself innocent. The $50 limit is for when your wallet is physically stolen and you report it. It does not apply to someone copying your information and abusing it.
--Dan
Re:What's next? - ECC! (Score:1)
--Dan
The Most Cigarettes (Score:1)
"ending up in prison married to the inmate with the most cigarettes"
-- Neal Stephenson, Cryptonomicon
---
Geesh - wouldn't it be easier to steal the keys? (Score:1)
Re:It's not about privacy. (Score:1)
Note that a credit card transaction (from the card holder's and bank's view) is simply a signature loan. The merchant only cares that the bank pays them the amount of the transaction. The credit card number is totally unneccesary to the merchant, then.
Ok... custuomer and merchant both use a public key system, with their public keys signed by a trusted entity (the bank itself or service like Verisign or Thawte). Using a standard format for the tranasaction details, both the customer and the merchant sign the transaction details with their secret keys. The doubly-signed transaction is sent to an automated system that identifies both parties by their public keys (on record) and performs the appropriate credit and debit and sends the authorization back to the merchant.
The best part is, this system works even with a non-encrypted connection, since no "useful" information (like a CC number) can be obtained from cracking the message even if it were encrypted.
Re:What's next? - ECC! (Score:1)
Because: 1. They're Government 2. They need to communicate themselves this information, and what better way than the Internet? (...) 3. The 2-3% of these agencies/individuals that are really competent enough to brew their own crypto tools much, much safer won't talk about it outside the office...
RSA: O(n^3) (Score:1)
1M = 2^20, 512 = 2^9, 8^(20-9) = 2^33 = 8G
It takes 8,589,934,592 times longer to encrypt/decrypt a 1Mbit key than a 512bit key.
(Maybe there's an alogrithm with O(n^2.something), could be really interesting for big keys)
Re:Oh great (Score:1)
-Barry
Another stupid question: Key Size! (Score:2)
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?
Credit Cards... (Score:1)
The latest and greatest computer cracking equipment might steal your credit card number, but we're not talking about major personal loss here.
I just wanted to let people know so they don't fall for these credit card insurance scams.
Credit Cards... (Score:1)
The latest and greatest computer cracking equipment might steal your credit card number, but we're not talking about major personal loss here.
This is kind of offtopic. I just wanted to let people know so they don't fall for these credit card insurance scams or think they'll be doomed financially if an e-commerce server is cracked.
Secure enough? (Score:1)
Given the value alluded to in the argument, and the relative cost to break the key, it's pretty clear that 512-bit RSA is nowhere near secure enough! We need much bigger keys, and algorithms that get more bang for the bits. (Like elliptic curve algos.)
This one is for real, gang.
--
Oh no! (Score:1)
Re:Oh no! (Score:1)
-Barry
Re:Shudder... it was made possible by.. (Score:1)
Oh the irony.
Bob.
Apple's G4 + cracking capability (Score:1)
Picking locks... (Score:1)
Re:Oh no! (Score:1)
Danger, Will Robinson... (Score:2)
* 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...
Re:How much was power and how much was parallelize (Score:1)
It's even easier to decrypt messages from the web. (Score:3)
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.
Re:How much was power and how much was parallelize (Score:1)
What i've heard Altivec is a superfast vector unit in the G4 series processors and it should deliver a lot of processing power...
Re:This method do s n t neskf3#3bvcb (o,e)? (Score:1)
Seems safe enough. Tried to create my own algo a few years back. Learned a lot. Won't trye again. Keeping the algo secret isn't half as good as having one that has been viewed and tested by the worlds leding cryptographers for decades.
LINUX stands for: Linux Inux Nux Ux X
From the Bible (Score:3)
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.
Something is NOT Safe. (Score:1)
LINUX stands for: Linux Inux Nux Ux X
Re:What's next? (Score:2)
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.
Actually... (Score:1)
If more numbers get stolen, fees will go upp, and it's money uotta your pocket anyway.
LINUX stands for: Linux Inux Nux Ux X
Re:A stupid question. (Score:1)
RSA is based on the idea that it is very very difficult to factor large numbers. The assumption has been that as you double the key size, the difficulty in factoring gets multiplied by something like 1,000,000 or so each time.
So if it takes 3.7 months to factor a 512 bit key pair, then it should take 3.7 million months to factor a 1024 bit key pair. However, methods to factor these numbers faster and faster seem to be popping up, so I'm not sure how much longer RSA is going to be a valid algorithm.
If doubling the key size eventually only doubles the difficulty in factoring, then RSA will be useless.
Re:Shudder... it was made possible by.. (Score:1)
Re:What's next? - ECC! (Score:1)
Remember Fermats last theorum? It was proven using breakthoughs in Eliptic Curve theory.
Eliptic Curves are under HEAVY research now. ECC isn't safe.
Sorry for the spelling.
Re:So? (Score:1)
First time I heard IDEA referred to as 'feeble'.
Go away, troll.
...phil
Re:Look what happened to Captain Crunch (Score:1)
Re:How much was power and how much was parallelize (Score:1)
architecture for slapping a lot of
processor cores on the same silicon.
Re:Oh great (Score:1)
true-random? can someone confirm this? I have always thought any non-hardware randomizer to be pseudo-random.
Random Numbers (Re:Oh great) (Score:2)
http://www.fourmilab.ch/hotbits/
Why this is not a problem (Score:3)
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
Re:How much was power and how much was parallelize (Score:1)
Re:Oh great (Score:2)
---
"'Is not a quine' is not a quine" is a quine.
Re:Danger, Will Robinson... (Score:1)
PS dont think that ECC is super safe. There is just too much unknown about it. 4000 bit RSA (always read the source) seems a lot safer.
Re:It's not about privacy. (Score:2)
Oh, and another thing to consider: regardless of how you get your credit card information to that place you want to buy a DVD player from, they still have your credit card information. It's not like they forward the encrypted packets to the credit card company; they usually even don't send the unencrypted packets, and go through a third-party fund transfer service. And just about anyone can setup a website, sell some products at a too-good-to-be-true price, and screw you over. Hell, anyone can take out an ad in a magazine for that matter.
---
"'Is not a quine' is not a quine" is a quine.
Re:Larger keys... (Score:2)
---
"'Is not a quine' is not a quine" is a quine.
Re:Larger keys... (Score:2)
---
"'Is not a quine' is not a quine" is a quine.
What Are Your Odds? (Score:1)
There are probably plenty of institutions into which such protestors may hope to be placed that are "carefully" run and therefore in which prisoner gang rape is reduced to the sort of "debt collection" technique just described.
But what are your odds?
According to You Are Going to Prison by Jim Hogshire [amazon.com] "Your odds aren't good, fish."
Unfortunately, being a political prisoner doesn't give one any privileges in selecting one's mode of institutionalization. Furthermore, there is good reason to believe the government actively targets dissidents for prisoner gang rape. A mass media broadcast threat by a US attorney and the reported experiences of dissidents are relatively direct evidence. But far more subtle and profound is the pervasive aura of fear in the general population that this sort of sexual sadism has become a component of governmental power via malign neglect of its law enforcement duties under the 8th amendment to the US Constitution. Little is done to dispel these fears, even, and especially, during initial encounters with policing and judicial agencies of the government. Such first encounters are a precious opportunity for law-abiding officers and judges to dispel the aura of criminality that now surrounds their jobs. The fact is that they do not energetically and without fail avail themselves of their opportunity to recover public trust and lawful authority during these initial encounters placing such declarations in the public record of every case.
This malignant silence broadcasts a powerful signal that is easy to decipher.
How much was power and how much was parallelized? (Score:3)
Re:Won't change anything, though. (Score:2)
Also in the article, they said that there wasn't a frog's chance in a supernova that anyone would listen.
Dreamcast's secretly do NSA's work (Score:1)
More Info...Comments (Score:4)
"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.
Re:How much was power and how much was parallelize (Score:2)
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
Who cares? (Score:2)
Hasta, Malachi
Re:Oh great (Score:1)
Re:Why this is not a problem (Score:1)
Re:What's next? - ECC! (Score:1)
http://world.std.com/~dpj/elliptic.html [std.com]
http://ds.dial.pipex.com/george.barwood/ec_faq.htm [pipex.com]
It seems that there are patents, not on ECC itself, but on certain methods of implementing it.
--
Re:Potential Legal Problems (Score:1)
There was a big problem when researchers from Iran wanted to use the Cray T3E [tudelft.nl] at Delft University of Technology, in the Netherlands.
The US goverment forced Cray to try to stop Delft University from letting those Iranians use the machine or else.. (I don't know what their threat was orwhat happened).
The problem with all this was that it is against the first article of our constitution (which prohibits discrimination upon race, religion, etc.) to deny access to certain university employees.
Re:What's next? (Score:1)
Re:Oh great (Score:1)
Re:Oh no! (Score:1)
Re:A stupid question. (Score:1)
Re:This method does not need the message to break (Score:2)
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.
Bah! Humbug (Score:1)
Stop pushing One Time Pads as a viable substitute for public key encryption... The logistics make it incredibly difficult to implement securely and without extreme headaches. Yes, for top secret communications, where discovery=death or torture, and you can find a way to exchange pads, by all means go for it... But it's useless in the context of e-commerce and every-day implentable encryption.
Re:Larger keys... (Score:1)
It'd take 2 days to break 512 bit RSA.
There's no mention of scalability.
It seemed to be a brute force cracker.
Given that, 1024 bit crypto is still pretty much in the clear... A few years from now everyone may need to rethink that, but not today, given what we know publicly.
Re:So?-what? (Score:1)
Suggested moderation for your post (and this one,(?)): -1 troll/flamebait/MYOB
Re:How much was power and how much was parallelize (Score:2)
neutrino
What do you mean by stenography? (Score:2)
And what related technologies?
Thanks for any insight,
timothy
Time for Civil Disobediance? Think Carefully... (Score:4)
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 [ccic.gov] 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 [thinkofit.com], 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 [umn.edu].
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 [deja.com] before taking any personal risks.
Oh no! (Score:3)
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.
A stupid question. (Score:2)
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?