blowfish.h

利用Blowfish对称加密算法对文件进行加密, 内含VC++ 6.0源码

/*
	Copyright 2006 - 2008
	ZhangLuduo <[e-mail]>
	All Rights Reserved.

	Blowfish 对称加密算法

	作者	- 张鲁夺(zhangluduo)
	MSN		- [e-mail]
	QQ群	- 34064264

	为所有爱我的人和我爱的人努力!
*/

#ifndef _BLOWFISH_H
#define _BLOWFISH_H

#define for if ( 0 ) ; else for
#define MINKEYBYTES  4	//  32 bits min
#define MAXKEYBYTES 56	// 448 bits max
#define NULL		0
#define N			16

class Blowfish
{
private:

	static const unsigned long pbox[N + 2];
	static const unsigned long sbox[4][256];

	unsigned long key_pbox[N + 2];
	unsigned long key_sbox[4][256];	

	unsigned long F(unsigned long x) ;

public:

	enum 
	{ 
		BLOWFISH_SUCCESS		= 0, // okay
		BLOWFISH_NULL			= 1, // Null pointer parameter
		BLOWFISH_INPUTTOOSHORT	= 2, // input data too short
		BLOWFISH_INPUTTOOLONG	= 3  // input data too long
	};

	// return error codes
	int Init( /* in */ unsigned char* const key, /* in */ int keyLen );

	// return error codes
	int Encrypt( /* in & out */ unsigned long *xl, /* in & out */ unsigned long *xr);

	// return error codes
	int Decrypt( /* in & out */ unsigned long *xl, /* in & out */ unsigned long *xr);
};

#endif

