More than a set of
Zip and Unzip Components!

ZipTV is a suite of over 37
compression related components!

   
Home
  What's New
Product Info
  Archive Filter
Downloads
Ordering Info
Problem Report
Upgrades
Contact Us
Home- | -What's New- | -Product Info- -Archive Filter- | -Downloads- | -Ordering Info- | -Upgrade- | -Contact

Archiving Security

ZipV2 vs AES Encryption

The original ZipV2 encryption algorithm is the most secure encryption method for archiving. Period. We've recently incorporated the AES (the Rijndael algorithm) into the ZipTV components. Not because it adds any level of security to password protected compressed data (because it doesn't) over it's predecessor, but to support the current zip standards.

The new AES encryption includes the same security hole that the original ZipV2 algorithm did. Instead of fixing the hole, other equally or less secure (freeware) encryption methods were sought to replace it. These developers have demonstrated their absolute lack of knowledge of encryption! In testing, we've broken the AES encryption using the same brute force method as we did ZipV2, by exploiting the same hole present in both algorithms. The only thing increased by adding additional encryption algorithms into compression applications is the users feeling of security.. that all.

For decades now, the ZipV2 algorithm has used the same 3 seed keys values. Their hard-coded into ALL compression applications. End users have never known the existance of these hard-coded values, thus not ever having the ability to change them. By changing the value of these 3 seed keys, the hole closes and the ZpV2 algorithm becomes the absolute most secure encryption possible for compressed data. The brute force method of retrieving a password from an archive is no longer valid.

Sure, there is a negative to revising these keys. You have to store the key values somewhere secure. I agree, this is no simple task. These additional measures are the strength of unbreakable security. The convience of, and the increased speed in decrypting data are the two major eroding factors of secure data. Both of which have always been major caveats for archiving applications.

ZipV2 Encryption
(traditional zip encryption)
---------------
SeedKeys Property
SeedHeaderKeys Property


SeedKeys Property
: used to encrypt password protected compressed data using the ZipV2 encryption method.

SeedHeaderKeys
: used as an extra (greatly enhanced) level of archive security. When an archive's headers are encrypted, the values used to compress the file are encrypted and not visible by hackers viewing the archive using a hex editor.

1. When dropping a component onto a form, the values of SeedKeys and SeedHeaderKeys are filled with the default values. After changing the default value, it can be restored by assigning the key a value of 0 (zero).
2. The ZipTV Components are the only to support the encryption of headers, so the default values of SeedHeaderKeys are unique to ZipTV, but the default values of the SeedKeys are the values that use to be hard-coded into all compression applications. No other compression application (unless using the ZipTV Components) can decompress a password protected archive when these key values are changed. Even the ZipTV Components will require the key values the archive was password protected with, to successfully decompress.
3. The issue of encryptng headers is completely seperate from password protected data encryption. It is not required to password protect a compressed file in order to encrypt it's headers. The Passwords property has nothing to do with header encryption.

Component supported:
TZipTV: SeedHeadKeys property. The headers have to be decrypted to view the archive directory contents (filenames, date/time, file attribute, etc).

TZipSplitter, TZip, TJar, TBlakHole: SeedKeys and SeedHeaderKeys properties. Both header and data encryption supported.

TUnZip, TUnJar, TUnBh: SeedKeys and SeedHeaderKeys properties. Both header and data encryption supported.