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%.
be careful he doesn't shoot you when you misspell his name :)
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?
This is yet another reason to switch to Elliptic Curve Cryptography! It is much more secure with smaller keys. (i.e a 160-bit ECC key is equivalent to 1024-bit RSA, a 256-bit ECC key is equivalent to over 3000-bit RSA, etc). And, of course, smaller key means less time taken on encryption! After all, choosing a key with a length of several kilobits is going to slow the encryption process to the point where you are going to wait weeks just to encrypt one message.
True. Wery true...
LINUX stands for: Linux Inux Nux Ux X
FRA: STFU GTFO
yeah larger keys...but sooner or later as the saying goes the thieves(enemies) always win(crack) first, then the good guys will win later.
No end to this kind of things..hope that someday it will end ??
A G4 would certainly be better than a G3, but its vector unit isn't in the same category as dedicated vector processors like in old-style Crays. An array of DSPs could be used creatively, though...
No, there's reason to think they haven't made any super advances. There are simply too many people in the world thinking about factorization (it's an important problem for things other than cryptography) for someone to make a giant advance and nobody else to think of it. But all they need is exponentially larger calculational tools - and given maybe $50M you could build an amazing dedicated factorization machine.
Not if you implement it efficiently. True, it's not the easiest thing in the world, but it can and has been done.
That is Gaussian elimination, not unlike the task to find the `row echelon form' of matrices in your linear algebra class, except that:
- the entries are 0's and 1's, and they are considered numbers in the modulo-2 system (i.e., 1+1 mod 2 = 0)
- the matrix is sparse
- the matrix is so large that even though its entries are just 0's and 1's (so you can use 1 bit per entry) and it is sparse (so you can use less memory in principle), it still takes GB's of memory to store
Although specialized algorithms are invented to just deal with this special case, it still takes a fast computer with fast memory access, due to the sheer size of the task; worse, no one has been able to parallelize it successfully yet, as far as I know.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.
Remember Fermats last theorum? It was proven using breakthoughs in Eliptic Curve theory.
Perhaps you'd be interested to know that mathematicians have been heavily studying Elliptic Curves for at least 100 years now.
Eliptic Curves are under HEAVY research now. ECC isn't safe.
Here is a bit of a history lesson for you:
RSA has been developed in the last 1970s.
ECC has been developed in the middle 1980s.
That's about 5 year difference for you. Of course, you can argue that factoring (the problem that RSA is based on) has been studied for a very long time and, thus, RSA is secure.
Well, guess what - discrete logarithm problem that ECC is based on has been studied for many decades now as well (the problem actually predates modern cryptography), which means that ECC is just as secure as RSA.
Or actually more secure since there are no known subexponential-time algorithms to solve a suitable elliptic curve problem. But there are subexponential-time algorithms (GNFS) to solve integer factorization problem.
And let's not forget that RSA has never actually been proven to be as hard as factoring, and factoring has never been proven to be as hard as discrete logarithm problem.
Personally, I'd choose ECC over RSA anytime..
Hmm... credit card numbers lead to personal information. Credit Card numbers lead to someone buying "things" that you might not ever buy, but what if it became public? "I didn't know" doesn't work. "Someone stole my credit card number to defame my character" comes across as a shrill whine...
All we need in the US to throw the Republican GOP machine for GWBush into a loop is for one of his old sources to come out and say, "well, Bush is full of crack [sic]. He bought from me a year ago".
IF the Demos get desperate, this could be the "Willie Horton" of the next election...
NIST (National Instutite of Standards and Technolology) is recommending ECC for use in government organizations such as Pentagon and NSA - http://csrc.nist.gov/encryption.
So, you are saying that what's strong for the government's own needs to hide national secrets and keep their screwups is not strong enough for you?
Ok, I'm starting my freshman year monday here (undergrad), but for me it came down to CMU and IIT. CMU kept putting me on the waiting list and not responding, and IIT gave me money. {g}
Anyways, I know IIT is one of the top engineering and computer schools in the country (ok, so its not extremely well known, bite me {g}), I'm not sure how it ranks in graduate though. Its one to look into, IMHO, though if CMU accepts you, go for it!
At least there's one thing I can tell you. The atmosphere is far different then any college I saw. The main campus is all engineers, so there's a lot of 'mutual respect' in attitude. The frats aren't drunken raves, more like a club of close friends. Its a lot nicer to work in. My brother went to CMU (physics, he's no doing grad. bio-physics at Stonybrook), and he kept telling me that CMU wasn't as great as I thought...
PS. Just because IIT gave me $ doesn't detract from their qualiy (if the idea of scholorships means they need to entice you beause there lower quality). I had two other high ranking colleges doing the same, just didn't like them as much. Even before I knew whether CMU was going to let me in or not, I had a hard time picking between the two.
PSS. IIT, aka Illinois Tech, is Illinois Institute of Technology (now really a University).
"Open Source?" - Press any key to continue
You're forgetting that vector processors are scads better at array-crunching that scalar (or even super-scalar) Alphas. The dual alpha could *do* it, but it would take much much longer. What's the vector length that Crays can deal with? I'd guess the alpha would be at *least* at factor of 32 slower; I wouldn't be surprised if the cray had 128-element vectors (==alpha 128 time slower).
[
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.
Um, no. A 1024-bit key will take 6 to 7 million months to do with TWINKLE (that 500,000 years for y'all without calculators in your skulls), according to RSA Labs.
[
On the consumer side, Dell's next server offering is a 64 bit machine with 8 way Xeons, and 36 GB of Ram. With stuff like this on market, what could a well funded group do with a room full of these?
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
Don't forget that your OTP has to be generated with a perfectly-random source. That's not a trivial constraint.
[
Um, physical locks are probably (if anything) *easier* to crack. Unless you're willing to spend *big* bucks and pour a *lot* of concrete.
[
guys i don't wanna hear it abot comprizons of with rc5des the algorithm is totally different, = for simple words... more numbers to serach do the hw, or check the mailing list. theers some good answers. -d.r rep :)
You are under-informed and doing something (asking) about it. That's not stupid, that's smart.
Bill - aka taniwha
--
Leave others their otherness. -- Aratak
My PC would've helped, I guess it has to go on doing boring rc5-64 instead..
The second part is solving the matrix. This requires a very fast computer with a large amount of memory. This step is not parallelizable, and will be the limitting factor in the future as sieving becomes more efficient.
Although this result is interesting, it is really no surprise to the cryptographic community. This is definitive proof of the weakness of 512-bit keys, but 1024-bit keys are not in any danger and unlikely to be for a very long time. Personally, I would be surprised if anyone was able to break a 1024-bit key before the advent of quantum computers.
Another important point is that this is not a general solution for 512-bit RSA keys. You have to do the whole thing over again for each key you wish to crack.
Finally, just as it is easy to overemphasize the importance of this development, it's also easy to dismiss it too readily. Anyone using 512-bit keys for signing should have gotten rid of them long ago. Anyone using 512-bit keys for signing should change to 1024-bit keys immediately. This includes anyone using SSL 2.0, as many old servers can only use 512-bit keys. If you have a newer server that can do SSL 3.0 it's important that you get a 1024-bit key even if you expect most of your traffic to use export strength crypto. This is because an SSL 3.0 server with a 1024-bit key will generate random 512-bit keys to be used for export strength communication. Netscape servers do this whenever they start. Therefore, if you restart your server every so often, you can make the cost of breaking your communications prohibitive. Although this won't prevent someone from breaking the weak bulk encryption, it will prevent them from breaking all of your traffic wholesale.
The end is near! I prefer a physical lock over encryption anyday.
This is what you would call "security through obscurity" and is a very poor method of encryption. In order for anyone to decode the message, they will need to have the algorithm in hand (either in the form of source or a binary). In either case, it is child's play to figure out the decryption algorithm.
Stick with the tested encryption methods.
-Tom
someone puts your reality in check. Not bad.
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?
personal attacks hurt, especially when deserved
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!
You show only time for sieving. Applying the Number Field Sieve took 3.7 months. There were other steps involved that raised the total time to over 7 months. Like reducing a set of simultaneous equations with millions of variables. This technique is not strictly brute force trial and error. They also mention that if the resources of other parallel cracking efforts were available (I think they mean distributed.net) then the process would have been complete in only a week.
Electrical Conductors, Medicines (I'm taking it), mallability, non-corrosivness...
So, what's the next step? Should we now start thinking about secure keys in terms of kilobits? Megabits? Yikes.
I'll tap into all of Bill Gates accounts, thank you.
It sure makes me feel safe to know that my online transactions can now be cracked :-) even if it does take a few months. Oh well I suppose it had to happen sooner or later Anyone have any idea how long it will take to crack that Uncrackable HardEncrypt? Patrick Barrett Yebyen@adelphia.net "It's X Window Dammit, not X Windows!!!"
Patrick Barrett
Yebyen@adelphia.net
Restating the obvious since nineteen aught five.
we havn't been on the gold standard in forever. Someone flunked Social Studies, I take 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)
I expect that 1024-bit keys will still probably be safe from current known attacks for at least a few more years, right?
Someone cracked a 512-bit key. Big deal. Who here uses 512-bits? I use 4096-bit Diffie/Hellman, so you won't see me wetting my pants over this.
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.....)
You know what Stuart, I like you. Your not like the other people, here, in the trailer-park.
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.
Does this mean that Sun's MAJC architecture (with say
1024 processors on one chip), would also be ideal?
Realize this: those in power will never voluntarily relinquish their control. Only by destorying those who would destroy us will we regain our freedom. Each year they take more and more of our freedoms from us. They will continue to do so until they are forced to stop. Emphasis on the word force.
Where are refrences for ECC? Any software? Are there nasty patents?
> 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?
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
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
--Dan
If you assume that a non standard method can be used then you assume that you can establish a secure channel *before* the actual encrypted communication happens, because you have to agree with the recipient on the method. BUT, if you can establish a secure channel once than you can use a method proved unbreakable. Simply choose a random key in length equal to the length of the message and you are set. You can use modulo addition or XOR operating on the message and key bitstrings to do the encryption. The problem of course is that the next message needs another key, and that the key is long compared to the message. But if all you need is to send a message about your next secret meeting with the other party or sg like that, then this method is appropriate since at the next meeting you can exchange a new key etc. The standardized methods are developed partly because the above mentioned solution requires a secure channel and needs too long a key. Actually, it is worth noting that the parties can agree that the key will always be a certain text on a certain page of a newspaper. And then they can include the date of the issue used for the next message to be sent. You can also choose a webpage content independent to you that might be more handy nowadays. Of course the key is not random but it still might work. I doubt that from 2 XOR-d text in general it is easy to find out both. (You can use different languages and leave out certain characters like blanks and/or preprocess the text to get the key etc.) And of course you can exchange a lot of keys at the first time for future use, which would take up a lot of space of you have a lot to send. Matyas
"ending up in prison married to the inmate with the most cigarettes"
-- Neal Stephenson, Cryptonomicon
---
If the gov't is going to dedicate this much time/money/power/people/resources to cracking keys wouldn't it make more sense just to steal them? This reminds me of the EMP research conducted where the nuclear planners wanted to build stronger and stronger EMP protection. The workaround is simply to apply more cheap nuclear EMP emissions. Since there is no upper bound it just becomes a game of chicken. Similarly with encryption - Use huge compute resources therefore just apply longer keys. As an intellectual experiment make a key infinitely long therefore you could not apply enough compute power to its solution. The alternative is to steal the key to begin with. Hell - build an encryption scheme that creates several keys only one of which decrypts the message and the rest destroy the message, or something along those lines.
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...
C.
heh..
:)
Yes, I noticed that too. I reposted it to the right one.. and hoped no one would notice.
If you double the key size, it takes eight times longer to encrypt/decrypt a message (assuming no other overhead and a 'standard' RSA implementation).
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)
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?
New Linux Security Column from Kurt Seifried Jim Reavis - August 28th 1999, 22:29 EST SecurityPortal.com is proud to announce the inaugural column of Kurt's Closet, appearing every Wednesday and featuring Kurt Seifried, noted security analyst and the author of the "Linux Administrators Security Guide". His first article is part of a series on encryption for Linux. It's a great primer on the different types of and applications for crypto on Linux, as well as the technical and political issues that abound. This article is the first in a three part series. [Seems oddly appropriate] http://securityportal.com/closet/
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.
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.
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.
--
"Genius may have its limitations, but stupidity is not thus handicapped." --Elbert Hubbard (1856-1915)
It looks like all my online purchases are now in jeopardy! Of course, you could just scrounge around the dumpsters behind Micro Center or Best Buy to find my credit card number with entirely less hassle.
>I use 4096-bit Diffie/Hellman Apparently YOU do. And since we're questioning everyone elses *need* for strong encryption what's your reason?
Microsoft helping to show the inadequacies of computer security?
:-)
Oh the irony.
Bob.
Sure, why not?
There have been, and almost certainly still are, security problems with Microsoft software. Believe it or not, there are people in the company and people in MS Research who are very concerned about that.
It would be a cheap shot, but for the fact that I know Alec Muffett very well, to remind you that security flaws in Sun's software enabled the Morris worm to spread like wildfire (and, as a consequence, kick-start the whole CERT business). I don't think Alec would be so stupid as to claim, seriously, that Sun no longer has security problems.
Every significant piece of software has bugs; every significant supplier ships security holes; every significant supplier tries not to ship them, tries to fix them when they are discovered, and tries to learn how to improve security in future products.
Paul Leyland
Disclaimer: Dese claims are mine alone and I do not speak for Microsoft in any official capacity (or, indeed, for Sun!). If MS wants to make claims, that's their prerogative.
Now that Apple has introduces the G4 with nice, fast vector processing instructions, should we expect an even steeper decrease in the time it takes to crack these keys by the general public? Apple advertises 1 GFlop/s normally, but upto 4 GFlop/s in certain cases. Give that an earlier poster mentioned that these algorithms are massively parallizable, I wouldn't be surprised if a key-factorizing program could be written for the G4 which ran close to the 4 Gflop/s boundary. And given the 18-month-till-speeds-double trend, we have much to worry about.
...is a lot easier than you'd think. It may take a brazen theif to try to pick a lock in broad daylight for 7 months straight, but it doesn't take 7 months. My little brother can pick a standard padlock in 2 minutues, and he picked it up from a book. Anybody with REAL training in lockpicking would be able to do it much faster. Also, a bolt cutter, or an acetylene (sp?) torch really makes a physical lock seem like a bad line of defense.
And, of course, smaller key means less time taken on encryption!
Not nessicarily... if the algorithim is more complex but uses a smaller key, then it quite possibly could take longer to do the en/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...
ok, this is probably a silly question, but what is MAJC?
Not too much, unless it was a sufficiently large room. The big limiting step is diagonalizing a very large (about 6*10^6 for RSA-155) sparse matrix, and that just requires a single huge, preferably vector, processor. It's not usefully parallelizable, which can be a damned nuisance for a lot of other things in life.
You gain a multiplicative increase in security (difficulty in cracking) for every few bits you add. In other words, a 1024 bit key will be MUCH MUCH harder to crack than a 512 bit key.
Unless the feds have a secret way to crack RSA in much shorter amounts of time - which I really doubt, otherwise they wouldn't allow US banks to entrust their financial data to RSA encryption - 1024 bits is pretty safe, 2048 bits is really safe.
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
Concerning vectorwork, would a G4 with Altivec solve al to of problems....
What i've heard Altivec is a superfast vector unit in the G4 series processors and it should deliver a lot of processing power...
Using a well known and tested algo and method is far more secure than creating your own. Spreading your data around will probably just give you a false sence of security, since the guy you send it to has to know how to get it, and that involves telling him how, somehow. I'm using a 4096-bit Diffie-Hellman public key and whenever i remember to type the swich 168-bit tripple-des secret key.
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
FRA: STFU GTFO
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.
you are mistaken 2000 bit keys can be routinly used in systems such as ssh (secure shell) and modern PCs hardly notice the overhead.
Yes you'r right. The same effort that was used to crack the 512bit here(that cost like zip-$ to create and use!!) whould brake any multimillion bank wault in probably less than a single DIN 8-hour day. Far less than 7-monts!!!
LINUX stands for: Linux Inux Nux Ux X
FRA: STFU GTFO
When credit card fims get hit. It's the customers that pay in the end. Where do you think those outrageus credit fees come from?
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
FRA: STFU GTFO
Yes, source for RSA and DES are available. They are both public standards. However, RSA at least is a patented algorithm. To use it in a commercial product, you have to pay money to the RSA corporation.
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.
Hey, you got to applaud them when they do good and boo them when they do bad. Anyway, from what I understand Microsoft Research doesn't have much to do with the rest of the company.
ECC? Humm. I wou;dn't trust it!
:)
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.
I'm more than a little disturbed by your suggestion that Captain Crunch might enjoy being raped because he tripped your gaydar. To me, this suggestion is no different than speculating that a woman might enjoy rape because she's straight, or that you might enjoy a lobotomy because you're already a idiot.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
My understanding was that it was Sun's
architecture for slapping a lot of
processor cores on the same silicon.
.. 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
Sun's attempt (depending on which EE Times article you're reading, either a good one or one too rushed out the door) at a VLIW/EPIC target architecture for Java code... eet.com search on MAJC should turn up one or two informative articles.
Various ramblings
But in that case, it would be better to mangle the data on output instead. For instace, agree on a few locations were extra bytes would be included after encryption. You don't even need to say where, or how many - you can just make multiple attempts to decrypt.
However, if you can exchange that information securely, it might be more efficient to exchange huge secret keys, and add another layer of non-public key encryption.
Don't forget, a Xeon is still a 32 bit processor.
It can't handle more than 2/4GB as easy and straightforward as a 64 bit processor can. The 36(?) bit "trick" from Intel ("PSE-36 mode") to enlarge the memory area is an ugly hardware hack, nearly as ugly as the way an 8086 adresses more than 64kB memory.
If this is a 155-bit key, isn't RC5 a bit silly now (except as a model for a distributed computing environment)?
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 "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.
Seastead this.
You are correct and I apolgize. That wasn't my intention when I started the post, but that is the way I presented it. There was no justification. Thank you for correcting me. --AC
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?
Has anyone heard this rumor? I have, twice now. although I don't believe it, it would be interesting to see an army of dreamcast dorks unknowningly breaking some nuclear codes.
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
Microsoft Research (Cambridge, UK)...
OH MY GAWD
Hasta, Malachi
"Life is all about strategy, mathematics and psychological perceptiveness."
http://world.std.com/~dpj/elliptic.html
http://ds.dial.pipex.com/george.barwood/ec_faq.htm
It seems that there are patents, not on ECC itself, but on certain methods of implementing it.
--
He was arrested, tried, convicted, jailed for his efforts.
On the first day in prison, he was asked by a large inmate if he could be part of his class. "What class, I just want to stay out of trouble." "The class that teaches us to phone free." "I ain't teaching no class." "You either teach a class, or you'll be my wife and wash my underwear."
The Captain taught thousands of inmates how to steal phone service, got out of prison, wrote a book, and did a brilliant Art Bell interview, available on tape.
Moral: Don't mess with your fellow inmates, and don't mess with the people who can put you in prison.
Methinks you wanted this in the article about CS grad schools? Just a thought.
This is exactly what I meant by the use of orthoganal methods in my earlier post. Multiple cipher streams don't increase security. Multiple dimensions due.
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.
OTP is yes, the most provably secure encryption available. It's implentation is just daunting, though. Exchange different, custom CD's with everyone you want to ever exchange info with. If you're that worried, you won't want to FedEx it, so instead you need to get an airplane ticket and arrive face to face to exchange pads... If said CD is ever intercepted, stolen, etc... your data is wide open...
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.
It was mostly for bragging rights over one of my freinds (who is an alarmist). His P100 croaked on anything over 2048 bits. So I did 4096 just to piss him off. But I'd really have been just as secure with, say, 1024. None of the enemies I've made so far in school have the brains to even know what encryption is, and the government couldn't be less interested in some 15-year-old computer nerd.
Suggested moderation for your post (and this one,(?)): -1 troll/flamebait/MYOB
Thank you. It sounds like a dual Alpha with a few GB of RAM would be able to do the work. This is a little scary. I am thinking that this would be good for BOFHs, though -- farm the embarrassingly parallel stuff out to a company's worth of NCs for the little MIPS chips to chew on, filtering it for the larger machines in the back room to work on. All the NCs with 128MB RAM, all on ATM ... hmmm ...
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
very astute; i can confirm that the final stage was attacked in at least three parallel ways - the cray (big, good at the job, code already exists) and two other methods of a more experimental nature, with new and untried code. At least one of the methods involved a network of Leyland's NT workstations, and the other might have involved an Alpha system, but my memory is uncertain of that; I am too zonked to remember straight.
in the end, I suspect the Cray won out because it was old and tested code, that has been doing this sort of thing for several years now.
- alec
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. I
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.
Not 155 bits silly. 155 digits(approx) thats _512_ bits. The thing is that it is... Well you wouldn't understand anyway.
LINUX stands for: Linux Inux Nux Ux X
FRA: STFU GTFO
What's Twinkle?
(I don't mean to be stupid, but....)
Insert mind here.
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?
It didn't try to crack the message by trying every possible key, then looking at the resulting data to see if it was real.
Instead, it actually factored the public key to find the secret. With that info, it could get your mangled message, which would be much easier to crack.
-- these are only opinions and they might not be mine.
This is much different from the Distributed.net project where they are trying brute force. With
this crack, they intelligently factored the public key. And it didn't take them that long either. I would imagine that there are some systems out there right now that could do this in what, a day or less?
-- these are only opinions and they might not be mine.