Archive

Posts Tagged ‘Cryptography’

CipherCloud DMCA

April 20, 2013 1 comment

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.

Cost of Brute-force

November 9, 2011 Leave a comment

Over at crypto.se┬ásomeone asked a question about the cost in dollars of brute-forcing a 256 bit key. In my answer, I estimated it to be about 8 octodecillion dollar ($8 * 10^57). And that is for the electricity only! Some of the answers were pretty interesting and I learned a few things. For example, I never knew exactly how a quantum computer would affect symmetric-key cryptography. It turns out that it would halve the key space, which is optimal (i.e., you cannot do better). If one could do better with a quantum computer, then that would prove that the key could be brute forced in less than 2^n time. I won’t pretend to understand exactly why that is, but it is a pretty interesting result that I had wondered about for some time.

Categories: Cryptography Tags: , ,

PHP crypt() bug

August 22, 2011 Leave a comment

A serious (and kind of funny) bug was reported in PHP crypt() today. Under certain circumstances, crypt() with an MD5 salt would only return the salt (no hash of the password). The bug was introduced on 7 Aug by rasmus.

Take a look at the diff:

That’s right, only one line was changed. Can you spot the problem (vulnerable code on the left)?

Take a look at the man page for strlcat, specifically, what is the third parameter? “Unlike those functions [strncpy and strncat], strlcpy() and strlcat() take the full size of the buffer (not just the length) and guarantee to NUL-terminate the result (as long as size is larger than 0 or, in the case of strlcat(), as long as there is at least one byte free in dst).” So, line 380 in the incorrect code is saying that passwd is only one byte in length.This messes everything up which leads to:

Description:
------------
If crypt() is executed with MD5 salts, the return value conists of the salt only.
DES and BLOWFISH salts work as expected.

I tested with php from openSUSE PHP5 repository

> php -v
PHP 5.3.7RC6-dev (cli)
> rpm -q php5
php5-5.3.6.201108112132-94.1.x86_64

Test script:
---------------
printf("MD5: %s\n", crypt('password', '$1$U7AjYB.O$'));

Expected result:
----------------
MD5: $1$U7AjYB.O$L1N7ux7twaMIMw0En8UUR1

Actual result:
--------------
MD5: $1$U7AjYB.O

 

So, what is the takeaway? If you look at the commit logs in svn, the bug actually started before the commit shown in the diff above. The author of that change changed a strcat to a strncat in order to “Make static analyzers happy”. The very next commit changed the strncat to strlcat with the comment “…let’s use strlcpy/strlcat instead for these static string copies”. NOTE: same author for both of those commits. So, it was a combination of trying to make a static analyzer happy and not understanding the difference between two function calls. The real kicker though is the most recent commit that fixes the bugs. It has the following commit message “If you want to remove static analyzer messages, be my guest, but please run unit tests after”. It turns out that the PHP unit tests would have found this bug, but someone didn’t run them before committing a fix to the repository. An interesting lesson in software development.

Introducing: thep

March 5, 2010 1 comment

For the last few weeks I’ve been reading a lot about homomorphic encryption. I found it very interesting and decided to implement some of the algorithms I’d read about. Which brings me to thep.

The Homomorphic Encryption Project (thep) is a library of homomorphic encryption algorithms, methods, protocols, etc. At least, that is what it will be. For the time being, I’ve implemented the Paillier cryptosystem, it’s homomorphic methods, and key generation functions. In the future I’ll be implementing some of the cool protocols I’ve been reading about, more algorithms, and porting the library to other languages (currently I’ve written it in Java).

Check it out and let me know what you think.