Slashdot Mirror


Weak Elliptic Curve Cryptography Brute-Forced

thegrommit writes "It seems one implementation of elliptic curve cryptography has been broken. It took four years to break a 109 bit key, but the contest sponsors (who provide encryption products for Cisco, Nortel and Palm among others) believe it's still impossible to break their 163 bit keys. The real question is, for how long?" Update: 11/07 01:59 GMT by T : Dan Kaminsky wrote to point out that the key here was really brute forced, and not broken -- that is, no fundamental flaw was discovered in the algorithm.

270 comments

  1. secure enough by MisterFancypants · · Score: 4, Insightful

    4 years for the 109 bit version (and that's with a massive, dedicated attack).... I'm willing to believe (barring some unknown theoretical advance, which is always something you have to worry about with all real-world usable cryptography) that the 163 bit keys are good enough for my data considering the exponential difficulty in attacking the longer keys.

    1. Re:secure enough by Fembot · · Score: 2

      Its good enough for your data now, but for how long exactly? Moore's Law looks like its going to hold for the forseable future (still), so it wont be long before the 109 bit version becomes trivial and the 163 bit is doable in a reasonable time frame

    2. Re:secure enough by FasterThanLight · · Score: 2, Interesting
      Moore's Law looks like its going to hold for the forseable future (still), so it wont be long before the 109 bit version becomes trivial and the 163 bit is doable in a reasonable time frame
      Depends what you call a reasonable time frame- Moore's law predicts a doubling every 18 months, and if the same brute-force code-guessing techniques are used to "break" the encryption it will be awhile. 109! is a much smaller number than 163!(!), and IMMIC(If My Math Is Correct), there are ~2 x 10^114 more bit combinations in 163 factorial than in 109 factorial...

      --
      They're a little melty, but damn are they exquisite!
    3. Re:secure enough by MindStalker · · Score: 1

      Assuming how difficult it is doubles with every bit you add (how it generally works) It only needs to double 54 times, 15714 days =~ 43 years we will have the power to be able to compute this in the same 4 year time frame. Of course the funny thing is that if we start right now, using only current tech throughout the entire project it would obviously take about 216 years, and if we used progresivly better technology we'd probably only beat the team that started 43 years from now by a few months, but I personally don't care to try to do the math for that now.

    4. Re:secure enough by Anonymous Coward · · Score: 0

      "I'm willing to believe ... that the 163 bit keys are good enough for my data ..."

      True. I mean, how much encryption do you really need to protect your 200 GB porn collection.

  2. Brute-Forced != broken by JUSTONEMORELATTE · · Score: 5, Informative

    It wasn't broken, it was brute-forced.
    --

    1. Re:Brute-Forced != broken by poot_rootbeer · · Score: 0, Insightful


      Just because brute-force is an inelegant method of breaking encryption doesn't mean it isn't valid.

    2. Re:Brute-Forced != broken by p3d0 · · Score: 2, Insightful

      The site is slashdotted already, but I think you're right. Nothing to see here. Move along, folks.

      --
      Patrick Doyle
      I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
    3. Re:Brute-Forced != broken by Anonymous Coward · · Score: 1, Insightful

      The information that was "secure" isn't anymore. So regardless of how they broke it, it was broken. Brute-force is one of many ways. As the following threads will surely show. :)

    4. Re:Brute-Forced != broken by martyn+s · · Score: 2, Insightful

      Yes, but it means it will take just as long to break another code. It's not like they found some magical universal scheme for decoding any key.

    5. Re:Brute-Forced != broken by Anonymous Coward · · Score: 5, Informative

      To say that a cipher has been broken has a specific technical meaning: that a weakness has been found which reduces the cost of decryption without the key to less than the cost of an exhaustive search. The cipher in question was decrypted without the key using an exhaustive search. It was most certainly NOT broken.

    6. Re:Brute-Forced != broken by Skyshadow · · Score: 2
      Technically, you're not breaking anything when you brute-force it. Rather, you're just coming up with the key by an alternate method. I wouldn't call that breaking the enryption and more than I'd call torturing you until you coughed up the passphrase breaking the encryption.

      IMO, "breaking" implies that you've found an error in the algorithm or discovered a Gunter Janek-style shortcut which allows you to read the encoded information.

      --
      Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
    7. Re:Brute-Forced != broken by Anonymous Coward · · Score: 0

      You just showed your own ignorance. to "break" a cipher has a specific mathematical/information theoretic meaning. how does it feel to make an ass of yourself???

    8. Re:Brute-Forced != broken by benwb · · Score: 2

      Yes, but that by that logic everything but one time pad encryption is already broken, since you can brute force anything else. The act of breaking an encryption scheme is the creation of an algorithm that can go from cypher to plain text without knowledge of a shared secret.

    9. Re:Brute-Forced != broken by kaphka · · Score: 3, Informative
      Just because brute-force is an inelegant method of breaking encryption doesn't mean it isn't valid.
      True. However, brute force is only a valid technique for breaking a single message, which is what happened here. The headline says "Weak Elliptic Curve Cryptography Broken", which is false.
      --

      MSK

    10. Re:Brute-Forced != broken by FamousLongAgo · · Score: 5, Insightful

      'Breaking' is a term of art in cryptography. It means finding a solution that requires less time than a brute-force search. Even a 1% improvement qualifies as a 'break', although it might not have any practical value.

      It's a valid distinction to make, since a flawed algorithm may be unsafe at any key length.

      --

      A customer service representative will be with me shortly.
    11. Re:Brute-Forced != broken by Karamchand · · Score: 1

      Though this argument is not really good because the news are not "Elliptic Curve Cryptography can/will be broken" but "Elliptic Curve Cryptography Broken", i.e. "has been broken" (sorry for possibly bad english)

    12. Re:Brute-Forced != broken by iabervon · · Score: 4, Insightful

      More precisely, they broke a single key, not "weak elliptic curve cryptography". Breaking another 109-bit key (one that had been used to encrypt something, for example) would take another 4 years.

    13. Re:Brute-Forced != broken by afidel · · Score: 1

      not really, if you start today you get todays computer power and the acompanying growth, so it might take 2 years or less now.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    14. Re:Brute-Forced != broken by Q+Who · · Score: 0

      'Breaking' is a term of art in cryptography. It means finding a solution that requires less time than a brute-force search. Even a 1% improvement qualifies as a 'break', although it might not have any practical value.

      Any x% improvement is certainly not a "break". "Breaking" must involve improvement in time- or space-complexity of the solution.

    15. Re:Brute-Forced != broken by Ed+Avis · · Score: 2

      Yeah, when I first started reading Slashdot I was excited by the 'Break RC4' (or whatever it was) contests. I thought it meant break the algorithm for all time by finding a way to decrypt for all possible keys, or something like that. I was a bit disappointed when it turned out to be just a brute-force attack on a single message. The only 'breaking' that has been done is to demonstrate that the algorithm doesn't withstand the amount of brute force that you can reasonably expect a cipher to these days. Which is worthwhile, but not the same as 'Breaking X' where X is some algorithm name like 'DES'. Better to say 'Breaking message 140123780175012729104729174214728193274320', but that doesn't sound as glamorous.

      --
      -- Ed Avis ed@membled.com
    16. Re:Brute-Forced != broken by thing12 · · Score: 4, Insightful
      Right - so what's the lesson here?

      Encrypt your data using a key large enough in proportion to the length of time it will take to brute force if someone started today with a supercomputer. Essentially it takes X amount of time to check if a key is valid multiply that by number of combinations and you have a rough guess. So if you want something to be safe for a longer period of time (assuming no fundamental weakness is found in the algorithm), then encrypt it with a larger key - every bit doubles the probable time to break it at current cpu speeds. Of course you have to factor in the approximate doubling of cpu speeds every 18 months... but all that really means is that if we add a bit to the key length every 18 months going forward it will continue to take just as long to break into newly encrypted data.

      The fact remains that most people don't have anything that needs to be kept 'secret' for a long time anyway. Credit card numbers for online purchases? Those expire after a couple years and the amount of financial gain is not worth the time/cost to break the code. Given that you still need supercomputer equivalents to brute force this encryption it's unlikely that your neighbor is going to be reading your email anytime soon. Even at 109-bit.

    17. Re:Brute-Forced != broken by GigsVT · · Score: 1

      unsafe at any key length.

      Nader might have to write a book about such a cipher.

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    18. Re:Brute-Forced != broken by Anonymous Coward · · Score: 0

      Mod +1 for Sneakers reference.

    19. Re:Brute-Forced != broken by Zeinfeld · · Score: 2
      It wasn't broken, it was brute-forced.

      Nah, it was actually broken and the PR flacks of Certicom claimed it was brute forced.

      There is no collection of computing power anywhere on this planet that comes close to breaking a 109 bit key of any algorithm by brute force.

      The EC attack requires a considerable amount of computing power but that does not mean the search is 'brute force'. Brute force is a very specical term that means that every single possible key is tried in turn. The expected time taken to break a 110 bit key with brute force attack is thus exactly double the time for a 109 bit attack.

      EC is nowhere near that secure, in fact no public key crypto system can be. This attack calls into question the claim that 168 bit certicom keys are as secure as the 1024 bit RSA keys they are commonly compared to.

      --
      Looking for an Information Security student project suggestion?
      Try http://dotcrimeManifesto.com/
    20. Re:Brute-Forced != broken by pheede · · Score: 1

      Excellent advice. A technical detail that is important to get right though: an extra bit in the key does not double the probable time to break it -- that is only true for symmetric key encryption where keyspace in bits signifies the total number of encryption keys.

      In asymmetric systems, where the number of bits typically signifies the size of the prime used or some other type of like property, adding a single bit changes the 'estimated time to break' very little.

    21. Re:Brute-Forced != broken by Twylite · · Score: 2

      You also have to factor in who is going to crack your key, and what they are prepared to throw at the problem. Moore's law is for commodity hardware - someone serious about cracking a key in a short time will use dedicated hardware.

      Simple DES FPGAs can way outperform a P4 on DES operations, even running at 1/50 the speed. If it takes 10,000 computers 18 months to crack a key, it could take 50000 dedicated chips (which would be a lot cheaper!) under a month - even less depending on how much hardware can accelerate the calculations.

      --
      i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
    22. Re:Brute-Forced != broken by Twylite · · Score: 2

      Brute force means trying every key in the keyspace in turn. Just because the key is 109 bit doesn't mean the keyspace is. DES uses a 64 bit key, but 8 of those bits are parity, so the keyspace is only 56 bits. RSA uses a 1024 bit modulus, but only prime numbers can be used and the top bit is always set to ensure that the length is 1024 bits; the keyspace is nowhere near 2^1024!

      --
      i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
    23. Re:Brute-Forced != broken by mpe · · Score: 2

      Encrypt your data using a key large enough in proportion to the length of time it will take to brute force if someone started today with a supercomputer. Essentially it takes X amount of time to check if a key is valid multiply that by number of combinations and you have a rough guess. So if you want something to be safe for a longer period of time (assuming no fundamental weakness is found in the algorithm), then encrypt it with a larger key - every bit doubles the probable time to break it at current cpu speeds. Of course you have to factor in the approximate doubling of cpu speeds every 18 months... but all that really means is that if we add a bit to the key length every 18 months going forward it will continue to take just as long to break into newly encrypted data.

      Where this does become relevent is the (mis)application of cryptography to DRM. Where not only do you have to give everyone a "black box" decryption machine you also want to be able to keep something secret for something of the order of a century.

    24. Re:Brute-Forced != broken by MrFredBloggs · · Score: 1

      Exactly. You could brute-force a One Time Pad if you had the patience and CPU power, but what would be the point? You might as well just generate one single random number. It would be about the same thing.

    25. Re:Brute-Forced != broken by thing12 · · Score: 2
      In asymmetric systems, where the number of bits typically signifies the size of the prime used or some other type of like property, adding a single bit changes the 'estimated time to break' very little.

      Aha - very good to know! Thanks!

    26. Re:Brute-Forced != broken by DickBreath · · Score: 2

      Encrypt your data using a key large enough in proportion to the length of time it will take to brute force if someone started today with a supercomputer.

      Also you must consider for how long your data is valuable. A credit card number might be valuable for a few years, then loose any value. A military message such as "We attack at noon!" might loose its value by next week. A government message such as "The stealth technology works as follows." might not loose its value for years.

      Several posters mention to take into account Moore's law on commodity hardware. What they fail to mention is to also take into account Gates' law on commodity hardware. (The speed of software halves every eighteen months.)

      --

      I'll see your senator, and I'll raise you two judges.
    27. Re:Brute-Forced != broken by iabervon · · Score: 2

      Sure, but that would still be true even if nobody had broken this key. The fact remains that the breaking of this key doesn't give any advantage toward breaking keys in the future.

  3. obscurity by _ph1ux_ · · Score: 0, Offtopic

    .... well I'd say itll be a long time - I have never even heard of elliptic curve security - and i am sure many others havent as well

    1. Re:obscurity by BitHive · · Score: 2

      Obscurity != Ignorance

  4. How long? by anomalousman · · Score: 1

    If the NSA doesn't throw a fit and complain if you try to export/import it out/into the US, then it's probably breakable already. Notice how the US government tolerance level floats up pretty consistently a few years ahead of publicised code cracking?

    1. Re:How long? by Anonymous Coward · · Score: 0

      the NSA has NEVER complained
      its always been the FBI, because they cant break it. I repeat the NSA has NEVER said anything about publicly avail encryption

      (that doesnt mean they can or cant break it, but we know the FBI cant)

    2. Re:How long? by corey_lawson · · Score: 1

      Reread the introduction to "Applied Cryptography". "You're so wrong it isn't even stupid."

  5. Kama jaluo rade gi joluo wadgi by Anonymous Coward · · Score: 1, Funny

    To ka kar iko ogik dhako ma youre dhi omo pi e aora gi dapi; to dapigni oting'o gi dier wiye lilo.
    Yuoreno olo pi e tago to yuoche mamoko omake ka gikete e thigo mar dhood dhako maduong' kanyo ema mon go luokoe kitundu.
    Giluoko lwetene gi tiendene; giluoko fuondege e oigla, oswaro kata tawo, to ka ojadwar giluoke e agulu bende. To ka giseluoke, yuochego lute ebur.
    Kiluto ng'ato e bur moro amora ok nyal ywak kata goyo koko nikech gikowe gi kwe.
    Ji okuyo ka gikulo wigi piny, to jo mochungo osiro lew tong' piny.
    To ka dhok pod ok odonjo e kul ok ginyal ike; gipero lowo, kata giumo bur gi pien kata thigo. Ka dhok osedonjo eka giike e kar saa apar ga ariyo ka chieng' podho.

    1. Re:Kama jaluo rade gi joluo wadgi by Anonymous Coward · · Score: 0

      This is elite encryption !

    2. Re:Kama jaluo rade gi joluo wadgi by Anonymous Coward · · Score: 1, Insightful

      It's a language from Kenya that you have never heard of.

      It worked on you just as well as Navahoe worked on the Japanese in WWII.

      As long as you cannot get a chance to torture a Kenyan into giving you a language training course this code will continue to be effective against you

      At least until bablefish adds Luo as an option.

    3. Re:Kama jaluo rade gi joluo wadgi by Herkum01 · · Score: 1, Funny

      Just what we need, another Jar-Jar Binks fan!

    4. Re:Kama jaluo rade gi joluo wadgi by kalamashaka · · Score: 1

      is this jango floss power ?? this is the last place i thought you would find jaluo.

      --
      import kenyan.geek.* ;
  6. Impossible by Skyshadow · · Score: 5, Insightful

    Impossible seems like a pretty weird word to ever use in this sort of situation. "Very, very difficult" or "requiring technology or techniques in advance of what is presently available" might be more accurate.

    --
    Every year during my review, I just pray the words "slashdot.org" aren't mentioned.
    1. Re:Impossible by djtack · · Score: 5, Informative

      Impossible seems like a pretty weird word to ever use in this sort of situation.

      Except that they didn't use the word 'impossible'... you can thank the slashdot editor for that bit of nonsense. The article actually claims it is "computationally infeasible" to break the larger keys.

    2. Re:Impossible by w42w42 · · Score: 1

      I think its a weird word to use in almost any research or development context. How many times have people claimed something is impossible to only be proved wrong a short time later.

      The person that said the above comes across as a marketing type, which is ironic, because it makes their position a little less believable.

  7. They defeated themselves... by Anonymous Coward · · Score: 0

    by calling it Weak from the outset!

  8. Re:i broke my penis by binaryDigit · · Score: 0, Offtopic

    judging by your post, not very long at all

  9. Impossible is relative by vee-dub.net · · Score: 0, Redundant

    We've seen time and time again as encryption gets stronger and better that breaking the 'impossibility' of breaking it merely depends on the computing power available.

    I wonder what they really mean by 'impossible'?

  10. Where have I see this before? by jdclucidly · · Score: 3, Informative

    Oh yea! (insert Slashdot grumblings here)

    1. Re:Where have I see this before? by Anonymous Coward · · Score: 0

      I believe seeN is spellt with an N

  11. Apple and FEE by wizbit · · Score: 4, Interesting

    Apple made use of NeXT's Fast Elliptical Encryption in their "personal security" element of OS 9, allowing basically any document to be encrypted and decrypted by the OS. Apparently they planned this for OS X as well, but I see no mention of it except as a future feature on their scientific papers page. I wonder if this will force them to reconsider such a relatively insecure approach to OS security?

    1. Re:Apple and FEE by egreB · · Score: 3, Informative

      It's only the 109-bit keys that's been brute forced. Quoting the article, it would take 100 million times more computing power to take the 163-bit challenge:

      "It would be about 100 million times harder (to break) than what was just done," Vanstone said. "If you could get every machine on the planet working on the problem...you're still not going to be able to touch the 163 problem."

      I don't think Apple has any troubles using this key as of yet. And it's certainly not an insecure approach to OS security. The encoding of these algorithms is quite fast. This would be a good performance thing for the OS.

    2. Re:Apple and FEE by Textbook+Error · · Score: 0

      I wonder if this will force them to reconsider such a relatively insecure approach to OS security?

      Considering that the Apple implementation uses 128 bit keys, and it took 4 years to brute force a 109 bit key, I don't think it's anything like "relatively insecure".

      --

      Nae bother
    3. Re:Apple and FEE by quintessent · · Score: 2

      No. It took four years to brute force a key. Why would they worry about that? Just use a bigger key.

    4. Re:Apple and FEE by SirCrashALot · · Score: 0

      Yea, adding a single bit doubles the power required to crack it. I.e. an additional bit, in theory should take 8 years. Remeber your binary.

    5. Re:Apple and FEE by smallpaul · · Score: 2

      It took four years to decode ONE document and this isn't even using standard key-length sizes. What do you mean by "relatively insecure". Relative to what?

    6. Re:Apple and FEE by Anonymous Coward · · Score: 0

      Yes I would hate for my password to be broken in 4 years.

    7. Re:Apple and FEE by mpe · · Score: 2

      It took four years to decode ONE document and this isn't even using standard key-length sizes. What do you mean by "relatively insecure". Relative to what?

      It depends on the value of the information in the document. If that information is only valuable for 2 years then it's a waste of time. If the information is valuable for 10 or 20 years then 4 years is time well spent.

  12. 4 long years and the answer was ... by burgburgburg · · Score: 5, Funny

    Mrs. Peacock with a metal pipe in the kitchen

    1. Re:4 long years and the answer was ... by Anonymous Coward · · Score: 0

      [cough] Lead pipe [cough]

  13. Some Background by Kramer747 · · Score: 5, Informative
    Wolfram has some cool stuff on Elliptic Curves:

    http://mathworld.wolfram.com/EllipticCurve.html

    It was also use by Anrew Wiles in 1993 to prove Fermat's famous last thereom.

    http://mathworld.wolfram.com/FermatsLastTheorem.ht ml

    Enjoy!

  14. Free software gets a share by Clipper · · Score: 2, Informative

    It is nice to see that Monico is donating the majority of the prize money to the FSF.

    --
    /<en
    1. Re:Free software gets a share by GigsVT · · Score: 1

      Heh, If I ever had that kind of cash to donate to the FSF, I would just buy official copies of the GNU utility CDs... with full official docs for $5000

      It would be fun to say you actually bought them from the FSF, and it cost them little to produce, so it's still mostly a donation. Plus they probably sell so few of those, it might be worth something in 50 years when GNU has taken over the world.

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
  15. Money going to good cause by br0ck · · Score: 3, Informative

    The winner is giving 8 grand to the FSF. Monico, who took up the challenge to "raise awareness of cryptography", will donate the bulk of his prize money to the Free Software Foundation and the remaining $2,000 to two men whose computers helped solve the problem.

  16. WEC is terrible by Anonymous Coward · · Score: 0, Troll

    Basicly, it's just a delay mechanism that will let you transfer messages securely at a later time assuming you've transmitted equally much information securely already. So the question is, why don't you use the secure medium in the first place? Ok granted, you can send an agent out on a mission with an WEC and he can communicate securely with home base, but I mean for everyday use?

    The typical idea about cryptography is to use a secure medium to provide the key, while using the insecure medium to send the data, because the insecure medium is much faster/better/easier to use. So I can meet you in person and get the key, or call you on the phone and verify your PGP (or GPG if you please) fingerprint (assuming you're not being wiretapped as well), and then use the Internet as a medium from then on.

    The WEC "solution" would be to say a random sequence of 1s and 0s, then use those to decrypt the irc converation later, not really an option. You'd "run out" of the curve rather quickly. Oh, and quantum computing does as far as I know not affect encryptions based on elliptic integrals (which by theorem can't be solved analytically, but I suppose there could be approximations).

  17. How Long? A Loooooooong Time... by chrisleonard · · Score: 4, Informative

    Since a 163-bit key is 2^54 times more complex than a 109-bit key, and it took 4 years for the 109-bit key, aren't we looking at at least 4 * 2^53 years, not even figuring in the elliptical complexity (which I admit I would need to read up on)?

    According to calc.exe, 4 * 2^53 years is 36,028,797,018,963,968 years. Anybody want to start working on that one?

    1. Re:How Long? A Loooooooong Time... by chrisleonard · · Score: 1

      Oh, and I should add (with respect to the impossibility claim) that 36,028,797,018,963,968 years is approximately 2.5 million times the estimated age of the universe.

      So, while we might not want to use the word "impossible," I suppose we could say something like "unimaginably unlikely given current technologies."

    2. Re:How Long? A Loooooooong Time... by Anonymous Coward · · Score: 1, Informative

      Since a 52-bit key is 2^57 times easier than a 109-bit key, and it took 4 years for the 109-bit key, please tell me how to break a 52-bit key in one nanosecond.

      Obviously something is wrong with your thinking. Hint: take a computational complexity class. Time complexity isn't always O(2^n). Sorting can be done in O(n*log(n)), etc.

    3. Re:How Long? A Loooooooong Time... by chrisleonard · · Score: 1

      > Obviously something is wrong with your thinking. Hint: take a computational complexity class.

      You're obviously right, and (having done quite well, thanks, in all my PhD linear and nonlinear programming classes) I knew it when I posted. That's a little embarrassing to admit, but I still thought it would be a fun post that might make people think a little bit.

      Problem is, I don't use any of those nifty advanced math skills anymore, so I just posted the "easy lie." You know: "statistics, damned statistics, and bad math posted in a pop-science forum."

      I hope it still communicates to people the degree to which the size difference in the keys might matter. I actually thought another poster did a better job when s/he said something like "add another bit and you've just pushed Moore's law back 18 months."

    4. Re:How Long? A Loooooooong Time... by Anonymous Coward · · Score: 0

      Mod parent up!

    5. Re:How Long? A Loooooooong Time... by Cutriss · · Score: 2

      Four years?

      It took the power of 10,000 computers running around the clock for 549 days, coupled with the brain power of a mathematician at Indiana's University of Notre Dame, to complete one of the world's largest single math computations.

      Calc.exe says that's 1.50 years, with 10,000 systems (no mention of CPU speed or configuration. The contest started four years ago, but Notre Dame didn't start participating until almost two years ago.

      Furthermore, today's Pentium 4 2.8 GHz (or Athlon XP if you prefer) is far more powerful than the <=1 GHz CPUs available around the time that these systems were constructed. The article's short on details, so it doesn't mention if the systems were SMP-configured, or if they were all single-CPU nodes.

      This was a brute force attack as well - You can always decrease the time by throwing more computing power at it.

      The number *is* still incredibly huge, but not quite as huge as you say.

      --
      "Mod, mod, mod...and another troll bites the dust."
    6. Re:How Long? A Loooooooong Time... by Anonymous Coward · · Score: 2, Insightful

      Time complexity? What the hell is that? Hint: Brute-forcing most encryption schemes is O(2^n), where n is the length of the key. Brute forcing encryption is not sorting.

    7. Re:How Long? A Loooooooong Time... by Anonymous Coward · · Score: 0

      The number doesn't mean much anyway, since we don't know if they lucked out and stumbled on it early, or were unlucky and got a key that took a long time (with their algorithm).

    8. Re:How Long? A Loooooooong Time... by richard-parker · · Score: 5, Informative

      Since a 163-bit key is 2^54 times more complex than a 109-bit key, and it took 4 years for the 109-bit key, aren't we looking at at least 4 * 2^53 years, not even figuring in the elliptical complexity (which I admit I would need to read up on)?
      Recovering a 163-bit ECC key is estimated to require 2^27 times as much effort as a 109-bit ECC key. Current recommendations are that 163-bit ECC keys should be safe to use until 2011, although I don't think we'll see public key-recovery efforts succeed against 163-bit ECC until 2020 or so.

      The following is one of the better articles on this subject:

      A. Lenstra and E. Verheul, "Selecting Cryptographic Key Sizes,"
      Journal of Cryptography, v. 14, 2001, pp. 255-293.

      A PDF file of the article can be downloaded here.
    9. Re:How Long? A Loooooooong Time... by Anonymous Coward · · Score: 0

      A 163 qbit quantum computer should be able to solve the problem instantly. that technology may only be a couple decades away.

      no encryption is unbreakable. for every defense, there is a counter.

    10. Re:How Long? A Loooooooong Time... by Q+Who · · Score: 0

      Brute forcing encryption is not sorting.

      Encryption is not symmetric key encryption.

    11. Re:How Long? A Loooooooong Time... by Q+Who · · Score: 0

      Obviously, you have no clue of what qbits are.

    12. Re:How Long? A Loooooooong Time... by chrisleonard · · Score: 1

      Thank you. I knew somebody would have the real goods on this question.

    13. Re:How Long? A Loooooooong Time... by Anonymous Coward · · Score: 0

      Time complexity? What the hell is that?

      Google may help you

      Brute-forcing most encryption schemes is O(2^n), where n is the length of the key.

      Turns out the time complexity is O(1.414^n) in this particular case.

    14. Re:How Long? A Loooooooong Time... by Twylite · · Score: 2

      Umm, no. Brute forcing 1024-bit RSA is not O(2^1024), its closer to brute forcing 64-bit DES, which is O(2^56). Brute forcing simply involves an exhaustive search through the keyspace. It does NOT mean you have to do a full calculation and comparison with every possible value that can fit into a key representation.

      e.g. RSA keys can only be prime, so you search for prime numbers of length 1024 bits rather than trying a RSA operation will all 1024 bit numbers. In addition, some techniques allow you to detect that a key cannot possibly give the desired solution before the entire calculation is completed, so you can do only partial calculations on some values.

      --
      i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
    15. Re:How Long? A Loooooooong Time... by mpe · · Score: 2

      Since a 52-bit key is 2^57 times easier than a 109-bit key, and it took 4 years for the 109-bit key, please tell me how to break a 52-bit key in one nanosecond.

      The length of the key in itself does not tell you the size of the keyspace. Criteria such as all keys having to be prime, have the same parity, etc can make a big difference

    16. Re:How Long? A Loooooooong Time... by AyeRoxor! · · Score: 1

      "According to calc.exe, 4 * 2^53 years is 36,028,797,018,963,968 years. Anybody want to start working on that one?"

      I'm no mathematician, but I'd love to see a formula that applies moore's law, where calculation speed approximately doubles every 18 months.

  18. No code is impossible... by sterno · · Score: 4, Insightful

    There is no such thing as a crypto key that is impossibile to crack. What it comes down to is how improbably it is to crack it. In this example, it took 10,000 computers 549 days to crack it and it's only 109 bits. At 163 bits, that's a doubling in difficulty for ever additional bit.

    Just add a bit, and suddenly you've pushed off the efficiencies gained by moore's law for another 18 months. By going to 163 bits, you've got a good 80 years before the that key can be broken in the same time as this 109 bit key. Frankly I wouldn't be too worried about that problem.

    As long as your crypto is good enough to make it too expensive to crack for those who might want to crack it, you've got no worries. And I don't see a lot of people out there able to throw together the 10K computers to crack a key who also don't mind wasting almost two years on the effort.

    --
    This sig has been temporarily disconnected or is no longer in service
    1. Re:No code is impossible... by MtViewGuy · · Score: 2

      ...But trying to break that 163-bit "elliptical code" is going to require current technology computers (even if you have 10,000 of them) several hundred years to break the code.

      You're going to need a good number of supercomputers about the level of IBM's upcoming Blue Gene system to even think about attempting a crack of 163-bit "elliptical code."

    2. Re:No code is impossible... by ralphus · · Score: 1
      There is no such thing as a crypto key that is impossibile to crack

      One time Pad is known to be impossible when used correctly. Quantum cryptography is supposed to.

      --
      Revolutions are never about freedom or justice. They're about who's going to be top dog. -- Kilgore Trout
    3. Re:No code is impossible... by Anonymous Coward · · Score: 1, Informative

      Not true. A proper one time pad, used appropriately
      (e.g. only one time!) is mathematically provable to be absolutly secure, not just "practically secure".

      The problem with one time pads is the key distribution problem - how do all sides agree and share a key without exposing that key to the bad guy? Especially since with a OTP, the key is as long as the original plaintext in which you want to encrypt.

      Quantum Key Distribution algorithms such as BB84 (which is what people are actually refering to when they talk about "Quantum Cryptography") allows two parties to exchange absolutly secure OTP keys over an insecure medium, while the properties of quantum mechanics ensure that an adversary couldn't evesdrop or modify the traffic in transit.

    4. Re: No code is impossible... by Black+Parrot · · Score: 2


      > Just add a bit, and suddenly you've pushed off the efficiencies gained by moore's law for another 18 months. By going to 163 bits, you've got a good 80 years before the that key can be broken in the same time as this 109 bit key.

      I'm not familiar with the relevant statistics, but it may be the case that the number of computers that we can usefully cluster together is also growing exponentially, in which case our cracking speed is actually growing at O(e^{e^t}). I would guess far less than 80 years before a brute force attack works against 163 bits.

      --
      Sheesh, evil *and* a jerk. -- Jade
    5. Re:No code is impossible... by imnoteddy · · Score: 2, Informative

      There is no such thing as a crypto key that is impossibile to crack. What it comes down to is how improbably it is to crack it. In this example, it took 10,000 computers 549 days to crack it and it's only 109 bits. At 163 bits, that's a doubling in difficulty for ever (sic) additional bit.

      Just add a bit, and suddenly you've pushed off the efficiencies gained by moore's law for another 18 months. By going to 163 bits, you've got a good 80 years before the that key can be broken in the same time as this 109 bit key. Frankly I wouldn't be too worried about that problem.

      As long as your crypto is good enough to make it too expensive to crack for those who might want to crack it, you've got no worries. And I don't see a lot of people out there able to throw together the 10K computers to crack a key who also don't mind wasting almost two years on the effort.

      There are lots of organizations with 10,000 computers, or more. There are distributed systems like SETI which could put a million computers on this problem. People can improve the algorithms used to attack the problem.

      I doubt it'll be 80 years before 163 bit is brute forced.

      --
      No electrons were harmed creating this post, though some may have been subjected to electrical and/or magnetic fields.
    6. Re:No code is impossible... by Q+Who · · Score: 0

      Quantum Key Distribution algorithms such as BB84 (which is what people are actually refering to when they talk about "Quantum Cryptography") allows two parties to exchange absolutly secure OTP keys over an insecure medium, while the properties of quantum mechanics ensure that an adversary couldn't evesdrop or modify the traffic in transit.

      Unlike OTPs, Quantum Cryptography security is not provable from mathematical axioms. Therefore, the OTP keys being exchanged are not "absolutely secure".

    7. Re:No code is impossible... by Vilim · · Score: 1

      You take for granted the number of computers wokring on the problem will stay the same. More copmuters + more powerful computers = massive savings in cracking time. Teh numbers of computers in use is not even close to levelling off, more comptuers are being sold every day while fewer old ones are being taken out of commission. The CPU power per capita is going up regardless of moores law.

      --
      History will be kind to me, for I intend to write it - Sir Winston Churchill
    8. Re:No code is impossible... by Anonymous Coward · · Score: 0

      You are the dummy, dummy.

      According to Schubert's dialectic UFO transmogrifier method, two parties can exchange the key in an emerald lock box, requiring 2^emerald(lock)box to conceal. After concealing the jewels (hah - pun!) the parties agree in a secure mode to never speak of it again. What happens before that is a mystery. Remember E=Mc^2? well, that is what you need to know to go backwards in time which is what lends elegance to this method. You must travel back in time to review the original transmogrification in real time (damn near impossible without over 60,000 computers the size of Blue Gene just to commence the launch codes for that one, never mind the whole structure....)

      By then the sun will have expired (2^6 * e^27 years) and the algoirithm is still considered strong. I think my data will be safe, little man. Go back and review your Rilke if you are perhaps, /a little clueless/..

  19. Even if it was "broken" ... by binaryDigit · · Score: 5, Insightful

    The time is the most significant factor here. If this was military use, the 500+ days it took to break wouldn't worry anyone since any message more than a few days/hours old is pretty much worthless. If someone where more concerned about long term security, they could setup a system to refresh the keys on any encrypted data, say every year or every quarter.

    1. Re:Even if it was "broken" ... by neirboj · · Score: 2, Insightful
      "If someone where more concerned about long term security, they could setup a system to refresh the keys on any encrypted data, say every year or every quarter."

      It seems to me that encryption has little value for long term security. Encryption won't stop a thief from breaking in and absconding with one's files. It may deter them electronically but not physically. At that point, it doesn't matter how many times you've refreshed the keys on your files since you won't have another opportunity do so. The thief could have all the time they want to crack the code.

      If you want to get your data from point A to point B and have some assurance that no one has peeked at it or modified it, then encryption is a wonderous thing. If you want to keep something a secret for many years, then you need a concrete bunker!

      My $0.02. Your milage may vary.

    2. Re:Even if it was "broken" ... by fstanchina · · Score: 2, Insightful

      That doesn't work. If you did encrypt it in the first place, it's because you anticipate the message will be intercepted. You just can't call up the bad guy a day later and say "hey, here's yesterday's message, but encrypted with a new key -- please throw away the old one and start from scratch".

    3. Re:Even if it was "broken" ... by binaryDigit · · Score: 2

      The thief could have all the time they want to crack the code.

      True, but you can have as much physical security as you think you need (or can afford). Plus, if it takes someone a year and a half to decode your data, you have a fair bit of time to do whatever damage control is necessary. Also, if you did something like say cut up all the bytes of your data and seperate them into eight files and then encrypted each file individually, it would take that much longer to crack, esp if all those files where stored in different locations (one can of course dream of multiple ways to make the problem near impossible to deal with).

    4. Re:Even if it was "broken" ... by pediddle · · Score: 1

      they could setup a system to refresh the keys on any encrypted data, say every year or every quarter.

      But there would be nothing preventing someone from continuing to hack at the "old" encrypted data. If someone already has the encrypted data, then re-encrypting it won't change that.

    5. Re:Even if it was "broken" ... by 0x0d0a · · Score: 2

      Err...no. If something is a few days old...well, knowing old information about where submarines were planning to rendezvous in WWII made quite a difference, hearkening to Cryptonomicon.

    6. Re:Even if it was "broken" ... by mpe · · Score: 2

      True, but you can have as much physical security as you think you need (or can afford). Plus, if it takes someone a year and a half to decode your data, you have a fair bit of time to do whatever damage control is necessary.

      If you know that your data has been compromised. A typical spy will copy your data, rather that stealing it.
      The real use of encryption is to protect data, either in storage or in transit (there are plenty of ways in which you can send data where third party evesdropping is trivial), that it will have lost it's value before any third party can have made sense of it.

    7. Re:Even if it was "broken" ... by merlin_jim · · Score: 2

      If someone where more concerned about long term security, they could setup a system to refresh the keys on any encrypted data, say every year or every quarter.

      That's the absolute worse thing you could do.

      Disclaimer: IANAC, but I've read quite a bit on the subject, and implement it frequently.

      If you change your keys periodically, you are doing so under the assumption that your documents are in danger of being received, and your keys being cracked.

      Let's setup the following situation:

      Alice wants to send a document to Bruce. They meet in person and agree on a key. This key works for both locking and unlocking documents, that is it is symmetric.

      Alice encrypts a document for Bruce and transmits it over radio. She later learns that it may have been intercepted by Charlie, whom she really doesn't want to read her messages, so she and Bruce meet in person and agree on a new key together.

      Alice decides that to be safe, she had better unencrypt everything she ever encrypted, and re-encrypt it with her new key, which she's pretty sure Charlie hasn't brute-forced yet.

      Charlie never found the old key. He didn't have the time or resources; he's hoping to break Alice's crypto-system before he has to brute force it. One day while rummaging through Alice's hard drive, because Charlie's friend Dave is a pretty good cracker and can do stuff like that, he finds a document with the same date/time stamp as a transmission he intercepted. He compares it to the intercept and finds that it is an entirely different set of bits.

      By comparing the two sets of bits, which are, thanks to our incredibly complicated elliptical curve encryption algorithm, basically noise, he can glean information. As a matter of fact, if he's right and the source of this document is the exact same as the source of the first document, he stands a good chance of making some interesting assumptions about the original document, and depending on the exact details of the cryptosystem and how it's applied to the documents, this could be (in order from best case to worst case):

      a) Portions of the unencrypted document
      b) the unencrypted document (this would probably require a crib)
      c) portions of one or both of the keys used, this may be limited to mathematical facts about the keys... this would make a brute-force approach take a significantly less amount of time
      d) one or both of the keys used to encrypt the document

      In fact, the absolute best case that can occur, from Alice's point of view, is that Charlie will now have to mount a known-plaintext attack, which while difficult, is orders of magnitude easier than a known-ciphertext attack.

      --
      I am disrespectful to dirt! Can you see that I am serious?!
    8. Re:Even if it was "broken" ... by binaryDigit · · Score: 2

      A typical spy will copy your data, rather that stealing it.

      Well true, but any data worth this level of encryption shouldn't be stored in such a way that you could just drag and drop the thing onto a floppy. You should be able to tell the last time the file was touched and/or have alerts when a file is being touched.

  20. Duplicate article... by camusflage · · Score: 5, Informative

    We already covered this on slashdot. This is just Yahoo picking up on it now.

    --
    The truth about Scientology, Xenu, and you: Operation Clambake
  21. Whats so hard about 163-bit? by Nathanbp · · Score: 2, Insightful

    What about their 163-bit encryption makes it harder to brute force than any lesser bit encryption? Why is is "impossible" to break whereas the 109-bit encryption is only difficult?

    1. Re:Whats so hard about 163-bit? by Zebbers · · Score: 2, Insightful

      the extra 54 bits

    2. Re:Whats so hard about 163-bit? by Qender · · Score: 1

      I think it's because it's incrimentally more complicated.

    3. Re:Whats so hard about 163-bit? by vadim_t · · Score: 1

      Because every bit doubles the time needed to brute force it, so it takes 2^54 = 18014398509481984 times longer.

    4. Re:Whats so hard about 163-bit? by 0x0d0a · · Score: 3, Insightful

      Assuming that there will be no additional reduction of strength from attacks, it's another 54 bits.

      Assuming Moore's Law roughly holds, that's about lg(54) * 1.5 = 11.5 years before systems can break this thing in four years.

      Now, that's actually a little shorter than one might like, and more importantly, it doesn't leave as much breathing room as one might like if more holes are found, but...

    5. Re:Whats so hard about 163-bit? by lirkbald · · Score: 3, Informative

      A common mistake I've seen is people assuming that key size == keyspace size. For nearly all cyphers this isn't true. Suppose, for example, that your key requires a large prime number. The Prime Number Theorem says that the fraction of numbers up to N that are prime is approximately 1/lg(N) (that's base e, not base 2). So if we are using a k-bit prime number as the key, the keyspace size would be 2^k/(k*lg(2)), not 2^k. This isn't a huge reduction in keyspace size, but then again most codes have much stronger restrictions on valid keys.

      The point is, a code with, say, 1024-bit keys may only give you, say, a 700-bit keyspace.

  22. It WAS broken: It wasn't cracked by burgburgburg · · Score: 2
    It doesn't matter how, but it was broken (what was hidden is now revealed).

    However, it wasn't cracked open. There wasn't a shortcut, a tragic flaw in the algorithm. Just time and computer power tossed at it.

  23. Doesn't beat a hardened steel padlock. by Anonymous Coward · · Score: 0

    I don't understand how people can trust their data to a simple cubic polynomial in x and y. This stuff isn't tangible. It's like hiding data in the 4th dimension or something.

  24. Broken Elegantly vs Broken By Brute Force by outlander78 · · Score: 2, Insightful

    Encryption is not a permanent thing; encrypted data is *always* vulnerable after a time. The question is how long the data is protected for, and this is a functino of time. Either an elegant method will be revealed, or a system (software and/or hardware) will be powerful enough to break it using a brute-force method. Note that for the brute-force method to matter, it has to be within a given time frame. (e.g. decoding a VISA number sent over the web within microseconds is useful; within days it is not)

    --
    cheers,
    Andrew
    1. Re:Broken Elegantly vs Broken By Brute Force by Anonymous Coward · · Score: 2, Insightful
      encrypted data is *always* vulnerable after a time

      Not correct. One time pads are secure forever, as long as the pad is protected from compromise.

  25. Difference between brute force and cryptanalysis by yerricde · · Score: 5, Informative

    Just because brute-force is an inelegant method of breaking encryption doesn't mean it isn't valid.

    Brute force just gives a baseline against which other attacks can be measured. With a brute-force break, it takes the same amount of time to break one key that it takes to break any other. With a cryptanalytic attack, on the other hand, you only need to successfully attack one key as a proof of concept; once you've expended the effort to break one key cryptanalytically, you've broken the system and probably reduced the effort to break a key by a couple dozen orders of magnitude relative to the baseline.

    --
    Will I retire or break 10K?
  26. Arms race by coryboehne · · Score: 4, Insightful

    Cryptography is (and I assume will likely always be) an arms race of sorts... You create a new cryptographic cypher and instantly there are people out there whom are willing (some for the potential prize money, most simply for the pleasure) to spend a great deal of time and effort to crack the encryption. The advent of quantium computers however is an interesting problem for cryptographers, as a cypher that now takes years to break will only take seconds/minutes with a quantium computer, once again the arms race is on, and I don't beleve that one side will ever prevail as the absolute end-all solution. As computers get more powerful and people become more savvy there will always be a new way to encrypt data, and a new way to break the encryption. As for me? I enjoy it, and I hope you do too!

  27. Well, she's got a point by Anonymous Coward · · Score: 1, Funny
    I didn't want to, but I'm forced to agree. Except for:

    Ji okuyo ka gikulo wigi piny, to jo mochungo osiro lew tong' piny.

    That's just silly.

  28. password SWORDFISH ! by Flamesplash · · Score: 0, Flamebait

    I'm just waiting for the dude in SWORDFISH to crack 4096 bit encryption.

    --
    "Not knowing when the dawn will come, I open every door." - Emily Dickinson
  29. (OT) Slashdot is an English language board by Anonymous Coward · · Score: 0

    Slashdot is an English language board. When posting in a language other than English, please give the common name of the language you are using, and remember that very few readers will understand you.

    1. Re:(OT) Slashdot is an English language board by Dahan · · Score: 4, Informative
      please give the common name of the language you are using

      Why? What good does that do? But since you care, it's in Luo, and is just copied from jaluo.com. Not that that helps you understand what it says...

    2. Re:(OT) Slashdot is an English language board by Compuser · · Score: 1

      What does it say? In English, I mean.

    3. Re:(OT) Slashdot is an English language board by Dahan · · Score: 2
      What does it say? In English, I mean.

      I have no idea... I just found the page by doing a Google search on some of the words. Like I said, knowing what language it's written in doesn't help in understanding it.

    4. Re:(OT) Slashdot is an English language board by matastas · · Score: 1

      It might help me understand how big of an arrogant cock you are.

      I was curious myself. And yes, knowing what language it is might help him understand, or find someone who does. If I'm speaking Afrikaner, and you don't know that, you're screwed, aren't you? Yet if you know I'm speaking Afrikaner, well, you've got a shot (however remote).

      The poster asked a simple question. Being an ass about it is, of course, purely optional, but rather unnecessary.

  30. 4 years? by CySurflex · · Score: 5, Funny

    4 years?? My bird broke all 104 keys on my keyboard in just one day when I mistakenly left the cage door open.

    1. Re:4 years? by Anonymous Coward · · Score: 0

      Actually I counted 88 keys, far short of the 104 keys mentioned. You are claiming victory in a battle that you haven't even fought yet.

  31. "How long" is the question... by Da+VinMan · · Score: 4, Interesting

    ...because no system is uncrackable or unbreakable, given enough time. The question isn't "will anyone ever be able to see my data?". The question a user should ask "how long would it take someone to get into my data and will it matter if they finally do get into it?".

    Purists will argue against that idea, but I am being realistic here.

    --
    Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
    1. Re:"How long" is the question... by Anonymous Coward · · Score: 0

      Well, what if "enough time" is longer than the life expectancy of the universe? I think in that case you could use the word impossible.

    2. Re:"How long" is the question... by Da+VinMan · · Score: 2

      I think you're right since it would be impossible to prove that it's not impossible.

      Umm.... yeah.

      --
      Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
  32. Re:Kama jaluo rade gi joluo wadgic by i_need_no_nick · · Score: 1

    I would moderate this +1 hore-yrrg-rapelcgrq, but noone would be able to break my uber-leet-encryption to read it ;P

  33. A hardened steel padlock IN the fourth dimension by Anonymous Coward · · Score: 0

    would be much more effective.

  34. 163-bit keys bill begin to break when... by inode_buddha · · Score: 2, Insightful

    64-bit computing with very large RAM (and possibly bandwidth) becomes as commom as the current PC configurations, IMHO

    --
    C|N>K
    1. Re:163-bit keys bill begin to break when... by alannon · · Score: 2

      Not to be offensive to the original poster, but how did this get moderated as 'Insightful'? Brute-forcing encryption algorithms do not require ANY significant amount of RAM to do. It involves doing many, many, many TINY calculations very quickly. RAM size and memory bandwidth have no effect on it, since almost certainly all the data and instructions to do the calculations fits either inside L1 or L2 cache.

      Moving from 32 bit to 64 bit functional units on the CPU MIGHT give you a doubling of computational speed, but so will waiting 18 months for the processors that will be twice as fast. So would using 2 32 bit processors instead of 1 64 bit one (which would be more expensive.)

      When it comes to the scale of time it takes to do these calculations, simply cutting the required time in half is barely a scratch in the surface.

  35. too new... to say impossible. by jukal · · Score: 5, Insightful

    (or unfeasible to be exact) The study of elliptic curves - as a branch of mathematics is not very old one. And as Elliptic Curve Cryptography originates from this theory .... I think this is one of the main reasons why it has not yet been commonly approved for mission critical tasks. Currently, yes, we do know that it is pretty(very) strong against brute-force attacks - but there is still a significant chance that a fundamenta flaws or new discoveries are achieved in ECC theory - leading to easy compromise of previous implementations based on it.

  36. More info by blu3b3rry · · Score: 2, Redundant

    http://www.nd.edu/~prinfo/news/2002/10-29c.html http://www.nd.edu/~cmonico/eccp109/ This thing was solve on 10-15.. Kinda old news

  37. ugly decimal ugly by Anonymous Coward · · Score: 0

    Why oh why not just give the bit count in hexadecimal? This just made me angry. It's like shit on a Picasso.

  38. Not a foreign language by Anonymous Coward · · Score: 0

    He used the 109 bit elliptic encryption. Since it has been broken, you should be able to read it, no problem.

  39. Re:Difference between brute force and cryptanalysi by jpetts · · Score: 2, Insightful

    With a brute-force break, it takes the same amount of time to break one key that it takes to break any other.

    Not strictly true. It is possible that a brute-force attack will hit upon the right key at its first attempt. Or indeed, not until the last possible key in all of the keyspace. On average, though, the correct key will be found 0.5 way through the keyspace search.

    --
    Call me old fashioned, but I like a dump to be as memorable as it is devastating - Bender
  40. Weak eliptic curve is great by Anonymous Coward · · Score: 0, Troll

    Weak eliptic curve is great. SSH2 uses weak eliptic curve with digital signatures to prevent a "man-in-the-middle" attack. That being said, this article made some goofs. I understand that they were just trying to show off bc's MP arithmatic. However, it just gets a little old to see poorly implemented crypto as the standard way to show off MP arthmatic. Don't get me wrong, I have Applied Crypto on my night stand and all, but it would be nice to see an arbitrary binomial expansion program or a program to search for Merseme primes. Maybe just a nice Miller-Rabin primality tester or a Blum-Blum-Shub pseudorandom number generator.

    The public number "n" they refer to should be a generator mod q. Primality does not guarantee that n is a generator mod q.

    They mention needing to use larger numbers, but they don't scale it up enough. q should be at least 1024 bits, which is a little more than 16e306, which looks like a couple of lines of digits. The secret parameters xa and xb should be at least 64 bits, more safely 128 or 256 bits. Luckily, as long as xa and xb are large enough, the generator (n) can be pretty small. 2 often works as a generator. (I think the eassiest test for n bein a generator is for each prime factor p of (q-1), n ^((q-1)/p) % q != 1.) One of the main reasons you want (q-1)/2 to be prime is that it makes testing candidate generators easy.

    Also, weak eliptic curve is not an encryption algorithm. It is a key agreement algorithm. Those numers they "sneaked past" Mallory (ka and kb) connot be predicted or controlled without actually calculating them. The whole point is that it's computationally infeasable to calculate discrete logarithms in a large finite field generated by modular arithmatic. If Bob gets ya and can feasably compute xb such that ka= kb = m for some chosen value m, then the whole crypto system is broken. weak eliptic curve is great for generating shared secrets (usually used as crypto keys for encryption algorithms), but cannot be used directly for encryption itself. The simplest way to use weak eliptic curve as part of an encryption algorithm is to generate a shared one-time-pad that is xor'd with the plaintext. The ElGamal encryption algorithm does basically this, the only differece is that it uses modular multiplication instead of xor'ing to do the encryption once it has the shared one-time-pad.

  41. Re:Difference between brute force and cryptanalysi by ChadN · · Score: 3, Insightful

    Furthermore, the article doesn't say how much of the total keyspace was searched (I'm assuming it was a simple exhaustive search algorithm). The time to search 50% of the keyspace, and 100% of the keyspace (corresponding to average and max time to "break" another 109 key, at the same average key checking rate) would be very useful to know.

    But yes, this isn't breaking the algorithm, by any means. In fact, the contest is meant to show how infeasible a brute-force attack is against larger key sizes.

    --
    "It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
  42. Hello? by pclminion · · Score: 2
    Have you forgotten that computing speeds double every 18 months? 54 * 18 months is 81 years.

    If Moore's law holds up that long, I'll eat my hat.

    1. Re: Hello? by Black+Parrot · · Score: 1


      > Have you forgotten that computing speeds double every 18 months? 54 * 18 months is 81 years.

      > If Moore's law holds up that long, I'll eat my hat.

      Bad idea. At that age your digestion won't tolerate hats.

      --
      Sheesh, evil *and* a jerk. -- Jade
    2. Re:Hello? by Emugamer · · Score: 2

      err not to say the first guy was right but 2^54 !=54......
      and if thats not what you meant then could you reexplain it?

      even with moores law... if computing capacity doubles every 1.5 years.... then the equation for it would be something like 0,x integral (4 years * 2 ^ 54)/ (x/1.5)^2
      where x= time taken to brut force this based on current standard
      I think anyone know if that is right and if so is has anyone taken calc in the last 10 years to help me figure that one out? :)

      sorry for the terrible notation but it has been a while

    3. Re:Hello? by chrisleonard · · Score: 1

      Catch-22: Unfortunately, if you started cracking it today, you'd be using today's computers. :o)

      But I agree with you that 54 years is probably the more practical guess. The interesting thing to me is that 54 years isn't very long really. Which means somebody might actually be working on this with some justifiable optimism.

      The main problem I would like to hear a real crypto-head comment on, however, is what the appropriate order of complexity is for "weak elliptic curve" crypto. We are assuming it is exponential - add a bit to the key, and the complexity doubles. But is that right? It certainly might not be. Anybody know the answer?

    4. Re:Hello? by pclminion · · Score: 2
      err not to say the first guy was right but 2^54 !=54...... and if thats not what you meant then could you reexplain it?

      It's precisely what I meant. Each bit doubles the number of operations. Computer speeds double every 18 months. Therefore, for computer speeds to double 54 times (in order to keep up with the keyspace doubling in size, 54 times), you need 54*18 months.

      Yes yes, I appreciate your calculus, but we're talking rough estimates here :) And that would only apply if your computer smoothly transitioned and somehow became faster and faster at the rate of Moore's law.

      In any case, it's certainly different from billions of aeons!

    5. Re:Hello? by Drawkcab · · Score: 3, Insightful

      A little math is a dangerous thing. You've confused yourself completely unnecessarily. He is correct that if Moore's Law were to hold up, then it would take 81 years for computing power to get 2^54 as fast as it is now. Thus in 81 years, we would expect to be able to brute force a key with 54 more bits than one that we can brute force in an equal amount of time now.

    6. Re:Hello? by aaarrrgggh · · Score: 2

      If my math is right, it would be 216 years to solve it given Moore's Law.

      roughly... 2^54 / 2^(n/1.5) = 4 * (2^(4/1.5))

    7. Re:Hello? by Emugamer · · Score: 2

      ahh okay .. makes sense now.. brain must not be fireing on all synapses..
      you are basically saying that every 18 months the equivilent of one bit of difficulty is removed so you have the 54*18 and then have the extra four years of figureing out the current 109 key alright ...
      anyway I was basing my system on the distributed computing method assumiong an even upgradepattern with nill participant growth

      thanks for the clarification.. would still love to know the asnwer to the calc problem

    8. Re:Hello? by Emugamer · · Score: 2

      it makes sense now.... just lost of his steps ( unused math mind deteriorates quickly with management....)
      Got an answer to the calc question?

    9. Re:Hello? by 0xA · · Score: 2

      Moore's law has nothing to do with speed, it is about transistor density.

    10. Re:Hello? by AndrewRUK · · Score: 1

      would still love to know the asnwer to the calc problem

      Assuming I haven't messed it up (which is not entirely unlikely, given that I'm trying to do integration at 1am on /. from a novel notation) it gives a divison by zero. And something tells me that the time to brute for a key wouldn't be infinity. So, what's wrong, my integration or your formula? (or both?)

    11. Re:Hello? by Anonymous Coward · · Score: 0

      True, but then again, that only assumes you use a single procedure to try to do it (for 216 years?).

      I wonder if anyone is taking into account the fact that we are also constantly expanding our knowledge of math and science and becoming more efficient in its usage to solve problems.

      I hope we aren't using the same formulas 216 years for now to solve complex problems... then again, 2+2 has equalled 4 for a long time now (there still isn't a more efficient way to add).

      I'd be optimistic and say in less than 10 years this problem could be history given the following: The continued adbundance of readily available computational power (that is constantly increasing in power), The continued creativity of scientists and mathematicians, and the fact that if it's a challenge, if it's difficult, someone will do it (who probably otherwise didn't care before it was a challenge).

      Hopefully, the trends do not continue and it doesn't turn out to be someone's 8 year old who figured it out while writing programs to copy and share the DNA of his neighbor's purebred dog on Internet 4.

    12. Re:Hello? by vandy1 · · Score: 1

      Assuming computing speed doubles every 1.5 years, and we only start working on it when we can solve it in 4 years, *I* get 85 years, so hence it is less than that. Sorry - your maths must be wrong :)

      Michael

    13. Re:Hello? by Emugamer · · Score: 2

      its mine ...

      I think its integral from 0 to a for that equation solve for what value does a need to be for the integral to = 2^58 .. I dunno its late and I really can't rethink this right now... anyone else want to have a go? :p

    14. Re:Hello? by muyuubyou · · Score: 1

      Not necessarily. In a brute force attack, you can store your progress and continue with different computers. For instance, since you are testing ALL the keys from 0 to 2^163, you can go in straight order starting from 0. If you reach, for example, the key 2^90 in 1 year and the key wasn't there, you can then use another computer to continue from there. Add to that the fact you could be using clusters (you should be, so you don't get fucked by a machine failure) that allow adding elements during operation. That would work for not only brute-force, but ANY attack. Well, not everybody seems to have EXACTLY the same concept of brute force, partly because it doesn't always apply in the same way to problems.

    15. Re:Hello? by chrisleonard · · Score: 1

      True, but my point was just that you couldn't start with computers from 54 years (or whatever) in the future. :o)

      I just wanted to start a thread where people would talk about the problem intelligently and mathematically, so I started with the simplistic math just to generate some excitement (it appears I succeeded!). Kind of like bad journalism. Maybe I should be censored by the /. community for this - nobody every does stuff like that on these pages, right?

      Seriously, I've done lots of advanced math, but I quit a decade or so ago, and so now I'm at a point where I was interested in seeing the good math, but was feeling far too lazy (read: efficient?) to do the math myself.

      Several posters made some interesting comments, but the post that finally came up with what I thought was the most useful information can be found here.

  43. Don't forget computer processesors speed up too... by Mustang+Matt · · Score: 2

    It took 4 years... How slow were computers 4 years ago, how slow are they now?

    How long would it have taken if they just started this year on today's hardware?

    With the introduction of faster chips and memory, it might only take another 4 years.

    --
    The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
  44. Rep:secure enough. decimal . by Anonymous Coward · · Score: 0

    Why should I listen to you when you are clearly too stupid to understand number bases. Your use of decimal shows your lack of any sort of intelligence.

  45. Mod this guy up as Funny by Mustang+Matt · · Score: 2

    I already posted in this topic so I can't mod right now.

    --
    The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
  46. INSECURE?! LOL by ltwally · · Score: 2, Funny

    Relatively insecure? Forgive my ignorance, but didn't it take over 10,000 computers blasting away to defeat this thing?

    Personally, I feel that if the CIA or NSA wishes to spend that kind of processing power just to break in my research paper notes, let them. Hell, I'll even donate my computers to the project to help them. ;)

    --



    /dev/random
  47. Rep: Decimal...is..evil. by Anonymous Coward · · Score: 0

    Clearly your brain cannot comprehend number bases, so why are you talking about bits? Let me clue you in, a bit is a digit that can take either the value of zero or one. Ok, you learned something today. Your use of decimal indicates your inferiority.

  48. Rep:No code is impossible... decimal . by Anonymous Coward · · Score: 0

    How does it feel to be stupid? To be totally unable to comprehend anything other than decimal? I'm wondering what you mean by "bit" here since you are cleary too stupid to know what it is. Learn that first, then you can move to hexadecimal, you idiot.

  49. Is my front door broken? by DrSkwid · · Score: 3, Insightful

    As brute force will open it, even if that means making every possible shaped key or just the mundane big enough hammer.

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    1. Re:Is my front door broken? by CmdrSam · · Score: 1

      Your front door may be open, but it's not any easier for me to get into any other door.

      Now, if I developed the algorithm of going in through the window, which I could use on every house in the neighborhood, that might be cause to say the system of relying on the door to keep your house secure has been broken...

      --Sam L-L

  50. can anyone help me figure this one out? by Emugamer · · Score: 2

    I haven't done calc in such a long time ...
    assuming the key is 54 bits longer and therefor 2^54 times harder to brutforce. How long would it take to solve if you started now and included moore's law?

    even with moores law... if computing capacity doubles every 1.5 years.... then the equation for it would be something like 0,x integral (4 years * 2 ^ 54)/ (x/1.5)^2
    where x= time taken to brut force this based on current standard
    I think

    anyone know if that is right and if so is has anyone taken calc in the last 10 years to help me figure that one out? :)

    sorry for the terrible notation but it has been a while

  51. Security for the Masses by Oculus+Habent · · Score: 5, Interesting

    It's interesting to see graphs of cracking power.

    RC5 took almost 5 years to crack, but take look at the graph. At the beginning of 1998 there were about 15 GigaKeys/sec. Then look at the increase.

    Sure, a fair portion of the increase was also the addition of new computers, but 261 days to double is comfortably below Moore's Law. If the whole project had run continuously at 200 GigaKeys/sec, it would have taken under 2.5 years, and under two years at their reported peak rate of 270 GigaKeys/sec.

    So, if we follow the 261 day doubling statistic they had, all these encryption methods seem weaker than reported. The big issue is if it's 4 years now, it's 1 year soon, and 3 months, soon after.

    If the cracking power scales nearly linearly, shouldn't we make some projections on how fast we can crack this encryption in a year? In two years?

    If your data is very time sensitive, then most "strong" encryptions currently available will do. If your data is, however, of a continuously sensitive nature (some corporate or government info), maybe you should be looking at the 1000+ bit keys now.

    --
    That what was all this school was for... to teach us how to solve our own problems. -- janeowit
    1. Re:Security for the Masses by Entrope · · Score: 2, Informative

      261 days to double is below Moore's Law? I'm sure Gordon Moore would like to hear this. The usual expression is that semiconductor (whatever) doubles every 18 months. If you say speed doubles every 18 months, that's about 540 days -- comfortably LONGER than 261 days.

      1000+ bit keys (or larger) are mandatory for secure large-prime public key systems now, but they are overkill for elliptic curves. Adding one bit to an ECC key gives relatively more strength than adding one bit to an RSA key does; that 109 bit ECC problem is already roughly comparable to factoring a 512 to 640 bit product of large primes.

      But thanks for playing anyway.

    2. Re:Security for the Masses by Anonymous Coward · · Score: 0

      You might want to read what he said again...

      If I said it took me 261 days to do something and it took you 540 days to do the same thing, my time would be "comfortably below" yours.

    3. Re:Security for the Masses by Dionysus · · Score: 1

      All encryption can be broken given enough time. It's really a matter of how long your data is sensitive, and then choose your keys accordingly.

      Not disagreeing with you, just wanted to add something.

      --
      Je ne parle pas francais.
    4. Re:Security for the Masses by Anonymous Coward · · Score: 0

      But of course it's going to have a greater increase than Moore's law(I know moore's law relates to transitior density, but we'll ignore that for now).

      With something like distributed.net you have the speed of systems increasing, and you also have the number of systems increasing, this would most likely give you an exponential rate of increase.

    5. Re:Security for the Masses by Anonymous Coward · · Score: 0

      but take look at the graph... but 261 days to double

      Did anyone look at that graph? It looks more logarithmic to me than that quadratic looking line they have there. I suspect some over-optimistic curve fitting afoot.

  52. Rep: -1 decimal . by Anonymous Coward · · Score: 0

    Your use of decimal indicates your stupidity. Stupid people shouldn't be allowed to post. Use hexadecimal. Idiot.

  53. Quantum? by mindstrm · · Score: 2

    It is my understanding that with quantum cryptography.. it's not that the message is unbreakable, but that it is not possible to intercept the data without leaving a trace.

    So you can break it, but everyone will know you did, ie: you can't eavesdrop.

    1. Re:Quantum? by vidarh · · Score: 2
      Ah, but that combination means that you can do quantum cryptography that is unbreakable (as in there is no way of attacking the algorithm itself - you can still attempt to bruteforce it, as you can with any encoded data you get hold of):

      First you transmit a random stream of bits, and you verify which bits weren't eavesdropped on. Then you use the bits you know isn't in the hands of an adversary as a onetime pad for the real message.

  54. great content guys... keep it coming by Anonymous Coward · · Score: 0

    God,

    With all the bullshit and nonsense those editors are posting from very valid articles everyday, I think it's time for the community to either
    1) pay these guys a degree
    2) hire someone who can actually read technical stuff and FIGURE OUT WHAT IT MEANS before they write headlines about it
    3) Complain here anonymously to keep your karma :)

    Really editors, if you don't want most people to believe you're long haired teenagers with no clue whatsoever, please read the articles before you post :)

    --
    SELECT * from editors where clue > [...]
    you know

  55. clarification by binaryDigit · · Score: 2

    OK, I didn't explain very well. The thought was that if I use the same key to encrypt all my data, doing the key refresh would prevent someone who got a hold of a piece of my data from cracking it, discovering my key, and then being able to subsequently decode all my data. This was assuming that they wouldn't get their grubby hands on all the data at once anyway, more that they might capture some data as it was being transmitted.

    1. Re:clarification by merlin_jim · · Score: 2

      The problem with that is why symmetric encryption is being used less frequently, except in certain sectors.

      How do Alice and Bruce agree on a key to use without giving Charlie a chance to intercept it?

      There has yet to be a better answer than:

      Alice gets on a plane and goes where Bruce is, where they proceed into a concrete bunker, inside a faraday cage, into a pitch black room filled with white sound generators, where Alice whispers sweet nothings into Bruce's ear.

      The quantum-crypto-over-fiber guys are coming close to it, using the polarization of photons to convey meaning.

      --
      I am disrespectful to dirt! Can you see that I am serious?!
  56. It's *NOT* broken!!! by wirelessbuzzers · · Score: 4, Insightful

    Elliptic encryption is not broken. FEE is still secure, as are all the other well-implemented versions of the encryption out there (unless the NSA has some big news they're not telling us...). Geez.

    What happened is they brute-forced a 109-bit key. That's a small key. The minimum used in this company's product is 163 bits. While I wouldn't call this "impossible," it certainly is computationally secure for several years, and that's the minimum size.

    When distributed.net cracked the 64-bit RC4 key, you didn't hear anyone saying "Oh no! OFB stream ciphers are broken!" That's about what this article amounts to: they brute-forced a small key, and /. claims the algorithm is broken.

    --
    I hereby place the above post in the public domain.
  57. Re:ALMOST no code is impossible... by kakos · · Score: 2, Informative

    Actually, you're almost right. But so very wrong. There is one cryptosystem that is IMPOSSIBLE(!!) to break: the One Time Pad. With that exception, it just becomes very hard. Another thing to realize about these codes is that *none* of them are provably hard. They are thought to be hard, but some mathematical genius might come out tomorrow with a fast method of computing discrete logs, or factoring primes, or figuring out elliptic curves. For now, it is practically impossible, but it might very well be trivial should such a breakthrough occur.

  58. A little math by Pedrito · · Score: 2, Redundant

    Okay, let's do some math here. The guy used 10,000 computers and he won $10,000. It took 549 days to crack it. Okay, well, that's $1.00 per computer, so that works out to a little under 0.2 cents per day per computer. Now subtract the cost of electricity, and how much did he make? Hmmm, that was worthwhile.

    I mean, it's one thing if you don't know if it can be done, then you get the thrill of proving it can be done, but if you're just brute-forcing the damn thing, which it sounds like what happened here, then all I can say is, what a waste.

  59. find the message by Anonymous Coward · · Score: 0

    To ka kar iko ogik dhako ma youre dhi omo pi e aora gi dapi; to dapigni oting'o gi dier wiye lilo . Yuoreno olo pi e tago to yuoche mamoko omake ka gikete e thigo mar dhood dhako maduong' kanyo ema mon go luokoe kitundu. Giluoko lwetene gi tiendene; giluoko fuondege e oigla, oswaro kata tawo, to ka ojadwar giluoke e agulu bende. To ka giseluoke, yuochego lute ebur. Kiluto ng'ato e bur moro amora ok nyal ywak kata goyo koko nikech gikowe gi kwe. Ji okuyo ka gikulo wigi piny, to jo mochungo osiro lew tong' piny. To ka dhok pod ok odonjo e kul ok ginyal ike; gipero lowo, kata giumo bur gi pien kata thigo. Ka dhok osedonjo eka giike e kar saa apar ga ariyo ka chieng' podho.

  60. Something most fail to realize by Kaz+Riprock · · Score: 2


    This is the first and only person to break their 109-bit key. They took over 500 days with 10,000 computers worth of power. This is by no means an average time or even the upper limit of the time necessary.

    You *could* crack the 109-bit key tomorrow if you started in the morning and your 10th inputs were somehow lucky enough to be the right ones. Or, you could start tomorrow and have it take 10 years instead of 2. The more important thing is: of the 109-bit possibilities (2^109?), how many did the 10,000 computers have to go through in 500+ days to finally reach the correct inputs?

    Until we truly do have *impossible*-to-beat encryption, we still have to rely on making higher and higher improbabilities to reduce the chance that someone could stumble onto the correct input to break even 1024-bit encryption in a day.

    --
    Mordor...a magical, mythical land where women are more rare than dragons--but where every man would rather find a dragon
  61. Assumptions assumptions! by bugnuts · · Score: 4, Interesting

    It may be computationally infeasable, but that claim is made using certain assumptions which may be wrong.

    An example of such an assumption is that it takes n log(n) time to sort a list of n elements, using the best sort possible. The proof of this is based on the compare statement. However, there are sorts that work in O(n) time, not O(n log(n)) such as a radix sort which does not use the comparison operator (a/k/a "if-then-else").

    The assumptions made are that brute-force is the only way to break this code.

    I don't know of any attacks on elliptic curve crypto, when implemented correctly. That doesn't mean they don't exist using different assumptions, different number systems, or different computer hardware. (Quantum computing looks very promising to destroy our complacent attitude toward "computationally infeasable" problems.)

    1. Re:Assumptions assumptions! by vandy1 · · Score: 1

      As an aside, may I ask what a radix sort is, and what its drawbacks are? After all, my STL doesn't seem to be implementing it :)

      Michael

    2. Re:Assumptions assumptions! by bdash · · Score: 1

      Lots of information about the radix sort is available. Data Structures and Algorithms: Radix Sorting describes the algorithm and its performance characteristics, and Radix Sort Revisited describes how to work around the problem of sorting negative floating point values, as well as reducing the complexity and increasing temporal coherence.

    3. Re:Assumptions assumptions! by CableModemSniper · · Score: 1

      Augh radix sort. Last question on AP CS test...This is how a radix sort works. Implement it. That was fun. No wait, no it wasn't. Can I switch majors yet?

      --
      Why not fork?
    4. Re:Assumptions assumptions! by NovaDenizen3 · · Score: 1
      However, there are sorts that work in O(n) time, not O(n log(n)) such as a radix sort which does not use the comparison operator (a/k/a "if-then-else").

      Bullcrap. Radix sort works in O(ln(m) * n) time where n is the number of elements and m is the size of the key field. Since m has to be greater than or equal to n to have a unique sorting order, O(ln(m)*n) is greater than O(ln(n)*n).

      If you make the idiotic assumption that the key field is of a fixed size, then you are no longer permitted to use the big-O operator. big-O is only defined in the asymptotic case, where you take the limit as all relevant variables are increased to infinity. You might as well say that bubble sort is O(1) in the case where n is smaller than 100.

    5. Re:Assumptions assumptions! by bugnuts · · Score: 2
      Radix sort works in O(ln(m) * n) time where n is the number of elements and m is the size of the key field.
      Perhaps, but m is a small constant.

      Since m has to be greater than or equal to n to have a unique sorting order...
      wtf are you talking about? M does not have to be greater. m is the number of times you process the N elements, and will be a constant. You're sorting them by a single part (say, a digit), so m could be only 10 for a 10-digit integer. It could be higher or lower. Using a correct implementation you actually end up with a large coefficient, but O(n) is the same as O(10n). You do not end up with O(ln(m) * N), unless the ln(m) is actually merely a small constant which is determined independently of N upon implementation. In that case, it is still a constant. Let's even say it was a LARGE constant, the big-O remains the same.

    6. Re:Assumptions assumptions! by bugnuts · · Score: 2

      lol, nm. You're making assumptions. And your assumptions were wrong about my statement. (gee, what's the title of this?)

      The above example isn't necessarily referring to a generalized radix sort, which you assumed. Key length can be held constant if you have any idea of the range of your input, yielding O(n) time.

      Now, if you have an idea of the range of your input using a quicksort, you gain no real bonus because of the comparison operator. It is always O(n ln(n)). The only time it would beat a radix sort is if n was small, or compatably pre-sorted.

      And I'll add, lastly, your trollish attitude will get you dismissed sooner than get a response.

    7. Re:Assumptions assumptions! by NovaDenizen3 · · Score: 1
      When you say 'm is a small constant' you are again making a totally inappropriate assumption about limiting the key field size. When you make that assumption you're no longer allowed to use the O() operator because it is solely defined in the asymptotic case where all relevant variables are increased towards infinity, including m.

      Perhaps I wasn't very clear with my intended definition of m. If the key field is 16 bits, then M is 2^16, not 16.

      Anyway, switching to your intended definition of m, O(m) still must equal or exceed O(ln(n)) in order to have a unique sorting order. The execution time is O(m * n), which still equals or exceeds O(ln(n)*n) no matter how you slice it.

  62. Here's an idea: by Anonymous Coward · · Score: 4, Interesting

    So now we know distributed efforts can solve great big math problems. Don't get me wrong, that's good to know and all, but.. aren't there any math problems that would be of more use than giving people with 210 IQs something else to bicker over during Star Trek conventions? Really, I'm an engineer, and sometimes I actually have to use math to do things like MAKE A FRIGGIN CAR OR SOMETHING.

    There are plenty of nontrivial engineering problems out there, especially when you take a trip into thermodynamics and fluid flow. Let's solve those. Or sequence the human genome to grow an extra arm or something. Or better yet, let's put the computing power of mankind to work to randomly generate a script for Episode 3 that won't make us want to beat Lucas senseless with our plastic lightsabers. Why can people scrape together all these prizes for pointless pseudo-intellectual drivel but nobody can get some money behind something worthwhile, or at least interesting?

    Here's an idea: Instead of using distributed computing for all this junk science, let's start a central distributed network. This network would have a basic interface element for all the major OS configurations, and would be able to update from the web with whatever mathematic formula and trial space it was supposed to run at a given time. Everyone everywhere could download the client, and set it up to run with whatever processor load they wanted, update on a schedule, maybe vary processor load on a schedule so it works extra hard when you're not using the system. Not much of an interface really. Then some organization, say the NSF or better yet an international science conglomerate, could alot portions of the system load to projects they deemed worthy, depending on complexity and value. The cost is basically nothing, in fact since you could get somebody on the planet to write the code for free one weekend, and the bandwidth would likely be rather low, you would most likely not be talking about the cost of funding a minor research project. Users could still run other distributed clients if they wanted, and the system would be completely voluntary. But it would attract a lot of attention and users, do some good for mankind, and direct our computing power in positive directions.

    1. Re:Here's an idea: by ealar+dlanvuli · · Score: 1

      Thats a good idea, shoot me an email if you ever start such a venture and I'll think about helping you :)

      --
      I live in a giant bucket.
    2. Re:Here's an idea: by puppet10 · · Score: 2

      Here's the distributed computing project for you:

      http://folding.stanford.edu

      --
      -------- This space intentionally left blank --------
    3. Re:Here's an idea: by crimsun · · Score: 2
      Hmm...this sounds vaguely akin to the Treehouse project in Tad Williams's
      • Otherland
      . :)
    4. Re:Here's an idea: by wcbarksdale · · Score: 1

      The problem with distributed computing is that it only lets you get at the problems that are just out of your reach. If you used all the computers in the world, you could not find the exact solution for the travelling salesman problem for 1000 cities.

    5. Re:Here's an idea: by Anonymous Coward · · Score: 0

      I always find it amusing that when the articles are duplicates, so are many of the comments.

      You did post as an AC, though, so you can't be accused of karma whoring.

  63. So boring by Anonymous Coward · · Score: 0

    When I was little, I loved to write computer programs that would count. They'd start at one and count upward, and I'd keep track of when it gained decimal places.

    Pointless, right? Well, does this cryptography cracking have a point? We know that the algorithm will be cracked when the right key is hit. It's just as much electrowanking as jumping up and down when your computer counts to a million, with a bit of cryptography politics thrown in.

    I don't get why people are drawn to these projects over more significant problems like OGM or protein folding.

  64. Re:Rep:Something most fail to realize. decimal . by Kaz+Riprock · · Score: 0, Troll

    I don't even know why I'm dignifying this with a response....but after 01 in binary is 10.

    I even use a binary clock, smartass. At the tone, the time will be 111 : 000 PM EST....ding.

    --
    Mordor...a magical, mythical land where women are more rare than dragons--but where every man would rather find a dragon
  65. Re:Arms race & Quantum Computers by jpmorgan · · Score: 2
    Hmm. Quantum computers are often granted remarkable properties that actually go beyond what we know is actually possible. While a quantum computer is provably 'faster' than a classical computer, this doesn't mean that you can just take a normal program that would run on a classical computer, compile it with your quantum compiler and observe an exponential improvement in performance.

    While it might be possible that a certain algorithm can be cracked exponentially faster with a quantum computer, you still have to find that algorithm. RSA is dependent on factoring large numbers, and is weak against quantum computers due to Shor's algorithm, but that doesn't imply all public key cryptography is.

    As far as I'm aware nobody has conclusively determined whether or not quantum computers will be able to break elliptic curve cryptography any faster than classical computers, but there are algorithms (based on coding theory) which have been proven to be just as secure against quantum computers as they are against classical computers.

  66. Rep :Money going to good cause . decimal . by Anonymous Coward · · Score: 0

    A good cause would be to get you a brain transplant so we'd have one less decimal infected brain around. Moron.

  67. Perfect encryption by jpmorgan · · Score: 2

    We do have perfect (i.e., impossible to break) encryption. It's called the one time pad, and is a very old idea.

    1. Re:Perfect encryption by Kaz+Riprock · · Score: 2

      Sorry, I don't have time to walk a new secured pad to everyone I want to have access to my encrypted data every time I have something to send.

      Off course, that also doesn't take into account the non-randomness of the created pad (I misplaced my quantum event counter...).

      Maybe it'd be better if I said "until we have a truly impossible to break encryption system that is worth using for realistic situations...".

      "As a practical person, I've observed that one-time pads are theoretically unbreakable, but practically very weak. By contrast, conventional ciphers are theoretically breakable, but practically strong." - Steve Bellovin (taken from http://www.ranum.com/pubs/otpfaq/index.htm )

      --
      Mordor...a magical, mythical land where women are more rare than dragons--but where every man would rather find a dragon
  68. Weak Elliptic Curve Cryptography Broken by Dunark · · Score: 3, Insightful

    I have a question about brute-force attacks on encryption: How do you know when you've found the right key? Suppose I encrypted my data twice. A brute-force attacker could test *every* possible key (to the outer encryption) and get trash every time.

    1. Re:Weak Elliptic Curve Cryptography Broken by Anonymous Coward · · Score: 1, Insightful

      This is effectively equivalent to a single encryption with twice the key length. That's assuming the encryption algorithm is known, which is a given here.

      Imagine you encrypt twice with two 109-bit keys, using algorithm A such that encrypted = A(key, data). Then let algorithm B be defined as:
      break the key into two halves, 109 bits each
      decrypt the message using msg = A'(key1, encrypted)
      decrypt the result using data = A'(key2, msg)

      This implies that the encryption/decryption algorithms are roughly linear in the number of bits in the key, but search time is exponential in the number of bits. Which is what we'd expect.

    2. Re:Weak Elliptic Curve Cryptography Broken by Dunark · · Score: 2, Interesting

      "...assuming the algorithm is known...". Isn't this a great weakness of all codebreaking efforts? I think another weakness is the need for a quick way to recognize properly-decoded data. It doesn't matter how fast you can do test decryptions with candidate keys if you don't have a near-equally-fast way to test the results and recognize a success. If you have no idea what the decrypted data is supposed to look like, you're pretty much screwed.

    3. Re:Weak Elliptic Curve Cryptography Broken by vandy1 · · Score: 1

      Well, the reason is is that you start off knowing the public key, and then you keep plugging values for the private key in until you get something that makes sense, i.e. gives you the public key. *That's* when you know you've got it.

      N.B. That's only for assymetric, or public-private key encryption. For shared secret, you probably need several messages to figure out what it is, and encrypting it twice does work, i.e. sends them off the trail.

      HTH

      Michael

    4. Re:Weak Elliptic Curve Cryptography Broken by Hays · · Score: 1

      Yeah this is the thing that blows my mind about all these competitions, and maybe I'm just an idiot... but without knowing the exact message you're looking for, how do you know when you've broken it? Even if you're looking for plain text, it seems like you could get so many false positives in the form of grammatically valid statements that it would be of no use.

      People always (see 100 posts above) use these competitions to draw conclusions about when the government could break your emails with supercomputers or something to that effect, but even if they know how you encrypted it, and even if they know it's written in english plain text, how would they know when they've properly decoded a short message? Maybe I'm just missing something here...

    5. Re:Weak Elliptic Curve Cryptography Broken by mamba-mamba · · Score: 2

      I've always wondered about this, too.

      I think that they must just do a randomness test on it. I believe that a message decrypted with the wrong key would still be highly random, whereas a message of interest would contain a great deal of highly evident non-randomness.

      One way to look at it is this: if you attempt to decrypt a message with the wrong key, you have, in fact, encrypted it a second time. You wouldn't expect the doubly encrypted message to make any sense or be obviously non-random.

      Another way to look at it is this: the key space is MUCH smaller than the space of all messages of the correct length, so chances are slim that the wrong key would give a message which looked anyting but random.

      I have never done this, but maybe I will now: I'll try to brute force decrypt a file of my own. I'll encode it and then actually try decoding it with a series of keys, and do some simple statistical tests on the output. For example, I can test the hypothesis that all bytes in the file appear with equal frequency, and if I can reject that hypothesis at some confidence level, then I'll know I've found the key. I'll have to brush up on my statistics first, I guess.

      --
      MM

      --
      By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
    6. Re:Weak Elliptic Curve Cryptography Broken by Shimbo · · Score: 1

      I have a question about brute-force attacks on encryption: How do you know when you've found the right key?

      That depends on what you're encrypting. If you encrypt a random stream of text, you don't in general with a shared secret key. For plaintext, you usually need some sort of crib. A lot of people got thrown on the Enigma decrypt in Simon Singh's code book because he coded spaces as X (Enigma had no spacebar), throwing their frequency analysis check on the 'plaintext' out. Don't overestimate the security of hacks like using multiple crypto algorithms though.

      For public key algorithms, like elliptic curves, it's dead easy. You can choose whatever plaintext you like and encrypt it with the public key. In practice, it will be simpler than that: for RSA if you think you know what the factos are, just multiplying them will tell you if you're right!

  69. But what exactly does this all mean? by stevejsmith · · Score: 1

    Hm...sorry to be ignorant, but what exactly does 109-bit eliptic encryption mean? Does that mean there are 2^109 possibilities, or what? And if it does mean that, how long exactly would it take for a computer to try a possibility? One per second? Sorry if I'm completely off with my estimations.

    And regarding the fact that it took four years to crack: even if it took three days to crack, couldn't somebody just change around the key every couple of days? That seems like a much more effective way of guarding data. Anything that can still be fresh in four years can easily have the key changed!

    1. Re:But what exactly does this all mean? by Anonymous Coward · · Score: 0

      That doesn't make much sense, does it? I mean if the guy trying to crack your data has a copy of it with key x, and keeps working on that copy, what does it matter if you re-encrypt your copy?

      Maybe I'm just too old to understand computers now.

    2. Re:But what exactly does this all mean? by stevejsmith · · Score: 1

      You could have a password to get to the data (you could make it thousands of characters long so that it would take way too long to crack), and then have a key to get to the password. Would that work, or would it be too easy to crack the thousand-character password?

  70. Think of EMP shielding by gelfling · · Score: 4, Interesting

    Back in the day when we worked on EMP shielding, no matter the elegance of the solution it all came down to raw force. If you wanted to shield to 100 MEV then all your opponent has to do is create 110 MEV. *Poof*

    "Give me a big enough hammer and a place to stand and I can break practically anything"

    -Archimediocrates

    1. Re:Think of EMP shielding by Kaz+Riprock · · Score: 2
      "Give me a big enough hammer and a place to stand and I can break practically anything"

      -Archimediocrates

      "Give me a big enough hammer and a place to stand and I can break practically anything while making a mess and getting laughs for it."

      -Gallagher

      --
      Mordor...a magical, mythical land where women are more rare than dragons--but where every man would rather find a dragon
  71. So? by Simulant · · Score: 3, Insightful

    Just change keys every three years and you'll be fine.

  72. 4 years THEN... by gotih · · Score: 2

    so it TOOK 4 years to break a 109 bit key. does this mean that it will take less than 2 years if we start now considering the increases in computer speed?

    and should we be using 218 bit keys for data that should be secure for more than 4 years?

    <HUMOR>maybe we should have the cia encrypt and submit to public the domain all of thier classified information. said info would be encrypted with key lengths appropriate for the amount of time they wish the data to be hidden. that would ensure that we all get to know what really happened, safely after those who are at fault have retired and entered hiding somewhere us courts can not punish (like winona ryder's house.

    Though the charges can carry a prison term of up to three years, it is unlikely that Ryder will be sentenced to jail time.)</HUMOR>

    --

    fear is the mind killer
  73. mistaken math by Indy1 · · Score: 4, Informative

    IANAC (I am not a Cryptographer)
    every time you increase the bit length by 1, it doubles the brute processing time it takes to crack it. A 219 bit key is 109 bits longer then a 109 bit key, therefore it would take 2^109 = 6.4903710731685345356631204115251e+32 times as long to crack it. If I recall correctly, the reason why you sometimes see huge keys that are 1024 or 2048 bits long is the possibility that a weakness is found in the encryption technique that makes it a lot faster to brute force the key.

    --
    Lawyers, MBA's, RIAA? A jedi fears not these things!
    1. Re:mistaken math by seschmi · · Score: 1

      The longer Keys you mention (>1024) are usually used for asymmetric encryption (with different keys for encryption and decryption). The algorithms used for this are totally different and the key size is in no way comparable. Furthermore, if a weakness is discovered that makes it possible to break the encryption, a longer key probably wouldn't help much. I remember the example of an important software from a major company, where only 20 bits of a 128 bit key where really used...

    2. Re:mistaken math by merlin_jim · · Score: 2

      If I recall correctly, the reason why you sometimes see huge keys that are 1024 or 2048 bits long is the possibility that a weakness is found in the encryption technique that makes it a lot faster to brute force the key.

      Or to paraphrase Neal Stephenson:

      If someone knew that Avi was using 4096 bit keys, the could conclude one of the following about him:

      a) He is very paranoid
      b) He believes that fundamental advances in cryptographic technique will be made in the near future that will require very strong cryptography
      c) He has a planning horizon of several centuries

      In reality, Randy thinks it is a bit of each.


      If anyone's curious, I strongly believe that every citizen on earth should follow Avi's example, as a little bit of all three of the above can't hurt anyone and might certainly help everyone at some point in the future.

      --
      I am disrespectful to dirt! Can you see that I am serious?!
  74. Re:Arms race & Quantum Computers by coryboehne · · Score: 2

    but there are algorithms (based on coding theory) which have been proven to be just as secure against quantum computers as they are against classical computers

    I am a bit curious as to how they proved this exactly since AFAIK no quantium computer (to date) has ever achevied stability.

    Otherwise though great comment, and thank you for pointing out the fact that quantum computers are not the end all point, as your conclusions and speculations prove my point wonderfully- cryptography is nothing more than an arms race, there will always be someone, somewhere that will take the next step forward, be it creating a nifty new algorithm or figuring out how to break the latest nifty algorithm.

  75. Re:Rep:Security for the Masses . decimal . by Anonymous Coward · · Score: 0

    Most people have ten fingers. That's why we use the decimal number system. Maybe we should examine why you don't have ten fingers. Is your father extremely hairy? Does he bark frequently, and answer to "Fido"? Are your kissin cousin and your mother the same person? Inbreeding IS a major cause of genetic mutation...

  76. $4 billion of computing? by peter303 · · Score: 2

    The article cites 132 million CPU hours over 18 months. At one time my computer center used to charge $30 a CPU hour.

  77. What are the trade offs of adding bits by thistle · · Score: 2, Interesting

    I don't know much about encryption and am curious to know why we don't just choose some arbitrarily high key-length like 500 bits. What is the rational for slowly increasing key size every year? Is there some kind of computational limitation that makes longer lengths undesirable?

    1. Re:What are the trade offs of adding bits by vidarh · · Score: 2

      The longer the key, the longer it takes to encrypt and decrypt the data.

  78. No 'impossible' to see by Wouter+Van+Hemel · · Score: 2
    "[...] but the contest sponsors (who provide encryption products for Cisco, Nortel and Palm among others) believe it's still impossible to break their 163 bit keys."

    'Impossible' is the wrong word to use when it comes to cryptography.

    Perhaps that's why that word is nowhere in the text linked to.

    It's exactly the attitude not to have, if you care about security.

  79. Quantum Crypto and OTP by reverseengineer · · Score: 5, Informative

    One-time pads are uncrackable- mathematical proof exists. That assumes (and it's a rather large assumption) that the rules of using a one time pad are followed.

    Messages encrypted with a OTP have been deciphered in the past, but not from any mathematical failing- people simply failed to correctly follow the rules.

    1. You need a random process to generate the pad. This means random, not pseudorandom. Admittedly, modern pseudorandom number generator algorithms are very complex, and trying to reverse engineer (hey!) a PRNG from just a stream of outputs would be a mammoth task. Rules are rules, however complex- if your pad is pseudorandom, your cipher will only be pseudo-uncrackable. The Enigma produced vey complex keys with a convoluted series of rules, but if you know how an Enigma works, as the Brits did, you can use the ciphertext to help find the key, and then dechiper the entire message. This is one area where quantum mechanics fits in- lots of nice random phenomena arise naturally from quantization- I'll get back to that. Also, the key on the pad must be as long as the message you wish to encode- if you try to encode a 2000-character message by using a 1000-character key two times, your security is no longer guaranteed.

    2. Only use each key on the pad once. That's why it's a one-time pad. If you use the same key more than once, you remove the randomness, and create a pattern that can help the cryptanalyst. Deciphering will still be difficult- but if you wanted difficult, you could have just used triple-DES or RSA or elliptic curve crypto- those are all varying degrees of difficult. You want impossible.

    OTP is unbreakable, if you follow the rules- but the rules are really hard follow. You need random processes, and once you have these neat pads, you face the Key Exchange Problem- if you have an agent out in the field that you'd like to communicate with, and you must communicate in an absolutely secure fashion, you must get a copy of the one-time pad to the agent- it's the only thing that will decipher your messages. However, you can't just pick up the phone and relay the contents of the pad to your agent- the enemy might be bugging your phones- and hilarious hijinks will no doubt ensue when the enemy uses their new your insecurely transmitted pad to read your secure encrypted messages. Encrypting transmission is a good idea, but you can't use OTP to send the first OTP to the agent- how will the agent decrypt his encrypted pad? The classic analogy is that you're trying to send a key (think physical, lock-opening key) in a locked box that only the key inside the box can open. You could encrypt the key with hardass public key crypto, say 1024-bit RSA, but that isn't unbreakable in the same now-and-forever sense as OTP. It would be vulnerable to quantum computers, and vulnerable to any computer if someone discovered a polynomial time algorithm for prime factorization of really gigantic numbers, or if I win a Clay Mathemtics Prize for proving P=NP. You could of course do what the government does for secure key distribution- send couriers carrying OTPs directly to the agent in the field. This is an expensive, difficult, dangerous method, so better ways were searched for.

    This is of course where Quantum Cryptography comes in. Photons all have specific polarizations. You can send a stream of randomly polarized photons through a polarizing filter, and photons with the same polarization angle as the filter will pass, while those with a polarization rotated 90 degrees with respect to the filter are blocked. What then happens to photons that have some intermediate angle? On the macroscale, we can say that the intensity of the light is a function of the angle, and infer that at a 45 degree tilt, 1/2 of the light is blocked, and 1/2 passes through. Enter Quantum Mechanics. It is fairly obvious to see the effect that polarizing filters have on a large scale quantity of light, but what about individual photons? Since the intensity of light at a 45 degree angle is 1/2 its normal value, one can infer that one half of the photons with a 45 degree polarization pass through, while one half are blocked. Simple enough. But if you send just one photon through with a 45 degree polarization, can you determine whether it will pass through? The answer, surprisingly enough, is no. You cannot determine whether a photon will pass through, and you will not know whether it passed through until it hits (or fails to hit) a detector on the other side. Can't determine? That makes it a random process, perfect to set up a OTP. It happens to have some interesting side benefits as well. Since the possibilities are pass and blocked, two possibilities- a string of photons sent at the filter produces a random binary sting of 1's (passed) and 0's (blocked). There is another fascinating benefit- if someone tries to sit in the middle of the photon stream and determine photon polarization, their eavesdropping will be evident- by checking the polarization of a photon in transit, they change the value of the polarization. All two people using quantum crypto need to do is confirm a few values that were sent (this can be done insecurely, since these values will not actually be used in the cipher pad)- if they match up, then send the message, encoded with the OTP, if not, someone is eavesdropping, and so discard the pad. It's a lot more complex than that, of course, but that's the general idea- you can use QC to generate a one-time pad, and then send it in such a way that you know whether or not you're being spied on.

    --
    "FDA staff reviewers expressed concern about the number of patients who were left out of the study because they died."
  80. Re:ALMOST no code is impossible... by adamdeprince · · Score: 1

    Factoring primes? Um, by definition add a "1 x" and you are done.

  81. Re:INSECURE?! LOL by Anonymous Coward · · Score: 0


    Re: your sig

    I haven't seen a geek code since about 1996.

  82. Right... by mindstrm · · Score: 3, Insightful

    Hence, if it doubles in 261 days, that is indeed below the time specified in Moore's law.
    What's your point?

    1. Re:Right... by Entrope · · Score: 2

      If you can harness an ever-increasing fraction of the Internet to do your code cracking for you, it's practical to do better than Moore. Not otherwise.

      Most "bad guys" (whether they are government, corporate, or whatever) cannot afford to double the number of computers they buy every 18 months -- which is what you need to keep that 260 day doubling. The numbers of computers putting time into distributed projects like this only strengthen claims that it is hard to break the encryption.

      The Internet isn't magic dust you can sprinkle on code breaking to make it magically go faster. Why do you act like it is?

  83. Re:Rep:Something most fail to realize. decimal . by Talez · · Score: 1

    Ummm...

    Wouldn't a 24 hour H:M:S clock require 16 bits not 9?

    4 for the 24 hours or 12 hours + sign, 6 for 0-60 minutes and 6 for the 0-60 seconds?

  84. VISA numbers are useful for much longer than uS by anto · · Score: 1

    The good thing about CreditCard numbers is they remain vaild for an amazingly long time - you have a few years in some cases to break the encryption and grab the number - you even have a nice checksum to verify the number you retrieved is valid.. To make it even better they transmit a nice validity date to ensure you dont accidently try and use an expired card.

  85. Re:Rep:Security for the Masses . decimal . by 3-State+Bit · · Score: 2

    I believe your parent referred to the fact that its parent said "1000+" rather than "1024+" bits. Because 1024 seems more "round" to him/her than 1000 does.

  86. Re:Kama jaluo rade gi joluo wadgic by snakecoder · · Score: 1

    I'll rot13 you!

    --
    -Nuke the moon
  87. Back to the future by Cheese+Cracker · · Score: 2

    It took the power of 10,000 computers running around the clock for 549 days, coupled with the brain power of a mathematician at Indiana's University of Notre Dame, to complete one of the world's largest single math computations.

    Maybe we should tell these guys to use modern computers instead of the network of Altair 8800, C-64, VIC-20, ZX81, TI-99/4A and MicroBee computers.

  88. Here it is by pclminion · · Score: 2
    Out of curiosity, I worked it out.

    Assume that in order to break a 109-bit keyspace you need to try half of the keys. In other words, you need to try 2^108 keys. They managed to do this in 4 years. This gives a base rate (rate as of now) of 8.11e31 keys/year.

    Since we assume computing speed increases exponentially, doubling every 18 months, we need to multiply this base rate by 2^(t/1.5), where t is the time in years from the present date. This gives a keyrate of 8.11e31*2^(t/1.5) keys/year at time t.

    Now, we want to break a 163-bit keyspace. Again, we assume we need to try half the keys, so we need to try a total of 2^162 keys. We integrate the rate from time t=0..x on the left, and equate that to 2^162. This gives the equation:

    1.76e32*exp(0.462*x)-1.76e32 = 5.85e48.

    Solving this for x yields x = 82.33 years.

    Quite close to the original estimate.

  89. Not "at least" by Chuck+Chunder · · Score: 2

    If you are exceedingly lucky you might get the key right with your first guess in a brute force attack. The bigger the keyspace the less likely that is. On average a bigger key will take longer to brute force than a smaller key but it is feasible to get lucky and find a particular 163 bit key in less time than it took for that particular 109 bit key. It's just somewhat unlikely.

    --
    Boffoonery - downloadable Comedy Benefit for Bletchley Park
  90. It'll be broken any day now! by evilpaul13 · · Score: 1

    In 4 * 2^54 years!!!

    That's 72,057,594,037,927,936 years.

    Give or take a few of course.

  91. Re:ALMOST no code is impossible... by Ironica · · Score: 2

    The one-time pad is impossible to break, but possible to brute-force. The big difference between the one-time pad and other systems is that the key is never reused, so that even if you manage to crack that key, the system keeps its integrity, since that key is never used for another message.

    Now, just because it's "possible" doesn't mean it's feasible... but I don't exactly call 10,000 computers x 549 days feasible for one message, either. Depending on how the one-time pad is implemented, it may be more or less feasible to crack a single message than this key was, but it's not impossible.

    --
    Don't you wish your girlfriend was a geek like me?
  92. Re:ALMOST no code is impossible... by Anonymous Coward · · Score: 0

    No, no, no.

    Take two primes. Multiply them together. Give that number to someone else. Ask them to tell you the primes you multiplied together.

    Sounds easy? Well, try using prime numbers which are tens of digits long ...

  93. Re:Rep:Something most fail to realize. decimal . by Kaz+Riprock · · Score: 1

    I was too lazy to type out the extra zeros. Be happy I put 3 for the minutes. My binary clock (same as ThinkGeek, same as the gnome tool) does it by the decimal digits anyways (i.e. 12:45 is 0001 0010 : 0100 0101).

    --
    Mordor...a magical, mythical land where women are more rare than dragons--but where every man would rather find a dragon
  94. Re:ALMOST no code is impossible... by reverseengineer · · Score: 1

    Yeah, yeah, the above poster isn't refuting that prime factorization is hard- just that it's not the same as "factoring primes." To say "factoring primes" to many people implies that it is a prime number you are factoring, which is of course easy, since the factors of a prime are 1 and the number itself. You speak of finding the prime factorization of a number, which is ideally a composite, so you break it down into a product of primes. The composite numbers used in public-key cryptography are a little unusual, since they generally have precisely 3 factors- 1, a very large prime, and another very large prime.

    --
    "FDA staff reviewers expressed concern about the number of patients who were left out of the study because they died."
  95. Agreed.. article is kinda pointless without it. by Kjella · · Score: 2

    5%, 50%, 100%? For all we know they could have gotten plain old lucky. After all, there's a 2^-109 probability that I can crack this key by brute force using 1 attempt. Doesn't make much sense to base any judgement on that though.

    Kjella

    --
    Live today, because you never know what tomorrow brings
  96. Depends on the method. by Kjella · · Score: 2

    For instance, many algorithms (not elliptic curves though) depend on factoring being much harder than multiplying. If you've factored it, you also know the only solution that works, because that is the only factoring.

    You might only get trash, but it was the trash you encrypted, not some random trash...

    I don't know enough about elliptic curve crypto to know about that one, but it's very possible that once you have the right key, you will know that that key is the right one.

    There are algorithms that will accept any key, and not give you any clue that you have failed. For instance you can just XOR the text with the password repeatedly. However in my experience that trade-off usually comes with bad protection against known plain-text attacks.

    Kjella

    --
    Live today, because you never know what tomorrow brings
  97. 219 is 109 more than 109? by Kjella · · Score: 3, Funny

    You wouldn't by any chance work for intel, do you? I mean 2+2 = 3.99999998673 is close enough ;)

    Kjella

    --
    Live today, because you never know what tomorrow brings
    1. Re:219 is 109 more than 109? by Indy1 · · Score: 2

      LOL, you caught me with a low blood level of caffiene, my bad : )

      --
      Lawyers, MBA's, RIAA? A jedi fears not these things!
  98. Suggested Reading by seschmi · · Score: 2, Informative

    For everyone interested in cryptographic stuff, I always suggest to read the publications of Bruce Schneier (http://www.counterpane.com). His monthly newsletter "crypto-gram" is very interesting and really fun to read (at least most times) and he produced several books I like very much (especially "secrets and lies", or "Applied Cryptography", if you are interested in mathematics of cryptography)

  99. Project Venona by dachshund · · Score: 1
    Only use each key on the pad once. That's why it's a one-time pad. If you use the same key more than once, you remove the randomness, and create a pattern that can help the cryptanalyst

    Don't underestimate cryptanalysts ability in this area, either. The Soviet Union made the mistake of reusing some of their One Time Pads a few decades ago; as a result, Project Venona, was able to decode enormous amounts of archived (but still useful) secret traffic.

    Don't think traffic that old is useful? Tell it to the spies who were still in place when Venona broke those old communications.

  100. Re:ALMOST no code is impossible... by Insurgent2 · · Score: 1

    Actually, it *is* impossible to break if it's truly a one time pad. Since the is no repetition over the length of the message, all keys are the same length as the message and therefore trying all possible keys will yield all possible combinations of messages of that length and you have no way of knowing what the message is. i.e. Is 46adab8bd51c187c7cab9e = ATTACKATDAWN or ATTACK TODAY With a proper OTP you *can't* know.

  101. Dude... by Anonymous Coward · · Score: 0

    he ate your Dell!

  102. brute forcing your front door. by Anonymous Coward · · Score: 0

    I'll be coming 'round Nottingham to brute force your front door some evening soon. I'm sure you'll find that it is broken after I do that.

  103. Quantum computers by peter · · Score: 2

    attacks on RSA and Diffie-Hellman with a quantum computer can use Shor's algorithm, giving an exponential speedup. Nobody's got a quantum algorithm to attack ECC yet, at least not that I've heard about.

    --
    #define X(x,y) x##y
    Peter Cordes ; e-mail: X(peter@cordes , .ca)
    1. Re:Quantum computers by richard-parker · · Score: 2

      With regard to quantum computers, it is my understanding that with suitable modifications, Shor's algorithm can be applied to ECC. It is unclear if quantum computers sufficiently large to attack cryptographic systems are at all feasible, but if they could be built then all of today's popular asymmetric cryptosystems would be insecure. However, I don't expect a quantum computer sufficiently large to attack 163-bit ECC will be built before 163-bit ECC falls to a more conventional attack.

      The most efficient method published to attack ECC is Pollard's parallelizable rho method, with an expected run time on order of the square root of q group operations. So, while the run time of an attack against ECC is exponential in the size of q, it doesn't grow as fast as an exhaustive search attack against a symmetric key cryptosystem. As a rule of thumb, an ECC key is approximately as strong as a symmetric key with half as many bits, so a 163-bit ECC key is roughly equivalent to an 80-bit symmetric key.

  104. What?? by mindstrm · · Score: 1

    Why do I act like it is? Where did I act like it was?

    The guy said that 260 days was below moore's law, and you told him he was wrong.
    He was right.

    I was responding to that.

    I wasn't saying anything about how relevant Moore's law was to what he was describing.

    I'm not sure when we started talking about magic dust, but maybe you better quit snorting it just to be safe.

  105. Last Post! by alpg · · Score: 1

    VMS Beer: Requires minimal user interaction, except for popping the top
    and sipping. However cans have been known on occasion to explode, or
    contain extremely un-beer-like contents.

    - this post brought to you by the Automated Last Post Generator...