Slashdot Mirror


Parallel Algorithm Leads To Crypto Breakthrough

Hugh Pickens writes "Dr. Dobbs reports that a cracking algorithm using brute force methods can analyze the entire DES 56-bit keyspace with a throughput of over 280 billion keys per second, the highest-known benchmark speeds for 56-bit DES decryption and can accomplish a key recovery that would take years to perform on a PC, even with GPU acceleration, in less than three days using a single, hardware-accelerated server with a cluster of 176 FPGAs. The massively parallel algorithm iteratively decrypts fixed-size blocks of data to find keys that decrypt into ASCII numbers. Candidate keys that are found in this way can then be more thoroughly tested to determine which candidate key is correct." Update by timothy, 2010-01-29 19:05 GMT: Reader Stefan Baumgart writes to point out prior brute-force methods using reprogrammable chips, including Copacobana (PDF), have achieved even shorter cracking times for DES-56. See also this 2005 book review of Brute Force, about the EFF's distributed DES-breaking effort that succeeded in 1997 in cracking a DES-encrypted message. "'This DES cracking algorithm demonstrates a practical, scalable approach to accelerated cryptography,' says David Hulton, an expert in code cracking and cryptography. 'Previous methods of acceleration using clustered CPUs show increasingly poor results due to non-linear power consumption and escalating system costs as more CPUs are added. Using FPGAs allows us to devote exactly the amount of silicon resources needed to meet performance and cost goals, without incurring significant parallel processing overhead.' Although 56-bit DES is now considered obsolete, having been replaced by newer and more secure Advanced Encryption Standard (AES) encryption methods, DES continues to serve an important role in cryptographic research, and in the development and auditing of current and future block-based encryption algorithms."

