Deniability has long time been seen as a principle outside of cryptographic studies, and seen more as a feature of steganography. However, deniable cryptography (or “deniable encryption”) has been accepted in mainstream discussions amongst crypto experts. The whole point of deniable encryption is to allow its users to convincingly deny that some specific encrypted data exists, that a given piece of data is encrypted, or that they are able to decrypt a given piece of encrypted data.
Having deniable encryption in place enables the suspect to legally challenge his adversary to demonstrate and prove that the “random blob of data found on his hard disk” is indeed an encrypted container ? If he cannot prove this, and neither can an appointed expert, then there are grounds to appeal and reject the question to “unlock the encrypted container” altogether. Although we still have to see the first legal case where deniability is put to the test, I’m sure it’s going to be an interesting debate.
The strength of deniable encryption begins with using a cryptographically secure pseudorandom number generator, as we’re dealing with pseudorandom permutations of existing block ciphers to make it cryptographically infeasible to prove that the ciphertext is not in fact random data. To top things off, deniability usually also involves decoy data that a user can divulge, so that the adversary is forced to believe this is all there is.
At Cryptocow we feel strongly about these features, as they also offer a plethora of security in democratic regimes against any adversary trying to invade your privacy. In various non-democratic regimes, this may result in rubber-hose cryptanalysis.
Using sensor fusion on smart-phones to improve deniability
Truecrypt is a good example, and was most likely the first widely adopted and free crypto software that used deniability as a selling point. Still today, Truecrypt is widely used and rightly so. At Cryptocow we love this product as well. For stored data, the robustness of deniable encryption is directly linked to the entropy level of random-data. Randomness is key, and is one of the first and foremost problems. Because computers are machines, it is impossible to get them to act in a truly random fashion.
Modern cryptosystems use a number of hardware metrics, such as hard drive seek time, thermal noise, and other physical processes to more closely approximate truly random data. On smart-phones, we can access the sensor values to add more randomness to the seeding. The best part is, sensors are present in most (if not all) modern smart-phones, and they are all readily accessible through native API calls, in non-rooted environments both on Microsoft, IOS and Android systems.
At Cryptocow, we predominantly use sensor fusion of the sensors present on the smart-phone for randomness seeding. Using a Lorenz system and attractor on sample values from the microphone, gyroscope, accelerometer and Wi-Fi signal strength you get very high entropy values (both using Shannon entropy and min-entropy calculations).
Eventually the random data is used to generate a master key,salt, iteration count, and general random blobs of data. Effort was also spent on making the generated data chi-squared cryptanalysis resistant, as this is often used to detect encrypted data in storage.
In order to test the randomness of generated data, we use the randomness tests at http://www.fourmilab.ch/random/:
- It should pass a chi-square distribution test by having an extremely low suspect score
- It should pass the arithmetic mean by being as close to 127.5 as possible
- It should pass the Monte Carlo Value for Pi by providing a score as close to the actual value of Pi as possible
- It should pass the Serial Correlation Coefficient by providing a score as close as possible to zero (0.5 means it’s non-random)
Making this all work, we’re going to release some Bouncy-castle patches for the org.bouncycastle.crypto.prng.RandomGenerator you can apply for making your crypto containers more deniability resistant, and pass these tests.
That’s a heads-up how we would recommend everyone to go about using randomness on smart-phones. And that’s the reason why we consider deniability to be an intrinsic part of cryptography, rather than being a stand-alone principle or part of steganography.