On Feb 22, 2015, at 5:09 , Jeffrey Walton <[email protected]> wrote: > //What is it used for?!, fast verification that decryption was > successful, > // as otherwise you get some random noise here > char magic[4]; /* "TRUE" in ASCII */ > > That is probably broken, and you should not use it. First, its too small at > 32-bits. Standards like SP800-38A require 64-bits and above (and recommends > 96-bits and above). Second, its easy to defeat. I can tamper with a file in > its second or third block so that the first block decrypts OK but the file is > junked.
As an authentication tag - 32 bits would be fine for low-value online traffic protection (e.g. video stream), and totally inadequate for any long-term security. > We've seen enough oracles for a lifteime. If you are going to provide > integrity assurances, then use a authentication tag designed for for the job. > See, for example, http://www.cryptopp.com/wiki/Authenticated_Encryption. Yes, IMHO AEAD is the most reasonable answer here. > Some interesting stuff should be dropping out of Bernstein's Crypto > Competition at http://competitions.cr.yp.to/. They are AEAD ciphers with both > public and secret values in the AAD slots. It should prove to be very helpful > here, where the header would be a public value treated as AAD and protected > like the cipher text (sans encryption). I would not bother with/wait for that competition results, and use AES/GCM instead. It has been accepted in several standards, and analyzed well enough. There is only one possibly better option today - AES/OCB, which comes with some legal use restrictions. > /* SHA-3-256 of everything before this, validate this*/ > char header_hash[32]; > > Same problem here (sans the small size of MAGIC). It can be tampered with all > day long and the system would be no wiser. :-) > Also, I'm not aware of how to turn SHA-3 into an HMAC. You don’t need HMAC with SHA-3. As was published some time ago, Envelope construct is provably secure, and performs better than HMAC. The only thing to watch for is that the key must be in its own block both prepended and appended. (See Preneel, sorry don’t have a reference at hand). > Apparently its not as easy as one would think because previous HMACs were > predicated upon an iterative hash function, while SHA-3 is recursive. Has > anyone standardized anything for SHA-3 HMACs? Has the CFRG signed off on > anything from the IETF (https://irtf.org/cfrg)? I’ve seen something on this, but don’t think CFRG did that yet. As I said, with SHA-3 it is unnecessary. > On Saturday, February 21, 2015 at 5:43:24 AM UTC-5, Jean-Pierre Münch wrote: > Am Freitag, 20. Februar 2015 14:02:37 UTC+1 schrieb Ilya Bizyaev: > I'm afraid I haven't understood how the TrueCrypt stores the file size: > ------------------------------------------------------------------ > struct TrueCrypt_Header { > > /* Salt is visible (appears as random bytes) */ //I store the IV like this > char salt[64]; > > /* Format (after decryption), 512 - 64(salt) = 448 bytes */ > /** Format is encrypted, isn't it? **/ > /* before this line, everything's open, after this line everything's > encrypted*/ > char magic[4]; /* "TRUE" in ASCII */ //What is it used for?!, fast > verification that decryption was successful, as otherwise you get some random > noise here > uint16_t version; /* Header format version */ //For now, I don't have > different versions, you may not have them, but you better make sure that you > can distinguish old from new header as processing may vary in the future > uint16_t version_tc; /* Minimal required program version */ //See > previous one, if you deploy your application, you will delivert patches and > security enhancements and hence defining a program version is a good idea > uint32_t keys_crc32; /* CRC32 of keys area */ //Hash of keys?, place a > hash of the keys here, to check if the keys are correct > uint64_t _reserved1[2]; /* unused (former modification time) */ > uint64_t hidden_volume_size; /* size of hidden volume or zero*/ //That's > the file size, isn't it?, that's the size of the HIDDEN volume, a future > TrueCrypt has and you don't need except you want plausible denieability > uint64_t volume_size; /* size of volume or zero */ //Another file size?, > that's the actual file size > uint64_t mk_offset; /* encrypted payload offset in bytes */ //Haven't > understood..., where does encrypted data start (I guess you don't need this) > uint64_t mk_size; /* encrypted area size; ignored by cryptsetup */ // > size of theencrypted are (including header I guess) > uint32_t flags; /* system/in-place; ignored by cryptsetup */ // > leaving space for flags may be a good idea > uint32_t sector_size; /* sector size in bytes, always 512 */ //What's the > sense in writing > //constant value?, it may change in the future as standard volume sector > sizes get larger, shouldn't affect you as you don't want to implement virtual > drives > uint8_t _reserved2[120]; /* unused */ > uint32_t header_crc32; /* CRC32 of header without keys; for version > 3 */ > //Hash of full header?, hash of everything before this value > > /* Key storage area */ > char keys[256]; //And the keys are here as well?!, where else to put the > keys? > // maybe you don't get this: TrueCrypt uses your password to derive a > key that decrypts this header, in the header you find the keys actually used > for the file, meaning you can change your password without needing to > re-encrypt the whole file (GIGABYTES!) - only the header > } > ----------------------------------------------------------------- > > I propose some modifications for your purpose: You may want to add a field > after the "magic" TRUE, of size 64 to 128 chars to place your program's name. > (-> you try to decrypt the header, check the magic value and check the file > is intended for your program. > The IV should be put (un-encrypted) at the beginning, as the only unencrypted > data block. > File size is stored in the header above > > I'll quickly outline my proposal: > > struct TrueCrypt_Header { > > /* Salt is visible (appears as random bytes) */ //I store the IV like this > char salt[64]; // looks random -> whole file looks random :) > > // from here on, everything is encrypted > /* before this line, everything's open, after this line everything's > encrypted*/ > > char magic[4]; /* "TRUE" or something else in ASCII, validate this > string's correct */ > char program_name[128] /* your program's name*/ > uint16_t version; /* Header format version, validate you support this > */ > uint16_t version_tc; /* Minimal required program version, validate you > have it */ > char keys_hash[32]; /* SHA-3-256 of keys area, validate this */ > uint64_t file_size; /* size of the data following this header*/ > uint64_t mk_size; /* overall file size, as should be reported by OS, > validate this*/ > uint32_t flags; /* zeroed out, until you have ideas for flags, > ignore this if you don't have flags yet*/ > char header_hash[32]; /* SHA-3-256 of everything before this, validate > this*/ > char _reserved[36]; /* fill up to get 256 bytes, allowing ciphers with > up to 2048bits blocksize */ > > char keys[256] /* leaves you space to use up to 2048 bits of key > material -> even Threefish-1024 is supported :) */ > } > > -- > -- > You received this message because you are subscribed to the "Crypto++ Users" > Google Group. > To unsubscribe, send an email to [email protected]. > More information about Crypto++ and this group is available at > http://www.cryptopp.com. > --- > You received this message because you are subscribed to the Google Groups > "Crypto++ Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
