Updated 20 September 2003
See more on Chunks in general.
This is an Encryption Algorithm specification, used to configure parameters for an encryption algorithm. CRYP is a special case of FORM, subtype 65 (hex 41).
|r (range of instances)||all used in the general manner.|
|p (multi-part) & c|
|y (payload specification)|
|i (instance sizes)||Set when r is set, Clear otherwise.|
Although the y (payload specification) is allowed, it may not refer to itself! Generally, compressing this chunk is pointless, so any use of the y flag will probably be for other unrelated purposes, such as data-integrety of this critical information.
Subtype is set to 65 (hex 41).
The Instance Number is matched against the encryption value in any Payload Specification or Extended Payload Specification.
That is, when some chunk specifies a value for how its payload is encrypted, that value refers to a CRYP chunk of that number.
Instance numbers from hex 40 through hex FFF (64 through 4095) are reserved. An archive shall not contain instances in this range.
|64||RC4 with KEYD=64 (generic passphrase prompt).|
|65||RC4 with KEYD=1 (which must also be present).|
|66||Rijndael (AES) with KEYD=64 (generic passphrase prompt).|
|67||Rijndael (AES) with KEYD=1 (which must also be present).|
Some pre-defined instances of CRYP use a generic password prompt and don’ include any intermediate keys. This is the simplest case and should only be used when this is acceptible.
Other pre-defined instances refer to KEYD#1, which must also be present in the archive. For example, you can encrypt using CRYP#67 and since CRYP#67 is pre-defined you don’t (can’t actually) include it in the archive. However, that refers to KEYD#1, which is not pre-defined. You configure the encryption key by defining KEYD#1, which might be a more specialized password prompt, an intermediate key that itself references a password key, etc.
The Payload of a CRYP chunk contains parameters for encrypting some other chunk’s payload.
The payload is a list of records.
The record begins with a uintV indicating the encryption algorithm number. This is followed by any parameters needed to decompress data. What parameters needed (if any) vary by algorithm.
If more than one record is present, each is performed in turn to decrypt the data, as is the case with any kind of FORM (transformation algorithm) chunk.
The algorithm identifiers are in the range of hex 40 through hex FFF for consistancy with other pre-defined values in the ZIP2 specification. In the future, there may be a chunk type for defining algorithms other than built-in ones, so it makes sence to use the same numbering system.
|65||RC4||uintV value for N,|
uintV for KEYD (key definition) instance.
|66||Rijndael (AES)||uintV for KEYD (key definition) instance.|
|67||reserved for Twofish||uintV for KEYD instance,|
uintV for KEYD instance for “family key”.
See http://csrc.nist.gov/encryption/aes/rijndael/Rijndael.pdf for the official description.
See the cryptography usage page for in-depth details. To summarize, AES is used with a 256-bit key in counter mode.
This uses Ron Rivest’s RC4 algorithm as published in the second edition of Bruce Schneier’s Applied Cryptography.
This is a serious encryption technique that is so simple to implement that it can be done in a few lines of code without requiring large cryptographic libraries.
The use of this stream cipher is as similar as possible to the definition for using block ciphers. They are very similar in nature because the block ciphers are used in counter mode to generate a key stream, and are sensitive to the same unique initialization vector issues as RC4.
To encrypt a chunk with a specified key, first create a derived key with a parameter of “RC4” || uniqueIV (the symbol || is concatenation).
The uniqueIV is the same as described for block ciphers, only there is no need to zero-out the
last 4 bytes. So, simply form it with
CrypHash (hash-id || chunk ID
|| length || alg-id || 0x00), where alg-id in this case is the byte 65 (hex 41).
The resulting uniqueIV becomes the key used to set-up the RC4 keystream generator. After set-up, generate 1536 key bytes and throw them away. The 1537th byte will be XOR’ed with the first byte of the message.
Note that current wisdom is that a RC4 keystream should not be longer than 230.6 bytes.
This is a simple obfuscation technique that does not use any password. ASCII alphabetic characters are rotated half the alphabet, keeping the case the same. All other characters are unchanged.
This is included somewhat as a joke, because of the Classic ZIP encryption algorithm that is seriously flawed and offers no real security. Here is an algorithm that nobody can realize is not very secure!
A possible practical use, besides users who wish to be passive-aggressive when ordered to encrypt when they don’t want to, is to hide text within the file from disk indexing programs and file searches. This gives some privacy (without requiring a password) but no real security against someone who wants to read it as opposed to accidently peek at it.
Twofish is a good alternative to AES, for those people who may be adverse to it, because it is sufficiently different from AES that it doesn't have the same issues with the newest hints of a new class of anaylsis. Also, it offers the family key feature.
The encryption algorithm doesn’t add any kind of check data to the payload. So, if the wrong key is used (such as entering the wrong password) it will have no idea that it didn’t work! To provide such a check, include a KHSH-a chunk. As explained in the cryptography features reference, applying an authentication mechanism is required when using encryption, though such features are not part of the CRYP chunk.
Need examples. Include the use of multiple records.
Page content copyright 2003 by John M. Dlugosz. Home:http://www.dlugosz.com, email:mailto:firstname.lastname@example.org