Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
BSD Operating Systems Hardware

Hardware Crypto Support In OpenBSD 65

As seen on the OpenBSD -announce list, OpenBSD now has hardware cryptographic support to boost IPSEC performance. "Currently, only cards using the HiFn 7751 chip can be used. This Hifn chip is an IPSEC-oriented DES/3DES and SHA1/MD5 hmac engine; ie. only symmetric cryptography..&nbsp.we are getting 63.12Mb/s 3des/sha1 ESP IPSEC. That's documented as the top performance the chip can provide. In other words, we're pretty damn impressed at ourselves." Read on for more from the message, or go straight to the OpenBSD Hardware Crypto page.

"Further work will now happen. We wish to support other products (ie. IRE, Bluesteelnet, perhaps even 3COM or PCC-ISES if they would open their minds). Some crypto chip vendors are being extremely friendly to us. If anyone wants to help write drivers, get in touch."

We also hope to add more parts to our cryptography framework so that it can supply RSA/DSA type operations for chips that support that, so that OpenSSL can use the framework, and thus enhancing everything from https to ssh performance. We have grand schemes in mind."

"If you order a card from www.powercrypt.com, tell them you intend to use it with OpenBSD. I have heard rumours they are allowed to export it."

"Most of this work was done by Jason Wright and Angelos Keromytis."

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

Hardware Crypto Support In OpenBSD