41 of 186 comments (clear)

  1. Re:searching for ASCII by 2.7182 · · Score: 3, Funny

    Agreed! Also what I do, is before I encode is to switch 1 to 0 and 0 to 1. That'll really confuse'em!

  2. Should be building standardised FPGAs into systems by Colin+Smith · · Score: 4, Interesting

    Apps could load a custom config into the chip to run faster.

     

    --
    Deleted
  3. How do you know when it's decrypted? by petes_PoV · · Score: 5, Interesting
    Apart form the trivial case where some ASCII, or a picture pops up, how can a decrypter know when the block or stream of apparently random data has been decrypted?

    If I was to start transmitting some random data and told people it was encrypted with DES 56 bit, but in fact it wasn't - it was just random data. Then, apart from exhaustively testing it with every possible key, how could they demonstrate that it was NOT encrypted as claimed?
    It does seem to me that one of the problems with decrypting "stuff" is that you need to have some idea what the "answer" will look like. Without that you can't ever be certain when you've succeeded.

    --
    politicians are like babies' nappies: they should both be changed regularly and for the same reasons
    1. Re:How do you know when it's decrypted? by Lord+Byron+II · · Score: 3, Informative

      Exactly right.

      Properly encrypted data should be indistinguishable from random noise.

      The pigeon hole principle applies to the "decrypted" data. Say you have 16 bytes of data protected by a 16-byte key. Then, there will be lots of keys that produce non-random "decrypted" sequences. But, if you have 1GB of data and a 16-byte key, then there is likely (depending on the nature of the underlying data) only one key that will produce the decrypted data.

      It's similar to why there can't exist a generic compression algorithm that *always* shrinks a file.

    2. Re:How do you know when it's decrypted? by txoof · · Score: 2, Interesting

      Even if it's ASCII or a picture, just encrypt it twice.

      I've always wondered what would happen if you were to encrypt a file over and over again, with different keys. Would that lead to any greater security, or would somehow leave more and more obvious clues as to how the data was encrypted? What would happen if you encrypted over and over using the same key?

      --
      This one's tricky. You have to use imaginary numbers, like eleventeen... --Hobbes
    3. Re:How do you know when it's decrypted? by Anonymous Coward · · Score: 5, Informative

      Depending on the cipher, this may, or may not work.

      A common method to enhance the security of DES is/was to do a encrypt/"decrypt"/encrypt cycle, each with a different key. You may know this method under the name of 3DES. While DES is long broken, 3DES is still considered pretty secure, albeit slow. In contrast, using "tripple-XOR" will most likely not increase the security of a cipher.

      And encrypting multiple time with the same key will, for any reasonably secure crypto system*, not increase security. The security incerase in 3DES was due to the increased key length (i.e. the combined length of the 3 keys used in 3DES). Using the same key over and over again does not increase the effective key length.

      *Increasing the number of rounds used internally in a crypto system can in some cases increase the security. Usually, cryptoanalists start breaking reduced-rounds versions of ciphers before breaking the full version.

    4. Re:How do you know when it's decrypted? by BrotherBeal · · Score: 3, Insightful

      ... but I bet you could some how measure how disordered the data stream was and make a guess about weather or not it was encrypted. It seems that encrypted data should also have some level of order to it.

      Encryption doesn't work that way, at least not good encryption. The goal of every encryption scheme is to transform a plaintext input into a ciphertext output that is indistinguishable from random noise. Your example of frequency analysis being used to attack ROT13 shows that it's a terrible encryption algorithm because it leaves so much information about the original message embedded in the transformed output. Every time you hear about an encryption scheme being broken, you're hearing about some way to recover information about the plaintext from the ciphertext. That information is what allows adversaries to beat brute-force decryption (although not always by much - a scheme with a keyspace of 2^n is considered broken if an attack is found that requires only 2^n-1 of the keys to be examined).

      The OP brings up an interesting point, of knowing when your data is actually decrypted.

      This is why a one-time pad is "perfect". A one-time pad leaves absolutely zero information about the original plaintext apart from length (and even that can be obfuscated by null padding). That means that there is no way for an adversary, even through a brute-force attack, to positively identify the original plaintext. Let's say we encrypt "HELLO WORLD" with a one-time pad, and the output is "ZBCHGRTKOP". "ZBCHGRTKOP" could be brute-forced by an adversary and produce "HELLO WORLD", but such an attempt would also produce "BUY MUSTARD" or "URINAL TOWN" or any other string of 10 characters (possibly including nulls - remember padding!). All of these are equally plausible if the one-time pad scheme is implemented perfectly. The point is that, depending on the encryption scheme, in a sense you can't always know that you've done it perfectly. Recreated internal structure is a good signal that you have done it correctly, but if you were trying to decrypt something you knew NOTHING about (couldn't tell it from random noise), you'd have a hell of a time telling whether you screwed up your decryption. Make things any clearer?

      --
      I'm disabling ads until because I choose not to reward redesigns that are less usable than "view source".
    5. Re:How do you know when it's decrypted? by maxume · · Score: 4, Informative

      If the encryption is properly implemented, the repeated cycles should not reveal any information, but it works better to just use a larger key (encrypting twice with 2 different 2 bit keys should be roughly equivalent to encrypting once with a 3 bit key, 4 different 2 bit keys would be equivalent to a 4 bit key and so on, so just going up to a much larger key is probably easier).

      --
      Nerd rage is the funniest rage.
    6. Re:How do you know when it's decrypted? by smallfries · · Score: 3, Insightful

      Why have you bothered to argue a point that you clearly know nothing about?

      Link level encryption. In order to defeat Traffic Analysis it is necessary to fill the channel.

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
    7. Re:How do you know when it's decrypted? by tepples · · Score: 2, Insightful

      it works better to just use a larger key

      That's not always easy, especially if you have sunk a lot of money into crypto hardware that supports only short keys. That's one reason why triple DES took off: existing DES ASICs could still handle it.

    8. Re:How do you know when it's decrypted? by microbox · · Score: 3, Interesting

      And encrypting multiple time with the same key will, for any reasonably secure crypto system*, not increase security.

      I understand that from a theoretical point of view, but from a practical point of view -- how would you break an encrypted file if it is doubly encrypted, even if you knew both algorithms involved. How do you solve the problem of recognizing if you'd actually decrypted with the first key, so that you can start working with the second key?? Haven't you increased the key-space to an exponent of itself (in practical terms), and therefore created something vastly more secure?

      --

      Like all pain, suffering is a signal that something isn't right
  4. What? by trifish · · Score: 4, Insightful

    Parallel Algorithm Leads To Crypto Breakthrough

    Crypto Breakthrough? Huh? What's that supposed to mean?

    I mean, yes, his DES-cracking hardware is about 800x faster than a PC. Where's the "Crypto Breakthrough"?

    1. Re:What? by Colin+Smith · · Score: 3, Funny

      I mean, yes, his DES-cracking hardware is about 800x faster than a PC. Where's the "Crypto Breakthrough"?

      He noticed the previous researcher's "sleep" statements.

       

      --
      Deleted
    2. Re:What? by QuoteMstr · · Score: 4, Funny

      I guess "Interesting Thing This Guy Did with Numbers n' Shit" just doesn't have quite the newsworthy ring to it.

      Nah, if we adhered to normal journalistic conventions, the headline would read something like "Man Causes Pig to Fly using Homemade Rocket".

      Or if this were the New York Times, "In New Development, Swine's Aerial an Inspiration to All" and an editorial the next day, an editorial "Pigs Must Fly Farther, Higher", paired with "Opinionator: Will the Pig Land? Experts Divided. Join the Discussion."

      (Then, on Monday, Krugman's "Why we Need Swine Flight Credits" and Ross Douthat's "When will This Liberal Pig Eat Your Children?")

    3. Re:What? by DigitAl56K · · Score: 2, Informative

      "What?" indeed.

      This is exactly the same technique as the EFF DES cracker used in 1998, except using FGPAs instead of custom chips.

      http://w2.eff.org/Privacy/Crypto/Crypto_misc/DESCracker/HTML/19980716_eff_des_faq.html#howsitwork

  5. Too bad... by mister_playboy · · Score: 2, Insightful

    FIrst post!

    Your encryption was cracked, and you didn't post first.

    Just not your day. :)

    --
    Do what thou wilt shall be the whole of the Law ::: Love is the law, love under will
    1. Re:Too bad... by NatasRevol · · Score: 2, Funny

      Don't blame him. He's not using FPGAs so his encryption takes a long time!

      --
      There are two types of people in the world: Those who crave closure
  6. Interesting but not shocking by Shrike82 · · Score: 3, Informative

    DES is obselete anyway, though the way the decryption was carried out is fairly interesting. A little bit of homework shows that (apparently) a 56-bit DES key was broken in less than a day over ten years ago. So he's a decade late and 66% less efficient!

    --
    You can advertise in this sig from as little as £99.99 a month!
    1. Re:Interesting but not shocking by arcade · · Score: 4, Informative

      apparently?

      Loads of us slashdotters was part of distributed.net's effort.

      I had 3 of my home computers running rc5des, and about ~200 university computers running it too. :)

      And you come up with this "apparantly" thing?! Less than 20 years old, prehaps? Born in the 90s? Not remembering? Harumpfh!

      --
      "Rune Kristian Viken" - http://www.nwo.no - arca
    2. Re:Interesting but not shocking by Shrike82 · · Score: 2, Funny

      I wasn't personally involved in the decryption effort, so I naturally assumed it was probably some kind of scam carried out by a consortium of international security agencies, trying to convince us that all the encrypted pornography on our hard drives wasn't actually safe from outside scrutiny. Of course I could be wrong, so I covered myself both ways by inserting the qualifier "apparently". I'm a child of the 80's since you ask, but sadly at the time of the distributed.net decryption event I was limited to either an archaic 486 at home, or the "computers" at my college. I use speech marks as when an operating system is so bogged down in security software and access controls that word processing causes a lockdown (complete with flashing lights, armed guards and your name being entered onto a register for cyber-terrorists), the device it's running on pretty much ceases to be useful as a computational device.

      --
      You can advertise in this sig from as little as £99.99 a month!
  7. Re:searching for ASCII by Arancaytar · · Score: 4, Funny

    Me, I let a Navaho code talker read out the bit stream before transmission.

  8. Re:Practical value by Shrike82 · · Score: 2, Interesting

    In the case of Triple-DES you're dealing with three times as many bits for the key, so you move fairly rapidly from decryption in three days to several billion years. Other ecryption algorithms use even more bits, and more complex key schemes so, while the work is interesting, we can still hide porn on our PCs without fear.

    --
    You can advertise in this sig from as little as £99.99 a month!
  9. Anyone else... by Pojut · · Score: 2, Funny

    ...reminded of the little box hidden in an answering machine in that movie Sneakers? lulz

  10. Isn't it clear? by QuoteMstr · · Score: 4, Insightful

    One of Slashdot's corporate overlords at VA Research, or Sourceforge, or whatever it's called this week finally heard about Twitter from his nephew, and demanded that Slashdot be made "Web 2.0" relevant. He probably asked about moving Slashdot to the "cloud" too. After being rebuffed with arguments like "that makes no sense" and "we were a blog before blog was a word" and "do you even know what the cloud is", the executive was only dispatched a huff after being told "we're not ready for that yet".

    It's the same reason we have the idle section (which if you're sane or over 16, you'll turn off). It's the same reason we have obvious troll stories ("Which editor is better? Visual Studio or a Diseased Chimpanzee? Discuss."). It's why we have pictures in articles, slashvertisments, and and ten times more stories about first person shooters than about functional programming languages.

    The Slashdot owners (if not its actual maintainers) see the level of loyalty, tenacity, and clickthrough-friendly stupidity over at Digg and drool all over themselves in MBA-enhanced dollar sign dreams.

  11. Re:Practical value by QuoteMstr · · Score: 4, Insightful

    DES algorithm is quite similar to AES and Blowfish.

    In that they're both block ciphers, yes. That's where the similarity ends; AES doesn't even use a Feistel network. Your comparison is like saying that a flintlock rifle is just like an M1 tank. In other words, you have absolutely no clue what you're talking about.

  12. Re:Should be building standardised FPGAs into syst by bcmm · · Score: 2, Interesting

    How fast can an FPGA be reconfigured? I suspect that they would not lend themselves to task switching as readily as CPUs do, and the potential of FPGAs to accelerate day-to-day tasks would be somewhat reduced if only one process could use it at a time.

    --
    # cat /dev/mem | strings | grep -i llama
    Damn, my RAM is full of llamas.
  13. Re:searching for ASCII by rubycodez · · Score: 3, Funny

    I rot-13 everything first, and then I go the extra mile and do it again, cause you can't be too sure

  14. Re:Defective by design by Truekaiser · · Score: 2, Insightful

    i would expect as much, it's within the cia's self interest to prevent the existence of a encryption algorithm they can't crack or don't already have a key too.

  15. Re:Should be building standardised FPGAs into syst by SmurfButcher+Bob · · Score: 3, Informative

    10 years ago called, they want their ideas back - starbridgesystems.com

    --

    help me i've cloned myself and can't remember which one I am

  16. Re:Should be building standardised FPGAs into syst by Anonymous Coward · · Score: 2, Informative

    Yeah, well Xilinx pursued this in the early 90s with a swappable FPGA with an open architecture. That was discontinued pretty quickly, though.

    The main issue is that apps aren't slow in the right way. Very few apps these days are in fact ALU-bound. With GPU resources and SSE, even fewer need extra ALU power, and the hard limits come from memory access speed (especially random access, as required by a great many algorithms). FPGAs don't really make this any easier (except insofar as they can offer *small* local caches which are blisteringly fast).

    Also, any application domain which does have a speed problem tends to get hardware accelerator support pretty quickly - think of H.264 encoding, for instance. Whatever can be done on an FPGA is already done in various other products. None-the-less, a generic FPGA in every computer would reduce the need for all this custom silicon.

    Personally I like the idea, but I fear it is too "niche" to ever make it as a standard PC component.

    OTOH, what Intel etc. might consider is putting some FPGAable "special instructions" in the ISA, then attaching some FPGA resources that can be programmed in a relatively simple manner to execute some specially-needed instruction. I used to dream of this back in the early 90s when I was writing texture-mapping software ... the bit-twiddling there can take several instructions, whereas a few custom FPGA cells could do the same thing in one inst. But then, the programmer would want to implement pipelining on anything > 1 cycle, and that could be interesting to interface back to the main core.

    For the niche applications where this all makes sense, you can buy some pretty awesome development kits. Pico Computing (mentioned in TFA) look to make interesting products, but there is also the whole XGameStation thing which - thanks to its nature - can easily be repurposed.

  17. Re:searching for ASCII by JustOK · · Score: 3, Funny

    I do rot-6.5, but I do it four times.

    --
    rewriting history since 2109
  18. What a load of crap! by ladadadada · · Score: 5, Informative

    There has been no "crypto breakthrough".

    What they have done is created a chip that can do 1.6 billion DES operations per second (compared to 250 million for a GPU card) and then put 176 of them in a 4U server. This lowers the price to performance ratio by around a factor of 6 if you assume that their chip and a GPU are the same price.. By the way, this press release (and research) was made by the company that manufactures the chips in question.

    The "massively parallel" algorithm (their term, Dr. Dobbs just copied it) only decrypts a little of the file and looks for ASCII integers because that's what they put in the file before encrypting it. They have not found a way of culling candidate keys without already knowing what sort of data is in the encrypted file. That would be a "crypto breakthrough".

    it's a good bit of technology with many uses beyond cryptography that has, unfortunately, been marred by some overly breathless reporting.

    --
    Sig matters not. Judge me by my sig, do you?
  19. Breakthrough? meh. by gmarsh · · Score: 2, Informative

    Brute-forcing DES doesn't require any creative algorithm to be run in parallel. You have 2^56 possible keys, split them amongst 2^n crackers and each cracker has to process 2^(56-n) keys. Not too hard.

    And loading an array of DES cracker cores onto an array of chips isn't novel either, ie:

    http://en.wikipedia.org/wiki/EFF_DES_cracker (using ASICs)
    http://www.copacobana.org/ (using FPGAs)

  20. Re:searching for ASCII by Sir_Lewk · · Score: 4, Insightful

    I know you are joking, but I think it should be pointed out that there is no reason this technique can't look for something other than ASCII chars. Most binary files have predictable sequences of bits in them, often some sort of header.

    --
    "linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
  21. Re:Should be building standardised FPGAs into syst by Zerth · · Score: 2, Informative

    There are a run-time reconfigurable FPGAs on the market, but they still take time to switch(something like 200 microseconds). Not terribly long on our scale, but not exactly fast for the CPU.

    The real problem is that FPGAs are generally more expensive for anything that you can mass-produce. FPGAs shine if you want something custom and parallel, like this cluster, and can be cost-competitive compared to getting your own silicon made for prototypes.

  22. Re:searching for ASCII by Arthur+Grumbine · · Score: 3, Funny

    I rot-13 everything first, and then I go the extra mile and do it again, cause you can't be too sure

    I do rot-6.5, but I do it four times.

    You guys are both doing it wrong - wasting CPU cycles to get that additional security. I just do one pass with ROT-26.

    --
    Now that I think about it, I'm pretty sure everything I just said is completely wrong.
  23. Re:Defective by design by keckbug · · Score: 2, Informative

    While I can't argue that NSA hasn't been able to decode DES from an early point, it's not all doom and gloom. From the same Wikipedia page are several sources confirming that Lucifer, as initially conceived by IBM, was vulnerable to differential cryptanalysis, and the NSA's modifications, back in 1974, significantly strengthened the subsequent DES algorithm. This wasn't confirmed until 1990. Before we dismiss any government involvement out of hand, lets consider all sides. Relevant passage from Wikipedia: Some of the suspicions about hidden weaknesses in the S-boxes were allayed in 1990, with the independent discovery and open publication by Eli Biham and Adi Shamir of differential cryptanalysis, a general method for breaking block ciphers. The S-boxes of DES were much more resistant to the attack than if they had been chosen at random, strongly suggesting that IBM knew about the technique back in the 1970s. This was indeed the case — in 1994, Don Coppersmith published some of the original design criteria for the S-boxes. According to Steven Levy, IBM Watson researchers discovered differential cryptanalytic attacks in 1974 and were asked by the NSA to keep the technique secret.

  24. 3DES still only 112 bits even with 3 keys by billstewart · · Score: 2, Informative

    It turns out that there are attacks on 3DES that mean that the effective strength is still only 112 bits, not 168, even if you're using three different keys. Since 2 keys are just as strong, it lets you use a 128-bit or 160-bit source of randomness to generate them.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
    1. Re:3DES still only 112 bits even with 3 keys by fatphil · · Score: 2, Informative

      Cracking cost is not proportional to time. Cracking cost is proportional to the product of the amount of equipment used times the time it's being used. In order to reduce the time cost by 2^56, you need to multiply the equipment cost by 2^56 - that's what MITM does. The total real cost has remained the same - 2^168. The Biham approach, as applied by Lucks to 3DES, while reducing the time to 2^90, increase the space to 2^88, for a total cost of 2^178 - a net loss. 2 keys are clearly weaker than 3.

      --
      Also FatPhil on SoylentNews, id 863
  25. Re:Should be building standardised FPGAs into syst by digitalunity · · Score: 2, Interesting

    There could be a market for this. I see 2 obvious applications.

    First application would be for photo and movie processing. An FPGA that could be configured by photoshop plugins or other linear movie editing programs could see dramatic speedups.

    Another would be finite element analysis, in CAD/CAM applications or others such as Inventor, Simulia, Catia, MathCad, etc.

    I see some desire for GPGPU in these areas but with a little added complexity, I think these applications would see a big speedup even over GPGPU.

    --
    You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
  26. Use with Care... ROT-26 for expert use only by yareckon · · Score: 2, Funny

    ROT-26 has several interesting properties that make it unique among encryption algorithms,and only by knowing it's strengths and weaknesses can you decide if it is the right tool for your use case. For one, ROT-26 (and the entire ROT family of ciphers) are unique among encryption strategies in their heavy reliance on avoiding hostile interception altogether. Even if intercepted, like many of the latest stenographic or hidden volume techniques, a ROT-26 cyphertext nearly always succeeds at being completely unidentifiable as an encrypted document. It has, however, been singled out (fairly In my opinion) for being vulnerable to a trivial known-ciphertext attack that may be employed by any minimally literate expert. Although praised for it's universal hardware support and unbeatable performance (a constant time implementation of the algorithm has been discovered(!)), nonetheless, securing your data using ROT-26 is increasingly viewed as unwise.