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 cont
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
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
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 ha
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
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 - Wi
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
e
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 ag
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
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
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 usin
11 matches
Mail list logo
