Archive for June, 2014

This list of rules by no means is a sure bet to secure your web services, but it will help in preventing script-kiddings from doing some basic browsing around.

MySQL injection attempts are one of the most common hacking attacks against PHP websites. If your website is hosted on a dedicated or virtual server, the best solution is to your server hardened with proper mod_security rules. However, if you’re on shared hosting, this is not an option. If you now think that it’s not possible to protect your website against various hacking methods on shared hosting, you’re wrong. Although it’s not possible to use advanced strategies to protect your website, you’re still able to protect it against hacking attempts using .htaccess rules. To implement such a protection, append your current .htaccess file with the following code, or create a new file called .htaccess, if you don’t use any yet, and place it in your website’s main folder):

Beginning of your .htaccess file to set the basics up

# Block access to the .htaccess file
<files .htaccess>
order allow,deny
deny from all

# No web server version and indexes
ServerSignature Off
Options -Indexes
Options FollowSymLinks

HTTP Headers to Help Secure Your Website

Preventing cross-site request forgery (CSRF) attacks is hard and web applications must be built to prevent CSRF vulnerabilities. The first vulnerability is cross-site scripting (XSS).

Around 70.000 web sites have been catalogued by XSSed as being vulnerable to cross-site scripting (XSS). These attacks leave your users open to cookie theft, information theft, account hijacking, clickjacking and more.

Modern web browsers have some powerful protection build in nowadays but you need to tell the browser that you want those protection mechanisms used for your website. This can be archived by setting specific HTTP headers.


The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame> or <iframe>. This can be used to avoid clickjacking attacks, by ensuring that your content is not embedded into other sites.

This directive is pretty similar to the frame buster code explained in “Double Trouble on Google Images” except that it is only supported in the following browsers:

  • Internet Explorer 8+
  • Opera 10.50+
  • Safari 4+
  • Chrome
  • Firefox 3.6.9+ (or earlier with NoScript)

There are three possible values for this header:

  1. DENY – This setting prevents any pages served from being placed in a frame even if it is on the same website it originates from. should be used if you never intend for your pages to be used inside of a frame.
  2. SAMEORIGIN – This setting allows pages to be served in a frame of a page on the same website. If an external site attempts to load the page in a frame the request will be denied.
  3. ALLOW-FROM origin – If the value contains the token ALLOW-FROM origin, the browser will block rendering only if the origin of the top-level browsing context is different than the origin value supplied with the Allow-From directive.

The code below sets the directive to DENY, preventing our pages from being served in any frames, even from our own website.

# drop Range header when more than 5 ranges.
# CVE-2011-3192
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range
# optional logging.
#CustomLog insert-path-and-name-of-log common env=bad-range

# Don't allow any pages to be framed - Defends against CSRF
Header set X-Frame-Options DENY

# prevent mime based attacks
Header set X-Content-Type-Options "nosniff"

# Only allow JavaScript from the same domain to be run.
# Don't allow inline JavaScript to run.
Header set X-Content-Security-Policy "allow 'self';"

# Turn on IE8-IE9 XSS prevention tools
Header set X-XSS-Protection "1; mode=block"

MySQL Injection Prevention:

MySQL injection attempts are one of the most common hacking attacks against PHP websites. If your website is hosted on a dedicated or virtual server, the best solution is to your server hardened with proper mod_security rules. However, if you’re on shared hosting, this is not an option. If you now think that it’s not possible to protect your website against various hacking methods on shared hosting, you’re wrong. Although it’s not possible to use advanced strategies to protect your website, you’re still able to protect it against hacking attempts using .htaccess rules. To implement such a protection, append your current .htaccess file with the following code, or create a new file called .htaccess, if you don’t use any yet, and place it in your website’s main folder):

<IfModule mod_rewrite.c>
# Enable rewrite engine
RewriteEngine On

# Block suspicious request methods
RewriteRule ^(.*)$ - [F,L]

# Block WP timthumb hack
RewriteCond %{REQUEST_URI} (timthumb\.php|phpthumb\.php|thumb\.php|thumbs\.php) [NC]
RewriteRule . - [S=1]

