Free cryptography software for linux

Flux is an easy-to-use crypto, compression, I/O, and memory management library.

Flux consists of utility APIs that apply compression and strong cryptography to I/O channels (file or network), do strong hashing, and exchange C structs in an architecture-independent fashion.

It also provides n-ary trees whose contents can be serialized to human-readable files or network streams, along with some related utilities. It is written in C and integrates with the GLib main loop.

Ajisai is a SSL/TLS implementation written entirely from scratch in C++. It uses Botan for performing the cryptography and X.509 handling.
This is an alpha release, it is virtually certain that incompatible API changes will be made in the future. Suggestions on weak points in the API are most welcome. As of now, Ajisai is somewhat fragile, and does not make available many of the features TLS offers.
Currently only SSLv3 and TLS 1.0 are supported; TLS 1.1 and DLTS will be supported in future releases. At this point is can be built only on Unix and Unix-like systems, but that will change eventually.
TODO:
Bugs:
- We assume one recordone handshake message, this is not true for IIS/IE, probably lots of other stuff.
- No support for client authentication on either end (currently some code for it, but disabled as its completely broken).
Protocol:
- TLS 1.1
- TLS extensions
- DTLS
- Reading a SSLv2 client hello
- Session caching
- Compression support
- Anonymous Diffie-Hellman, maybe. Its useful in some contexts.
- OpenPGP key support
Server:
- We want to be able to multiplex multiple Server objects at once (multiple clients). This will probably be based on a Socket* select(2) wrapper, but I might end up leaving it to the application.
Sockets:
- IPv6 support
- IPv4 + IPv6 UDP sockets (for DTLS)
- Write a select() wrapper
- Support Win32 sockets (IPv4/IPv6)

CryptoServer is OpenSource Server-side cryptography tool and run as daemon.

It is already tested in very busy environment and can support over one million transaction an hour.

CryptoServer accept the GPL License and can use it for any purpose as is.

Linvpn is a secure socket layer for pppd. Linvpn project allows creation of virtual private networks by using an IP routing system between PPP network interfaces.

Cryptography is done by libgcrypts 3DES or blowfish, and Initialization Vector (IV) is changed in each packet transmission.

As linvpn works as client and server, and communication is a single TCP connection, it allows creation of secure tunnels even in complex network layouts, when one or both endpoints are behind a firewall or NAT, with or without dynamic IP addresses.
Linvpn has been tested under Linux, FreeBSD, NetBSD and OpenBSD.

borZoi is a C++ Elliptic Curve Cryptography Library. borZoi implements the following algorithms using elliptic curves defined over finite fields of characteristic 2 (GF2m):
ECDSA (Elliptic Curve Digital Signature Algorithm)
As specified in ANSI X9.62, FIPS 186-2 and IEEE P1363.
ECIES (Elliptic Curve Integrated Encryption Scheme)
As specified in ANSI X9.63 and the IEEE P1363a Draft.
Elliptic Curve Diffie-Hellman Key Agreement Scheme
As specified in ANSI X9.63 and IEEE P1363.
The AES symmetric encryption scheme (NIST AES draft) and SHA-1 hash algorithm (FIPS 180-1) are also included.
Installation:
borZoi can be built using either an internal math library or Victor Shoups NTL number theory library which provides better performance. If NTL is used, it must be first downloaded from http://www.shoup.net and installed.
GNU Development Tools:
1) (If NTL is not installed) ./configure
(If NTL is installed) ./configure --enable-ntl
2) make
3) make install
Enhancements:
- Fixed a bug in the KDF2 function which caused the effective key length to be limited to a maximum of 160 bits.
- This problem did not affect the security of ECKAS_DH1 because the key length is set to 128 bits, however the security of the 256 bit symmetric key used in ECIES was reduced to an effective key length of 160 bits.
- Corrected the section on KDF2 in the manual so that the oLen parameter refers to the length of the key in bytes not bits.

