PCMania 10

home *** CD-ROM | disk | FTP | other *** search

/ PCMania 10 / Pcmania_Ep2_10_CD-01.iso / ARTICULOS / tecnologia / PUFFER.ZIP / SPECS.TX_ / SPECS.TX

Wrap

Text File | 1996-02-13 | 11.3 KB | 291 lines

Puffer (tm) 2.0 File Formats and Security Protocols (13 February 1996) File Formats ------------ Puffer is designed to run on personal computers using the Windows 3.1 and compatible operating systems. Puffer supports three output formats: Binary, ASCII, and Self- Extracting. Each type can hold up to 1000 encrypted files. All the files in a single archive are encrypted with the same key. Files from the binary and ASCII formats can be decrypted independently. Binary Format ------------- The default file extension for a binary file is ".PUF". Binary PUF files begin with a file header, shown here in Pascal format: file_header: record id: array[1..4] of char; method: byte; end; The id field is always 'PUFX'. The method field is one of these values: method format ------ --------------------------------------- 3 Symmetric encryption, 40-bit PC1 4 Symmetric encryption, 160-bit Blowfish Note: Version 1.0 binary files (now obsolete) used an id of 'PUF8' and had method numbers 1 and 2. Method 4, using the Blowfish algorithm, is not available in the exportable versions of Puffer. Global Header ------------- A global header follows the file header with this structure: gheader: record nfiles: word; encrypt_headers: boolean; case_sensitive_pw: boolean; pw_salt: array[1..5] of byte; giv: array[1..8] of byte; pw_check: word; end; Note: boolean values are 1 byte in length with values of 0=false and 1=true. Words are 16-bit unsigned integers. All multi-byte integers are stored in little-endian (least significant byte first) format. nfiles = the number of files in the archive from 1 to 1000. encrypt_headers = true if the local headers are encrypted. case_sensitive_pw = true if the case sensitive password option is set. pw_salt = 5 bytes of random password salt. giv = 8 bytes of random data for a global initialization vector (IV). pw_check = 2 bytes of ciphertext used for password confirmation. Local Headers ------------- Immediately preceding each file in the archive is a local header. If encrypt_headers=true in the global header, then each local header is preceded by a header initialization vector: hiv: array[1..8] of byte; hiv = 8 bytes of random data. Next follows: hlength: word; hlength is the length of the local header in bytes. This number varies because the length of the plaintext file name can vary. Next follows the local header in this structure: lheader: record id: array[1..3] of char; compression: byte; size: longint; csize: longint; time: longint; crc32: longint; next: longint; ptname: string; end; id = 'PUF' compression = 0 for no compression, 1 for LZ77 compression. size = length of original plaintext file in bytes. csize = compressed length of plaintext file. Will be the same as size if compression=0. time = plaintext timestamp in MS-DOS date/time format. crc32 = 32-bit CRC value of original plaintext file. next = absolute offset in PUF file for next file header in archive. ptname = plaintext file name. The first byte contains the length of the string. Following the local header is the file initialization vector: fiv: array[1..8] of byte; fiv is 8 bytes of random data. Following the fiv is the encrypted (and possibly compressed) file using either the 40-bit PC1 or the 160-bit Blowfish algorithms. The encryption key is the user's pass-phrase, salted and hashed with SHA-1. The file is padded with random bytes (after compression) if necessary so that its length is an even multiple of 8. ASCII Format ------------ The default extension for an ASCII file is also ".PUF". When ASCII PUF files are split to facilitate e-mail delivery, the extensions are ".P01", ".P02", ".P03", etc. ASCII PUF files are similar to Binary PUF files except all the binary data is xxencoded to text format so that they can be safely mailed across the Internet. Also, the lheader.next field contains the data line number (1-based) of the next file in the archive rather than its byte offset. Each line in an ASCII PUF file is terminated by a carriage return and line feed character (#13#10). Some e-mail systems will strip out the carriage returns. Therefore, Puffer will look for line feed characters when decrypting and will ignore carriage returns. ASCII files begin with a file header line of: Begin PUFXnn where nn is the encryption method: method format ------ --------------------------------------- 03 Symmetric encryption, 40-bit PC1 04 Symmetric encryption, 160-bit Blowfish Any text before the file header line is ignored during the decryption process. The header line must appear in the first 100 lines, however. Following the file header line is the same data that follows the file header in Binary PUF files except the data is encoded in the following manner: Every three binary bytes are converted to four text bytes by splitting the original 24 bits into four pieces of 6 bits each. These 6-bit values correspond to an offset into this array: const xxcode: array[0..63] of char='+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ'+ 'abcdefghijklmnopqrstuvwxyz'; Each data line in the ASCII file contains 64 characters plus a cr/lf representing 48 bytes of ciphertext. The output lines are flushed at certain points of the file. Flushing the line means appending random data until a complete 64-character line is ready for output. Flushing occurs once after all the global header information is output. It also occurs after the local header is output for each file and after the last byte of ciphertext for each file is output. Before the file is closed, a footer line is appended to the file: End Puf Any data past the footer line is ignored during decryption. When ASCII files are split, each split file also contains a header and footer line except the "Xnn" suffix is only placed in the first ".P01" split file. Self-Extracting Format ---------------------- Self-Extracting files are DOS executables with an extension of ".EXE". They are identical to Binary PUF files except they contain header code that prompts the user for a password and then decrypts the data stored past the header code. Blowfish Algorithm ------------------ Due to U.S. export restrictions, the Blowfish option is not available in the shareware or the international versions of Puffer. Blowfish is a fast, unpatented variable size-key block encryption algorithm invented by Bruce Schneier, security consultant and author of "Applied Cryptography" (Wiley, ISBN 0-471-11709-9). The Blowfish algorithm used in Puffer follows the original specification as described in the April 1994 edition of Dr. Dobb's Journal and the second edition of "Applied Cryptography" with two exceptions: 1. The data blocks are processed in little-endian (least significant byte first) format, the natural state for Intel-based processors. 2. The p-array and s-boxes are initialized with the output of a linear congruential random number generator (RNG) instead of the hexadecimal digits of pi. The RNG used is based on the formula: rng(i) = rng(i-1) * 134775813 + 1, where rng is a 32-bit integer with an initial value of ffffffff hex. Puffer runs Blowfish with a 160-bit key in Cipher Block Chaining (CBC) mode. An 8-byte initialization vector (IV) is generated from the compiler's (Borland Delphi) pseudo random number generator (PRNG). The PRNG is seeded with data from the system clock at startup to ensure a unique IV for each file. Puffer Cipher 1 (PC1) Algorithm ------------------------------- PC1 is a very fast, unpatented variable size-key stream cipher that produces an identical key stream as RSA Data Security Inc's RC4 algorithm. The algorithm follows the RC4 specification as described by Schneier in "Applied Cryptography". Puffer runs PC1 with an 80-bit key consisting of 40 bits of secret key material and 40 bits of salt provided by the compiler's PRNG. Key Generation -------------- Encryption keys are generated from the user's password. Passwords can be up to 50 characters in length using any character available from the keyboard. The user has the option of setting a "case sensitivity" flag at run-time which is saved in the global header of the ciphertext file. If this flag is disabled, the password is converted to uppercase. To discourage pre-computed dictionary attacks, five bytes of random salt from the compiler's PRNG are appended to the password and then run through the Secure Hash Algorithm (SHA-1) to produce a 160-bit hash value. The SHA-1 algorithm conforms to FIPS PUB 180-1 specification as published by the National Institute of Standards and Technology (NIST). The password salt is saved in the global header of the ciphertext file. For the Blowfish algorithm, the entire 160-bit hash is used as the encryption key. For the PC1 algorithm, only the 40 least significant bits are used as the encryption key and the remaining 120 bits are discarded. Key Confirmation ---------------- Puffer has a key confirmation feature that will determine if the user enters an incorrect password during decryption. A 64-bit IV is filled with output from the compiler's PRNG. For the Blowfish algorithm, the IV block is encrypted with the encryption key and the least significant 16 bits of ciphertext output is saved in a password check variable. For the PC1 algorithm, the first 40 bits of the IV are used as salt for the key. The other 24 bits of the IV are not used. The 40-bit encryption key is appended to the salt resulting in an 80-bit key. The PC1 engine is then cycled 10,000 times with results discarded. Two more cycles are made and the 16-bit result is saved in the password check variable. Both the IV and the password check variable are saved in the ciphertext file's global header. During decryption, the IV is retrieved from the header and the process is repeated. If the password check matches the stored valued then the password is assumed to be correct and the decryption process continues. The global IV/salt is only used for the password check. Each file encrypted in the archive uses a unique IV/salt. If the encrypted headers option is used, the local headers are encrypted with unique IV/salts, also. File Compression ---------------- Puffer uses LZ77, an unpatented sliding dictionary-based algorithm for file compression. Puffer's implementation includes a 4096-byte sliding window with an 18 byte look-ahead buffer. The output format consists of a series of 8-bit flags followed by 8 output tokens. The flag bits are read from right to left. A flag bit of 1 means the next output token is a standalone byte ready for output. A flag bit of 0 means the next output token is a 16-bit offset/length combination. The first 12 bits (0..4095) represent the offset into the sliding window and the remaining 4 bits (0..15) represent the length (3..18) of the string to output.