c/minizip-ng
1
0
Fork 0
mirror of https://github.com/zlib-ng/minizip-ng synced 2025-03-28 21:13:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

use HTTPS, whitespace and newlines fixes

Browse Source 
This is the only remaining HTTP link now: http://result42.com
This commit is contained in:
Viktor Szakats 2019-09-15 18:55:56 +00:00
parent 8bba5e3fdf
commit b11be60c0c
8 changed files with 143 additions and 143 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/appnote.txt
View File

@ -77,7 +77,7 @@ Copyright (c) 1989 - 2014 PKWARE Inc., All Rights Reserved.
1.5.2 Information about this format and copies of this document are publicly
available at:
http://www.pkware.com/appnote
https://www.pkware.com/appnote
1.6 Disclaimer
--------------
@ -3217,7 +3217,7 @@ Copyright (c) 1989 - 2014 PKWARE Inc., All Rights Reserved.
acquiring such a license.
10.2 Additional information regarding PKWARE proprietray technology is
available at http://www.pkware.com/appnote.
available at https://www.pkware.com/appnote.
11.0 Acknowledgements
---------------------

12
doc/winzip_aes.md
View File

@ -29,7 +29,7 @@ To perform AES encryption and decryption, WinZip uses AES functions written by D
Dr. Gladman's encryption functions are portable to a number of operating systems and can be static linked into your applications, so there are no operating system version or library dependencies. In particular, the functions do not require Microsoft's Cryptography API.
General information on the AES standard and the encryption algorithm (also known as _Rijndael_) is readily available on the Internet. A good place to start is [http://www.nist.gov/public_affairs/releases/g00-176.htm](http://www.nist.gov/public_affairs/releases/g00-176.htm).
General information on the AES standard and the encryption algorithm (also known as _Rijndael_) is readily available on the Internet. A good place to start is [https://web.archive.org/web/20100407101917/www.nist.gov/public_affairs/releases/g00-176.htm](https://web.archive.org/web/20100407101917/www.nist.gov/public_affairs/releases/g00-176.htm).
**II. Zip file format**
@ -39,7 +39,7 @@ General information on the AES standard and the encryption algorithm (also known
WinZip sets the version needed to extract and version made by fields in the local and central headers to the same values it would use if the file were not encrypted.
The basic Zip file format specification used by WinZip is available via FTP from the Info-ZIP group at [ftp://ftp.info-zip.org/pub/infozip/doc/appnote-iz-latest.zip](ftp://ftp.info-zip.org/pub/infozip/doc/appnote-iz-latest.zip).
The basic Zip file format specification used by WinZip is available via FTP from the Info-ZIP group at [https://infozip.sourceforge.io/doc/appnote-iz-latest.zip](https://infozip.sourceforge.io/doc/appnote-iz-latest.zip).
2. Compression method and encryption flag
@ -179,11 +179,11 @@ Note that the January 2004 version of the WinZip AE-2 specification, version 1.0
3. Key Generation
Key derivation, as used by AE-1 and AE-2 and as implemented in Dr. Gladman's library, is done according to the PBKDF2 algorithm, which is described in the [RFC2898](http://www.faqs.org/rfcs/rfc2898.html) guidelines. An iteration count of 1000 is used. An appropriate number of bits from the resulting hash value are used to compose three output values: an encryption key, an authentication key, and a password verification value. The first _n_ bits become the encryption key, the next _m_ bits become the authentication key, and the last 16 bits (two bytes) become the password verification value.
Key derivation, as used by AE-1 and AE-2 and as implemented in Dr. Gladman's library, is done according to the PBKDF2 algorithm, which is described in the [RFC2898](https://www.ietf.org/rfc/rfc2898.txt) guidelines. An iteration count of 1000 is used. An appropriate number of bits from the resulting hash value are used to compose three output values: an encryption key, an authentication key, and a password verification value. The first _n_ bits become the encryption key, the next _m_ bits become the authentication key, and the last 16 bits (two bytes) become the password verification value.
As part of the process outlined in RFC 2898 a pseudo-random function must be called; AE-2 uses the HMAC-SHA1 function, since it is a well-respected algorithm that has been in wide use for this purpose for several years.
Note that, when used in connection with 192- or 256-bit AES encryption, the fact that HMAC-SHA1 produces a 160-bit result means that, regardless of the password that you specify, the search space for the encryption key is unlikely to reach the theoretical 192- or 256-bit maximum, and cannot be guaranteed to exceed 160 bits. This is discussed in section B.1.1 of the [RFC2898 specification](http://www.faqs.org/rfcs/rfc2898.html).
Note that, when used in connection with 192- or 256-bit AES encryption, the fact that HMAC-SHA1 produces a 160-bit result means that, regardless of the password that you specify, the search space for the encryption key is unlikely to reach the theoretical 192- or 256-bit maximum, and cannot be guaranteed to exceed 160 bits. This is discussed in section B.1.1 of the [RFC2898 specification](https://www.ietf.org/rfc/rfc2898.txt).
**VI. FAQs**
@ -208,7 +208,7 @@ Note that the January 2004 version of the WinZip AE-2 specification, version 1.0
The purpose of the authentication code is to insure that, once a file's data has been compressed and encrypted, any accidental corruption of the encrypted data, and any deliberate attempts to modify the encrypted data by an attacker who does not know the password, can be detected.
The current consensus in the cryptographic community is that associating a message authentication code (or MAC) with encrypted data has strong security value because it makes a number of attacks more difficult to engineer. For AES CTR mode encryption in particular, a MAC is especially important because a number of trivial attacks are possible in its absence. The MAC used with WinZip's AES encryption is based on[HMAC-SHA1-80](http://www.faqs.org/rfcs/rfc2104.html), a mature and widely respected authentication algorithm.
The current consensus in the cryptographic community is that associating a message authentication code (or MAC) with encrypted data has strong security value because it makes a number of attacks more difficult to engineer. For AES CTR mode encryption in particular, a MAC is especially important because a number of trivial attacks are possible in its absence. The MAC used with WinZip's AES encryption is based on[HMAC-SHA1-80](https://www.ietf.org/rfc/rfc2104.txt), a mature and widely respected authentication algorithm.
The MAC is calculated after the file data has been compressed and encrypted. This order of calculation is referred to as Encrypt-then-MAC, and is preferred by many cryptographers to the alternative order of MAC-then-Encrypt because Encrypt-then-MAC is immune to some known attacks on MAC-then-Encrypt.
@ -252,7 +252,7 @@ Note that the January 2004 version of the WinZip AE-2 specification, version 1.0
2. Key Generation and HMAC-SHA1
The description of the [key generation](https://www.winzip.com/aes_info.htm#key-generation) mechanism has been updated to point out a limitation arising from its use of HMAC-SHA1 as the pseudo-random function: When used in connection with 192- or 256-bit AES encryption, the fact that HMAC-SHA1 produces a 160-bit result means that, regardless of the password that you specify, the search space for the encryption key is unlikely to reach the theoretical 192- or 256-bit maximum, and cannot be guaranteed to exceed 160 bits. This is discussed in section B.1.1 of the [RFC2898 specification](http://www.faqs.org/rfcs/rfc2898.html).
The description of the [key generation](https://www.winzip.com/aes_info.htm#key-generation) mechanism has been updated to point out a limitation arising from its use of HMAC-SHA1 as the pseudo-random function: When used in connection with 192- or 256-bit AES encryption, the fact that HMAC-SHA1 produces a 160-bit result means that, regardless of the password that you specify, the search space for the encryption key is unlikely to reach the theoretical 192- or 256-bit maximum, and cannot be guaranteed to exceed 160 bits. This is discussed in section B.1.1 of the [RFC2898 specification](https://www.ietf.org/rfc/rfc2898.txt).
Document version: 1.04
Last modified: January 30, 2009

2
lib/brg/aestab.c
View File

@ -386,7 +386,7 @@ AES_RETURN aes_init(void)
/*
Automatic code initialisation (suggested by by Henrik S. Gaßmann)
based on code provided by Joe Lowe and placed in the public domain at:
http://stackoverflow.com/questions/1113409/attribute-constructor-equivalent-in-vc
https://stackoverflow.com/questions/1113409/attribute-constructor-equivalent-in-vc
*/
#ifdef _MSC_VER

8
lib/liblzma/api/lzma.h
View File

@ -7,16 +7,16 @@
* format and raw (no headers) streams are supported. Multiple compression
* algorithms (filters) are supported. Currently LZMA2 is the primary filter.
*
* liblzma is part of XZ Utils <http://tukaani.org/xz/>. XZ Utils includes
* liblzma is part of XZ Utils <https://tukaani.org/xz/>. XZ Utils includes
* a gzip-like command line tool named xz and some other tools. XZ Utils
* is developed and maintained by Lasse Collin.
*
* Major parts of liblzma are based on Igor Pavlov's public domain LZMA SDK
* <http://7-zip.org/sdk.html>.
* <https://www.7-zip.org/sdk.html>.
*
* The SHA-256 implementation is based on the public domain code found from
* 7-Zip <http://7-zip.org/>, which has a modified version of the public
* domain SHA-256 code found from Crypto++ <http://www.cryptopp.com/>.
* 7-Zip <https://www.7-zip.org/>, which has a modified version of the public
* domain SHA-256 code found from Crypto++ <https://www.cryptopp.com/>.
* The SHA-256 code in Crypto++ was written by Kevin Springle and Wei Dai.
*/

2
lib/liblzma/check/crc32_fast.c
View File

@ -5,7 +5,7 @@
///
/// Calculate the CRC32 using the slice-by-eight algorithm.
/// It is explained in this document:
/// http://www.intel.com/technology/comms/perfnet/download/CRC_generators.pdf
/// https://www.intel.com/technology/comms/perfnet/download/CRC_generators.pdf
/// The code in this file is not the same as in Intel's paper, but
/// the basic principle is identical.
//

2
lib/liblzma/config.h
View File

@ -324,7 +324,7 @@
#define PACKAGE_TARNAME "xz"
/* Define to the home page for this package. */
#define PACKAGE_URL "http://tukaani.org/xz/"
#define PACKAGE_URL "https://tukaani.org/xz/"
/* Define to the version of this package. */
#define PACKAGE_VERSION "5.2.3"

2
test/fuzz/unzip_fuzzer.dict
View File

@ -1,6 +1,6 @@
# A dictionary for more efficient fuzzing of DoStuff().
# If the inputs contain multi-byte tokens, list them here.
# See http://libfuzzer.info#dictionaries
# See https://llvm.org/docs/LibFuzzer.html
"\x50\x4b\x03\x04"
"\x50\x4b\x01\x02"
"\x50\x4b\x05\x06"