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.