[BACK]Return to crypto.html CVS log [TXT][DIR] Up to [local] / www

Diff for /www/crypto.html between version 1.141 and 1.142

version 1.141, 2014/04/30 08:44:43 version 1.142, 2014/05/02 18:55:39
Line 39 
Line 39 
 We do not directly use cryptography with nasty patents.  We do not directly use cryptography with nasty patents.
 We also require that such software is from countries with useful export  We also require that such software is from countries with useful export
 licenses because we do not wish to break the laws of any country.  licenses because we do not wish to break the laws of any country.
 The cryptographic software components which we use currently were  
 written in Argentina, Australia, Canada, Germany, Greece, Norway, and  
 Sweden.  
 <p>  <p>
   
 When we create OpenBSD releases or snapshots we build our release  
 binaries in free countries to assure that the sources and binaries we  
 provide to users are free of tainting.  In the past our release binary  
 builds have been done in Canada, Sweden, and Germany.<p>  
   
   
 OpenBSD was the first operating system to ship with an IPsec stack.  OpenBSD was the first operating system to ship with an IPsec stack.
 We've been including IPsec since the OpenBSD 2.1 release in 1997.  We've been including IPsec since the OpenBSD 2.1 release in 1997.
 <p>  <p>
Line 107 
Line 98 
 network data interrupt latency, inter-keypress timing and disk IO  network data interrupt latency, inter-keypress timing and disk IO
 information to fill an entropy pool.  Random numbers are available for  information to fill an entropy pool.  Random numbers are available for
 kernel routines and are exported via devices to userland programs.  kernel routines and are exported via devices to userland programs.
 So far random numbers are used in the following places:<p>  
   
 <ul>  
 <li>Dynamic sin_port allocation in bind(2).  
 <li>PIDs of processes.  
 <li>IP datagram IDs.  
 <li>RPC transaction IDs (XID).  
 <li>NFS RPC transaction IDs (XID).  
 <li>DNS Query-IDs.  
 <li>Inode generation numbers, see getfh(2) and fsirand(8).  
 <li>Timing perturbance in traceroute(8).  
 <li>Stronger temporary names for mktemp(3) and mkstemp(3)  
 <li>Randomness added to the TCP ISS value for protection against  
         spoofing attacks.  
 <li>random padding in IPsec esp_old packets.  
 <li>To generate salts for the various password algorithms.  
 <li>For generating fake S/Key challenges.  
 <li>In <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=isakmpd&amp;sektion=8">isakmpd(8)</a>  
         to provide liveness proof of key exchanges.  
 </ul>  
   
 <p>  <p>
 <a name="hash"></a>  <a name="hash"></a>
 <h3><font color="#e00000">Cryptographic Hash Functions</font></h3><p>  <h3><font color="#e00000">Cryptographic Hash Functions</font></h3><p>
Line 142 
Line 113 
 </ul>  </ul>
 <p>  <p>
   
 In OpenBSD MD5, SHA1, and RIPEMD-160 are used as Cryptographic Hash Functions,  
 e.g:<p>  
 <ul>  
 <li>In <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=skey&amp;sektion=1">S/Key(1)</a>  
     to provide one time passwords.  
 <li>In <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=ipsec&amp;sektion=4">IPsec(4)</a>  
     and  
     <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=isakmpd&amp;sektion=8">isakmpd(8)</a>  
     to authenticate the data origin of packets and to ensure packet integrity.  
 <li>For FreeBSD-style MD5 passwords (not enabled by default), see  
     <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=login.conf&amp;sektion=5">  
     login.conf(5)</a>  
 <li>In libssl for digital signing of messages.  
 </ul>  
 <p>  <p>
   
 <p>  
 <a name="trans"></a>  <a name="trans"></a>
 <h3><font color="#e00000">Cryptographic Transforms</font></h3><p>  <h3><font color="#e00000">Cryptographic Transforms</font></h3><p>
   
