## T-MPC

Some of my PhD research was recently published in IEEE Information Forensics and Security journal. It is on a paradigm shift I came up with relating to multiparty computation, which I call transferable multiparty computation. The idea is to allow the set of parties involved in the computation to change over time without leaking intermediate results. Check it out here.

## Good Passwords

I was thinking about good passwords today. There has been a lot of talk about good passwords in the past few years. This is especially true given some problems we’ve seen with service providers not following best practices (*cough* Adobe *cough*). XKCD gave it’s thoughts, which Schneier says isn’t so great any more.

So, it made me wonder, is there a super simple way to gauge the security of your password? The thought I came up with is: if you write it down and show it to someone for 1 second, is your password still secure? If not, your method for generating passwords is too simple. If so, you **may** have something.

That said, password managers are still a good way to go. Given the fact that you can even get them on your phone with an encrypted database, there is no reason to not be using one.

## Guide to HElib (#3)

To demonstrate HElib and to be able to better play with some of the settings, I’ve written a simple application which implements a RPN calculator. You can grab a copy of it on the thep downloads page. You’ll have to modify *Makefile* to point the HElib variable to the proper directory. Compile by typing *make *and run it by typing *./HEcalc*. You’ll then be able to do things like:

3

4

*

q

at which point it should return *12*.

This is a very preliminary version of HEcalc. I haven’t done anything with ciphertext packing, etc. The purpose of this code is to demonstrate how to add, subtract, and multiply encrypted numbers (along with how to encrypt, decrypt, etc). Play with it some. You’ll notice that by changing the value of *L* you’ll be able to do more multiplications without the error becoming too great to properly decrypt. You can do as many additions as you want (basically) as the error grows very slowly with additions. Another thing you’ll see when playing with this is that when you decrypt a value, you actually get a number of copies of that value. This is due to ciphertext packing (i.e., storing many values in the same ciphertext). This allows you to do SIMD operations. I hope to detail ciphertext packing and SIMD in the next post. Until then, feel free to use the comments to ask questions about HEcalc and I’ll answer as best as I can.

## Guide to HElib (#2)

### Setting up the Context

HElib requires that you setup a context using the *FHEcontext *class to get things going. This stores all the parameters, etc needed for other tasks you will want to perform (key generation, encryption, decryption, homomorphic operations). I’ve been doing this in my code as follows:

#include long p=101; long r=1; long L=4; long c=2; long k=80; long s=0; long d=0; long w=64; long m = FindM(k, L, c, p, d, s, 0); FHEcontext context(m,p,r);

I explained the parameters in my last post so I won’t go into much detail. The *FindM* function is something new. I’m not going to go into the details of it (as I’m still trying to understand it all), but basically it will find a valid value for m given the specified values. In addition to setting up the context, we also need to build the modulus chain (this is what recent versions of BGV use to avoid bootstrapping). We also need a value *G *which is the monic polynomial used in constructing the ring BGV works in:

buildModChain(context, L, c); G = context.alMod.getFactorsOverZZ()[0];

### Key Generation

Once you have all this setup, generating public and private keys in HElib is pretty easy:

FHESecKey secretKey(context); const FHEPubKey& publicKey = secretKey; secretKey.GenSecKey(w);

The value *w* is the hamming weight to use in key generation (see appendix B of GHS12 for an explanation).

### Encryption and Decryption

Now that we have the key pair established, we can encrypt and decrypt. HElib uses the *EncryptedArray* class for data movement, so make sure you *#include <EncryptedArray.h>*. Then create an encrypted array as:

EncryptedArray ea(context, G);

We then use a PlaintextArray to represent a plaintext. The documentation shows all the various ways this can be done. I’m going to show a simple (yet inefficient) way to encrypt a single value:

Ctxt c(publicKey); PlaintextArray p(ea); p.encode(5); ea.encrypt(c, publicKey, p);

This will encrypt the number 5 and store it in *c*. Decryption is very simple too:

PlaintextArray p_decrypted(ea); ea.decrypt(c, secretKey, p_decrypted);

### SIMD

The reason for using a PlaintextArray is that BGV supports what is being called SIMD (single-instruction, multiple-data) operations. To understand this, consider a simple example. Say we have 20 pairs of numbers (a1,b1) to (a20, b20) and we want to multiply each pair together to get c1…c20. Clearly this can be done by computing (a1*b1), (a2*b2), and so on. BGV, however, will allow us to store all a1…a20 in a single ciphertext (say **a**) and all b1…b20 in a single ciphertext (say **b**). Then we only need to compute **c**=**a*****b**. When we decrypt **c** we can access c1…c20. Thus a single multiplication can actually multiply many values at once.

### Homomorphic Operations

The ciphertext values are stored in instances of *Ctxt*. Take a look at that class’s documentation to see the supported operations. The most basic are overloads of *operator+=*, *operator-=*, and *operator*=*. Using those you can operate on the ciphertexts to compute functions. You should be able to do as many additions and subtractions as you want. If, however, you do too many multiplications on the same ciphertext value, the ciphertext becomes too noisy to decrypt. More on that in the next post.

