RabbitHole : AES-256 archiver with multiple hidden volumes for plausible deniability

Greetings good people of Wilders Security. We're a team out of Norway that have created a free, open source (GPL v3) Windows application for creating AES-256 encrypted file archives with plausible deniablity. We believe privacy software should be free and available for all, and for such software to have any value at all it should be open source and open to code reviews and audits. We just released our app and source code on GitHub yesterday.

Our home on GitHub: https://github.com/Commitant/RabbitHole

We've only just signed up for this forum, but we know its reputation for having a large community of knowledgeable members on topics like privacy technology, practices and techniques, as well as encryption. We therefore welcome your opinions, comments and critique in order to continue developing our software and providing the best possible tool for keeping private stuff private, and to do so with plausible deniability.

Ofcourse, we dont't roll our own crypto, we've built our software around the trusted Bouncy Castle library from the Leagion of the Bouncy Castle. Also our code base is very small (around 500 lines of code), and so we invite you to review the code and make your own judgements. When it comes to privacy, we should all be mindful and selective of who we trust.

Our software is inspired by applications like TrueCrypt, VeraCrypt and similar software, and we believe our software has a combination of properties which make it interesting. Here's a quick overview:

• Encrypted file archive
• AES 256 (Rijndael block cipher)
• Bouncy Castle, trusted crypto
• Any number of hidden volumes
• Encrypted volumes indistinguishable from random data
• Plausible deniability
• Very small code base, easily inspected and audited
• Open source, free software (GNU GPL v3)

Stay safe, stay secure.

 

Change that encryption to AES 128 and it would be even better.
(The larger 256 bit key is not as well diffused by the standard rinjdael algorithm as is the smaller 128 bit key. This makes cracking AES 256 sometime in the near future, somewhat plausible while cracking AES 128 is considered impossible for the foreseeable future)

Having said all that, I would use serpent and be done with it. No one is cracking serpent. Not in this life.
The only reason serpent was not chosen over rijndael is on 1970's hardware, the far more secure serpent algorithm was noticeably slower. On today's hardware the difference is in milliseconds and is therefore irrelevant.

 

Now this I want to see a source for.

 

https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

 

Thanks for your input guys, it's obviously a very bold claim being made here, but on the other side Bruce Schneier isn't just anybody either. As Schneier points out, this is a "related key" attack, it requires access to plaintext data, and it only breaks 11 out of 14 rounds. While a practical attack is unlikely in the foreseeable future, we should take this seriously, and we will provide crypto algorithm options in RabbitHole quite soon.

I agree Serpent is a likely candidate for inclusion. It's allready supported by Bouncy Castle, so implementing it in our software doesn't require much. If you have other suggestions for crypto algorithms you would like to see implemented, please comment here. We should probably create a poll for this to gauge interest.

/Commitant

 

** New patched release v.0.1.2 available at https://github.com/Commitant/RabbitHole/releases
A bug in the routine checking for user folder write access was fixed, we want to apologize to any users who encountered this bug.

 

I am a LUKS user and I employ Serpent on all my volumes as a personal practice. Realizing that I forgo hardware acceleration offered by AES on my hardware, it is a tradeoff that I will make without hesitation. My iteration counts are ballistic as well.

Wishlist: just in case you know any linux coders I think you could find other folks such as me that would gladly send bitcoins to buy a SOLID linux approach that offered hidden volumes. I know it can be done but its outside of my "wheel house" for now anyway.

 

Program is written in C#, which is similar language to Java, so it could be ported quite easily to Java.
However program contains only one class, so I don't know if it can be described as SOLID approach (pun intended)

 

I'm not sure where you have your information from, but the RabbitHole application consists of 6 relevant classes, and we do indeed follow OO best practices and design principles. You probably just looked in the top folder containing the UI class program.cs, our domain classes are located in the Domain folder. As our day jobs are as professional software developers we're concerned with software design methodologies, and while we indeed follow most of the SOLID principles, the GRASP design patterns governs our day to day development practices. Maintainability is the key aspect, even in a compact software project like this. Thus espescially High cohesion/Low coupling are paramount.

 

Thank you for contributing Palancar, your wish is duly noted. We have a lot av Java experience on our team, so if there's enough interest we'll make a Java-version as well. We're using Bouncy Castle for encryption/decryption and they have a high quality Java-library as well, making the job quite doable on our side.

 

@Commitant You could do an android java app too although I did read somewhere the android bouncy castle is not quite what it should be.
I appreciate you taking on board my comments and I agree serpent would be a nice option, I believe it is rated to be some 3x tougher than AES, which technically is a broken cipher, meaning an attack, faster than brute force has been published.
I was wondering, as developers would you mind taking a look at my thread about aes source code?
https://www.wilderssecurity.com/threads/question-for-devs-aes-source-code.397608/

 

