How secure is using a pad (using xor) on a encrypted data, for the purpose of obfuscating/hiding the underlying encryption?

Question

Edit: I know this isn't really a one time pad (as pointed out), though I don't really know what to call it aside from just a pad, I guess.

I have been reading around (mostly various stackexchange sites, wiki and a few blogs/forum posts) about encryption and various techniques. I have read that doing a pad using XOR isn't secure unless the key is as long as the input, is sufficiently random, and not reused. They reference things such as the plain text being revealed in part may lead to being able to break the pad key, or repeated use may give away patterns, insufficient length (aka: reuse) may give away patterns, etc.

Now, I don't know a whole lot about encryption, but have been reading up on it of late. Let's say I have an application that performs this process on a group of files, maybe hundreds or thousands:

(in order)

• The file is read into memory in chunks
• The chunk is encrypted using AES256 and a randomly generated key.
• The chunk is padded with xor using a different key than was used to encrypted.
• The chunk is written to a different destination (say another drive).
• Repeat for each file in the list.
• The out put name and path to the file have absolutely no relevance to the original file.
• No temporary file is written to the drive containing the unpadded encrypted file.

Assuming the following:

• The pad key is 4096 bytes long. (Arbitrary number, nothing significant.)
• The pad key is sufficiently random, using a good source of entropy and unlikely to be attacked by that route.
• The file being encrypted is far larger than the key, sometimes several GB in size.
• The key is repeatedly used. Both in files that are longer than the key, and the other files the process is performed on.
• The key key used in the xor is destroyed, or otherwise inaccessible to the attacker.
• The attacker does not know the size of the key. At most they know it's been padded with xor.
• The attacker has no access to the plain encrypted file or, of course, the unencrypted data.
• The key is never used to pad anything other than the AES256 encrypted output.

Now normally I would say reusing a key would be a bad idea, and I would think made worse by the fact that it's so short and the input file could be very large. But, to my questions:

1. Would a previously AES encrypted file be more secure with a pad using XOR under the previous assumptions?
2. Would there be any way for them to tell that this is padded this way short of finding the application, or person, who encrypted it and seeing/asking the process that was done.
3. If they did know that it was XOR padded with the underlying encryption being AES, would they even be able to proceed?

With plain text being the known underlying file, I could see key reuse posing a problem with being able to crack the contents by looking for patterns. But seeing as how I can encrypt a file with AES and come up with different encrypted output every time, and the output is binary, I'm wondering if this is even an issue?

It should be noted, I am mostly posing this from a curiosity standpoint. Though, I have considered implementing this in an application, but mostly for seeing if I can efficiently. Plus the idea of obfuscating the encrypted file further under the mindset of "You can't attack what you can't find" doesn't sound bad.

Edit

e-sushi referenced two posts: Breaking Double Encryption and Double Encrypting with two different keys

I agree with the principle mentioned, that it should be assumed an attacker knows the encryption scheme, and that the security should be in the encryption algorithm and not obscurity. Though my main goal is, in a sense, to perform a fast and simple form of double encryption (though xor is not really strong encryption unless it's as long as the output and used only once. Unfortunately this would be impractical in my example scenario as I would literally need another drive to store the keys used to xor the files due to size alone.)

My main point with this is to find out if this method is insecure due to repeated key use, even though the key is used on the output of the AES algorithm, which is binary data (not plain text or anything like that). As well as get clarification as to why that would be insecure, as the way I'm seeing it in my head is there is no way to know what the underlying data is until you remove the XOR layer. Furthermore, if you knew the underlying encryption beneath the XOR layer was AES, how would you be able to determine that you had actually found the XOR key to know you had the valid AES encrypted data?

I can of course see how simply XOR encrypting a lot of files with the same key would be bad, especially if said files were plaintext. However, I haven't seen any examples using XOR in this fashion (as in, on the binary output of something like AES, whose output is not the same every time even if you encrypt the same data.)

Answer 1

There are two possibilities here:

1. AES is secure, in which case no one can open your encryption without knowing your keys, regardless of whether you layer anything else on top of AES.

2. AES is not secure and someone knows how to break it. In that case the security of your encryption might only be as strong as the second layer of encryption.

In neither case would you be significantly better off with a repeating pad, which isn't a strong way to encrypt something. (It's essentially a two+ time pad.)

In the second case you could be better off if you used another layer of strong encryption that the attacker cannot break. Perhaps Twofish or Serpent (both AES runners up), or Rabbit or Salsa20 (eSTREAM winners).

Answer 2

Merely stacking weak crypto (this is a very well-done weak crypto) inside strong crypto does not add any significant strength to the strong crypto.

I've studied interleaving crypto, and there are some cases where interleaved weak crypto would significantly strenghten already strong crypto, but AES is too hard for me to interleave without breaking it.

Now here's where it gets interesting. What happens if AES is applied first then the pad? The standard attack on the two-time pad won't work anymore (but the crypto is still weak). If AES were to really fall this setup wouldn't last long but if it's been merely weakened (say 96 effective bits) the outer layer is sufficient to require a custom attack. It's still the same order more or less but they'd have to retool and that might save you long enough.