Slashdot Mirror
The First Step to Cypherspace?
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.
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.
...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
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
It is indeed just DES; 56 bit encryption already proven to be just a toy and not for serious security when you want to keep a secret for a week or so. DES is good for mundane security, for example files on a shared computer at work, but not for keeping vital secrets away from the spying eyes of a company's competitors.
Perhaps the idea is to make DES more attractive as an option that can be performed at high speed, but the use of an ASIC means that you can't just switch on the fly and get say Blowfish implemented at the same speeds.
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...
___
If you think big enough, you'll never have to do it.
Tripple DES is good enough. If it isn't, DES encrypt 5 times, or 7, or 9. If you go all the way up to a 128 bit key, you'll never break it no matter what kind of hardware you create unless the algorithm has an exploit, and a serious one at that. DES has exploits, but they require massive amounts of storage to use.
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.
If tits were wings it'd be flying around.
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.
Xenu loves you!
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.
If tits were wings it'd be flying around.
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.
Xenu loves you!
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.
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.
--
"May I have ten thousand marbles, please?"
Wouldn't this also be an appealing platform for brute-force attacks?
But this thing doesn't crack keys really fast, it encrypts and decrypts really fast. You use this piece of equipment when you already know the key/passphrase, and you want to (de)encrypt a whole lot of stuff with it in real-time.
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.
COOL!!!
this could be a good first step to the ice in the matrix on William Gibson's Neuromancer (1983)
The ICE was created by Bruce Sterling as credited on the book. THIS IS THE MATRIX!
not the '98 movie!!
Just think, you could encrypt a 10 Gb hard disk in eight seconds using the throughput that they mention.
:)
Yeah, assuming you have a hard drive that has the bandwidth you're talking about.
Something like that could easily be put into a device driver under Linux.
Wow, that's be cool... "And here is my encrypted partition" Except for the fact that this is hardware the article is talking about, and that there's a Windows program that already does this.
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
Loose things are easy to lose. You're getting your hair cut. They're going there to see their aunt.
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.
But how would that work? I mean, if you encrypt everything coming out of your ethernet adaptor, then the POP3 commands would get encrypted too. The way I'm seeing this machine, is that you have on on each end of a connection that you wish to secure.
encryption? remember, this is one of the places that recently underwent a 2-day security lockdown because of problems that allowed information to be funneled to the Chinese... and it's the government, who isn't exactly thrilled about us even using our little orphan annie secret decoder rings...
Um, this isn't going to help you with that. Most corporate mail-reading isn't done via vampire taps or sniffers, methinks...
** This encrypts data on a given link using DES. **
Therefore, there are two things to note here.
1. The private key presumably must have been set up by the administrators (since both ends of the links must use the same key). Ergo, they know what the key is, and therefore can break their own link.
2. It's only encrypted on the link; i.e. your mail would be stored in its normal (decrypted) form at both endpoints, including the corporate mail servers, the tape backups, and so forth.
For both reasons, then, the admins can still read all the employee mail as necessary.
"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
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
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
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
"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 :
/sec
10 Gbits
8 bits / byte
10 Gbytes => 8 secs.
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.
Encrypted networks just help against passive monitoring of all traffic. It doesn't do much to build a truly private society. Networks that implement anonymous IP infrastructures, and full strength crypto help to create a place where physical location on the 'net does not define your access or view of the Internet. Current proposed legislation like Internet Gambling Act, or the Australian Censorship Bill will continue to make cyberspace a place full of government intervention unless the actual network itself is anonymous, and geographically independent. This is the same stuff written about in Shockwave Rider, and Diamond Age (Remember the discussion about how the net worked anonymously).
:)
There are actual projects doing this. Zero-Knowledge Systems, is the most notable. (Ian Goldberg who wrote the perl code in Cryptonomicon is the Chief Scientist).
These are the type of secure/private networks that should be build. This makes censorship, political filtering, network monitoring, and traffic analysis pointless and helps return the Internet to the individual.
(Anonymous networks are also the key requirement for data havens
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 think big enough, you'll never have to do it.
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?
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.
Citizens Against Plate Tectonics
We have had encryption for ages, but the essential problems remains: how do I establish a secure encrypted connection accross an unsecure, untrusted network? Chicken and the egg problem basically. DNSSEC might solve some of these problems but it depends on the root level servers being 100% secure. Encryption isn't the problem, trusting the remote end is.
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.
The real world ICE are IDS (IDS = Intrusion Detection System) systems (distributed or non-distributed), that protects bigger corporate networks with many clients, they can be programmed to launch a strike back on an intruder and nuke him off the net, but most todays IDS systems sends an report to the admin staff if it notifies any strange suspictious activity on the network.
Today I think it is illegal to have an IDS strike back on an cracker/intruder with known DoS attacks, but its is fully possible and in the future it sure will happen then it gets ruff on net.
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.
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.
Xenu loves you!
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...
I can see the fnords!
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
Citizens Against Plate Tectonics
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.
---
"The details of my life are quite inconsequential..."