Openwall GNU/*/Linux (or Owl for short) is a security-enhanced operating system with Linux and GNU software as its core, compatible with other major distributions of GNU/*/Linux. Openwall GNU/*/Linux is intended as a server platform. And, of course, it is free.
Main features:
- While we value quality above feature set, Owl does indeed offer a number of features besides just trying to be more secure.
- Most obviously, Owl can be used as a base for installing whatever software is generally available for GNU/*/Linux systems. It offers some compatibility (read below) for software packages found in or developed for other major Linux distributions, such as Red Hat Linux.
- Additionally, being a server platform, Owl will include a growing set of integrated Internet services.
- Owl includes a complete build environment capable to re-build the entire system from source with one simple command ("make buildworld"). (This is explained in more detail below.)
- Owl supports multiple architectures (currently x86, SPARC, and Alpha), as this lets you use it in more cases and helps us catch certain classes of software bugs earlier, thus improving the reliability of Owl packages.
Security:
- Owl combines several approaches to reduce the number and/or impact of flaws in its software components and impact of flaws in third-party software that one might install on the system.
- The primary approach used is proactive source code review for several classes of software vulnerabilities. However, because of the large amount of code, theres a certain level of "importance" for a software component or a part thereof to be audited. - Currently, only pieces of code which are typically run with privileges greater than those of a regular user and/or typically process data obtained over a network are audited before the corresponding software component is included. This covers relevant code paths in many of the system libraries, all SUID/ SGID programs, all daemons and network services. Other software may be audited when it is already a part of Owl. Potential problems found during the audit are fixed or, in some pathological cases, may prevent the software component from being included. In general, code quality and privilege management are always considered when theres a choice between implementations of a feature. As the project evolves, many of the software components will be replaced with ones of our own.
- When packaged for Owl, the software components are configured or, when necessary, modified in order to provide safe defaults, apply the least privilege principle, and introduce privilege separation. The use of safe defaults, where optional and potentially dangerous features need to be turned on explicitly, lets us audit the pieces of code used in in the default configuration in a more thorough way. Extra systems administration facilities ("owl-control") are provided for managing system features such as the optional SUID/SGID binaries independently from installing the corresponding packages. Every Owl package will have its audit status documented to allow for risk assessment.
- While source code review is the preferred way to deal with software vulnerabilities, it cant be applied in all cases. Typically, when insecure third-party software is installed on an otherwise secure system, "the game" is lost. The only thing an operating system can guarantee is that potential unauthorized access would be limited to those privileges granted to the software in question. However, in the recent years, a number of approaches were developed which reduce the likelihood and/or may reduce the impact of successful real-world attacks on insecure third-party software. Owl will use some of those "hardening" approaches in various parts of the system.
- Owl uses "strong" cryptography within its core components, and already includes some security policy enforcement (proactive password checking with "pam_passwdqc", password and account expiration, network address- based access control) and integrity checking ("mtree") capabilities. It is one of our goals to provide a wide range of security tools with Owl, available for use "out of the box".
Enhancements:
- After many Owl-current snapshots, Owl 2.0 release is finally out.
- Owl 2.0 is built around Linux kernel 2.4.32-ow1, glibc 2.3.6 (with our security enhancements), GCC 3.4.5, and recent versions of over 100 other packages.
- It offers binary- and package-level compatibility for most packages intended for Red Hat Enterprise Linux 4 (RHEL4) and Fedora Core 3 (FC3), as well as for many FC4 packages.
- Additionally, Owl 2.0 uses our new installer, making installation a lot easier than it used to be for Owl 1.1 and below.

jSaluki is a small easy to use Java Hyperelliptic Curve Cryptography Library.

Hyperelliptic Curve Cryptography is still an experimental area so this library is only recommended for research and educational purposes.

Real life cryptosystems should use a more proven method such as Elliptic Curve Cryptography.

Quick Start:

javac jSaluki_Example.java
java jSaluki_Example