Line 166 
Line 121 
 are normally used with an encryption key for data encryption and with  are normally used with an encryption key for data encryption and with
 a decryption key for data decryption. The security of a Cryptographic  a decryption key for data decryption. The security of a Cryptographic
 Transform should rely only on the keying material.<p>  Transform should rely only on the keying material.<p>
   
 OpenBSD provides transforms like DES, 3DES, Blowfish and Cast for the  
 kernel and userland programs, which are used in many places like:<p>  
 <ul>  
 <li>In libc for creating  
     <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=blf_key&amp;sektion=3">Blowfish</a>  
     passwords.  See also the <a href="papers/bcrypt-paper.ps">USENIX paper</a>  
     on this topic.  
 <li>In  
     <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=ipsec&amp;sektion=4">IPsec(4)</a>  
     to provide confidentiality for the network layer.  
 <li>In <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=isakmpd&amp;sektion=8">isakmpd(8)</a>  
     to protect the exchanges where IPsec key material is negotiated.  
 <li>In libssl to let applications communicate over the de-facto standard  
         cryptographically secure SSL protocol.  
 </ul>  
   
 <p>  
 <a name="hardware"></a>  
 <h3><font color="#e00000">Cryptographic Hardware Support</font></h3><p>  
   
 OpenBSD, starting with 2.7, has begun supporting some cryptography hardware  
 such as accelerators and random number generators.  
 <ul>  
 <li><b><a href="http://www.openbsd.org/cgi-bin/man.cgi?query=crypto&amp;sektion=9">  
     IPsec crypto dequeue</a></b><br>  
     Our IPsec stack has been modified so that cryptographic functions get  
     done out-of-line.  Most simple software IPsec stacks need to do  
     cryptography when processing each packet.  This results in synchronous  
     performance.  To use hardware properly and speedily one needs to separate  
     these two components, as we have done.  Actually, doing this gains some  
     performance even for the software case.  
 <p>  
 <li><b><a href="http://www.openbsd.org/cgi-bin/man.cgi?query=hifn&amp;sektion=4">  
     Hifn 7751</a></b><br>  
     Cards using the Hifn 7751 can be used as a symmetric cryptographic  
     accelerator, i.e., the  
     <a href="http://www.soekris.com/vpn1201.htm">Soekris VPN1201 or VPN1211</a>  
     (<a href="http://www.soekris.com/how_to_buy.htm">to buy</a>)  
     or  
     <a href="http://www.powercrypt.com">PowerCrypt</a>.  
     Current performance using a single Hifn 7751 on each end of a tunnel  
     is 64Mbit/sec for 3DES/SHA1 ESP, nearly a 600% improvement over  
     using a P3/550 CPU.  Further improvements are under way to resolve a  
     few more issues, but as of April 13, 2000 the code is considered  
     stable.  We wrote our own driver for supporting this chip, rather  
     than using the (USA-written)  
     <a href="http://www.powercrypt.com">PowerCrypt</a> driver, as well  
     our driver links in properly to the IPsec stack.  
     The 7751 is now considered slow by industry standards and many vendors  
     have faster chips (even Hifn now has a faster but more expensive  
     chip).  Peak performance with 3DES SHA1 ESP is around 64Mbit/sec.  
     <p>  
     After 2.9 shipped, support was added for the Hifn 7951 chip, a  
     simplified version of the 7751 which adds a public key accelerator  
     (unsupported) and a random number generator (supported).  Cards  
     were donated by <a href="http://www.soekris.com/">Soekris Engineering</a>.  
     <p>  
     After 3.0 shipped, support was added for the Hifn 7811 chip, a  
     faster version of the 7751 (around 130Mbit/s) with a random number  
     generator.  A card was donated by <a href="http://www.gtgi.com/">GTGI</a>.  
     <p>  
     After 3.2 shipped, support was added for the LZS compression algorithm  
     used by <a href="http://www.openbsd.org/cgi-bin/man.cgi?query=ipcomp&amp;sektion=4">ipcomp(4)</a>.  
     <p>  
     After 3.4 shipped, support was added for the 7955 and 7956 chips.  
     In addition to all the features of the previous 7951 chip, these add AES.  
     <p>  
     Hifn was initially a difficult company to deal with (threatening to sue  
     us over our non-USA reverse engineering of their crypto unlock algorithm),  
     but more recently they have been very helpful in providing boards and  
     support.  
     <p>  
   
 <li><b><a href="http://www.openbsd.org/cgi-bin/man.cgi?query=lofn&amp;sektion=4">  
     Hifn 6500</a></b><br>  
     This device is an asymmetric crypto unit.  It has support for RSA, DSA,  
     and DH algorithms, as well as other major big number functions.  It also  
     contains a very high performance random number generator.  We have one  
     device, full documentation, and sample code.  As of OpenBSD 3.1,  
     both the random number generator and big number unit are working.  
     <p>  
   
 <li><b><a href="http://www.openbsd.org/cgi-bin/man.cgi?query=nofn&amp;sektion=4">  
     Hifn 7814/7851/7854</a></b><br>  
     This device is a packet processor and asymmetric crypto unit.  It has  
     support for RSA, DSA, and DH algorithms, as well as other major big number  
     functions and also has a random number generator.  Currently, only the  
     big number engine and the random number generator are supported (no  
     packet transforms).  
     <p>  
   
 <li><b><a href="http://www.openbsd.org/cgi-bin/man.cgi?query=ubsec&amp;sektion=4">  
     Broadcom BCM5801/BCM5802/BCM5805/BCM5820/BCM5821/BCM5822/5823/5825/5860/5861/5862  
     (or beta chip Bluesteelnet 5501/5601)</a></b><br>  
     Just after the OpenBSD 2.7 release, we succeeded at adding preliminary  
     support for these early release parts provided to us by the vendor,  
     specifically starting with the test chip 5501.  
     These devices provide the highest performance symmetric cryptography  
     we have seen.  
     <p>  
     Bluesteelnet was bought by Broadcom and started making real parts.  
     Their new BCM5805 is similar, except that they also add an asymmetric  
     engine for running DSA, RSA, and other such algorithms.  With approximate  
     performance starting at more than four times as fast as the Hifn,  
     hopefully this chip will become more common soon.  
     <p>  
     The Broadcom/Bluesteelnet people have been great to deal with.  They gave  
     us complete documentation and sample code for their chips and a  
     sufficient number of cards to test with.  
     <p>  
     Post 2.8, this driver was also modified to generate random numbers on  
     the BCM5805 and similar versions, and feed that data into the kernel  
     entropy pool.  
     <p>  
     Post 2.9, support was added for the BCM5820, which is mostly just a  
     faster (64bit, higher clock speed) version of the BCM5805.  Untested  
     support for the BCM5821 was also added post 3.0.  
     <p>  
     As of 3.1, the big num engine is supported, and RSA/DH/DSA operations  
     can be accelerated.  
     <p>  
     Support for the BCM5801, BCM5802, BCM5821 and BCM5822 was added before  
     OpenBSD 3.2 (the untested BCM5821 support in 3.1 was broken because of  
     some undocumented interrupt handling requirements).  
     <p>  
     Partial support for BCM5823 was added for 3.4.  
     <p>  
     Support for the BCM5825, BCM5860, BCM5861, and BCM5862 including support  
     for AES with the BCM5823 or newer was added after 4.5.  
     <p>  
   
 <li><b><a href="http://www.openbsd.org/cgi-bin/man.cgi?query=ises&amp;sektion=4">  
     Securealink PCC-ISES</a></b><br>  
     The <a href="http://www.safenet-inc.com/technology/chips/safexcel_ises.asp">  
     PCC-ISES</a> is a new chipset from the Netherlands.  We have received  
     sample hardware and documentation, and work on a driver is in progress.  
     At the moment, the driver is capable of feeding random numbers into  
     the kernel entropy pool.  
     <p>  
   
 <li><b><a href="http://www.openbsd.org/cgi-bin/man.cgi?query=safe&amp;sektion=4">  
     SafeNet SafeXcel 1141/1741</a></b><br>  
     After 3.4 shipped, support was for added for these two chips (found on various  
     <a href="http://www.safenet-inc.com/products/accCards/">SafeNet</a>  
     crypto cards. Supports DES, Triple-DES, AES,  MD5, and SHA-1 symmetric crypto  
     operations, RNG, public key operations, and full IPsec packet processing.  
     <p>  
   
 <li><b>SafeNet SafeXcel 1840</b><br>  
     We have received documentation and sample hardware for the  
     <a href="http://www.safenet-inc.com/products/chips/safeXcel1840.asp">SafeNet 1840</a>  
     crypto chip. Work to support at least the RNG and symmetric cryptography of  
     these devices has started.  
     <p>  
   
 <li><b>SafeNet SafeXcel 2141</b><br>  
     We have received documentation and sample hardware for the  
     <a href="http://www.safenet-inc.com/products/chips/safeXcel2141.asp">SafeNet 2141</a>  
     crypto chip. Work to support at least the symmetric cryptography of  
     these devices has started.  
     <p>  
   
 <li><b><a href="http://www.openbsd.org/cgi-bin/man.cgi?query=txp&amp;sektion=4">  
     3com 3cr990</a></b><br>  
     3com gave us a driver to support the ethernet component of this chipset,  
     and based on that, we have written our own ethernet driver. This driver  
     has now been integrated once we were able to get a free license on the  
     microcode.  Due to poor documentation and lack of cooperation (partly  
     because of the high turnover rates at 3Com), the IPsec functions of the  
     chip are not supported.... so this turned out to be a less than completely  
     useful exercise.  
     <p>  
   
 <li><b>Intel IPsec card</b><br>  
     Much like Intel does for all their networking division components, and  
     completely unlike most other vendors, Intel steadfastly refuses to provide  
     us with documentation.  We have talked to about five technical people who  
     are involved in the development of those products.  They all want us to  
     have documentation.  They commend us on what we have done.  But their hands  
     are tied by management who does not perceive a benefit to themselves for  
     providing documentation.  Forget about Intel.  (If you want to buy gigabit  
     ethernet hardware, we recommend anything else... for the same reason:  
     most drivers we have for Intel networking hardware were written without  
     documentation).  
     <p>  
   
 <li><b><a href="http://www.openbsd.org/cgi-bin/man.cgi?query=pchb&amp;sektion=4">  
     Intel 82802AB/82802AC Firmware Hub RNG</a></b><br>  
     The 82802 FWH chip (found on i810, i820, i840, i850, and i860 motherboards)  
     contains a random number generator (RNG).  High-performance IPsec  
     requires more random number entropy.  As of April 10, 2000, we support  
     the RNG.  We will add support for other RNGs found on crypto chips.  
     <p>  
   
 <li><b>VIA C3 RNG</b><br>  
     The newer VIA C3 CPU contains a random number generator as an instruction.  
     As of <a href="33.html">3.3</a> this random number generator is used  
     inside the kernel to feed the entropy pool.  
     <p>  
   
 <li><b>VIA C3 AES instructions</b><br>  
     VIA C3 CPUs with a step 8 or later Nehemiah core contains an AES  
     implementation accessible via simple instructions. As of <a  
     href="34.html">3.4</a> the kernel supports them to be used in an  
     IPsec context and exported by <tt>/dev/crypto</tt>. As of <a  
     href="35.html">3.5</a> performances have been greatly improved  
     and OpenSSL now uses the new instruction directly when available  
     without the need to enter the kernel, resulting in vastly  
     improved speed (AES-128 measured at 780MByte/sec) for applications  
     using OpenSSL to perform AES encryption.  
     <p>  
   
 <li><b>OpenSSL</b><br>  
     Years ago, we had a grand scheme to support crypto cards that can do  
     RSA/DH/DSA automatically via OpenSSL calls.  As of OpenBSD 3.2, that  
     support works, and any card that is supported with such functionality  
     will automatically use the hardware, including OpenSSH and httpd in  
     SSL mode.  No application changes are required.  
 </ul>  
   
 <p>  
 <b>If people wish to help with writing drivers,  
 <a href="#people">come and help us</a>.</b>  
   
 <p>  <p>
 <a name="people"></a>  <a name="people"></a>
Legend:
Removed from v.1.141  
changed lines
  Added in v.1.142