xxtea.zip_Visual_XXTEA_mfc xxtea

// xxtea.cpp : Defines the entry point for the console application. #include "stdafx.h" #define MX (((z >> 5) ^ (z << 2 )) + ((z >> 3) ^ (z << 4))) ^ ((sum ^ z) + (k[e] ^ z)) void xxtea_enc(unsigned long* v, unsigned long* k) { unsigned long z, sum, e, DELTA=0x9e3779b9; unsigned int p,q; q = 32; //6+52/2 sum = 0; z = v[1]; while (q-- > 0) { sum += DELTA; e = (sum >> 2) & 3; z = v[1]; v[0] += MX; z = v[0]; v[1] += MX; } } void xxtea_dec(unsigned long* v, unsigned long* k) { unsigned long z,sum, e, DELTA=0x9e3779b9; unsigned int p,q; q = 32; //6+52/4 sum = q * DELTA; while (sum != 0) { e = (sum >> 2) & 3; z = v[0]; v[1] -= MX; z = v[1]; v[0] -= MX; sum -= DELTA; } } void _tmain(int argc, _TCHAR* argv[]) { unsigned long v[2], k[4]; unsigned long x,y,z; v[0] = 0x00000000; v[1] = 0x00000000; /* k[0] = 0x08040201; k[1] = 0x80402010; k[2] = 0xf8fcfeff; k[3] = 0x80c0e0f0; */ k[0] = 0; k[1] = 0; k[2] = 0; k[3] = 0; xxtea_enc(v,k); printf("%08lX,%08lX:",v[0],v[1]); xxtea_dec(v,k); printf("%08lX,%08lX\n",v[0],v[1]); return; } /* test vectors XXTEA (Corrected Block Tiny Encryption Algorithm) is a variable length symmetric block cipher, published in the paper ¡°Correction to xtea¡± (Wheeler & Needham, 1998). The algorithm can be implemented in under 20 lines of C code, and runs efficiently on most platforms. Several implementations of XXTEA exist in a variety of languages, but implementation errors and lack of clarity in the specification mean that some implementations are incompatible. In an effort to correct this problem I have worked from the reference implementation and common assumptions of other implementations to construct a set of test vectors. The test vectors are given as (key, plaintext, ciphertext) tuples. An XXTEA key is always 128 bits. # 64-bit block 00000000000000000000000000000000, 0000000000000000, ab043705808c5d57 0102040810204080fffefcf8f0e0c080, 0000000000000000, d1e78be2c746728a 9e3779b99b9773e9b979379e6b695156, ffffffffffffffff, 67ed0ea8e8973fc5 0102040810204080fffefcf8f0e0c080, fffefcf8f0e0c080, 8c3707c01c7fccc4 # 96-bit block ffffffffffffffffffffffffffffffff, 157c13a850ba5e57306d7791, b2601cefb078b772abccba6a 9e3779b99b9773e9b979379e6b695156, 157c13a850ba5e57306d7791, 579016d143ed6247ac6710dd # 128-bit block aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, 0102040810204080fffefcf8f0e0c080, c0a19f06ebb0d63925aa27f74cc6b2d0 9e3779b99b9773e9b979379e6b695156, 0102040810204080fffefcf8f0e0c080, 01b815fd2e4894d13555da434c9d868a # 160-bit block 0102040810204080fffefcf8f0e0c080, 157c13a850ba5e57306d77916fa2c37be1949616, 51f0ffeb46012a245e0c6c4fa097db27caec698d # 192-bit block 9e3779b99b9773e9b979379e6b695156, 690342f45054a708c475c91db77761bc01b815fd2e4894d1, 759e5b212ee58be734d610248e1daa1c9d0647d428b4f95a # 224-bit block 9e3779b99b9773e9b979379e6b695156, 3555da434c9d868a1431e73e73372fc0688e09ce11d00b6fd936a764, 8e63ae7d8a119566990eb756f16abf94ff87359803ca12fbaa03fdfb # 256-bit block 0102040810204080fffefcf8f0e0c080, db9af3c96e36a30c643c6e97f4d75b7a4b51a40e9d8759e581e3c40b341b4436, 5ef1b6e010a2227ba337374b59beffc5263503054745fb513000641e2c7dd107 Updated 2007/09/12 John Kendall has contributed test vectors for messages that are not a multiple of 64 bits. While the XXTEA specification does not handle such cases it is possible to pad any message to a suitable length; John¡¯s test vectors use zero padding. I have reproduced them here in the format of my original test vectors: # 8-bit message, zero-padded to 64-bit 6a6f686e636b656e64616c6c6a6f686e, 4100000000000000, 014e7a34874eeb29 # 16-bit message, zero-padded to 64-bit 6a6f686e636b656e64616c6c6a6f686e, 4142000000000000, e9d39f636e9ed090 # 24-bit message, zero-padded to 64-bit 6a6f686e636b656e64616c6c6a6f686e, 4142430000000000, d20ec51c06feaf0e # 32-bit message, zero-padded to 64-bit 6a6f686e636b656e64616c6c6a6f686e, 4142434400000000, b1551d6ffcd4b61b # 40-bit message, zero-padded to 64-bit 6a6f686e636b656e64616c6c6a6f686e, 4142434445000000, 0ff91e518b9837e3 # 48-bit message, zero-padded to 64-bit 6a6f686e636b656e64616c6c6a6f686e, 4142434445460000, 7003fc98b6788a77 # 56-bit message, zero-padded to 64-bit 6a6f686e636b656e64616c6c6a6f686e, 4142434445464700, 93951ad360650022 # 64-bit message 6a6f686e636b656e64616c6c6a6f686e, 4142434445464748, cdeb72b9c903ce52 Zero padding is adequate for text messages (which cannot contain the character NUL = 0¡Á00), but in a binary context it is not a reversible padding scheme. If your data can include the byte 0¡Á00 I would recommend the ¡°Pad80¡å scheme in which you always add a single ¡°1¡å bit to your data (even if the data is already a multiple of the block length) then pad with ¡°0¡å bits to a multiple of the block length. This padding can always be reversed without confusion. */