Re: [COMPRESS] pkware header id for crypto extensions
On 2015-09-04, Bear Giles wrote: > I just came across a press release that suggests that it is possible to > support AES encryption for zip files: > http://www.prnewswire.com/news-releases/pkware-announces-free-licensing-program-for-secure-ziptm-and-pkzip-reader-technologies-72382192.html I contacted PKWare so we can stop speculating. The license program cited above no longer exists, there is no way we can legally implement the encryption format added by them. IMHO this doesn't apply to the metadata stuff from Bear's pull request, I'll try to find time to look into it during the weekend. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [COMPRESS] pkware header id for crypto extensions
I have a moment to explain why the PKWARE crypto is stronger than the WinZip crypto. 1. The key has validation data, the VData and VCRC32 values. There are a couple different ways to compute a message integrity check that allows you to verify the encryption key and that the message contents have not been modified. This is only available after encrypting all of the data - in streaming mode this information would have to be written to a footer. That's not difficult but it means that something has been written to the disk before it's verified and that might cause problems. Message integrity checks also require maintenance of a second key that's independent of the first. Some ciphers have an encryption mode that handles message integrity at the same time it does decryption but many ciphers do not and you can't assume all readers supports those ciphers and modes. Key validation won't detect message corruption but the file CRC gives us a modest level of protection. It's only modest though since it's easy to set the message CRC to whatever value you want if you can modify 4 bytes. That's impractical with a true HMAC with strong algorithms. 2. Encrypted random data (ERD) You can often predict the initial contents of a file from the filename extension. For instance a .xml file probably starts with or the compressed version of the same. This means you have a "known plaintext" problem and it is a powerful tool used to break the legacy ZIP encryption. ERD handles that by prepending random data to the file. The reader knows to ignore those bytes. The ERD is encrypted in the header with the same key (but all-zero IV?) to avoid the same "known plaintext" problem. One of the WW-II (or WW-I?) German ciphers was broken this way. Messages were supposed to start with a unique value but one clerk repeated one by accident. It was enough to break the cipher since all messages started the same way. Bear On Sun, Sep 20, 2015 at 8:36 PM, Bear Giles wrote: > I took out some debugging scaffolding so you can check it out. One of the > unit tests fails but it should since it's trying to read an archive with an > encrypted CD. (I haven't gotten around to wrapping it with an exception > handler that fails if an exception isn't thrown.) > > Theoretically you can do a pull request. I think. > > Bear > > On Tue, Sep 15, 2015 at 8:03 AM, Stefan Bodewig > wrote: > >> On 2015-09-14, Bear Giles wrote: >> >> > I want to capture as much information as possible but the documentation >> is >> > a weird mixture of details and hand-waving. Some is detailed, some is >> > "compatible with the format used by the Microsoft CRYPTOAPI". How is >> > anyone supposed to use that if all they have is the APPNOTE.txt file? >> >> Compared to some other "specs" we implement, this is brilliant ;-) >> >> > Anyway I can demonstrate that the headers are recognized in at least one >> > test case so I'll just remove the debugging code and add a few getters. >> >> Sounds great. >> >> > FWIW my initial impression from what's in the fields is that WinZip is >> > competently implemented but PKWare is a LOT more solid. I can give >> details >> > if anyone wants to be bored. :-) >> >> Expect me to ask you for the boring details once I start breathing >> again. Probably better off-list :-) >> >> Cheers >> >> Stefan >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >
Re: [COMPRESS] pkware header id for crypto extensions
I took out some debugging scaffolding so you can check it out. One of the unit tests fails but it should since it's trying to read an archive with an encrypted CD. (I haven't gotten around to wrapping it with an exception handler that fails if an exception isn't thrown.) Theoretically you can do a pull request. I think. Bear On Tue, Sep 15, 2015 at 8:03 AM, Stefan Bodewig wrote: > On 2015-09-14, Bear Giles wrote: > > > I want to capture as much information as possible but the documentation > is > > a weird mixture of details and hand-waving. Some is detailed, some is > > "compatible with the format used by the Microsoft CRYPTOAPI". How is > > anyone supposed to use that if all they have is the APPNOTE.txt file? > > Compared to some other "specs" we implement, this is brilliant ;-) > > > Anyway I can demonstrate that the headers are recognized in at least one > > test case so I'll just remove the debugging code and add a few getters. > > Sounds great. > > > FWIW my initial impression from what's in the fields is that WinZip is > > competently implemented but PKWare is a LOT more solid. I can give > details > > if anyone wants to be bored. :-) > > Expect me to ask you for the boring details once I start breathing > again. Probably better off-list :-) > > Cheers > > Stefan > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [COMPRESS] pkware header id for crypto extensions
On 2015-09-14, Bear Giles wrote: > I want to capture as much information as possible but the documentation is > a weird mixture of details and hand-waving. Some is detailed, some is > "compatible with the format used by the Microsoft CRYPTOAPI". How is > anyone supposed to use that if all they have is the APPNOTE.txt file? Compared to some other "specs" we implement, this is brilliant ;-) > Anyway I can demonstrate that the headers are recognized in at least one > test case so I'll just remove the debugging code and add a few getters. Sounds great. > FWIW my initial impression from what's in the fields is that WinZip is > competently implemented but PKWare is a LOT more solid. I can give details > if anyone wants to be bored. :-) Expect me to ask you for the boring details once I start breathing again. Probably better off-list :-) Cheers Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [COMPRESS] pkware header id for crypto extensions
No problem, I've also been preempted. I want to capture as much information as possible but the documentation is a weird mixture of details and hand-waving. Some is detailed, some is "compatible with the format used by the Microsoft CRYPTOAPI". How is anyone supposed to use that if all they have is the APPNOTE.txt file? Anyway I can demonstrate that the headers are recognized in at least one test case so I'll just remove the debugging code and add a few getters. I also found documentation on WinZip so I can also capture that information later. It uses a different compression method ID to indicate encryption instead of new extra fields. FWIW my initial impression from what's in the fields is that WinZip is competently implemented but PKWare is a LOT more solid. I can give details if anyone wants to be bored. :-) Bear On Mon, Sep 14, 2015 at 1:34 AM, Stefan Bodewig wrote: > Hi Bear > > sorry for the late reply. My spare time is currently severly limited > but this should be getting better by the end of the month. > > On 2015-09-05, Bear Giles wrote: > > > I was just reminded of the risks of making assumptions. There's two > > separate implementations of AES strong encryption - WinZip AES and > PKWare. > > I've been focused on the latter but we should recognize both types of > > headers. > > IIRC WinZip AES works rather differently by using a separate > "compression method". I haven't looked into the details so far, though. > It should be fine to start with just one implementation IMHO. > > > I've pushed a bit more code that partially parses the PKWare headers. > It's > > enough to identify the encryption and hash algorithms used but a lot is > > left unparsed. > > Unless we really wanted to implement the crypto part this sounds > like a lot already. > > Thanks > > Stefan > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [COMPRESS] pkware header id for crypto extensions
Hi Bear sorry for the late reply. My spare time is currently severly limited but this should be getting better by the end of the month. On 2015-09-05, Bear Giles wrote: > I was just reminded of the risks of making assumptions. There's two > separate implementations of AES strong encryption - WinZip AES and PKWare. > I've been focused on the latter but we should recognize both types of > headers. IIRC WinZip AES works rather differently by using a separate "compression method". I haven't looked into the details so far, though. It should be fine to start with just one implementation IMHO. > I've pushed a bit more code that partially parses the PKWare headers. It's > enough to identify the encryption and hash algorithms used but a lot is > left unparsed. Unless we really wanted to implement the crypto part this sounds like a lot already. Thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [COMPRESS] pkware header id for crypto extensions
I was just reminded of the risks of making assumptions. There's two separate implementations of AES strong encryption - WinZip AES and PKWare. I've been focused on the latter but we should recognize both types of headers. I've pushed a bit more code that partially parses the PKWare headers. It's enough to identify the encryption and hash algorithms used but a lot is left unparsed. Bear On Fri, Sep 4, 2015 at 12:17 PM, Bear Giles wrote: > I just came across a press release that suggests that it is possible to > support AES encryption for zip files: > > > http://www.prnewswire.com/news-releases/pkware-announces-free-licensing-program-for-secure-ziptm-and-pkzip-reader-technologies-72382192.html > > (We might have discussed this several years ago...) > > Bear > > On Thu, Sep 3, 2015 at 10:12 PM, Bear Giles wrote: > >> I've forked at github.com/beargiles/commons-compress and committed some >> initial work - five new ExtraHeader classes, their registration, two test >> files and four unit tests. >> >> One test file uses certificate encryption and signature but does not >> encrypt filenames. The second test file uses certificate encryption and >> signature and encrypts filenames. I am using my Symantec certificate for >> bgi...@coyotesong.com and can verify that information is present with >> 'strings'. >> >> The results of the tests are a little confusing. The good: >> >> - the use of strong encryption is recognized >> - the substitution of an encrypted filenames is recognized. (recorded >> filename is 1, not LICENSE.txt). >> >> The bad: >> >> - I'm only seeing the headers loaded in one unit test. I don't know if >> the rest should be reading the headers or not so I don't know if I'm >> properly handling them or if they're quietly handled by the default handler. >> >> - one unit test blows up due to missing central directory (it's >> encrypted). >> >> I guess the next step is either finding a way to have the unit tests >> trigger reading the extra headers or confirm that it's not possible. >> >> Bear >> >> On Wed, Sep 2, 2015 at 3:58 PM, Bear Giles wrote: >> >>> Hi, I know that the implementation of the PKWARE AES crypto is subject >>> to license restrictions but is it possible to recognize the extension >>> fields so anyone scanning an unfamiliar file will at least know what the >>> extra field headers contain? >>> >>> I don't know if code to parse the contents (solely using the standard >>> JCE) would trigger export restrictions. This would NOT be decrypting the >>> data, just adding a thin layer of code to parse a standardized ASN.1 object. >>> >>> (BTW there are some other header types documented but except for a few I >>> don't know what they are.) >>> >>> The header IDs (per >>> https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) are: >>> >>> 0x0014PKCS#7 Store for X.509 Certificates >>> 0x0015X.509 Certificate ID and Signature for >>> individual file >>> 0x0016X.509 Certificate ID for Central Directory >>> 0x0017Strong Encryption Header >>> 0x0019PKCS#7 Encryption Recipient Certificate List >>> >>> The definitions are: >>> >>>4.5.9 -PKCS#7 Store for X.509 Certificates (0x0014): >>> >>> This field MUST contain information about each of the certificates >>> files may be signed with. When the Central Directory Encryption >>> feature is enabled for a ZIP file, this record will appear in >>> the Archive Extra Data Record, otherwise it will appear in the >>> first central directory record and will be ignored in any >>> other record. >>> >>> >>> Note: all fields stored in Intel low-byte/high-byte order. >>> >>> Value Size Description >>> - --- >>> (Store) 0x00142 bytes Tag for this "extra" block type >>> TSize 2 bytes Size of the store data >>> TData TSizeData about the store >>> >>> >>>4.5.10 -X.509 Certificate ID and Signature for individual file (0x0015): >>> >>> This field contains the information about which certificate in >>> the PKCS#7 store was used to sign a particular file. It also >>> contains the signature data. This field can appear multiple >>> times, but can only appear once per certificate. >>> >>> Note: all fields stored in Intel low-byte/high-byte order. >>> >>> Value Size Description >>> - --- >>> (CID) 0x00152 bytes Tag for this "extra" block type >>> TSize 2 bytes Size of data that follows >>> TData TSizeSignature Data >>> >>>4.5.11 -X.509 Certificate ID and Signature for central directory >>> (0x0016): >>> >>> This field contains the information about which certificate in >>> the PKCS#7 store was used to sign the central directory structure. >>> When the Central Directory Encryption feature
Re: [COMPRESS] pkware header id for crypto extensions
I just came across a press release that suggests that it is possible to support AES encryption for zip files: http://www.prnewswire.com/news-releases/pkware-announces-free-licensing-program-for-secure-ziptm-and-pkzip-reader-technologies-72382192.html (We might have discussed this several years ago...) Bear On Thu, Sep 3, 2015 at 10:12 PM, Bear Giles wrote: > I've forked at github.com/beargiles/commons-compress and committed some > initial work - five new ExtraHeader classes, their registration, two test > files and four unit tests. > > One test file uses certificate encryption and signature but does not > encrypt filenames. The second test file uses certificate encryption and > signature and encrypts filenames. I am using my Symantec certificate for > bgi...@coyotesong.com and can verify that information is present with > 'strings'. > > The results of the tests are a little confusing. The good: > > - the use of strong encryption is recognized > - the substitution of an encrypted filenames is recognized. (recorded > filename is 1, not LICENSE.txt). > > The bad: > > - I'm only seeing the headers loaded in one unit test. I don't know if the > rest should be reading the headers or not so I don't know if I'm properly > handling them or if they're quietly handled by the default handler. > > - one unit test blows up due to missing central directory (it's encrypted). > > I guess the next step is either finding a way to have the unit tests > trigger reading the extra headers or confirm that it's not possible. > > Bear > > On Wed, Sep 2, 2015 at 3:58 PM, Bear Giles wrote: > >> Hi, I know that the implementation of the PKWARE AES crypto is subject to >> license restrictions but is it possible to recognize the extension fields >> so anyone scanning an unfamiliar file will at least know what the extra >> field headers contain? >> >> I don't know if code to parse the contents (solely using the standard >> JCE) would trigger export restrictions. This would NOT be decrypting the >> data, just adding a thin layer of code to parse a standardized ASN.1 object. >> >> (BTW there are some other header types documented but except for a few I >> don't know what they are.) >> >> The header IDs (per >> https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) are: >> >> 0x0014PKCS#7 Store for X.509 Certificates >> 0x0015X.509 Certificate ID and Signature for >> individual file >> 0x0016X.509 Certificate ID for Central Directory >> 0x0017Strong Encryption Header >> 0x0019PKCS#7 Encryption Recipient Certificate List >> >> The definitions are: >> >>4.5.9 -PKCS#7 Store for X.509 Certificates (0x0014): >> >> This field MUST contain information about each of the certificates >> files may be signed with. When the Central Directory Encryption >> feature is enabled for a ZIP file, this record will appear in >> the Archive Extra Data Record, otherwise it will appear in the >> first central directory record and will be ignored in any >> other record. >> >> >> Note: all fields stored in Intel low-byte/high-byte order. >> >> Value Size Description >> - --- >> (Store) 0x00142 bytes Tag for this "extra" block type >> TSize 2 bytes Size of the store data >> TData TSizeData about the store >> >> >>4.5.10 -X.509 Certificate ID and Signature for individual file (0x0015): >> >> This field contains the information about which certificate in >> the PKCS#7 store was used to sign a particular file. It also >> contains the signature data. This field can appear multiple >> times, but can only appear once per certificate. >> >> Note: all fields stored in Intel low-byte/high-byte order. >> >> Value Size Description >> - --- >> (CID) 0x00152 bytes Tag for this "extra" block type >> TSize 2 bytes Size of data that follows >> TData TSizeSignature Data >> >>4.5.11 -X.509 Certificate ID and Signature for central directory (0x0016): >> >> This field contains the information about which certificate in >> the PKCS#7 store was used to sign the central directory structure. >> When the Central Directory Encryption feature is enabled for a >> ZIP file, this record will appear in the Archive Extra Data Record, >> otherwise it will appear in the first central directory record. >> >> Note: all fields stored in Intel low-byte/high-byte order. >> >> Value Size Description >> - --- >> (CDID) 0x00162 bytes Tag for this "extra" block type >> TSize 2 bytes Size of data that follows >> TData TSizeData >> >>4.5.12 -Strong Encryption Header (0x0017): >> >> Value Size
Re: [COMPRESS] pkware header id for crypto extensions
I've forked at github.com/beargiles/commons-compress and committed some initial work - five new ExtraHeader classes, their registration, two test files and four unit tests. One test file uses certificate encryption and signature but does not encrypt filenames. The second test file uses certificate encryption and signature and encrypts filenames. I am using my Symantec certificate for bgi...@coyotesong.com and can verify that information is present with 'strings'. The results of the tests are a little confusing. The good: - the use of strong encryption is recognized - the substitution of an encrypted filenames is recognized. (recorded filename is 1, not LICENSE.txt). The bad: - I'm only seeing the headers loaded in one unit test. I don't know if the rest should be reading the headers or not so I don't know if I'm properly handling them or if they're quietly handled by the default handler. - one unit test blows up due to missing central directory (it's encrypted). I guess the next step is either finding a way to have the unit tests trigger reading the extra headers or confirm that it's not possible. Bear On Wed, Sep 2, 2015 at 3:58 PM, Bear Giles wrote: > Hi, I know that the implementation of the PKWARE AES crypto is subject to > license restrictions but is it possible to recognize the extension fields > so anyone scanning an unfamiliar file will at least know what the extra > field headers contain? > > I don't know if code to parse the contents (solely using the standard JCE) > would trigger export restrictions. This would NOT be decrypting the data, > just adding a thin layer of code to parse a standardized ASN.1 object. > > (BTW there are some other header types documented but except for a few I > don't know what they are.) > > The header IDs (per > https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) are: > > 0x0014PKCS#7 Store for X.509 Certificates > 0x0015X.509 Certificate ID and Signature for > individual file > 0x0016X.509 Certificate ID for Central Directory > 0x0017Strong Encryption Header > 0x0019PKCS#7 Encryption Recipient Certificate List > > The definitions are: > >4.5.9 -PKCS#7 Store for X.509 Certificates (0x0014): > > This field MUST contain information about each of the certificates > files may be signed with. When the Central Directory Encryption > feature is enabled for a ZIP file, this record will appear in > the Archive Extra Data Record, otherwise it will appear in the > first central directory record and will be ignored in any > other record. > > > Note: all fields stored in Intel low-byte/high-byte order. > > Value Size Description > - --- > (Store) 0x00142 bytes Tag for this "extra" block type > TSize 2 bytes Size of the store data > TData TSizeData about the store > > >4.5.10 -X.509 Certificate ID and Signature for individual file (0x0015): > > This field contains the information about which certificate in > the PKCS#7 store was used to sign a particular file. It also > contains the signature data. This field can appear multiple > times, but can only appear once per certificate. > > Note: all fields stored in Intel low-byte/high-byte order. > > Value Size Description > - --- > (CID) 0x00152 bytes Tag for this "extra" block type > TSize 2 bytes Size of data that follows > TData TSizeSignature Data > >4.5.11 -X.509 Certificate ID and Signature for central directory (0x0016): > > This field contains the information about which certificate in > the PKCS#7 store was used to sign the central directory structure. > When the Central Directory Encryption feature is enabled for a > ZIP file, this record will appear in the Archive Extra Data Record, > otherwise it will appear in the first central directory record. > > Note: all fields stored in Intel low-byte/high-byte order. > > Value Size Description > - --- > (CDID) 0x00162 bytes Tag for this "extra" block type > TSize 2 bytes Size of data that follows > TData TSizeData > >4.5.12 -Strong Encryption Header (0x0017): > > Value Size Description > - --- > 0x00172 bytes Tag for this "extra" block type > TSize 2 bytes Size of data that follows > Format2 bytes Format definition for this record > AlgID 2 bytes Encryption algorithm identifier > Bitlen2 bytes Bit length of encryption key > Flags 2 bytes Processing flags > CertData TSize-8 Certificate decryption extra field data >
Re: [COMPRESS] pkware header id for crypto extensions
On 2015-09-02, Bear Giles wrote: > Hi, I know that the implementation of the PKWARE AES crypto is subject to > license restrictions but is it possible to recognize the extension fields > so anyone scanning an unfamiliar file will at least know what the extra > field headers contain? I don't think this would be considered anything close to implementing PKWARE strong encryption, so don't sense any legal problem here. > I don't know if code to parse the contents (solely using the standard JCE) > would trigger export restrictions. This would NOT be decrypting the data, > just adding a thin layer of code to parse a standardized ASN.1 object. Commons Compress has already got AES support for 7zip so we've filed the necessary papers and there already are the necessary disclaimers in https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=blob;f=README.txt;h=b743b64210c5d550962e8b88322af24d351aa08f;hb=HEAD#l22 Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[COMPRESS] pkware header id for crypto extensions
Hi, I know that the implementation of the PKWARE AES crypto is subject to license restrictions but is it possible to recognize the extension fields so anyone scanning an unfamiliar file will at least know what the extra field headers contain? I don't know if code to parse the contents (solely using the standard JCE) would trigger export restrictions. This would NOT be decrypting the data, just adding a thin layer of code to parse a standardized ASN.1 object. (BTW there are some other header types documented but except for a few I don't know what they are.) The header IDs (per https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) are: 0x0014PKCS#7 Store for X.509 Certificates 0x0015X.509 Certificate ID and Signature for individual file 0x0016X.509 Certificate ID for Central Directory 0x0017Strong Encryption Header 0x0019PKCS#7 Encryption Recipient Certificate List The definitions are: 4.5.9 -PKCS#7 Store for X.509 Certificates (0x0014): This field MUST contain information about each of the certificates files may be signed with. When the Central Directory Encryption feature is enabled for a ZIP file, this record will appear in the Archive Extra Data Record, otherwise it will appear in the first central directory record and will be ignored in any other record. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description - --- (Store) 0x00142 bytes Tag for this "extra" block type TSize 2 bytes Size of the store data TData TSizeData about the store 4.5.10 -X.509 Certificate ID and Signature for individual file (0x0015): This field contains the information about which certificate in the PKCS#7 store was used to sign a particular file. It also contains the signature data. This field can appear multiple times, but can only appear once per certificate. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description - --- (CID) 0x00152 bytes Tag for this "extra" block type TSize 2 bytes Size of data that follows TData TSizeSignature Data 4.5.11 -X.509 Certificate ID and Signature for central directory (0x0016): This field contains the information about which certificate in the PKCS#7 store was used to sign the central directory structure. When the Central Directory Encryption feature is enabled for a ZIP file, this record will appear in the Archive Extra Data Record, otherwise it will appear in the first central directory record. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description - --- (CDID) 0x00162 bytes Tag for this "extra" block type TSize 2 bytes Size of data that follows TData TSizeData 4.5.12 -Strong Encryption Header (0x0017): Value Size Description - --- 0x00172 bytes Tag for this "extra" block type TSize 2 bytes Size of data that follows Format2 bytes Format definition for this record AlgID 2 bytes Encryption algorithm identifier Bitlen2 bytes Bit length of encryption key Flags 2 bytes Processing flags CertData TSize-8 Certificate decryption extra field data (refer to the explanation for CertData in the section describing the Certificate Processing Method under the Strong Encryption Specification) See the section describing the Strong Encryption Specification for details. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. 4.5.14 -PKCS#7 Encryption Recipient Certificate List (0x0019): This field MAY contain information about each of the certificates used in encryption processing and it can be used to identify who is allowed to decrypt encrypted files. This field should only appear in the archive extra data record. This field is not required and serves only to aid archive modifications by preserving public encryption key data. Individual security requirements may dictate that this data be omitted to deter information exposure. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description - --- (CStore) 0x00192 bytes Tag for this "extra" block type TSize 2 bytes Size of the store data TData TSize
