rijndael

The big hex blocks you see in the code most probably are S-boxes, a concept common to many encryption algorithms.
See the Rijndael page on Wikipedia for more info on the general layout of the algorithm.

If you're looking for an encryption algorithm to use you might also want to look into Tea (tiny encryption algorithm) or XTea. While it might not be as new as AES, it's fast and robust, plus the code to implement it is *tiny*. The reference implementation is public domain too, which is nice.

XTea

I like the concept of XTEA.

These algorithm work on fixed block sizes so that the size of the file has to match a multiple of those blocks. Are there tiny encryption algorithms that support arbitrary file lengths and password lengths?

Quote:

Original post by Lode These algorithm work on fixed block sizes so that the size of the file has to match a multiple of those blocks. Are there tiny encryption algorithms that support arbitrary file lengths and password lengths?

Why not append zero-bytes until your data is block aligned?

cu,
chris

Quote:

Original post by Christian Weis Quote: Original post by Lode These algorithm work on fixed block sizes so that the size of the file has to match a multiple of those blocks. Are there tiny encryption algorithms that support arbitrary file lengths and password lengths? Why not append zero-bytes until your data is block aligned? cu, chris

Just appending zero will get you confused if the data actually contains zeros at the end. What I've done before is store the length at the start of the file, then the encrypted file padded out to the required size. At load time you can then decrypt and strip off the extra info.

You can also avoid confusion over padding by adding e.g. a 0x01 byte and then adding some number (0 up to blocksize-1) of 0x00 bytes to pad it to the block size - that's perfectly reversible, unlike when you only use 0s.

Quote:

Original post by Excors You can also avoid confusion over padding by adding e.g. a 0x01 byte and then adding some number (0 up to blocksize-1) of 0x00 bytes to pad it to the block size - that's perfectly reversible, unlike when you only use 0s.

It's not reversible if your file just happens to fit without padding, and the last few bytes are 0x01, 0x0, 0x0. It's far easier just to include the actual file size at the start of the data.

Padding with known data reminds me of a known-plaintext attack. Instead you should pad with random data. Store the actual length of your file with the data, as OrangyTang suggested.

Quote:

Original post by OrangyTang Quote: Original post by Excors You can also avoid confusion over padding by adding e.g. a 0x01 byte and then adding some number (0 up to blocksize-1) of 0x00 bytes to pad it to the block size - that's perfectly reversible, unlike when you only use 0s. It's not reversible if your file just happens to fit without padding, and the last few bytes are 0x01, 0x0, 0x0. It's far easier just to include the actual file size at the start of the data.

(Oops, didn't notice your response before)
I think I may have been unclear, but that's why you have to always add the 0x01 byte (and then pad with zero or more 0s). If the original data would have fit precisely with no padding, it's going to get expanded to have a new block that starts with 0x01. It's reversible since you strip off any 0s at the end, and then strip off the guaranteed 1 at the end, and will get the original back. On average it's only an increase of one byte (or one bit, if you pad with bits instead of bytes), so it's slightly better than prefixing the length if you care immensely about space.

Quote:

Padding with known data reminds me of a known-plaintext attack.

It doesn't seem quite the same, since you've got the entire message acting as the initialisation vector [smile]

Quote:

Original post by Excors Quote: Padding with known data reminds me of a known-plaintext attack. It doesn't seem quite the same, since you've got the entire message acting as the initialisation vector [smile]

True with hashes, digests, and certain stream encryptions, but not with block encryption techniques. Don't rely on it.

Quote:

Original post by Wyrframe Quote: Original post by Excors Quote: Padding with known data reminds me of a known-plaintext attack. It doesn't seem quite the same, since you've got the entire message acting as the initialisation vector [smile] True with hashes, digests, and certain stream encryptions, but not with block encryption techniques. Don't rely on it.

If you properly use Block Cipher Modes of Operation, you don't have to worry about any problems with the method of "append 0x01 then fill to block size with 0x00" and it is the generally accepted method of padding data to fit a block size. Even if you store the file's size, you have to fill the last block with something, and many ways of filling it make the encryption algorithm less secure, unlike this simple method.

Edit: Browsing through Wikipedia, apparently a technique called Ciphertext Stealing allows you to avoid both of these methods.