# Block suspicious user agents and requests
RewriteCond %{HTTP_USER_AGENT} (libwww-perl|wget|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
RewriteCond %{THE_REQUEST} \?\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} \/\*\ HTTP/ [NC,OR]
RewriteCond %{THE_REQUEST} etc/passwd [NC,OR]
RewriteCond %{THE_REQUEST} cgi-bin [NC,OR]
RewriteCond %{THE_REQUEST} (%0A|%0D) [NC,OR]

# Block MySQL injections, RFI, base64, etc.
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http:// [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=http%3A%2F%2F [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=(\.\.//?)+ [OR]
RewriteCond %{QUERY_STRING} [a-zA-Z0-9_]=/([a-z0-9_.]//?)+ [NC,OR]
RewriteCond %{QUERY_STRING} \=PHP[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12} [NC,OR]
RewriteCond %{QUERY_STRING} (\.\./|\.\.) [OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} \=\|w\| [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)/self/(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} ^(.*)cPath=http://(.*)$ [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*iframe.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} (<|%3C)([^i]*i)+frame.*(>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} base64_(en|de)code[^(]*\([^)]*\) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>).* [NC,OR]
RewriteCond %{QUERY_STRING} (\./|\../|\.../)+(motd|etc|bin) [NC,OR]
RewriteCond %{QUERY_STRING} (localhost|loopback|127\.0\.0\.1) [NC,OR]
RewriteCond %{QUERY_STRING} (<|>|'|%0A|%0D|%27|%3C|%3E|%00) [NC,OR]
RewriteCond %{QUERY_STRING} concat[^\(]*\( [NC,OR]
RewriteCond %{QUERY_STRING} union([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} union([^a]*a)+ll([^s]*s)+elect [NC,OR]
RewriteCond %{QUERY_STRING} (;|<|>|'|"|\)|%0A|%0D|%22|%27|%3C|%3E|%00).*(/\*|union|select|insert|drop|delete|update|cast|create|char|convert|alter|declare|order|script|set|md5|benchmark|encode) [NC,OR]

# PHP-CGI Vulnerability
RewriteCond %{QUERY_STRING} ^(%2d|\-)[^=]+$ [NC,OR]

#proc/self/environ? no way!
RewriteCond %{QUERY_STRING} proc\/self\/environ [NC,OR]

RewriteCond %{QUERY_STRING} (sp_executesql) [NC]
RewriteRule ^(.*)$ - [F,L]



Using the script provided below you will be able to make automatic backup of your hosting account (domains and MySQL databases). This backup script includes SSL support. This is not necessary if you run the script on the server for which you are generating the backup; but the SSL support could be important if you are running the script somewhere else to connect to your cPanel hosting account.


// PHP script to allow periodic cPanel backups automatically, optionally to a remote FTP server. 
// This script contains passwords. It is important to keep access to this file secure (we would
// ask you to place it in your home directory, not public_html).  You need to create a 'backups'
// folder in your home directory ( or any other folder that you would like to store your backups in ).

// Information required for cPanel access 

$cpuser = "username"; // Username used to login to cPanel 
$cppass = 'password'; // Password used to login to cPanel.
// You could face some issues with the "$#&/" chars in the password, so if this script does not work,
// try to change the password.
$domain = "";// Your main domain name 
// Set to cPanel skin you use (script will not work if it does not match). Most people
//run the default "x" theme or "x3" theme
$skin = "x"; 

// Information required for FTP host 
$ftpuser = "ftpusername"; // Username for FTP account 
$ftppass = 'ftppassword'; // Password for FTP account
$ftphost = "ip_address"; // IP address of your hosting account 
$ftpmode = "passiveftp"; // FTP mode 

// Notification information $notifyemail = ""; // Email address to send results 
// Secure or non-secure mode $secure = 0; // Set to 1 for SSL (requires SSL support), otherwise will use standard HTTP 
// Set to 1 to have web page result appear in your cron log $debug = 0;
$ftpport = "21"; 
$ftpdir = "/backups/"; // Directory where backups stored (make it in your /home/ directory). Or you can change 'backups' to the name of any other folder created for the backups; 

if ($secure) { 
  $url = "ssl://".$domain; 
  $port = 2083; 
} else { 
  $url = $domain; 
  $port = 2082; 

$socket = fsockopen($url,$port);

if (!$socket) { echo "Failed to open socket connection... Bailing out!n"; exit; } 

// Encode authentication string 
$authstr = $cpuser.":".$cppass; 
$pass = base64_encode($authstr); 
$params = "dest=$ftpmode&email=$notifyemail&server=$ftphost&user=$ftpuser&pass=$ftppass&port=$ftpport&rdir=$ftpdir&submit=Generate Backup"; 

// Make POST to cPanel 
fputs($socket,"POST /frontend/".$skin."/backup/dofullbackup.html?".$params." HTTP/1.0\r\n"); 
fputs($socket,"Host: $domain\r\n"); 
fputs($socket,"Authorization: Basic $pass\r\n"); 
fputs($socket,"Connection: Close\r\n"); 

// Grab response even if we do not do anything with it. 
while (!feof($socket)) { 
$response = fgets($socket,4096); if ($debug) echo $response; 



To schedule the script to run regularly, save it as fullbackup.php in your home directory and enter a new cron job** like the following:

00 2 * * 1 /usr/local/bin/php /home/youraccount/fullbackup.php

(This will now run every Sunday night at 2:00 a.m.)

That’s it!

Coloured ls output in 10 steps

Always dreamt of having the same sort of output on your Solaris machine as you would have on Linux? Here is how you go at that.

  1. Coloured output is a feature of the GNU version of ls. So you first have to obtain this version. GNU ls is in the coreutils package. You can download it from (a mirror) of OpenCSW.
  2. Install the package using the pkgutil command:
    root@host /var/tmp> /opt/csw/bin/pkgutil -y -i coreutils
    Solving needed dependencies ...
    Solving dependency order ...
    Installation of <CSWlibgcc-s1> was successful.
  3. This will install GNU ls and some other useful GNU programs in /opt/csw/bin and /opt/csw/gnu. Check this directory.  Make sure that your PATH is set to include this directory FIRST: PATH=/opt/csw/bin:/opt/csw/gnu:${PATH}
  4. Information about the commands can be found in /usr/local/doc and /usr/local/man. Read the documentation for the new commands, e.g. for dircolors:
    user@host ~> info coreutils 'dircolors invocation'

    Lateron, make sure that the MANPATH variable includes /optcsw/share/man:${MANPATH}.

  5. Colours can also be set system wide, in that case you need a DIR_COLORS file in /etc. It may look somewhat like this:
    user@host ~> cat /etc/DIR_COLORS
    # Configuration file for the color ls utility
    # This file goes in the /etc directory, and must be world readable.
    # You can copy this file to .dir_colors in your $HOME directory to override
    # the system defaults.
    # COLOR needs one of these arguments: 'tty' colorizes output to ttys, but not
    # pipes. 'all' adds color characters to all output. 'none' shuts colorization
    # off.
    COLOR tty
    # Extra command line options for ls go here.
    # Basically these ones are:
    #  -F = show '/' for dirs, '*' for executables, etc.
    #  -T 0 = don't trust tab spacing when formatting ls output.
    OPTIONS -F -T 0
    # Below, there should be one TERM entry for each termtype that is colorizable
    TERM linux
    TERM console
    TERM con132x25
    TERM con132x30
    TERM con132x43
    TERM con132x60
    TERM con80x25
    TERM con80x28
    TERM con80x30
    TERM con80x43
    TERM con80x50
    TERM con80x60
    TERM cons25
    TERM xterm
    TERM rxvt
    TERM xterm-color
    TERM color-xterm
    TERM vt100
    TERM dtterm
    TERM color_xterm
    # EIGHTBIT, followed by '1' for on, '0' for off. (8-bit output)
    # Below are the color init strings for the basic file types. A color init
    # string consists of one or more of the following numeric codes:
    # Attribute codes: 
    # 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
    # Text color codes:
    # 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
    # Background color codes:
    # 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
    NORMAL 00	# global default, although everything should be something.
    FILE 00 	# normal file
    DIR 01;34 	# directory
    LINK 01;36 	# symbolic link
    FIFO 40;33	# pipe
    SOCK 01;35	# socket
    BLK 40;33;01	# block device driver
    CHR 40;33;01 	# character device driver
    ORPHAN 01;05;37;41  # orphaned syminks
    MISSING 01;05;37;41 # ... and the files they point to
    # This is for files with execute permission:
    EXEC 01;32 
    # List any file extensions like '.gz' or '.tar' that you would like ls
    # to colorize below. Put the extension, a space, and the color init string.
    # (and any comments you want to add after a '#')
    .cmd 01;32 # executables (bright green)
    .exe 01;32
    .com 01;32
    .btm 01;32
    .bat 01;32
    .sh  01;32
    .csh 01;32
    .tar 01;31 # archives or compressed (bright red)
    .tgz 01;31
    .arj 01;31
    .taz 01;31
    .lzh 01;31
    .zip 01;31
    .z   01;31
    .Z   01;31
    .gz  01;31
    .bz2 01;31
    .bz  01;31
    .tz  01;31
    .rpm 01;31
    .cpio 01;31
    .jpg 01;35 # image formats
    .gif 01;35
    .bmp 01;35
    .xbm 01;35
    .xpm 01;35
    .png 01;35
    .tif 01;35
  6. Test that your new setup works, using the /opt/csw/gnu/ls –color command in a couple of directories.

    If your colours seem ok (look also at other than plain text files), proceed to the next step.

  7. Now we don’t want to type /opt/csw/gnu/ls –color all the time. You can solve the problem by altering your PATH variable:
    user@host ~> export PATH=/opt/csw/bin:/opt/csw/gnu:${PATH}
    user@host ~> export MANPATH=/optcsw/share/man:${MANPATH}

    This way, when you just type ls, the first occurance in your search path will be the ls from /usr/local/bin instead of the default one from /usr/bin.

  8. Now we already have the correct program when we call it, but we are lazier than that, because we don’t want to type the –color option all the time either. So you might want to alias the ls command:
    user@host ~> alias ls='ls --color'

    Mind that this does not work for the common shell, /sbin/sh. You need a more advanced shell for making aliases, such as bash or ksh.

  9. Of course, when you log out, all these settings are gone, so add these lines to your shell configuration file, e.g. ~/.bashrc:
    user@host ~> echo 'PATH=/opt/csw/bin:/opt/csw/gnu:${PATH}' >> ~/.bashrc
    user@host ~> echo "alias ls='ls --color'" >> ~/.bashrc
  10. In order to make these settings available for all users on the system, put these last two lines in /etc/profile (check first, if PATH is already defined, it is cleaner to arrange the existing definition.

The Idea

The goal of the Advanced Crypto Software Collection (ACSC) is to provide a set of cryptographic tools to system developers. This site will primarily be focused on providing software that implements “advanced” cryptographic primitives. By advanced we typically mean cryptography that uses more modern methods and can’t necessarily be built from the traditional tools of hashing, signing, and basic encryption.

The collection is intended to provide a diverse set of tools ranging from low-level number theoretic primitives such as a bilinear-map implementation, to API’s for new efficient cryptographic primitives like Broadcast Encryption and Forward Secure Signatures, to applications. The software was developed by several different contributors, who are credited along with the project descriptions. The software provided here is primarily intended for the use of researchers in building system prototypes. Currently, most software has not been reviewed thoroughly enough for commercial deployment.

The Projects

Listed below are the current projects along with short descriptions. Click on a project’s name to access a longer description and software. Eight projects are currently available. Some are still under development, while others are fairly stable.

Some of these projects are hosted locally at the ACSC website. Other projects (notably the PBC Library) predate the ACSC and have their own homepage elsewhere; these are marked “external”.

  • Ciphertext-Policy Attribute-Based Encryption
    Developers: John Bethencourt, Amit Sahai (advisory role), Brent Waters (advisory role)
    License: GPL
    Added to ACSC: December 1, 2006
    Last updated: March 24, 2011
    This project provides an implementation of a Ciphertext Policy Attribute-Based Encryption (CP-ABE) system due to Bethencourt, Sahai and Waters. In such a system each user’s private key is associated with a set of attributes representing their capabilities, and a ciphertext is encrypted such that only users whose attributes satisfy a certain policy can decrypt. For example, we can encrypt a ciphertext such that in a company it can only be decrypted by a someone with attributes “Senior” and “Human Resources” or has the attribute “Executive ”. One interesting application of this tool is that we can do Role-Based Access Control (RBAC) without requiring trusted data storage.
  • Paillier Library
    Developer: John Bethencourt
    License: GPL
    Added to ACSC: July 21, 2006
    Last updated: January 30, 2010
    Paillier is a public key cryptosystem which offers an additive homomorphism, making it very useful for privacy preserving applications. This is a simple C library based on GMP which implements Paillier key generation, encryption, decryption, and also makes it easy to use the homomorphism.
  • Private Stream Searching Toolkit
    Developers: John BethencourtBrent Waters (advisory role)
    License: GPL
    Added to ACSC: July 21, 2006
    Last updated: September 28, 2009
    This toolkit provides programs implementing a private stream searching scheme due to Bethencourt, Song, and Waters that built upon work of Ostrovsky and Skeith. Suppose a client sends some search keywords to a server. The server checks some documents against the keywords and eventually sends back all the documents that matched. But the catch is that the client wants all this to take place without the server being able to learn what keywords they are interested in or which documents they end up with. These programs let you do that.
  • Forward-Secure Signatures with Untrusted Update
    Developers: Emily Shen (primary), John Bethencourt (build system)
    License: GPL
    Added to ACSC: September 13, 2007
    Last updated: October 22, 2007
    This C library implements a forward-secure signature scheme that allows “untrusted updates”. In most forward-secure signature constructions, a program that periodically updates a user’s private signing key must have full access to the private key. However, this prevents the common practice of encrypting it on disk under a passphrase. A scheme supporting untrusted updates, however, allows updates to the private key while it is encrypted.
  • Proxy Re-cryptography Library [external]
    Developers: Giuseppe AtenieseKevin FuMatthew GreenSusan Hohenberger
    License: only non-commercial use permitted
    Added to ACSC: March 28th, 2007
    Proxy re-encryption is a form of public-key encryption that allows a user Alice to “delegate” her decryption rights to another user Bob. In a proxy re-encryption scheme, Alice delegates a semi-trusted proxy to translate ciphertexts encrypted under her key into ciphertexts encrypted under Bob’s key. Once delegated, the proxy operates independently of Alice. The proxy is considered “semi-trusted” because it does not see the content of the messages being translated, nor can it re-encrypt Alice’s messages to users for whom Alice has not granted decryption rights. This project is a C++ implementation of the proxy re-encryption schemes proposed in NDSS 2005, using the MIRACL library. A future version of the library will incorporate “proxy re-signature” schemes from CCS 2005.
  • Percy++ [external]
    Developer: Ian Goldberg
    License: GPL
    Added to ACSC: March 6th, 2007
    Percy++ is an implementation of Private Information Retrieval (PIR) protocols in C++, as described in the paper Improving the Robustness of Private Information Retrieval, Ian Goldberg, IEEE Symposium on Security and Privacy (Oakland), 2007. Briefly, private information retrieval is the task of fetching a block of data from a database server (or group of distributed servers) without the server(s) learning which block it was that you were interested in. The protocols implemented in this project provide information-theoretic, computational, and hybrid privacy protection against configurable numbers of honest, faulty, or malicious servers.
  • Broadcast Encryption [external]
    Developers: Matt Steiner (original), Ben Lynn (current)
    License: GPL
    Added to ACSC: July 28, 2006
    A broadcast encryption scheme allows a broadcaster to send an encrypted message to a set of receivers S, each of which has a different private key. Given any subset S’ of S, the broadcaster may construct an encrypted message so that only the receivers in S’ may decrypt it. This may be trivially accomplished by having a key pair for every member of S. Then a copy of the message may be separately encrypted under the key of each receiver in S’. This of course results in very inefficient communication, however. The challenge is to construct a scheme which has communication sublinear in the number of receivers. This project is an implementation of the BGW broadcast encryption scheme (see also this more recent paper) based on the PBC Library.
  • Pairing-Based Cryptography Library [external]
    Developer: Ben Lynn
    License: GPL
    Added to ACSC: July 21, 2006
    Pairing-based cryptography (PBC) is a relatively young area of cryptography that revolves around a certain function with special properties. The PBC library (Pairing-Based Cryptography library) is a high performance C library built on top of theGMP library that contains routines which aid the implementation of pairing-based cryptosystems, including curve generation and pairing computation. In addition to the detailed documentation, simple implementations of many sample cryptosystems are included as examples of using PBC. PBC makes it very easy to quickly implement a great many of the recent advances in cryptography.
  • PIRATTE: Proxy-based Immediate Revocation of ATTribute-based Encryption
    Developers: Sonia JahidNikita Borisov (advisory role)
    License: GPL
    Added to ACSC: August 24, 2012
    Last updated: August 24, 2012
    This toolkit provides an implementation of Proxy-based Immediate Revocation of ATTribute-based Encryption (PIRATTE) system by Sonia Jahid and Nikita Borisov. PIRATTE is a revocation scheme for Ciphertext Policy Attribute-Based Encryption (CP-ABE) system due to Bethencourt, Sahai, and Waters. Revocation in CP-ABE is challenging since most existing approaches are based on key expiration, re-keying every user, and/or re-encrypting existing ciphertext. A key and novel feature of PIRATTE architecture is that it is possible to remove access from a user without issuing new keys to other users or re-encrypting existing ciphertexts. We achieve this by introducing a proxy that participates in the decryption process and enforces revocation constraints. The proxy is minimally trusted and cannot decrypt ciphertexts or provide access to previously revoked users.
  • Damgârd-Jurik Cryptosystem
    Developers: Frederick Douglas
    License: GPL
    Added to ACSC: September 12, 2012
    Last updated: September 12, 2012
    The Damgârd-Jurik cryptosystem is an extension of the Paillier public key cryptosystem (and libdj is an extension of libpaillier). DJ has additive homomorphism, and the ability to control the plain/ciphertext spaces that a given public key is currently encrypting from/to. Specifically, for a public key n, the plain/ciphertext spaces can be Zns, Zns+1 for any s. This lets a single key encrypt arbitrarily large messages – in particular, nested encryptions with only linear growth of the ciphertext are possible. This property, together with the homomorphism, enables e.g. an efficient private information retrieval scheme. libdj also includes a threshold version: rather than a single private key, many key shares capable of producing decryption shares exist, and some threshold of decryption shares must be gathered to decrypt. This version also has the homomorphism and size control.
  • Charm – A Rapid Prototyping Library for Cryptography
    Developers: Joseph Ayo Akinyele, Christina Garman, Ian Miers, Matthew W. Pagano, Michael Rushanan, Matthew Green, andAvi Rubin
    License: LGPL
    Added to ACSC: April 3, 2014
    Last updated: March, 2014
    Charm is a framework for rapidly prototyping advanced cryptosystems. Based on the Python language, it was designed from the ground up to minimize development time and code complexity while promoting the reuse of components. Charm uses a hybrid design: performance intensive mathematical operations are implemented in native C modules, while cryptosystems themselves are written in a readable, high-level language. Charm additionally provides a number of new components to facilitate the rapid development of new schemes and protocols. Charm ships with a library of implemented cryptosystems. This library includes public key encryption schemes, identity-based encryption schemes, attribute-based encryption schemes, digital signatures, privacy-preserving signatures, commitment schemes, zero-knowledge proofs, and interactive protocols such as anonymous credential and oblivious transfer schemes.
  • AutoTools – Automation Tools for Cryptographic Design
    Developers: Joseph Ayo AkinyeleMatthew W. PaganoMatthew Green, and Susan Hohenberger
    License: LGPL
    Added to ACSC: April 3, 2014
    Last updated: March, 2014
    The AutoTools project is a collection of automated compilers for performing various cryptographic design tasks. These consist of tools that improve efficiency and security of cryptographic primitives. For example, AutoBatch is an automated tool for finding efficient batch verification algorithms from high-level descriptions of digital signature schemes. AutoGroup is an automated tool for optimizing several types of pairing-based public-key encryption and signature schemes using Satisfiability Modulo Theories (SMT) solvers. Moreover, AutoStrong is a tool for converting existentially unforgeable signatures into ones that are strongly unforgeable. The tools demonstrate the notion that it is possible to transition some of the design work to computers and in most cases the automation can be performed in a matter of seconds.