Ports Search

GNU SASL is an implementation of the Simple Authentication and Security Layer framework and a few common SASL mechanisms. SASL is used by network servers (e.g., IMAP, SMTP) to request authentication from clients, and in clients to authenticate against servers. GNU SASL contains a library (`libgsasl'), a command line utility (`gsasl') to access the library from the shell, and a manual. The library includes support for the SASL framework (with authentication functions and application data privacy and integrity functions) and at least partial support for the CRAM-MD5, EXTERNAL, GSSAPI, ANONYMOUS, PLAIN, SECURID, DIGEST-MD5, LOGIN, NTLM and KERBEROS_V5 mechanisms. The library is portable because it does not do network communication by itself, but rather leaves it up to the calling application. The library is flexible with regards to the authorization infrastructure used, as it utilizes callbacks into the application to decide whether an user is authorized or not.

racoon speaks IKE (ISAKMP/Oakley) key management protocol, to establish security association with other hosts. This is the IPSec-tools version of racoon. Enchancements: - Support of NAT-T and IKE fragmentation. - Support of many authentication algorithms. - Tons of bugfixes. Known issues: - Non-threaded implementation. Simultaneous key negotiation performance should be improved. - Cannot negotiate keys for per-socket policy. - Cryptic configuration syntax - blame IPsec specification too... - Needs more documentation. Design choice, not a bug: - racoon negotiate IPsec keys only. It does not negotiate policy. Policy must be configured into the kernel separately from racoon. If you want to support roaming clients, you may need to have a mechanism to put policy for the roaming client after phase 1 finishes.

Super is a setuid-root program that offers: o restricted setuid-root access to executables, adjustable on a per-program and per-user basis; o a relatively secure environment for scripts, so that well-written scripts can be run as root (or some other uid/gid), without unduly compromising security. The design philosophy behind super is two-fold: (a) some users can be trusted when executing certain commands; (b) there are some commands, such as a script to mount CDROM's, which you'd like to be safely executable even by users who are NOT trusted. Although setuid-root scripts are insecure, a good setuid-root wrapper around a sensible non-setuid script can be hard to break, and super provides that wrapper so that even a non-trusted user can use the scripts.

NCrypt is intended to give you security in an insecure environment. If you are wanting to encrypt files (particularly on a multi-user system where you don't have root), wishing to hide your activites from prying eyes, and want to "cover your tracks", then NCrypt is for you. It is a symmetrical file encryptor/decryptor that gives you the choice of the top three candidates for AES as the encryption algorithm (Rijndael, Serpent, Twofish), tries to minimize exposure of the plaintext password in memory, and can safely erase the plaintext version from the hard drive. It compiles without any extra crypto libraries, making it ideal for systems where you just have a compiler and basic libraries (such as an ISP's shell server).

[ excerpt from developer's www site ] The Cryptokit library for Objective Caml provides a variety of cryptographic primitives that can be used to implement cryptographic protocols in security-sensitive applications. The primitives provided include: Symmetric-key cryptography: AES, DES, Triple-DES, ARCfour, in ECB, CBC, CFB and OFB modes. Public-key cryptography: RSA encryption and signature; Diffie-Hellman key agreement. Hash functions and MACs: SHA-1, MD5, and MACs based on AES and DES. Random number generation. Encodings and compression: base 64, hexadecimal, Zlib compression. Additional ciphers and hashes can easily be used in conjunction with the library. In particular, basic mechanisms such as chaining modes, output buffering, and padding are provided by generic classes that can easily be composed with user-provided ciphers. More generally, the library promotes a "Lego"-like style of constructing and composing transformations over character streams.

This module is a Perl-only implementation of the ECB mode. In combination with a block cipher such as DES, IDEA or Blowfish, you can encrypt and decrypt messages of arbitrarily long length. Though for security reasons other modes than ECB such as CBC should be preferred. See textbooks on cryptography if you want to know why. The functionality of the module can be accessed via OO methods or via standard function calls. Remember that some crypting module like for example Blowfish has to be installed. The syntax follows that of Crypt::CBC meaning you can access Crypt::ECB exactly like Crypt::CBC, though Crypt::ECB is more flexible. For example you can change the key or the cipher without having to create a new crypt object.

Sometimes it's necessary to protect some certain data against plain reading or you intend to send information through the Internet. Another reason might be to assure users cannot modify their previously entered data in a follow-up step of a long Web transaction where you don't want to deal with server-side session data. The goal of Crypt::Lite was to have a pretty simple way to encrypt and decrypt data without the need to install and compile huge packages with lots of dependencies. Crypt::Lite generates every time a different encrypted hash when you re-encrypt the same data with the same secret string. Nevertheless you are able to make double or tripple-encryption with any data to increase the security. Decryption works also on hashes that have been encrypted on a foreign host (try this with an unpatched IDEA installation ;-).

This module implements TEA, the Tiny Encryption Algorithm, and some Modes of Use, in Perl and JavaScript. The $key is a sufficiently longish string; at least 17 random 8-bit bytes for single encryption. Crypt::Tea_JS can be used for secret-key encryption in general, or, in particular, to communicate securely between browser and web-host. In this case, the simplest arrangement is for the user to enter the key into a JavaScript variable, and for the host to retrieve that user's key from a database. Or, for extra security, the first message (or even each message) between browser and host could contain a random challenge-string, which each end would then turn into a signature, and use that signature as the encryption-key for the session (or the reply).

The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols with full-strength cryptography world-wide. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL tookit and its related documentation. OpenSSL is based on the excellent SSLeay library developed by Eric A. Young and Tim J. Hudson. The OpenSSL toolkit is licensed under an Apache-style licence, which basically means that you are free to get and use it for commercial and non-commercial purposes subject to some simple license conditions.

The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols with full-strength cryptography world-wide. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the OpenSSL tookit and its related documentation. OpenSSL is based on the excellent SSLeay library developed by Eric A. Young and Tim J. Hudson. The OpenSSL toolkit is licensed under an Apache-style licence, which basically means that you are free to get and use it for commercial and non-commercial purposes subject to some simple license conditions.