## Analysis of XKCD’s Hash Competition

There was a question over on Crypto.SE on “almost” collisions as related to XKCD’s hash breaking competition. I had a few minutes to write-up some analysis. Pretty cool question that I too had wondered about but never worked out the math.

## Guide to HElib (#1)

Shai Halevi has released an implementation of the BGV cryptosystem over on github. I know a lot of people (myself include) have been wanting to play with FHE to get a better understanding of it. A while back I started a sage implementation of BGV (which I have never released). That helped a lot in understanding BGV. If anyone is interested in the very beta version of my sage code, let me know.

Given that HElib has now been released, I wanted to start playing with it and release my notes. So, here goes. In post #1 I will go over installation and playing with some of the test programs that come with HElib.

**Install (Compilation)**

Installation/compilation of HElib is quite easy if you get things right. First of all you will need NTL (number theory library). I tried using the default version of NTL for my version of Ubuntu, but HElib wouldn’t compile. So, get the newest version 6.0.0. Compile and install (*./configure; make; make check; make install*).

Then head over to github and clone the git repository (*git clone https://github.com/shaih/HElib.git*). Compilation of HElib is pretty easy (*cd HElib/src; make*). This will build a library against which you can statically compile your own code which can use HElib. There are, however, also some test programs you might be interested in (named *Test_**). To compile these do (*make test*).

### Test_General

Within *Test_General.cpp* we can learn a lot about HElib and how to use it in code. First off is the *main* function. There are a lot of parameters. Running *(./Test_General_x –help*) explains what these parameters are (to some degree). I’ll go in more detail on some of them here. The parameters are:

R is the number of rounds

p is the plaintext base [default=2]

r is the lifting [default=1]

d is the degree of the field extension [default==1]

(d == 0 => factors[0] defined the extension)

c is number of columns in the key-switching matrices [default=2]

k is the security parameter [default=80]

L is the # of primes in the modulus chain [default=4*R]

s is the minimum number of slots [default=4]

m is a specific modulus

*R* is the number of rounds of testing (basically a parameter to a for loop around the testing). *p* is the plaintext base. Basically this is the plaintext space. Setting *p=2* basically says that plaintexts are in {0,1}. *p* should be a prime number. *d* as it says is the degree of the field extension. GHS12 explains (section 2.3) what this is:

We note that the values in the plaintext slots are not just bits, rather they are polynomials modulo the irreducible F_j’s, so they can be used to represents elements in extension ﬁelds GF(2^d).

*k* as said, is the security parameter. A default of 80 is 80 bits of security. The length of the modulus chain, *L*, allowes for “leveled” FHE. *L* reduces or eliminates the amount of bootstrapping (see BGV11). Finally, *s* tells how many (at a minimum) number of plaintext slots you’d like. Set this too high and it will complain.

The basic parameters given in the file are pretty good for testing. Take a look at the GHS12 paper for more on parameter tuning. In that paper they look specifically at tuning BGV for AES.

## CipherCloud DMCA

Something interesting is happening over at Crypto.SE. Someone a while back posted a question about CipherCloud (cached here). Turns out that CipherCloud wasn’t too happy about the analysis and sent a DMCA to StackExchange. The question has been deleted.

This raises a bunch of questions about CipherCloud. The analysis on Crypto.SE looked pretty scary. Especially given that the company has raised $30 Million. I looked over their leadership team, their board of directors, job postings, etc and don’t see a single cryptographer listed. That raises another set of warning flags.

**The Analysis
**I don’t want to repost the analysis here, but the basic idea was that it seemed to be using a constant mapping from plaintext to ciphertext. Thus the word ‘the’ always mapped to ‘qmf’. Thus, patterns in the ciphertext are recognizable and the security of the system is minimal. This analysis was all done on screenshots/videos of the product. It could be that it was just marketing material and does not reflect the actual security of the product. It is hard to tell though as they do not publish the details of their work. They offer a white paper if you give them your personal information (which I may do and post my own analysis here).

**Why the big deal?**

Why is this such a big deal? Well, cryptography research (and thus practical cryptography) is very hard to do. I’d venture to say that the practical stuff is even harder than the theoretical stuff. If you don’t publish loads of information on your cryptographic protocols, etc, how can anyone know it is secure? There isn’t really a certification group for cryptographic protocols. If you are afraid of losing your IP, you could hire reputable cryptographers to review your product. It doesn’t appear CipherCloud has done any of this. This is why it is a big deal. The security of the system could be imaginary at best. Bruce Schneier once said something to the effect of “anyone can design a cipher that they themselves cannot break”. Same goes with protocols, security systems, etc.

**Recommendations
**To potential users of CipherCloud, I’d recommend you contact them and tell them you want open evaluations of their products or you won’t be using it. Also tell them sending DMCA notices to StackExchange is very counter-productive. Instead a well reasoned response on Crypto.SE would have been better. Defend your product, don’t try to censor those who are curious about the security.