follow

#61 File Format Magic String / Version mismatch between Docs and Source

Reported by hannibal218bc 2012-02-05

According to http://oss.codepoet.no/revelation/wiki/FileFormatSpec, the magic string every Revelation file should start with, is 0x72766ce0427b ('rvl' + 0xe0427b).

According to the source at http://oss.codepoet.no/revelation/src/6e46fd4aa400/src/lib/datahandler/rvl.py , the header is:

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

As I'd like to be able to open Revelation files on my Android device, I'm investigating the creation of such an app and hence I'd need to know the actual file format definition. Thanks!

Attachments

Comments and changes

1. #1 hannibal218bc

   written 2012-02-06

   • Changed priority from minor to 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.
2. #2 Mikel Olasagasti Uranga

   written 2012-02-06

   • Changed status from new to open.

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

   written 2012-02-12

   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.
4. #4 Mikel Olasagasti Uranga

   written 2012-02-13

   • Changed responsible from nobody to mikel.olasagasti.

   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
5. #5 hannibal218bc

   written 2012-02-13

   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!

Verification: Please write the text from the image in the box (letters only)

Is that you, Humanoid? Is this me?

• Cancel