Am Sonntag, 22. Februar 2015 16:10:02 UTC+1 schrieb Mouse: > > On Feb 22, 2015, at 5:09 , Jeffrey Walton <[email protected] <javascript:>> > 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. > The magic value is by no means intended as authentication tag. For this purpose we do have the hashes / MACs / authenticated cipher. This is supposed to be a fast way to check if a (valid) user entered the right password. For validation you'd use the hashes, which in-fact use CRC-32 in TrueCrypt 7.1a (considered secure?), so I proposed SHA-3 as a more adequate solution.
> > 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. > That's nice to have but not absolutely neccessary for drive encryption. F.ex. TrueCrypt uses XTS-mode without any authentication (except for the CRCs in the header). As no one did the work on XTS for Crypto++(yet? - not me!), I guess AEAD is the best way to go. > > 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. > For now AES/GCM is fine, I guess, but that's why there's a header version :) 2.0 gets the winner? > > /* 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. > > > :-) > Of course if one feels more comfortable with it, one can of course use some sort of MAC here, that uses a key that's derived along with the encryption key from the password. > > 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. > > > > BR JPM > 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] > <javascript:>. > 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] <javascript:>. > 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.