Comments Filter:
  • by Anonymous Coward
    3DES. Your ATM's favorite cypher.

    If by ATM, you mean "Automated Teller", the vast majority of ATM's still use single length DES keys. I work in the industry, and I am not aware of any large scale deployment of triple-DES ATMs.

  • by Anonymous Coward
    You're just frustrated because you expected a GUI Install after downloading the boot floppy.

    Linux monkeys, please stay in your cages. Thank you.

  • by Anonymous Coward
    Why are you telling me to grow up?
    I didn't slam Linux. I don't see much of a reason to slam it anyways.
    So why is it ok to slam BSD? That's (Linux) advocacy taken too far. It is not really not funny, yet I'm sure it will continued to get moderated way us as funny.
    This is advocacy gone wrong.
  • Some of the posts a misunderstanding between what is being annouced (hardware accleration) as opposed to the traditional hardware security modules (often known as a "HSM", the type FIPS 140 adresses). Hardware acceleration is a very useful feature, but true a HSM is much more difficult to achieve. A good example of a cheap HSM is chipcard.

    The HSM has to provide both physical and logical security. Real world costs force a cheap HSM to skimp on physical security, but there is no good excuse for poor logical security. Logical security is much easier to acheive if you keep the functionality simple. As you add more features (IPSEC and SSL and SSH), it starts getting very complicated.

    One post suggested a "cheap" solution of an FPGA and internal-read-only registers to store keys. That only brushes the surface. Here are some other potential issues:

    * Control access for "writing keys"
    * Controls for functionality (limit who can perform certain actions
    * Figure out how to import and export existing keys in a secure manner.
    * Make sure that keys are tied to their appropriate function (i.e. can't use a SSL key to perform IPSEC functionality).
    * Provide assistance to the hardware in resisting attacks (timing, power, etc.).
    * Provide for a method of securly updating functionality without revealing internal data.

    Since I do software design, and have a good hardware group, I tend to think the logical security is the most interesting part. If you would like to find out more about this, try taking a look at an implementation: the PKCS #11 (http://www.rsasecurity.com/rsalabs/pkcs/pkcs-11/) . Keep a couple of things in mind when reading the PKCS11 documents:

    1) PKCS #11 is designed for "client" security tokens - like smart cards. A number of Certificate Authority vendors are using it for servers, but it does not work that well. Activating special features by sending passwords in the clear may make sense for a smartcard, but is a real problem when you are worried about insider-fraud.
    2) PKCS #11 is very flexible, and can be misconfigured. Just because you are following the PKCS #11 "standard" does not mean you have a secure implementation.

    The FIPS 140 standards are a little more difficult to read. But skimming over these will give you an idea of the things that can go wrong. Remember, your security is only as good as the weakest link!
  • by Anonymous Coward
    AltiVec can accelerate any block cipher. In fact one of the purposes of AltiVec envisioned by Motorola was for VPNs
  • by Anonymous Coward
    Don't be a bigot.

    Hey, his statement is better than Linus's being a play-thing for corporate products (see /. on the LinVideo/"legal" Linux DVD player).

    Better than the Linux hackers that were so sure of themselves during the MindCraft fiasco, hemming, hawing, and touting their code as better. Hell, articles picked up on it, they touted themselves as such in public, and during the re-run of the testing. Then they go themselves proved utterly wrong. Guess what? Linux's networking code STILL sucks months later.

    Your fooling yourself if you think this is a BSD mentality. It's a common human trait that occurs in many people. Don't think you're better than others. He's touting his accomplishments, and that IS the truth. Good code is good code. Suck it up.

    --
    Say LIE NUX: it's more representative of their community and the OS--it has the word "Lie" in it and rhymes with the "Sucks".
  • by Anonymous Coward
    Not likely. The folks at Intel are totally anal about releasing specs to the open source community.
    --Louis (louis at spamthis signalpath dot on dot ca)
  • Just like DVD, code on the CD or even programs installed on your hard drive will be encrypted and region coded. Your CPU of the future will also have a region code assigned to it. Code will be decoded on the fly inside the CPU just before execution. US software won't run in Singapore, etc. And export controls on CPUs can remain strong because it's not about crypto. It's about exporting high-tech. Remember, that Chinese guy busted on espionage for stuff like this? The warez/piracy problem will be solved by dividing the world into 32 incompatible regions. Even compilers can be made to produce region locked code. PH3@R the future. I know I do.
  • Probably not. Distributed is trying to crack RC5-64 currently, and this chip doesn't do RC5 (I can't think of anything offhand that does that in hardware).

    -lee
  • There's a difference between open and free bsd there, dude.. And sure, Solaris has had it all for quite some time, but if you don't want to pay assloads of cash for the hardware, you want some other options. I'm sure FreeBSD will get this hardware crypto support soon, so you have your SMP support there.

    Now sure, for huge compute apps, there's no intel boxes beating a sun or digital machine, but just use the right tool for the job, yes?

    cheers,
    -o

  • Why are you posting anonymously? You seem to have some strong feeling about all this, and speak like an authority. "Debunking" this and that.. Man. Nobody is going to give anonymous coward a job..

    I don't understand how you can say that an audit does not cause less bugs. The only way that could be is if you induce bugs during the audit. Huh? Do you think the OpenBSD guys are completely incompetant?

    And secure by default is just that. Sure, a good admin can make either BSD or Linux secure or insecure. But our of the box is out of the box. How many remote root exploits are there for RedHat? How many for OpenBSD? I'm not giving numbers, but I can guarantee that OpenBSD is LESS.

    Geez, kids these days..
    -o
  • BSD is cool because it does some things in a way I prefer to the linux way. Linux does some things I prefer to the BSD way.

    I think both sides could benefit from looking more closely at the best of what 'the competition' has to offer.
  • How useful is hardware encryption? How does it compare in speed and, more importantly, price/performance to software ecryption? 600+ MHz CPUs are pretty cheap these days, so wouldn't it make more sence to buy a second CPU instead of the crypto card?
    ___
  • Hardware has two advatages. 1) it is generally faster. 2) It is harder to trojan a hardware device then software. The first one is all that most people think about.
  • (disclaimer: I like both linux and bsd, and a number of other os's. I just found the post funny).
    [sarcasm]Of course, the linux developers are NEVER proud of their work, are they? :)[/sarcasm]
    dude, get over yourself :)
  • Wow, could I really kick ass on distributed.net if I got one of these puppies? If so, I'm all over it! :)

    -Waldo
  • Mocking quote:
    99% of the Linuxers who slam linux installed NT in 1997, and switched to Linux in 1999 when NT got too popular. Now they need some reason to justify their move, other than "I don't feel 31337 using NT anymore."

    The other 1% had their dog run over by Bill Gates when they were younger.


    Believe it or not, just because people make choices different from yours, doesn't mean they aren't making them on a rational basis. Right now I use linux as a desktop unix, but if I were to administer a server openbsd would be high on my list of operating systems to consider.

  • 99% of the BSDers who slam linux installed linux is 1997, and switched to BSD in 1999 when linux got too popular. Now they need some reason to justify their move, other than "I don't feel 31337 using linux anymore."

    The other 1% had their dog run over by linus torvalds when they were younger.
  • heh. believe it or not, some people have a sense of humor. I love it when this flamewar comes up because it gets so ridiculous so quickly.

    typing this on a SMP linux box, through an openbsd nat/firewall.

    of course, my mocking post was funnier, so neener neener!
  • Miguel may be a man I have a lot of respect for as a great coder. He's the man of Gnome. He just doesn't have much of a grasp on Distro issues. He has the idea that the second a stable piece of code releases the hands of the developers, it should be in distros. The turnover time is a little longer then that. He's also said that Debian packages are 'too hard' and so Helix didn't ship deb's with their recent Gnome Preview.

    That doesn't mean I'm mad at him. He just doesn't understand. Give him a chance, be rational. He's a good coder, just maybe a little naive.
  • I'm not a crypto-head by any means, and I don't really follow IPSec stuff or anything. But, I'm gonna offer my completely uninformed opinion anyway. :)

    Seems to me like this would be good hardware to put in a bridgehead router... particularly with software/drivers to opportunistically encrypt IP traffic between routers that support it. I don't know how far away we are from this, but I think this is the goal. Transparent end-to-end opportunistic encryption. Yee ha.

    Its really not a matter of having anything secret to protect, either, it's more a matter of wheat and chaff... as much encrypted traffic the better. And besides, it helps to obfuscate brain damaged plain-text password protocols.

    I think this rocks.

  • Well, you could always get into a situation
    where you could choose between a new cpu
    and ~6 more encryption cards if they are cheap.

    If you haven't got a dual-cpu motherboard, or
    are running on some platform for which SMP isn't
    supported yet, you probably want to have it on
    the network card anyway.
  • What, the world of people with names who know what they're talking about?

    Zurk: OpenBSD had a root exploit
    Smart person: no it didn't
    Zurk: OpenSSH had a root exploit
    Smart person: no it didn't
    Zurk: RSAREF had a root exploit

    I will use short words to get this through to you: RSAREF is not part of OpenSSH. RSAREF is not part of OpenBSD. RSA is a code that men own. You must pay these men to use RSA. You can use RSA and not pay if you use RSAREF. RSAREF is a code that has a bug that we can not fix. The bug that is in RSAREF is not our bug! It is the bug of the men who own RSA! Those men will not fix it since no one pays for RSAREF. This bug is with us till late this fall. Then we can use RSA that is not RSAREF and still not pay.

    Clear?
  • umm..i hate to burst your fantasy but -
    BSD doesnt support more than one CPU.
    Solaris is the #1 ecommerce platform becuase its more reliable and scalable than almost anything else...including linux.
    Hardware crypto support for SSL has been around a long time in linux, NT and solaris on apache, netscape enterprise and every other webserver. just ask nfast.
  • umm...ssh exploit anyone ? yes, openssh was vulnerable to it. theo's released a few patches for the current version of openBSD too.
  • umm..*cough* *cough*
    here's something interesting :
    openssh:
    Even though the OpenSSH code checks all input parameters carefully,
    internal RSAREF functions can still overflow.

    from : http://www.openbsd.org/advisories/sslUSA
  • 3DES. Your ATM's favorite cypher.
  • HAHAHA, you're funny.

    Cryptography is a very important issue to EVERYONE, especially with the amount of digital information being passed around(be it on internal or external networks).

    Cryptography is used to protect your credit card numbers, your confidential personal records held by schools. hospitals, and government agencies, and to protect your machine from foreign espienage(sp?).

    This is *definitely* "news for nerds". I just think you're a troll( I wish I had some points ).

    I sure as hell wouldn't want my credit card number floating around in clear text... how about you?

  • I swear, you anonymous cowards need to get a clue. Lots of people would use this encryption( besides pedophiles anyway). Think about credit card companies, and schools, and hospitals.

    They all need encryption. And this helps alot!

    I really think the anonymous coward status should go away!
  • Does anyone support the security chip on the Intel NICs?
  • Well, it they can't be too bad, we do have intel nic support after all.
  • Now what exactly do userland tools have to do with Linux having security problems. Those are the userland tool problems, retardo. More BSD faggots trying to obfuscate the issues. That's why you guys are losers. So then userland tools have nothing to do with security? I never made an personal attack on you or did i say something wrong like "Linux sucks." I should just leave the 14 year olds to their rpm problems.
  • I really don't understand the FreeBSD people, they want to keep the base system completely under that license, but I don't think their tools have evolved like they should have evolved. Their kernel is great, but their tools, their userland, is just ancient. It needs some updating.

    Funny how this bit of ignorance comes from one of the largest penguins out there. Miguel de Icaza! Miguel's Incompetence [linuxtoday.com]

    Miguel is wrong.

    I never find core files for the stock OpenBSD binaries.

    When bash.core stops being found, perhaps he can make some claims.

    When they stop having security holes, perhaps they can start to claim that their userland tools are non-ancient.

    When they stop calling mktemp(), inet_addr(), and strcpy, then perhaps they can start to claim something like that. Their source code is unmaintained. Theo's response [sigmasoft.com]

  • I don't have a cellphone. when/if I get one, I'd prefer one with encryption. crypto is better than no crypto, don't get me wrong.
    And a software implementation of SSL in Netscape works just fine for my credit card numbers (like there's an alternative for buying something online anyway?)

    As for address/phone number, I feel like the cat is more or less out of the bag on that one. I haven't tried myself, but I wouldn't be surprised if it were easy to look those up.

    overall, and as much of a misanthrope as I am, I just haven't felt like much of anyone is out to get me, electronically at least ;)
    And I can't think of a whole lot of personal info about myself, that I keep outside my head, that I feel like I don't want others to know about.

    I enjoyed your joke about the tinman, if I understood it.
    but I can't think of a good reason to be the "tinman" (secure my linux box that or run OpenBSD, encrypt all my data, etc.) other than that it would be fun and educational (which, I admit, might be reason enough)

  • this sounds so cool-- lots of strong encryption at blisteringly fast speeds--

    but wait... I don't have anything to encrypt... or decrypt. guess I better find something appropriately shady to do to justify that kind of protection.

    much as I want to reserve the right to have the kind of secrecy strong crypto might permit, I can't think of anything I want to hide that badly. any suggestions?

    <sarcastic> if only I was a secret agent or something </sarcastic>

  • Seems to me like this would be good hardware to put in a bridgehead router... particularly with software/drivers to opportunistically encrypt IP traffic between routers that support it. I don't know how far away we are from this, but I think this is the goal. Transparent end-to-end opportunistic encryption. Yee ha.

    I agree there, now that you mention it; user-transparent encryption certainly can't hurt other than to give some users a possibly false sense of security. And it looks like they are doing something like what you're talking about, at least with respect to DSL modems and related equipment (check out their press releases [hifn.com]). It will definitely be cool, I think, if routers that used this sort of technology come into use.

    I apologize if this post is redundant.

  • I guess what I really meant was: If I can do Twofish at >100Mbps in software, I see a lot less need for hardware implementations.
  • In a word? nope.

    VPNs only protect traffic as it traverses from one VPN gateway to the other. (or host if the VPN is host-based) Before the first gateway and after the last gateway the traffic is susceptible to any and all forms of network attack/abuse. AFAIK, VPN gateways do no massaging of packets in order to attempt to make them less dangerous - it just encapsulates them (AH/ESP...) and sends them on their way.

    Irregardless...

    This also includes sniffing, which is certainly enough reason to not use insecure authentication protocols.

    sedawkgrep
  • Don't have anything to hide? Credit card numbers, addresses, phone numbers, pr0n habits, personal private conversations...

    Have a cellphone? You won't mind me listening in then... Since you don't believe in hiding, I mean, encrypting that data...

    <sarcastic> if only you were the tinman instead of the scarecrow...</sarcastic>

  • Why prefer one with crypto? For me, the choice is to have the option now, even when I don't need it, because if I do need it, its too late...

    As for SSL, time moves on and I wouldn't be surprised to see hardware encryption supporting much higher workloads used for common activities in the future. SSL isn't brand new stuff... And as the hardware becomes cheaper, its just like a mouse. Why *not* have it?

    With your address and such, its just like encryption these days. Guess what? Pretty much everything available to us is crackable... (I know, I know, you're shocked. *grin*) The question is, how easy do we make it for "them"? My answer? As hard as I reasonably can...

    "Just because you're paranoid doesn't mean they aren't out to get you."

    I'm glad you enjoyed the joke. I was suitably amused with myself for coming up with it but then I was worried it might come across too irritating/insulting.

    I plan on playing with security more seriously (up to and including using an encrypted filesystem) on my Linux box once I get time to bother to do more than slump in front of my monitor at nites... *chuckle* Gotta love a deadline.

  • This is slightly offtopic... we're building a large scale site thats expected to handle 180k pages an hour, the majority of them encrypted with SSL. Our server platform is Solaris, but even with load balancing, I think the servers will choke on this much SSL :)

    Does anybody have any experiences with using this kind of solution? and are there any export restrictions etc on the hardware (our company is in the UK)? I'm a little fuzzy about whether the key strength is determined by the hardware, or the software controlling it.

    We most probably will use Apache, but NS Enterprise is also an option.

    Yahoo! [yahoo.com] have a category devoted to this stuff, but I didn't know where to start.

  • by Anonymous Coward
    This is why many people don't use OpenBSD. They don't like to be proactive about security, even minorly so. Or they don't see the point. And if it doesn't suit them, they think they have to search for a reason to use it.

    Look, are you afraid of remote logins? Data protection? Connecting securely to another machine? Then this might prove useful. To others, it may not be because they interoperate in a world where no one really gives a *real* damn about security (I mean beyond the lip service you get from several Linux distros (e.g. Redhat), MS products, etc.).

    If anything, it isn't so you "hide" something. It can be simply an added layer of protection so your Linux or BSD box doesn't become some bouncing off point for attacks to other boxes, reducing your possible liability (I don't mean necessarily legal ones either; I don't want the feds blasting down my door because they *think* I'm the one hitting a machine when in reality someone hacked into it first).

    --
    Pronounce Linux as "LIE NUX": it's more representative of the community and the OS because of the way it sounds. It has the word "Lie" in it and rhymes with the word "Sucks."
  • 3DES is not known to have exploitable weaknesses. If you have a choice between 3DES and anything else, the current choice is 3DES.

    Except that I can't find out how DES was developed. Oh sure I have the source, but it contains tables and tables and tables of magic numbers! The choice of the values for the S boxes and why and how those choices were made is **still** classified! Why? In the interests of my own security, I have no choice but to assume that it was to leave in some weak back door to the data that Feds (and any h4xx0r who stumbles upon the same trick) can quickly exploit at any time.

    The problem is that nothing else is as well-explored; all of the "NSA-safe" algorithms are too new to have been properly dug through.

    But at least other algorithms *can* be explored. There's no magic unexplainable source code in there. And I trust many crypto experts around the globe saying [crypto-method] is secure based on examining the algorithm than I do the gov't telling me DES is secure "because we say it's secure but won't tell you why". Besides, the DOJ/FBI never did crack Kevin Mitnick's blowfished files. And for that, they refuse to return his equipment to him on the grounds that it "might" (excuse me?) contain illegally obtained data.

  • This sounds like it'll be pretty handy for things like VPNs.

    In browsing the web sites mentioned, I don't see pricing/availability info on the actual hardware, only mention that "we OEM."

    Are there vendors actually selling these in "consumer" quantities?

  • Sure -- take a look at Hi/fn's customer lists (you might have to look into the press releases for info here, sorry); more and more of them are looking at and announcing DSL/cable scale routers.

    -Billy
  • Except that I can't find out how DES was developed. Oh sure I have the source, but it contains tables and tables and tables of magic numbers! The choice of the values for the S boxes and why and how those choices were made is **still** classified! That's true, and should have an impact on the decision process -- but again, we've been eyeballing those S-boxes for a LONG time, and we've found a lot of their characteristics -- and all of them we've found so far indicate that they're _strong_, not weak. But at least other algorithms *can* be explored. There's no magic unexplainable source code in there. Now, what would make you say _that_? The fact that you haven't studied crypto? _All_ of the other algorithms contain incompletely understood mathematics. Even RC4, a model of beauty, simplicity, and NO magic numbers, is a black box mathematically. And I trust many crypto experts around the globe saying [crypto-method] is secure based on examining the algorithm Ahem. Fire them. All of them. Any crypto expert telling you an algorithm is "secure" is LYING. Okay, there's ONE exception: one-time-pad. And that's impractical. than I do the gov't telling me DES is secure "because we say it's secure but won't tell you why" Well, they don't do that -- but there _are_ hundreds and even thousands of cryptographers who have focussed on DES for years and years, and who have found not only no holes, but have found that holes which are present in other similar algorithms are absent in DES. Besides, the DOJ/FBI never did crack Kevin Mitnick's blowfished files. If they had a secret method for craching DES, would they have admitted it? Certainly not. Blowfish is more likely, since admitting that wouldn't collapse the banking system, but it's still unlikely, since if they can crack it they'll want to save the secrecy for someone they don't have control over. Mitnick is nothing. -Billy
  • Except that I can't find out how DES was developed. Oh sure I have the source, but it contains tables and tables and tables of magic numbers! The choice of the values for the S boxes and why and how those choices were made is **still** classified!

    When the diffrential-cryptoanalsis attack came out in the mid-90s DES was one of the few cyphers that were extreamly resistant to it. DES with the old pre-NSA-change S-Boxes was very weak against the "new" attack.

    There were many people who beleved that

    • NSA "must have" known about the "new" attack for 20+ years
    • The S-Box change was to make sure DES was resistant against that attack

    There is no reason to beleve that the S-Box change made DES weaker. The again there is no reason to beleve that it didn't. Or wasn't breakable by some other means the NSA knew about, and they wanted to fix the S-Boxes because they thought some other goverment knew how to attack them.

    It's a hard field to make a right choice in, only in part because paranoia is actually a good mindset to be in when doing crypto think. I beleve 3DES is relitavly safe. But I don't know. I'll feel much better after we have 5+ years of experiance with whatever cypher wins the AES selection process.

  • If your network link is encrypted, is there any reason for encrypted applications like ssh, https, and friends? It seems the answer would be no, but I'm not an expert.
  • SSLv2, SSLv3 and TLS all support DES and 3DES (according to the installed ciphers in my copy of Opera 3.62 on Windows). So this chip will help with this bit of SSL, once the initial key exchange stuff is done; no doubt an accelerator that supported the key exchanges better would be faster.

    This would be a good chip to use for IPSec VPNs with pre-shared keys - OpenBSD comes with IPSec as standard these days, so it could make a nice firewall/VPN gateway combo. I believe quite a few router manufacturers use Hi/fn chips, so it should be fairly good.
  • I've always wanted a encryptor/decryptor board that is a huge FPGA or similar with a PCI busmaster interface. It would be better if it could hold a large number of differnt keys that the OS then can control the setting and use of. The key space would be write only memory so they can't be read back by any process. Only written to. The board would operate in burst mode when takling on the PCI bus. It would transfer in a block of memory, encrypt it, then burst mode transfer it out. It's operation would be much like a DMA controller, but with the encryption added in. By using a FPGA one can change the programming of the board as new methods come out. One would need a program protect jumper, but that is easy to do.
  • I'm not familiar with the issues of inet_addr, but mktemp is vulnerable to race conditions, where an malicious program could slip untrusted data into a temp file, which should be considered a trusted source for storage.

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  • This won't help SSL because SSL uses a different
    type of crypto made of up several parts.
    SSL can use DES (not DES-3 but a DES-3 engine should be able to do DES). SSL also uses MD5 and SHA which this device can do so maybe that would help some. The chip does not do the public key things that are required for cert signing and inital key exchange. Once the keys have been exchanged the hardware might be able to speed up some of the other bits but the overhead to talk to the card may be more than its worth.
  • I sure as hell wouldn't want my credit card number floating around in clear text... how about you?

    Yeah...that would almost be as bad as giving your credit card to, say, a waiter or something where they can take it away and look at it!

    I'm just kidding, but I find it kind of interesting that people are willing to hand the piece of plastic over the several people each day, but not transmit it in the clear over the net, where it's far less likely anyone is looking. I say, if you're going to be anal about your credit card numbers, you should be anal in all situations. Of course, that would make it nearly impossible to use the things. Catch 22? Who knows...

  • IPSec can tell you what machine you're talking to, but not which user AFAIK. So it isn't as powerful as ssh's RSA authentication or SSL client certificates.
  • Will these crypto chips still be a good idea when AES comes out? It's going to be much faster than 3DES.
  • by William Tanksley ( 1752 ) on Thursday April 13, 2000 @01:00PM (#1134288)
    FPGA is cool, but it's really slow. We prototyped one of our old chips in it back when, and decided we didn't enjoy it (plus, almost no existing FPGA will hold a compression engine).

    A better solution is to slap a MIPS processor, one of Hi/fn's newer chips (with a MIPS bus and protected mode, the 7811 will do for now, especially with its six DMA channels), and some memory on a PCI board. Write some code for the MIPS, and you've got yourself a packet processor which can be made FIPS-secure, possibly up to level 3. See the data sheet for the 7811 for more info on this kind of thing.

    -Billy
  • by William Tanksley ( 1752 ) on Thursday April 13, 2000 @12:26PM (#1134289)
    3DES is not known to have exploitable weaknesses. If you have a choice between 3DES and anything else, the current choice is 3DES.

    The problem is that nothing else is as well-explored; all of the "NSA-safe" algorithms are too new to have been properly dug through.

    I personally like RC4 more than DES-type algorithms, but it's even less understood. Twofish is an impressive algorithm as well, but again, its review process has only started. When (if) it becomes AES, then it'll have enough attacks to make it worth considering.

    -Billy
  • by William Tanksley ( 1752 ) on Thursday April 13, 2000 @12:33PM (#1134290)
    <i>The sad part is, even in meta-moderation these mismoderated points won't be corrected. If they hate BSD while moderating, why would their friends who are meta-moderating be any different</i>

    Because metamoderation involves random selection rather than self-selection. Only people "interested" in BSD (or Hi/fn, or HW encryption) will be attracted to this story, and unfortunately there are simply more people negatively than positively interested right now. Hopefully, the random selection involved in metamoderation will result in a more "disinterested" (i.e. impartial) group of people.

    -Billy
  • by William Tanksley ( 1752 ) on Thursday April 13, 2000 @12:36PM (#1134291)
    This particular chip (Hi/fn 7751) was designed and tested to accelerate SSL, so I suspect it won't have a problem there. I've put a couple of million SSL packets through it (give or take a million, who's counting).

    -Billy
  • by William Tanksley ( 1752 ) on Thursday April 13, 2000 @04:27PM (#1134292)
    Grin. I think that's part of it, yes.

    Actually, it's not too suprising that they have an influence on the RFCs; they're very relaxed about their patents, and tend to be willing to politely compete with people who are violating them (or, more often, fairly license to people who were starting to infringe). The only time I've seen them get nasty is when the competitor starts making threats, as happened with Microsoft. (It was good to see MS get a comeuppance there. :-)

    For those who don't know, BTW, Hi/fn is the core of the company formerly known as STAC; we split off from STAC a couple of years ago.

    -Billy
  • by William Tanksley ( 1752 ) on Thursday April 13, 2000 @12:06PM (#1134293)
    Well, Hi/fn helped design Twofish (Doug Whiting is our CTO), one of the leading AES candidates, so although our current chips won't run AES :), there's no room for doubt that our future chips will be able to.

    The chip they're using also accelerates DES, RC4, SHA-1, MD5, LZS, and MPPC. I wonder whether their driver handles all of that?

    -Billy

    P.S.: I'm not connected to any department at Hi/fn which would know these things for sure; I'm only using publicly available information, so your guess is as good as mine.
  • by keepper ( 24317 ) on Thursday April 13, 2000 @11:45AM (#1134294) Homepage
    This would give the BSD's more ground on large
    e-commerce websites, since hardware crypto is usually used when you need to reduce the load
    on a loaded ssl server. I say the BSD's because this is likely to be ported over to the rest too

    Cool...

    FreeBSD.... The Daemon Made me do it
  • by overshoot ( 39700 ) on Thursday April 13, 2000 @01:05PM (#1134295)
    Further work will now happen. We wish to support other products (ie. IRE, Bluesteelnet, perhaps even 3COM or PCC-ISES if they would open their minds). Some crypto chip vendors are being extremely friendly to us. If anyone wants to help write drivers, get in touch.

    In case anyone cares, specs for the VLSI (Philips) VSC115 [semiconductors.com] are published. Pretty nice performance specs. The official policy is to support Linux driver development for new products, but the details are still in the works and BSD is (alas) not a priority.
  • another neat thing, besides OpenBSD getting cooler, is that some companies are going to be using [prnewswire.com] this hardware encryption/decryption/authentication/etc. technology for DSL modems.

    there are press releases talking about this on the Hi/fn press release page [hifn.com].

    how long, do you suppose, before someone makes a keyboard that ssh's (or use some equivalent measure to encrypt all traffic between the keyboard and computer) to the computer, so that the truly paranoid can feel a little less worried about someone planting a KeyGhost [keyghost.com] on a machine when they're not looking? or is that way too paranoid?

  • by William Tanksley ( 1752 ) on Thursday April 13, 2000 @12:45PM (#1134297)
    Hmm. Well, the problem is that a network link is rather connection-oriented; it only encrypts stuff going from your machine to another specific one.

    If you try to visit any other sites, as when web browsing, you're not using the secured link any more, so you have to negotiate a new one.

    The main use for this type of technology is VPNs: two seperate buildings full of computers which want to be on the same network, but which want to use the internet (cheap) rather than a leased line (expensive). In that case, we simply plug one of these 7751 boards into the routers in each building, and tell the routers to encrypt when talking to each other. None of the users need know that they're being protected :).

    -Billy

Marvelous! The super-user's going to boot me! What a finely tuned response to the situation!

Working...