//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.
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.
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).
/* 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. 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)?
Jeff
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.
