Hi Jean Pierre: Thank you very much for your answer!
First of all: yes, I need read and write at any place in the stored file. I know this is a problem. I was reading some doc about AES-GCM, and the way you propose to work, and have some doubts/observations: - I understand that using 256bit AES, the GCM mode, and size of TAG = 96 bytes (the shortest recommended) will get a resulting file, 37.5% larger than the original (regardless of the header). Some of the files we will encrypt are about 1 GB or even 2GB, so we are speaking about 375MB for tags. This is correct? - You say *In your scenario I'd suggest dividing the file into several subsections*: Where can I find the info about how to handle the subsection concept for AES-GCM? - As I can see here https://groups.google.com/forum/#!topic/cryptopp-users/UHlnZ8r-0Gc there is not option to seek in GCM. It´s true? By the way, what do you think about using XTS as shown in the link? I see this option is not implemented in Crypto++... - If I want *not *to have TAG overhead I have two options AES-CTR+HMAC or AES-CBC+HMAC: - Pros: - File size will change only with header info. - Need to change HMAC every time file is changed. A test to perform: how long it takes to compute HMAC of a 1GB file? - Cons: - More slow encryption/decryption Thank you very much for your help! El domingo, 18 de octubre de 2015, 21:06:59 (UTC+2), jean-pierre.muench escribió: > > Am 18.10.2015 um 18:20 schrieb lasl...@gmail.com <javascript:>: > > Hi all: > > Never before have I worked in cryptography. Excuse me if the question > is very long but i´m very lost. > > We have a new project in my company related to cryptography and would > appreciate you give me advice. > > We have many customers who are going to save many files encrypted on > our servers. The files are now unencrypted. We'll encrypt files and, from > now on, read and change the content without completely decrypt. > Each file can have its own password, but we believe that most customers > will always use the same password. > > I'm thinking about putting a header to the file, as is done in > https://www.aescrypt.com/aes_file_format.html. In this way we can have a > new Initialization Vector ( if necessary ) for each compressed file and the > hash of the password. > > The header format is actually looking surprisingly good. However I'd > suggest only using 12 byte IVs (AES-GCM only needs a 12 byte IV) and > replacing the header's "HMAC" with an AES-GCM tag. And I'd suggest > authenticating the whole unencrypted header (extensions, version, ...) with > the header's tag (GCM can handle associated data). > > In the header we also will keep pointers to various sections of the > document in which we have to read for some encrypted information and write > some encrypted information on the fly. For this reason I need a semi-ramdom > access. > > This actually is really tricky. Just to make sure: You need to be able > securely read and write at any place in the stored file? > This will force you to re-authenticate the whole file (which can be done > quite fast via this trick[1]) or to pull off some other trick. In your > scenario I'd suggest dividing the file into several subsections. Each > subsection will have it's own IV which is just the IV of the previous > subsection incremented by one (this is safe with AES-GCM). And at the end > of each subsection there will be an authentication tag for said section. > This will give you a linear increase in size, but a linear decrease in > computation time as you only need to consider a specific subsection when > re-authenticating or verifying. > > > We have quite clear that we must use AES to encrypt files. We're not > sure whether to use 128bit or 256bit. There is really too much difference > in safety between them (we need to consider speed) ? > > You need to consider two points here. a) Marketing. AES-256 with a 2^256 > key space will sound much more impressive than AES-128 with a tiny 2^128 > key space. b) Security period. If you want to keep the data confidential > for a very long time (decades?) than you want to use AES-256. Otherwise > AES-128 is just fine (and NSA approved for secret information) and will be > a bit faster. > > > And the most important question is what may be the most secure mode, > even assuming that an attacker could download all the files from the server? > > AES-GCM is the mode of choice in modern Cryptography. It is considered > good style to use AES-GCM and will be significantly faster than most other > modes (like AES-CTR+HMAC or AES-CBC+HMAC). Furthermore you may be able to > exploit the underlying construction to be faster by multi threading via [1]. > > I hope this answered your questions, if there are any left you may ask > here or over at Crypto.SE[2] although you may not make it too broad there. > > BR > > JPM > > [1]: https://crypto.stackexchange.com/a/27468/23623 > [2]: https://crypto.stackexchange.com/ > > > > Thank you in advance! > -- > -- > You received this message because you are subscribed to the "Crypto++ > Users" Google Group. > To unsubscribe, send an email to cryptopp-user...@googlegroups.com > <javascript:>. > More information about Crypto++ and this group is available at > <http://www.cryptopp.com>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 cryptopp-user...@googlegroups.com <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 cryptopp-users-unsubscr...@googlegroups.com. 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 cryptopp-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
