File Format Magic String / Version mismatch between Docs and Source

hannibal218bc created an issue 2012-02-05

header  = "rvl\x00"              # magic string
header += "\x01"                # data version
header += "\x00"                # separator
header += "\x00\x04\x06"        # application version TODO
header += "\x00\x00\x00"        # separator

Comments (7)

1. hannibal218bc

   • marked as critical

   (changed bug summary)

   Upon further investigation, I discovered that the current code takes several shortcuts compared to the documented file format that result, in my opinion, in dramatically decreased security of the file's contents.

   To be specific,

   • only the first 32 characters of the passphrase are used (the rest is thrown away!)
   • the passphase is NOT iterated with SHA1 to derive the encryption key, but used directly as the key to the AES encryption. A dictionary attack on an already weak passphrase (e.g. using only ASCII chars) is even easier this way, as there are only 7 bits (or even less) to vary on each character. Also, the number of characters in the passphrase translates directly to AES key bits (or respectively, all-zero parts of the key for the remaining chars to length 32).

   With this differences from documentation to implementation, I'd not recommend using Revelation for sensitive information.

   • 2012-02-06T19:30:05+00:00
2. Mikel Olasagasti Uranga

   • changed status to open

   The FileFormatSpec is a Draft that currently has no implementation on code, so what rvl.py shows is correct.

   • 2012-02-06T20:00:16+00:00
3. hannibal218bc

   So both the draft and the current implemenation use a "data version" of 0x01, but are otherwise incompatible.

   In any case would I expect a hint that the current implementation's security is significantly weaker than what the proposal documents.

   Anyways, I'd say the current encryption process is flawed and should be ASAP changed to the proposed data format. Perhaps this should be a different issue; in my opinion, the current file format is everything else but a "single, secure place" -- without any key derivation function, there are just too few variable bits in the encryption key.

   • 2012-02-12T19:59:16+00:00
4. Mikel Olasagasti Uranga

   • assigned issue to Mikel Olasagasti Uranga

   I’ll try to work on this problem ASAP but I’m quite busy ATM.

   Jakob Westhoff made a new fileformat with salted multihashed keys on his fork which I’m testing and plan to merge soon. Would you have a look at it and share your opinion about it?

   https://bitbucket.org/jakobwesthoff/revelation

   • 2012-02-13T00:23:13+00:00
5. hannibal218bc

   Sorry I missed that while exploring Revelation. Yes, Jakob's approach seems cryptographically solid to me.

   The only thing I notice is that although the key-salt is a true 256 bit random from salt = os.urandom(32) , the AES-IV is a weaker one consisting only of ASCII bytes from iv = util.random_string(16) . Probably that should be changed to os.urandom(16) , but I guess it wouldn't do much harm if left as is.

   Thanks for your efforts!

   • 2012-02-13T14:46:27+00:00
6. Why hasn't this been fixed yet? This is a serious security problem.

   For example, recent generations of desktop Intel processors can decrypt a 64 byte buffer (enough to test a key) in under 384 cycles [1]. Running 12 threads concurrently on a high-end desktop PC (6 cores, hyper-threaded, 3.9Ghz) could probably average 70 cycles per key tested, so about 55 714 285 keys/second. Checking to ensure we got the expected output would take a bit more time, so let's say we can only test 25 000 000 keys/second (this is a very conservative estimate).

   Now, if we had to test the entire 256 bit key space at that speed, assuming that AES doesn't have any known cryptographic weaknesses (it does, but the effective key size is still considered good enough), it would take, on average, about 10^61 years.

   However, let's assume that the user has entered a simple, say, alphanumeric (a-z A-Z 0-9) password of 8 characters, and revelation has naively appended null bytes without any salt or key stretching. This will take on average a little more than 7 weeks.

   On customised hardware (FPGA) I wouldn't be surprised if this could be cut down to less than a day. Certainly, given the prospects of accessing someone's bank accounts / saleable confidential information (trade secrets/blackmail fodder), I expect a determined cracker would have no qualms about spending a few thousand dollars on high-end computer hardware.

   Even the 10 000 hash iterations done in Jakob Westhoff's fork is probably not enough given how quickly SHA256 can be parallelised in hardware. It would be much more effective to use a memory-intensive key derivation function (even just appending a large fixed string to the key in each hash iteration would greatly increase the security).

   [1] http://software.intel.com/file/27067

   • 2012-06-06T13:34:55+00:00
7. Mikel Olasagasti Uranga

   • changed status to resolved

   A new encryption system has been implemented using PBKDF2.

   The user will be informed that a the old system is non-secure and advice to save the file with the new format if it opens an old formated file.

   Will do a new release tomorrow after updating some translations.

   • 2012-06-24T14:00:58+00:00
8. Log in to comment »