//	from http://www.schneier.com/
//	Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish)
//	B. Schneier 
//
//	Fast Software Encryption, Cambridge Security Workshop Proceedings (December 1993), Springer-Verlag, 1994, pp. 191-204.
//
//	ABSTRACT: 
//
//	Blowfish, a new secret-key block cipher, is proposed. It is a Feistel network, iterating a simple encryption function 16 times. The block size is 64 bits, and the key can be any length up to 448 bits. Although there is a complex initialization phase required before any encryption can take place, the actual encryption of data is very efficient on large microprocessors. 
//
//	The cryptographic community needs to provide the world with a new encryption standard. DES [16], the workhorse encryption algorithm for the past fifteen years, is nearing the end of its useful life. Its 56-bit key size is vulnerable to a brute-force attack [22], and recent advances in differential cryptanalysis [1] and linear cryptanalysis [10] indicate that DES is vulnerable to other attacks as well. 
//
//	Many of the other unbroken algorithms in the literature--Khufu [11,12], REDOC II [2,23, 20], and IDEA [7,8,9]--are protected by patents. RC2 and RC4, approved for export with a small key size, are proprietary [18]. GOST [6], a Soviet government algorithm, is specified without the S-boxes. The U.S. government is moving towards secret algorithms, such as the Skipjack algorithm in the Clipper and Capstone chips [17]. 
//
//	If the world is to have a secure, unpatented, and freely- available encryption algorithm by the turn of the century, we need to develop several candidate encryption algorithms now. These algorithms can then be subjected to years of public scrutiny and cryptanalysis. Then, the hope is that one or more candidate algorithms will survive this process, and can eventually become a new standard. 
//
//	This paper discusses the requirements for a standard encryption algorithm. While it may not be possible to satisfy all requirements with a single algorithm, it may be possible to satisfy them with a family of algorithms based on the same cryptographic principles. 
//
//	AREAS OF APPLICATION 
//
//	A standard encryption algorithm must be suitable for many different applications: 
//
//	Bulk encryption. The algorithm should be efficient in encrypting data files or a continuous data stream. 
//
//	Random bit generation. The algorithm should be efficient in producing single random bits. 
//
//	Packet encryption. The algorithm should be efficient in encrypting packet-sized data. (An ATM packet has a 48- byte data field.) It should implementable in an application where successive packets may be encrypted or decrypted with different keys. 
//
//	Hashing. The algorithm should be efficient in being converted to a one-way hash function. 
//
//	PLATFORMS 
//
//	A standard encryption algorithm must be implementable on a variety of different platforms, each with their own requirements. These include: 
//
//	Special hardware. The algorithm should be efficiently implementable in custom VLSI hardware. 
//
//	Large processors. While dedicated hardware will always be used for the fastest applications, software implementations are more common. The algorithm should be efficient on 32-bit microprocessors with 4 kbyte program and data caches. 
//
//	Medium-size processors. The algorithm should run on microcontrollers and other medium-size processors, such as the 68HC11. 
//
//	Small processors. It should be possible to implement the algorithm on smart cards, even inefficiently. 
//
//	The requirements for small processors are the most difficult. RAM and ROM limitations are severe for this platform. Also, efficiency is more important on these small machines. Workstations double their capacity almost annually. Small embedded systems are the same year after year, and there is little capacity to spare. If there is a choice, the extra computation burden should be on large processors rather than small processors. 
//
//	ADDITIONAL REQUIREMENTS 
//
//	These additional requirements should, if possible, be levied on a standard encryption algorithm. 
//
//	The algorithm should be simple to code. Experiences with DES [19] show that programmers will often make implementation mistakes if the algorithm is complicated. If possible, the algorithm should be robust against these mistakes. 
//
//	The algorithm should have a flat keyspace, allowing any random bit string of the required length to be a possible key. There should be no weak keys. 
//
//	The algorithm should facilitate easy key-management for software implementations. Software implementations of DES generally use poor key management techniques. In particular, the password that the user types in becomes the key. This means that although DES has a theoretical keyspace of 256, the actual keyspace is limited to keys constructed with the 95 characters of printable ASCII. Additionally, keys corresponding to words and near words are much more likely. 
//
//	The algorithm should be easily modifiable for different levels of security, both minimum and maximum requirements. 
//
//	All operations should manipulate data in byte-sized blocks. Where possible, operations should manipulate data in 32-bit blocks. 
//
//	DESIGN DECISIONS 
//
//	Based on the above parameters, we have made these design decisions. The algorithm should: 
//
//	Manipulate data in large blocks, preferably 32 bits in size (and not in single bits, such as DES). 
//
//	Have either a 64-bit or a 128-bit block size. 
//
//	Have a scalable key, from 32 bits to at least 256 bits. 
//
//	Use simple operations that are efficient on microprocessors: e.g., exclusive-or, addition, table lookup, modular- multiplication. It should not use variable-length shifts or bit-wise permutations, or conditional jumps. 
//
//	Be implementable on an 8-bit processor with a minimum of 24 bytes of RAM (in addition to the RAM required to store the key) and 1 kilobyte of ROM. 
//
//	Employ precomputable subkeys. On large-memory systems, these subkeys can be precomputed for faster operation. Not precomputing the subkeys will result in slower operation, but it should still be possible to encrypt data without any precomputations. 
//
//	Consist of a variable number of iterations. For applications with a small key size, the trade-off between the complexity of a brute-force attack and a differential attack make a large number of iterations superfluous. Hence, it should be possible to reduce the number of iterations with no loss of security (beyond that of the reduced key size). 
//
//	If possible, have no weak keys. If not possible, the proportion of weak keys should be small enough to make it unlikely to choose one at random. Also, any weak keys should be explicitly known so they can be weeded out during the key generation process. 
//
//	Use subkeys that are a one-way hash of the key. This would allow the use of long passphrases for the key without compromising security. 
//
//	Have no linear structures (e.g., the complementation property of DES) that reduce the complexity of exhaustive search [4]. 
//
//	Use a design that is simple to understand. This will facilitate analysis and increase the confidence in the algorithm. In practice, this means that the algorithm will be a Feistel iterated block cipher [21]. 
//
//	Most of these design decisions are not new. Almost all block ciphers since Lucifer [5,21] are Feistel ciphers, and all have a flat keyspace (with the possible exception of a few weak keys). FEAL [13,14,15] and Khufu [11] use a variable number of iterations. Khufu [11] has a large number of subkeys that are a one-way function of the key. RC2 [18] has a variable-length key. GOST [6] uses a 32-bit word length and a 64-bit block size. MMB [2] uses a 32-bit word length and a 128-bit block size. 
//
//	BUILDING BLOCKS