We could do an Android app as well. While we havn't looked much into it yet, Spongy Castle seems to be a re-packaging of the original Bouncy castle library for Java, which avoids the class name conflicts that arise due to the built in iffy version. It should be manageable to do a diff between the Spongy Castle source code and the original source code and verify that no weaknesses are introduced.

 

I read in first post that source code is around 500 lines of code, so when I saw file with 500 lines of code I assumed this is all. My mistake.

 

No worries. Program.cs does indeed have around 500 lines, but that's with blank lines and everything. We use Visual Studio's code metrics calculation to perform the code line count, and as of now it reports 507 code lines.

However it should be noted that VS counts IL code lines, that's intermeditate language code lines. It won't give the exact same result as counting the source code lines manually.

 

Commitant,

Appreciate the acknowledgement. Where the linux code has me spinning is having the encrypted hidden volume be a linux system disk. Simple double archival volumes are doable where no system disk needs to be accommodated. So to clarify my wish list; it would be for a partition on a hard drive fully encrypted. Ideally it would be a LUKS header (I can create my own parameters, selecting algo, iteration count, etc..). Then if forced I show a well constructed shell volume with no pointers to the interior system, which would be linux nested within the encrypted partition. VeraCrypt and TC both have a fatal weakness (my opinion) in that they require a full decoy OS and not just a decoy outer volume on the hidden OS partition which by CODE had to be larger than the C drive - ridiculous and obvious. I edited TC boot code and removed my decoy OS completely, and then coded the hidden volume somewhere other than the second OBVIOUS position on the disk platter. Next I made ALL partitions outside of the C system disk smaller than the one I later created as my improved version of a better decoy. Now every partition is smaller than the C drive so NO hidden system disk could have been created by TC code. Wink! It takes awhile to build this geometry (step by step saving images along the way) and is a multi step process, but if you use sector based imaging like Macrium Pro restores are super simple if needed. As you might imagine the pointing during mount would be a problem on a generic MBR, but I accomplish it using Grub4dos and can point pre-boot without using anything canonical. That means I can produce a volume containing a hidden OS absolutely anywhere on the disk beyond the C drive. Hint: never use the next position because its a generic placement.

That same model with Debian or Arch would be the bomb! My opinion is that all the weaknesses stated above are not even close to those presented by using Windows. Therefore I have left my deployment of said code. I have no interest in that platform. I did it for hours and hours over many years at the original TC forums. I do applaud your fresh enthusiasm and the product you are trying to develop may help users on Windows. I cannot release any of this code as its not a singular effort on my part and others in a small group are still using it.

As you could imagine a similar model on a 1TB drive could easily produce half a dozen mission specific hidden and unique OS's where we preach compartmentalization around here. None of these would have any knowledge of the others. I did this with Windows, now to accomplish this with Linux. If only!!

 

I got 'is not a valid win32 application' with latest version after installation.

 

For me it is working. Windows 8.1 64-bit. .net [2.0,3.0,3.5,4.6.1] available.

 

Do you get this message when trying to start the application? Does the app run successfully after you have dismissed the message? Which OS version are you on? Thanks.

 

It's been tested on Windows 7, 8 and 10.

 

Thanks a lot for comments and input everybody, we've heard you, and we will be adding support for Serpent and Twofish shortly. The code changes are pretty much down, and once it's tested sufficiently we'll release it at GitHub.
Cheers.

 

Am I asking too much if I like to see some data compression algorithm also being implemented, such as LZMA2 and BZip2 etc?

 

That's easy to implement, and we will consider including it. However, it does make opening and saving archives slower, and it's yet another option for the user to consider. But if there's interest for it, we will include it.

 

Serpent and Twofish are now supported, and updated code is available on Github. The user is prompted for preferred crypto algorithm when a new archive is created. However we havn't made a new installer for it yet, but we will have it ready at the latest by Monday.

 

Many thanks for considering this option. I'm sure people will appreciate this option to have their archives compressed to save disk space.

I know you clearly said in the OP that RabbitHole is a Windows Application. Would you consider it at all to port it to Linux also? My main PC is running Ubuntu 16.04 so it would be great to have RH on Linux as well.

 

If there's enough interest, we'll consider porting it to Java, so that it can be run on Linux platforms. Maybe we should create a poll to gauge interest. Is there any way to post a poll on this forum? Or will I just have to link to an external poll-site?