Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

The First Step to Cypherspace? 68

Posted by Hemos from the fun-with-machinery dept.
bughunter writes "Need to encrypt/decrypt your net traffic at up to 6.7 Gigabits per second? Using an ASIC instantiation of DES, pipeline archetecture, and single-cycle key/mode switching, Sandia National Labs has got the hardware you need. They say that this device can actually support almost 10 Gbps, but they haven't tried to run it that fast? and if you used parallel ASICs, you could get to 1 Tbps. And since it's an ASIC, any encryption scheme could be used. Anyone else see where this could lead? " Drool.
This discussion has been archived. No new comments can be posted.

The First Step to Cypherspace? More

The First Step to Cypherspace?

Comments Filter:
  • Well, use a nice 1024-bit RSA system to give the other party your DES keys for a start. And if you are worried about a middleman attack, then just arrange to hand off the keys IRL on a floppy.

    But you have to be pretty parinoid to worry about a middleman attack over the internet. If nothing else because it is so decentrilized that guaranteeing interception would be a pain.

  • Speed of en/decoding is not a problem... (Score:4)

    by Kaa ( 21510 ) on Tuesday July 06, 1999 @10:41AM (#1816377) Homepage
    ...getting people to use encryption routinely is.

    It's not like people don't use encryption because it is too slow. People don't use encryption because

    (1) Both parties must use encryption. If you'd like your e-mail to be encrypted, but your grandma/girlfriend/business partner think you are silly, what do you do? You use plain-text e-mail.

    (2) It's a hassle to set up and use

    (3) People underestimate how easy it is to read other people's e-mail and tend to forget basic stuff such as the fact that your employer *owns* all e-mail on your office computer and has (or could easily have) a log of all the sites on the Web you've visited.

    (4) People do believe in security through obscurity: "There is nothing in my e-mail/browsing/ftping that is of interest to anybody".

    I can go on and on... Really, I don't think that increasing the speed of encryption will help any of the current problems crypto is having. And I don't know why they picked DES to implement into the ASIC -- nowadays DES is pretty useless.

    Kaa
  • Actually Sandia is an independent contractor who
    does alot of work for the DOE and is owned by Lockheed-Martin. They do work for the government, but they are not the government.

  • While DES is low security (only 56 bits), this chip allows you to change keys very fast, so Triple-DES (encrypt with one key, decrypt with a second, and reencrypt with the first or a third, depending) is possible.

    What do you mean? A message gets encrypted and then cyphertext gets encrypted two mre times?

    In any case, I don't really see the point of having these complecated symmetric algorithms. Consider this one:

    Two boxes, say a sender and a receiver, each have a pair of RSA keys (pulic & private). To send something, a client makes up a string of random garbage (say 1024 bits in length) and encrypts outgoing data with it (so, in effect this is the key). The receiver decrypts the incoming data using the same string. RSA encryption is used to exchange the actual keys.

    This encryption would be virtually bullet-proof. And very fast too, since it is a very simple algorithm. This makes me wonder why DES and other algorithms are even used...

  • The algorithm won't matter as long as it is based on a Feistel network. DES is a 16 round Feistel network, and from the article it appears that they have pipelined that network to gain a 16x speedup over a non-pipelined solution.

    Blowfish is also 16 round Feistel network, and it is a faster algorithm than DES, so this hardware would be very very easy to convert to Blowfish, and it would probably run faster with that algorithm.

    Sure, you couldn't switch on the fly, but a blowfish chip set is a no brainer.
  • Hybrid systems as used in all modernc crypto are much faster and much more secure than what you propose.
    --
    Employ me! Unix,Linux,crypto/security,Perl,C/C++,distance work. Edinburgh UK.
  • Triple-DES would definitely be a contender.

    Remember, if your encryption engine runs 16 times faster, like this one probably would, then to make a brute force search equally difficult to crack you would have to add a grand total of 4 bits to your encryption key.

    Whoop-de-dooo.

    ALWAYS REMEMBER that the faster that encryption engines run, the more secure things get. If it's no sweat to encrypt things with a 2048-bit key, then do it. The gap between processor speed required to encrypt and that required to brute force decrypt becomes ever wider and speeds increase, meaning more security overall.

  • Not necessarily more secure. The reason it is done is speed and nothing else. Use RSA to do the key exchange, but encrypt your data with DES, or Blowfish, or IDEA, or whatever. The symmetric ciphers run far faster than the public key ciphers.

    If you were to send your entire message using 2048-bit RSA you would be more secure than a hybrid of 2048-bit RSA with a triple-DES for the actual message. But it would run a lot slower.

    If you remember, this is what the big deal was about the Irish girl's (unproven) cipher last year. Supposedly it was really really fast compared to other public key ciphers.
  • Unless you're trying to encrypt an OC3 line on the fly, software crypto is *much more* than fast enough. A stream cipher like Panama can encrypt around 5 bits per clock cycle, which translates as around 1.4 Gbits/sec even on a 300 MHz machine.

    Most of the AES candidates should do 1 Gbit/sec without too much expenditure in hardware.

    Neat, but not *that* neat.
    --
    Employ me! Unix,Linux,crypto/security,Perl,C/C++,distance work. Edinburgh UK.
  • Exactly how would you propose someone using DES just add 4 bits to their keys? There is no way to just randomly extend the keys for most symmetric algorithms. Not to mention reworking your key handling infrastructure. Sure, you can rip out DES and replace it with something better (like triple DES, which does seem to be pretty secure), but you can't just magically add four bits to it.

    As an interesting aside, the guys who wrote the paper on differential cryptanalysis of DES determined how much stronger DES would be if they used independent sub-keys in each of the 16 rounds of encryption. They determined that using a 768-bit key (by using an independent 48-bit key for each of the 16 rounds.), they would only add (I forget the exact number) something like 10 or 20 bits to the strength of the algorithm. So, even though it is easy to redesign the key schedule algorithm for DES to use much larger keys, you can't make it much stronger. DES is inherently weak.
  • Tripple DES is good enough. If it isn't, DES encrypt 5 times, or 7, or 9


    Baaaad idea. Let the crypto people decide when adding rounds increases security. Even doing 3 DES rounds, if done improperly, can result in hardly-better security. Blindly chunking on extra passes is a great way to give yourself a false sense of security.

  • ..and DES is not reasonable security. If anything, this product makes DES less secure.

    Fast encryption is nice. But the real way to advance cypherspace is first through software implementations like IPSEC. Optimize with dedicated hardware later.

  • ..and DES is not reasonable security. If anything, this product makes DES less secure.

    Not necessarily. And if you read the text closer, you'll see that any encryption scheme could be implemented. That makes it more interesting.

    Just think, you could encrypt a 10 Gb hard disk in eight seconds using the throughput that they mention. Something like that could easily be put into a device driver under Linux.

    Even if one didn't want to encypt an entire hard disk, it could be used to encrypt backups, or (using IPSEC like you mentioned) an internal LAN or IP Tunnel; all of these are slower than 1 gigabit/sec so the overhead might not be noticed.
    --
  • Wouldn't this also be an appealing platform for brute-force attacks?
  • Maybe manufacturers will start building crypto into PCs. If the average Joe can encrypt all his data easily and with no slow-down, he probably will. Having everyone use encryption would be a Good Thing (tm).

    Of course, something better than DES would be nice. The write-up implies that it would be easy to switch crypto methods, though.
  • How? This is a streaming encryption system. Brute force attacks attempt to try to use a lot of keys in succession; this system appears to use a single key on a lot of data. Not the same thing.
    --
  • Dedicated encryption hardware. People are going to want this type of thing in lots of hardware. It'll be implement as an ASIC that will divulge a public key to anyone. The U.S. government is not going to like that, because they want it to be nice and easy for their (thought) police to spy on their citizens. So before anything like this goes into mass production, the government will insist that their be a code to get the thing to spit out its private key, and the government will be able to decode our data.

    Paranoia? Certainly. Is it justified? Given what the U.S. government has been like lately, it might be. Time will tell.

    Let's stick to software encryption. You can write your own, which makes it really hard for the government to screw with it.

    -Ender
  • I can't wait until everyone has dual-encryption processors in their home PC (even at the level of WebTV). No longer will we have to deal with Big Brother looking over our shoulders.

    How will this effect the corporate monitoring of email?

    The other side of the coin: If you're scared about spies in the DOE releasing secrets to other governments, think of how hard it will be to detect espionage when you can't even decode mail between employees.

    I don't know whether to grin or hide under the covers.
  • ASIC != FPGA. It couldn't run other algorithms.

    An ASIC is typically automatically design and premanufactured based on building-block design; they are not reconfigurable. An FPGA is undifferentiated logic that loads the configuration and interconnections (and thus the logic that it runs) at power-up.
  • Fast encryption is nice. But the real way to advance cypherspace is first through software implementations like IPSEC. Optimize with dedicated hardware later.

    I dunno. Sounds to me the way to advance cipherspace is first to apply decent crypto at fast transfer rates, then strenghten your crypto later.

    "There is no surer way to ruin a good discussion than to contaminate it with the facts."

  • ...and DES is not reasonable security.

    Okay, 3DES then.

    Fast encryption is nice. But the real way to advance cypherspace is first through software implementations like IPSEC.

    IPSEC bases its authentication on trusted hosts, not on trusted users. It does not solve the same problem.

    --

  • I'm in total agreement.

    The place where these devices would make the most difference is in the public/consumer arena. Will the government ever let something like this outside of DoD use without putting proprietery loopholes in it for getting the keys back? I don't think so.

    Cordova
  • Actually, Blowfish is not the best cipher for a small, embedded system. The main disadvantage to Blowfish is its 4k RAM requirment.

    If you want a small-memory cipher that uses a Feistel network, Twofish [counterpane.com] is an excellent choice. If you want something even thinner than Twofish, and do not need to use a Feistel network, Rijndael [kuleuven.ac.be] (pronounce it "Rain Doll") or Crypton [future.co.kr] are excellent choices.

    - Sam

  • "Sure DES can be broken, but if you are using Diffie-Hellman key exchange then your keys are cycled every 8 hours."

    euh ?

    You probably meant to add a bit more info : Diffie-Hellman is simply a key-exchange protocol. Its got no relation to any kind of timing notion.

    Anyways, no bashing needed, you probably meant something else.
  • IPSEC encryption is starting to take off in a big way in the networking world. Every corporation is looking at getting many Virtual Private Networks set up using IPSEC, and the router manufacturers are taking notice.

    With chips like these, the price for doing dozens or thousands of IPSEC tunnels from a single router gets pretty cheap. So every company starts setting them up next to their firewalls, and every employee working from home over their cable modem gets a nice secure and authenticated connection into the company network.

    Soon, 30% or more of all internet traffic is encrypted, and the intelligence agencies have to go back to intercepting the communications at the point where there is no encryption. So they have to focus attention on the criminals and terrorists, and stop throwing out wide dragnets like they are now. The end effect is that people will have more protection from fascist government agencies.

    The arguments about whether DES is strong enough if it can be broken in 22 hours are kind of stupid. Sure DES can be broken, but if you are using Diffie-Hellman key exchange then your keys are cycled every 8 hours. And if millions of users are using DES, it becomes very difficult to target specific communications with packet captures or taps, and the resources to break a stream make it unlikely the script kiddies will bother.

    This ASIC design is just a research project, the VHDL code should make it into commercial products soon enough, and I don't see why it wouldn't support 3DES at that point.

    So yes, products like this will make encryption more widespread. Slashdot readers already know all the pros and cons of that whole debate, and will probably agree this will be a good thing in the long run.

    the AC
  • As a second aside,

    last time I checked. The latest bunch of cryptanalysis attacks on 3DES brough its security down to a key space of about 80 bits (which is better then the original 56 of DES). 3DES was|is an original idea by the industry to spare it the works of reworking most of its infrastrucure with the "death" of DES. 3DES has never been considered seriously by anyone on the theory side of cryptography.

    3DES is not the best solution presently available. If one is to redesign their chip to use this algorithm then they should do their homework and consider other potentially much more appropriate algorithm. Moreover, choosing an algorithm that has been well studied by the field would/should make more sense.
  • Ooops, I meant that the IPSEC implementation mentioned in RFCs 2401-2412 sets the standard DH key exchange time to 8 hours, easily changeable during the key exchange handshake, shortest time wins.

    Creating a new key every few hours means that only a small amount of your data is compromised when someone cracks your key, not the entire amount of data captured over a period of months or years. The more valuable your data, the more often you want to create new keys if you think you will be the target of a serious cryptanalysis effort. The downside is that DH key exchange is very CPU intensive, so re-keying ever few minutes is probably not a good idea.

    And if you expect bad individuals to be capturing your valuable data for later analysis, and that data can hurt you, then you probably can afford to protect it with more crypto than off the shelf simple DES IPSEC. 3DES is also an option in IPSEC, so pay the extra for vendors who support it, just dont expect the exact same throughput for the price.

    the AC
  • "Two boxes, say a sender and a receiver, each have a pair of RSA keys (pulic & private). To send something, a client makes up a string of random garbage (say 1024 bits in length) and encrypts outgoing data with it (so, in effect this is the key). The receiver decrypts the incoming data using the same string. RSA encryption is used to exchange the actual keys. "

    I'm not sure what it is you're proposing exactly...

    is the 1024 bit thingy use for a one-time pad, for a DES scheme (somehow using 1024 bits...) or also for RSA algorithm...

    Which ever you use, the basis of this approach is what is typically used in the industry. For example, the SSL3.0 protocol uses one of three key exchange algorithm, the first is Diffie-Hellman (the precursor of RSA in terms of public-key cryptography), the second is Fortezza (a technique developped by the NSA for crypto-cards whose formal description I could never found, probably because its a national secret) and a third whose name/nature I forget, possibly an ElGamal scheme.

    Once the exchange has been done, both sides usually fall back on the best symmetric algorithm implemented on both side, worst case is DES. I have the paper in one of the drawers next to me, somewhere, but I do believe RSA is an acceptable algorithm however the speed probably drops to an unacceptable level.

    Anyways, which ever scheme you use, the security ultimately falls back on the key-exchange algorithm and nobody, nobody, would want to have a client wait for a key exchange with a 1024 bit prime numbers... So although the 56 bit of DES make it the prime target, the key exchange it also a fair target for other algorithms.

    Hope this clarifies all of this a bit.

    P.S. No encryption is ever "virtually bullet-proof".
  • The article :

    10 Gbits /sec
    8 bits / byte

    10 Gbytes => 8 secs.
  • Um, this is why you use DIFFERENT KEYS PER
    ENCRYPTION. If you do DES 3 times with
    3 different keys, you have 3-key 3DES with
    168 bits of keylength.

    This does not suck. The only weakness is a
    faster attack than brute force on DES itself.
    Given that DES is probably the most studied
    symmetric cipher in the world, I think that
    risk is acceptably low.

    If you just encrypt over and over again with the
    same key, you may lose. There was a suggestion
    at one point to do 3DES with 2 keys, but there
    is only one ordering which provides reasonable
    security, and there is a storage for compute
    tradeoff which makes this questionable.

    Insist on 3-key 3DES. Of course, 5-key 5DES
    will be even more secure, as would 7-key 7DES.

    Cryptography is NOT black magic. You need to
    understand what you're doing, true, but it's no
    more complicated than advanced compiler design
    or routing protocol design. Don't go into it
    blindly, but if you read a book like
    the Handbook of Applied Cryptography, you're
    on the road to clue.
  • I agree, DES is not the most secure method, but currently It takes a supercomputer a couple of days to decrypt it. Most people/orginizations will not waste the computing power to figure out what you are going to do to your girlfriend tonight or how much your business paid for that last shipment of ham. DES should be secure enough for common everyday messages.

    *****
    Knoweldge is power. Knowing is half the battle. Why do we still clout kid's views with that crap?
  • RSA is the most common because it's useful for signing and key exchange as well as being the fastest encryptor/decryptor (as compared to key generation, which DH is faster).

    From memory there is a reason why DH or ElGamal isn't as good for signing/key exchange, but I can't recall it. Elliptic curve crypto, works fine for signing and key exchange, and is very well suited to hardware (eg smartcard) applications. The memory requirements are fairly modest (for async crypto) and being able to perform all your maths in a field which does it's ops modulo a power of 2 a big plus. IIRC, you tend to need about 20% of the transistors to get a similar level of security. On the other hand, RSA and DH have had a lot more study (attempts to break them) than ECC.

  • Isn't DES a symmetric encryption? I remember seeing a table that listed different encryption algorithms. The only two asymmetric algorithms were RSA and some other which deals with elliptic curves.
    If DES is indeed symmetric, using it would kind of pointless. Can somebody clarify?
  • If you read the article, you will note that one of the features of this chip is that it can use a different key for each block it encrypts. Given a design like this, it's pretty easy to imagine that it could be used at the heart of a brute-force key cracker. Most encryption chips have relatively slow key initialization phases that prevent them from making effective cracking engines. This chip does not have that bottleneck. Now, whether or not you can feed keys into it fast enough to be really useful can't be determined from the article. Who knows, maybe the chip includes a way to increment the value in a key. It would only take a handful of transistors to implement, and would make it a nice dual-purpose chip.

    Does anyone know offhand how many keys/sec the chips in Deep Crack could check?
  • I think the point is that a cracker could use a dictionary attack more effectively (i.e. try every word in a (modified) dictionary as the password). All the more reason to use obscure passwords, in my mind.

  • Reconfigurable?? Uhh, no. (Score:1)

    by Anonymous Coward
    ASIC="Application Specific Intergrated Circuit"

    Means: It is designed to do one thing, and one thing only. Which is why they are so fast. The cool reprogrammable ones are called FPGA.

    While it COULD have been designed to be reprogrammable, encryption algorythims are usually very different and what goes into a CPU to make one fast would probably make at least one other one slow. I have not read the article, so I don't know the specifics, but this is true in the general case.
  • Indeed RSA is asymmetric and DES is symmetric. There are more than just 2 asymmetric ciphers. There's RSA, Diffie-Hellman, Elliptical Curves, El Gamal, and probably others I'm missing. RSA is the most common because it's useful for signing and key exchange as well as being the fastest encryptor/decryptor (as compared to key generation, which DH is faster).

    Asymmetric isn't used for encryption. It's too slow. Use a symmetric cipher for encryption, but exchange the keys using an asymmetric.

    While DES is low security (only 56 bits), this chip allows you to change keys very fast, so Triple-DES (encrypt with one key, decrypt with a second, and reencrypt with the first or a third, depending) is possible.
  • I was wondering that myself. I couldn't figure out how ASIC (Application Specific Integrated Circuit) meant And since it's an ASIC, any encryption scheme could be used. I'm glad someone else noticed this & it wasn't just me who thought it was a little strange. I think you're right and they were thinking FPGA.
  • Well, they could generate a number of dropable datapaths for the various encryption schemes, and just plug them into the layout before manufacturing them. Sure, once they made the ASIC for a specific type of encryption it'd be good only for that, but they could make a wide variety of them. Maybe that's what they meant in the article?

  • I never said that it was possible. I'm just pointing out the absurdity of the claim that a fast encryptor will endanger security.

    Fast encryption makes things more secure. Much much more secure.
  • Er, I think the previous poster was surmizing that in the future they will have a card or chip in your PC's that can encrypt anything. Sure you could use it for encrypting a network link, but you could also use it to encrypt email, hard disk partitions, or anything else you wrote the program for. Kinda what others were saying about being able to encrypt a 10G HD in 8 seconds (I don't know if this is true, I haven't done the math).

    Even so, it's probably a moot point. Even "personal" encryption software such as the PGP from network associates includes a "corporate" key in their commercial version of the product. In essence, it encrypts with the public corporate key that is setup by the network administrators before the product is made available to the users. Then, the corporate IT staff could decrypt any email they wanted with "proper" authority.

    So, even if this thing turns into a device that could be used as a generic encryption box for any applicatoin I don't see applications getting a corporate blessing unless they get to tag on their public key also.

    Here's a question: With the way the DOJ v. Microsoft trial has been going do you think corporations are starting to/will rethink their policy on reading email and not letting employees encrypt their email without them having a key. Seems that, if Bill Gates and the other players encrypted their email it would be kinda hard for the DOJ to argue forcing them to give up the key. If Microsoft the corporation had the key they might have had a little more luck. So does anyone forsee a relaxation of corporate policy here?

  • This IS hardware. That's why you'd have your driver streaming info through it (presumably on an addon card, though putting it on a SCSI controller would be even better) before reaching the filesystem. As for software solutions, they exist for both operating systems... the hardware route does significantly better in terms of minimising overhead, though.

    Hmm... even going the SCSI controller route, you'd still need to write drivers to initialize the thing w/ the key to be used... Since the hardware doesn't see the fs level, you'd miss out on user-specific encryption (which current software solutions offer) unless your drivers were pretty dang smart (sending the controller the root key before accessing root-owned files or system info, etc).

    Pardon the above rambling, grammar, formatting, spelling/logical errors and anything else which may be wrong. :)
  • What do you mean? A message gets encrypted and then cyphertext gets encrypted two mre times?

    Yes, more or less. DES is fixed at 56bit strength. It's part of the algorithm. Some attempts have been made to increase DES's bit length, but without much success.

    RSA encryption is used to exchange the actual keys.

    This is how we do it now. It is virtually bulletproof, but there are associated problems. For instance, what if the symmetric cipher you use to encrypt all the data, once the keys have been exchanged, is weak? This is the case with using DES. Also, public key exchange produces some hairy problems. If I've met you in person, it's no problem. You just give me a disk with the key on it, but then why use public key encryption at all? If I get your key off the Internet, how do I know it's really you and not someone pretending to be you? There are other problems, but this is all off topic. The reason people are claiming that this machine isn't secure is because you use DES to encrypt bulk data, and DES is insecure.
  • ISTR reading somewhere that ssh was designed to be easier to use than non-encrypted the equivalents.

    It does have neat features that are non-trivial to do otherwise (X forwarding) and once you set up the keys (a once-only job) you then never have to type in your password again.
  • IPSEC bases its authentication on trusted hosts, not on trusted users. It does not solve the same problem.

    This is one of the things that really annoyed me when I started using TCP/IP. With DECnet, users as well as machines are considered network principals, and DECnet protocols mean you can happily grant connections based on node and user ,assuming, of course, that you trust VMS login/authentication, but it's very good so there's no reason not to. Especially as so many people are trusting NIS+ and LDAP these days.

  • It doesn't endanger the security of ppl. who use the more secure keys allowed by the faster encryptor, but it lessens the security of any older messages, or messages which are still using too-low keys.

    Also, most common crypto is export legal, to avoid the hassle. The limits on export are set. You can't just increase your key size. Most people are stuck with what they have, and any advances in faster encryption reduces the amount of time a brute force attack will take.
  • DES is solid. It's been around nearly 30 years and has proven immune to all attacks except brute-force. It's even proved strong against differential cryptanalys (for long key lengths). A 56-bit key with todays computing power is insecure. So use a 128-bit key and you data will be secure until the heat death of the universe (Scheiner, Applied Cryptography).

    DES (the algorithm) is secure. There can be no argument about that -- it's 30 years old.

  • You're mistaken: you'd have to use something like a 3000-bit RSA key to get the same security as a 128-bit IDEA key. Public key systems are used because of their convenience, not becuase of their strength.

    The "Irish girl cipher" (I forget the right name, Cayley-something) was mostly the work of another cryptographer; she solved some important implementation problems. It's not the big deal everyone thinks it is; Schneier's comment was that the *important* news was the arrival of a good new cryptographer, not the actual work itself.
    I don't quite know what you mean by "(unproven)";
    the word has two meanings. No cipher is proven in the mathematical sense: many ciphers *have* proven_1 to be secure through experience, but no cipher except the impractical one-time-pad *is* proven_2 secure mathematically, if you get my meaning.
    --
    Employ me! Unix,Linux,crypto/security,Perl,C/C++,distance work. Edinburgh UK.
  • I am fully aware of the various flavors of ASIC, in both the factory customized and field programmable categories.

    My implication, which I admit was obscure, was that the general architecture is valid with any encryption scheme, since the encryption engine is localized to a single component... which could be replaced... physically... with a programmable device, perhaps yes.

    That means you have to actually touch the hardware; I know that's hard for some people to imagine...

  • The article says that the chip runs the data through a pipeline, rather than using the same circuit 16 times in a row. They also say that each block can be done with a different key, or switch from encryption to decryption. This implies that it can run at least 16 times faster for a brute force crack (even though checking each key would take the normal amount of time). And since its an asic, it should be cheaper to buy a lot of them and run them in parallel.

    This thing looks like it can blow single-DES out of the water. triple-DES might still be a contender, though.
  • It is not too difficult to predict when important information is going to be sent. For instance, at the beginning of the day, people will generally be responding to email. Take the hours between 7 and 10 AM and try decrypting all the data. Couple that with the fact that most emails contain similar headers and it's easy to find the messages you need.

    Eventually, even if it takes 48 hours (as compared to the 22 hours quoted for cracking DES), you will have that data. It doesn't matter that the key was changed later. Sniffing a network and storing the data on disk is not difficult

    It's not script kiddies we're worried about. It's well funded, dedicated attackers. For me, it's the US government, but it may be any number of organizations
  • Um...I don't think a DES encrypter is going to be able to reach out and kill someone who's trying to crack it.

    ICE was credited to Tom Maddox, author of Halo (if I remember correctly). He's not as prolific as Sterling or Gibson, but he's a great writer. It also happens that I went to college with his son, so I may be a little biased :)

  • Read the next-to-last paragraph in the article. The statement, as I read it, is that the design principles used to speed up the chip can be used with other algorithms. The fact that it is an ASIC makes it easier to work with the design.

    --
    Fourth law of programming: Anything that can go wrong wi

  • Chances are, the keys used won't be based on a passphrase. Instead, it should gather the keys from a good source of randomness. The keys would be generated automatically and exchanged using RSA or Diffie Hellman.
  • We've had boxes like this for some time. Hardware black boxes that encrypt/decrypt traffic. Sure, maybe they don't run at 10 Gbps, but speed increases are a matter of course these days.

    Let's keep in mind that this is not a public key system. Sandia's hardware is designed for creating encrypted network connections, using either virtual or physical pipes. (We were going to install similar hardware at one of my previous employers to encrypt 2 connections: one a direct wire to another site, and one a virtual pipe over the Internet to a third site).

    Great, we can encrypt faster. But this doesn't really get us anywhere towards using encryption globally on a daily basis in emails, messaging, etc. We still need a good PKI for something along those lines and I just haven't seen anything that qualifies yet.

    ---

Slashdot Top Deals

Life is cheap, but the accessories can kill you.

Close