Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

512-bit RSA Key Cracked. 173

Posted by justin++ from the go-alec dept.
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%.

This discussion has been archived. No new comments can be posted.

512-bit RSA Key Cracked. More

512-bit RSA Key Cracked.

Comments Filter:
  • be careful he doesn't shoot you when you misspell his name :)

  • It's not about privacy. (Score:3)

    by Pascal Q. Porcupine ( 4467 ) on Saturday August 28, 1999 @07:30PM (#1719255) Homepage
    I've resigned myself to the fact that there's no such real thing as privacy, only perceived privacy. It's easy enough for someone to connect my presence in any media to my real person. So, I don't go to obscenely obscure lengths to try to cover my tracks; it'd be fruitless.

    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.

  • True. Wery true...

    LINUX stands for: Linux Inux Nux Ux X
  • 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.
  • What was that step and why did it require a Cray[...]

    That is Gaussian elimination, not unlike the task to find the `row echelon form' of matrices in your linear algebra class, except that:

    1. 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)
    2. the matrix is sparse
    3. 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.

  • 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).

  • Re:Oh no! (Score:3)

    by kuro5hin ( 8501 ) on Saturday August 28, 1999 @07:36PM (#1719269) Homepage
    I use this same argument with people when they complain that buying things online is not safe.

    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:

    • It could happen to your country too
    • And, even if it only happens to us, there will be some great unpleasantness for the rest of the world.
  • 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 [rsa.com].
  • 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.
  • There was one aspect of this scheme that I wonder about: The group's use of the Cray C916. I'm not sure what the policies at SARA are, but with the Crays that I work on, there are fairly severe penalties for using processor time for projects that aren't specifically approved. On one, in fact, I get the following message upon login:

    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

  • 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.
  • You are under-informed and doing something (asking) about it. That's not stupid, that's smart.
  • My PC would've helped, I guess it has to go on doing boring rc5-64 instead..
  • 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.
  • 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.

    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?

  • I'll bet US gov. will still maintain their stance on export of encryption technology.


  • So, what's the next step? Should we now start thinking about secure keys in terms of kilobits? Megabits? Yikes.
  • 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
  • we havn't been on the gold standard in forever. Someone flunked Social Studies, I take it.
  • The announcement at RSA [rsa.com].

    The top [deja.com] of the most active thread on sci.crypt at DejaNews
    --
  • Go here - http://www.salon.com/news/feature/1999/08/23/priso ns/index.html (No deep linking here, boss - just an URL)
  • 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.....)
  • Depends on the OS; Linux gives you a perfectly-good true-random number generator (/dev/random) which works by taking all the random cruft from random sources and combining them randomly. Movements of the mouse, presses of the keyboard, receipt of Internet packets, time between requests for random numbers, line level on /dev/audio (just hook up a white-noise generator to your microphone port and you're set!), and just about anything else which exhibits non-deterministic behavior is fed into the entropy pool.

    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.

  • 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?
  • This is a canned response... it's used on any government multi-user machine. I get the same thing when I log in to the boxes at work (I work at NASA.) As for using hours on a cray, someone would obviously notice... supercomputers use batch schedulers so that people have to "wait in line" for time on the machine... there's no way someone could just stick a process on there sucking CPU without anyone noticing.
  • > 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? :)
  • * 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...

    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, of course, you have to PROVE your card got stolen/abused. You can't just buy that brand-new-spiffy-keen cryotech athalon and say "my card was stolen!" and get it for 50 bucks.

    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

  • <paranoia>If I know how to crack something, and I'm completely sure that nobody else does, would it not be to my advantage to say "Look, I'm using it!" to get others to as well?</paranoia>

    --Dan

  • as in
    "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.
  • Even better is an idea I had a few years ago, but didn't have the nerve to pitch to the banks...

    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.

  • If I know how to crack something, and I'm completely sure that nobody else does, would it not be to my advantage to say "Look, I'm using it!" to get others to as well?

    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...

  • 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)
  • I read the people who want *really* random numbers (NSA, CIA, folks with scary acronyms) take readings from geiger counters and record background radiation. Unless you have another geiger counter in the exact same point in space, at the exact same time, you can't get the same numbers. Building an OTP from that sounds secure to me. Sidenote: the novel Cryptonomicon has some cool stuff about OTPs.

    -Barry

  • 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?
  • The last think I would worry about is someone grabbing my credit card numbers. In the U.S federal law only holds you liable for $50 of fraudulent spending assuming that you make reasonable attempts to stop it, like reporting stolen credit cards and strange things on statements. The burden is obviously placed on credit card companies and vendors (I think the vendors take almost all the responsibility), so they have all the reason to promote secure transactions and keep their data safe and hire competent employees.

    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 last thing I would worry about is someone grabbing my credit card numbers. In the U.S federal law only holds you liable for $50 of fraudulent spending assuming that you make reasonable attempts to stop it, like reporting stolen credit cards and strange things on statements. The burden is obviously placed on credit card companies and vendors (I think the vendors take almost all the responsibility), so they have all the reason to promote secure transactions and keep their data safe and hire competent employees.

    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.

  • It is doctrine that there is no such thing as absolute security, only "secure enough". "Secure enough" means it costs more to crack the key than you can get back from having the information.

    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.

    --

  • 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.
  • Once you realize that your credit card is only slightly more secure then leaving all of your money on a sidewalk, you can stop worrying about it. It's also good to be poor so that if someone does take all your stuff, you're out $290 and a playstation.

    -Barry
  • Microsoft helping to show the inadequacies of computer security?

    Oh the irony. :-)

    Bob.
  • 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.
  • Even if the NSA knew how to crac 1024-bit keys it wouldn't make all that big of a difference. The NSA probably has cracked 512-bit RSA keys already. The point of this all is that PRIVATE CITIZENS did it, not a multi-billion dollar government agency. And if anyone is seriously concerned about privacy they are using 2048-bit RSA Keys or some of the other algorithms that use 4000+ bit keys.
  • 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...
  • 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.

  • It's even easier to decrypt messages from the web. (Score:3)

    by Ludd Kilken ( 81957 ) on Saturday August 28, 1999 @10:32PM (#1719336)

    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.

  • 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

  • From the Bible (Score:3)

    by someone stole my nic ( 21175 ) on Sunday August 29, 1999 @04:29AM (#1719339)
    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.
  • 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

  • Re:What's next? (Score:2)

    by Anonymous Coward
    Not true. This is true for symetric algorithms, such as DES, but even a simple factoring algorithm (try all odd numbers up to the square root of the number) runs is sqrt(2^n)=2^(n/2). That would mean that every two bits doubled the time it takes to crack.
    I read somewhere that with state of the art factoring algorithms, it takes 10 bits to double the time-to-crack for RSA. Of course, that still puts RSA-1024 at 2^50 times stronger than RSA-512, but I can see 728 bit keys cracked within a decade.
    Keep in mind that the cracking rate for RSA benefits not from just faster computers, but better algorithms.
  • 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
  • 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. :)
  • you are probably actually *encrypting* with des or something equally feeble like pgp

    First time I heard IDEA referred to as 'feeble'.

    Go away, troll.


    ...phil
  • 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.
  • My understanding was that it was Sun's
    architecture for slapping a lot of
    processor cores on the same silicon.

  • true-random? can someone confirm this? I have always thought any non-hardware randomizer to be pseudo-random.

  • .. of course, everyone should have one of these in their basement..

    http://www.fourmilab.ch/hotbits/

  • Why this is not a problem (Score:3)

    by jonathanclark ( 29656 ) on Saturday August 28, 1999 @11:57PM (#1719356) Homepage
    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

  • 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.
  • See, the thing is, /dev/random is a hardware randomizer. It just takes random factors from a whole bunch of devices which have nondeterministic behavior, such as the serial ports (it's not predictable when the mouse will be moved or when a modem will get or send some data) and the soundcard (it's generally not predictable when a sound will be played or what will be in the buffer). All this true-random data is thrown together pseudo-randomly; although the combination can only be pseudo-random, as it is in software, the data that's being combined is true-random.
    ---
    "'Is not a quine' is not a quine" is a quine.
  • Why is there reason to believe that the NSA has made super advances in Number Theory. Sure they are the largest single employer of mathematitians anywhere, but they certainly do not hire a majority of all number theorists. The NSA's advantage is probably in implementation.

    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.
  • Wow, I feel silly after rereading my post. I meant to say, instead of 64-bit RSA (in regards to sending credit card info to online retailers), 64-bit DES or rc5 or whatever the hell online retailers use. :) Though the rest of what I said still applies.

    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.

  • That's 6 to 7 million MIPS months; that is, the time it would take on a single 1MIPS processor. Hint: most (new) consumer systems these days are well over 250 MIPS by any sane metric. And as everyone on Slashdot is so quick to point out, you can always beowulf systems together.
    ---
    "'Is not a quine' is not a quine" is a quine.
  • Oops, sorry, wasn't paying attention that time. Go figure. :)
    ---
    "'Is not a quine' is not a quine" is a quine.
  • The profile of those likely to protest encryption regulations via civil disobedience would be young, non-violent, white protestant heritage, middle-class, not skilled in martial arts, not physically intimidating, first-time offenders who were not street-wise. These are also risk factors in becoming a prisoner gang-rape victim.

    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)

    by Anonymous Coward on Saturday August 28, 1999 @05:42PM (#1719372)
    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?
  • Apparently the committee that was handling the encryption issue has told the President and the Whitehouse in no uncertain terms that unless they scrap the encryption regulations, American business is down the tubes. (There's an interesting article on it, over on MSNBC - not the world's greatest bastion on accurate reporting, but it's better than nothing. Not by nuch, but there ya go.)

    Also in the article, they said that there wasn't a frog's chance in a supernova that anyone would listen.

  • 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...Comments (Score:4)

    by Rolan ( 20257 ) on Saturday August 28, 1999 @05:56PM (#1719375) Homepage Journal
    More info is here from CWI [ftp.cwi.nl]. 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.
  • well.... to grotesquely oversimplify:

    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

  • We know that our privacy is at risk every day. We truly have no privacy to those wealthy enough to have the toys which can be used. And when toys come down to the masses, there are longer and bigger chains that require even bigger toys which again only the at-large can buy. Keys will get longer, computers will get faster, the breaking will not end. A change in perspective perhaps.. I don't see why so many get so worked up. Every Ah-Ha leads to a stack more of digits.

    Hasta, Malachi

  • Cracking "Hardencrypt"? About 5 minutes if you follow their instructions and *re-use* the OTP...
  • That is what I meant, thanks. Re-reading my original post, I realize this may not have been particularly clear.
  • Google [google.com] rocks.

    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.
    --

  • Could be. The US goverment always tries very hard to stay in charge of US built machines, even when they are sold to the outside world.

    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.
  • multiple encryptions won't increase security unless said cipher streams are orthoganal...i.e., stream1 + stream2 = stream3, and stream3 is EXACTLY as strong as stream 1 or stream 2...now if we added a different dimension of complexity, then the strength would increase...

  • Re:Oh great (Score:1)

    by Anonymous Coward
    A nuclear source is a very good random number generator. Other less exotic hardware RNGs use amplified thermal "shot noise" across a resistor or measure the quantum tunneling effect in a diode. These two *are* affected by temperature, so as long as the temperature of the device is controlled properly they will work. A nuclear source isn't effected by temperature.
  • Sarcasm. You need to take a lesson in it
  • 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.
  • 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.
  • Twinkle? That's Shamir's device, true? We already went through this before:

    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.
  • 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
  • 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
  • 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
  • When a "former" NSA employee forbade me, in 1982, from continuing my work to incorporate RSA's public key algorithm in the home shopping and banking capabilities of the Western Electric videotex terminal that was to be deployed in the Viewtron service [mediainfo.com] a few years later, I knew it was going to be a long haul before the potential of this technology could be realized. (I believe my comment to him was "The NSA contracted with IBM to report on the security of its 56 bit DES, and many independent experts believe this was more than a mere conflict of interest." His response was something like, "I'm a former NSA employee. You will stop work on RSA and use DES.")

    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)

    by Ticker ( 79929 ) on Saturday August 28, 1999 @06:45PM (#1719410) Homepage
    I'm dumb. I screwed up my last post...
    Anyhow:

    I'm just shaking in my boots. It's so frightening to me that a cracker with a cluster of 30 computers to spare for a period of 7 months can get all of my secret credit card information. It's much more frightening than that scary person at the gas station who processes my credit card everytime I fill up with gas.

    Face it, there is no such thing as privacy, even with encryption. It's all just an *illusion* of privacy. I wouldn't be surprised if the NSA already knew how to crack 1024-bit RSA keys. Encryption, like any form of computer security, is not the process of making you invincible, it's just making it more difficult for someone to crack your information/system/network/whatever.
  • I'll admit, I'm clueless on encryption. But I keep seeing something here that confuses me. It seems that they always have the roadmap of what is necessary to decrypt a message. It's just a matter of finding a clever approach to it, or finding massive horsepower.

    What this points to, at least to me, is that when people are encrypting messages, they are using a pre-set published standard which describes how the message is going to be laid out. (Well, they would have to be, for any browser with encryption to seem to be able to send encrypted messages back and forth with various web servers.)

    If someone really wanted to encrypt a message, instead of throwing more keys at it, why don't they change the order of some of the bytes, the values of others, and pad in a large number of random or semi-random digits?

    If a massive key-cracker exists and works, it is going to plow right through someone running with a published encryption standard. But it'll stop dead cold on something like that. (But it might just be like waving a red flag, drawing attention.)

    Is this generally correct, or am I way off-base here?

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close