seppl is both a protocol definition and a software implementation of a new encryption layer for IPv4. seppl project makes use of symmetric cryptography for encrypting the whole traffic on a network. Its implementation is designed around Linux netfilter/iptables.
seppl introduces two new netfilter targets: CRYPT and DECRYPT. A firewall rule may thus be used for encrypting/decrypting the incoming and outgoing network traffic. This makes seppl extraordinarily easy to use, since no daemons need to run for secure communication.
seppl uses the encryption engine of the Linux Cryptographic API which is available in kernel 2.4.22 and newer.
seppl is primarily intended for encrypting wireless LANs (as secure replacement of the broken WEP encryption) and local ethernet networks but may be used for large scale VPN solutions as well.
The protocol seppl relies on is not compatible with any other software. The protocol is open and well defined but there is no implementation other than this reference software.
Why SEPPL, there are already IPSEC, CIPE,...?
CIPE may be used for point-to-point connections only. It has tunnel structure and thus introduces new IP addresses. This is not always desirable. It requires a user space daemon.
IPSEC/FreeSwan is extremely complicated to use. Due to its strange routing scheme it is nearly impossible to use together with routing daemons. IPSEC is heavyweight.
seppl is truely peer-to-peer. It encrypts seamlessly all outgoing traffic and it thus compatible with routing daemons. It is extremely easy to use as well, as it makes no change to the normal routing behaviour. seppl is extremely lightweight.
The Implementation
The implementation consists of three Linux kernel modules: seppl.o, ipt_CRYPT.o and ipt_DECRYPT.o. The former is the in-kernel key manager, the latter are the two new netfilter targets. Both depend on seppl.o.
seppl.o must be inserted into kernel in first place. The key manager may be accessed with the file /proc/net/seppl_keyring. It contains binary key data, and is initially empty. You may add a new key by writing it to that file.
The two Python scripts seppl-ls and seppl-gen-key me be used for key management. seppl-ls may be used for converting seppl keys between the binary format used by /proc/net/seppl_keyring and a human readable XML based format. Simply call seppl-ls for a list of all currently active keys. seppl-gen-key generates a new key from /dev/urandom. By default it will use the XML format. The parameter -x forces binary mode. You may generate and activate two keys "linus" and "alan" by issuing the following command lines:
seppl-gen-key -n linus -x > /proc/net/seppl_keyring
seppl-gen-key -n alan -x > /proc/net/seppl_keyring
seppl-ls without argument lists the new keys saved in the kernel keyring. You may remove all (currently unused) keys by issuing:
echo clear > /proc/net/seppl_keyring
Since seppl is based on symmetric cryptography using shared keys you have to copy newly generated keys to every host you want to connect to your seppl infrastructure. (preferably via SSH or any other secure file transfer) You get a binary copy of your current keyring by issuing:
cat /proc/net/seppl_keyring > keyring.save
Now copy that file keyring.save to all other hosts and issue the following command there:
cat keyring.save > /proc/net/seppl_keyring
That is simple, isnt it?
After doing so you may configure your firewall settings on each host:
iptables -t mangle -A POSTROUTING -o eth0 -j CRYPT --key linus
iptables -t mangle -A PREROUTING -i eth0 -j DECRYPT
This will encrypt all outgoing traffic on eth0 with the key "linus". All incoming traffic is decrypted with either "linus" or "alan", depending on the key name specified in the specific network packet. Unencrypted incoming packets are silently dropped. Use
iptables -t mangle -A PREROUTING -p 177 -i eth0 -j DECRYPT
for allowing both crypted and unencrypted incoming traffic.
Thats it. Youre done. All your traffic on the local subnet is now crypted with seppl.
The default cipher is AES-128. If you dont specify the name of the used key it defaults to "def".
An SysV init script /etc/init.d/seppl is provided. It will load seppls kernel modules and write all keys from the directory /etc/seppl to the kernel keyring. It will not add any firewall rules, however.
Performance issues
The network packets are increased in size when they are crypted, since two new headers and the IV are added. (36 bytes in average) This conflicts on some way with the MTU management of the Linux kernel and results in having all large packets (that is: package size near MTU) fragmented in one large and another very small package. This will hurt network performance. A work-around of this limitation is using the TCPMSS target of netfilter to adjust the MSS value in the TCP header to smaller values. This will increase TCP perfomance, since TCP packets of the size of the MTU are no longer generated. Thus no fragmentation is needed. However, TCPMSS is TCP specific, it wont help on UDP or other IP protocols.
Add the following line before encryption to your firewall setup:
iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o eth0 -j TCPMSS --set-mss $((1500-40-8-16-6-15))
The Protocol
For encryption every single unencrypted packet is taken and converted to a crypted one. Not a single further packet is ever sent.
Original SEPPL counterpart
+------------+ +-----------------------+
| IP-Header | | Modified IP-Header | |
+------------+ +-----------------------+ |
| Payload | | SEPPL-Header | > Unencrypted
+------------+ +-----------------------+ |
| Initialization Vector | |
+-----------------------+ /
| SEPPL-Header |
+-----------------------+ | Crypted
| Payload | |
+-----------------------+ /
The original IP header is kept as far as possible. Only three fields are replaced with new values. The protocol number is set to 177, the fragment offset is set to 0 and the total length is corrected to the new length. All other fields are kept as is, including IP options.
The unencrypted seppl header consists of a one-byte cipher number and a key name. Currently only 0 and 1 are defined as cipher numbers for AES with 128bit key, resp. AES with 192bit key. The key name (7 bytes) may be used to select a specific key in a larger keyring.
The IV is used for CBC coding of the cipher used. It differs from packet to packet, but is not randomly generated. Due to perfomance reasons, only the initial IV on system startup is randomized, all following IVs are generated by incrementing the previous ones.
The crypted seppl header consists of three saved fields of the original IP header (protocol number, fragment offset, total length) and a byte which is always 0 for detecting unmatching keys.
The payload is the original IP-playload, from the TCP/UDP/other header to the end.
Version restrictions:
- seppl interferes with netfilters connection tracking in some way. Thus you will not be able to use NAT in conjunction with seppl. If you use connection tracking in some other way together with seppl your mileage may vary.
- seppl is tested with Linux 2.6.1. Use version 0.3 for Linux 2.4.