Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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.)

share|improve this question
1  
Currently, I’m asking myself why you think AES256 in itself would not provide enough security in itself. Ignoring that, and not having enough time on my side to write up a complete answer, I’ll just drop that the first thing that immediately rings my alarm bell is: “The key is repeatedly used.” (Besides that, there are a few other potential issues, but I’m sure someone will mention them in his/her answer.) –  e-sushi Jul 17 at 17:02
    
@e-sushi That's true, though one aspect of what I was wondering is if the fact that the only thing it's repeatedly used on is binary (AES encrypted) output, does that pose as much risk? Every time I hear it mentioned it's always under the context of no previous encryption used, but rather just on some plain text file. Also thanks for the comment! And np on the time. Edit: It's not that I doubt the security of AES, but rather a curiosity question about the use of xor with a repeated key/cipher in this context as opposed to what it's usually brought up in. –  Thomas F. Jul 17 at 17:06
    
As they’re somewhat related – so, maybe the answers to this question and/or this question can provide some additional insights… –  e-sushi Jul 17 at 17:10
1  
@e-sushi Thanks for the references, I'll have a look at those as well! –  Thomas F. Jul 17 at 17:13
2  
@e-sushi I read through those two posts, and am adding some more clarification. They were an interesting read as well, ty! –  Thomas F. Jul 17 at 17:44

2 Answers 2

up vote 2 down vote accepted

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).

share|improve this answer
    
This makes a good point, using a second encryption scheme which is a strong contender with AES would make sense to increase security significantly as opposed to re-inventing the wheel (or at least making my own "wheel"). Would +1 but can't due to rep. However, the linked post isn't quite accurate to the situation. They all deal with educated guessing or suspecting common phrases in the unencrypted text, where as I am encrypting something then performing a two+ pad on it. The underlying bits wouldn't really be "guessable" as far as I know? Still a good read, though. –  Thomas F. Jul 17 at 19:29
    
Also should be noted I'm not interested in implementing this, and will more than likely just add another layer of security if I went that route (I trust AES so I don't really think it's a huge issue), but the way I see it still is even if they were able to get 100 of the files that were represented in the encrypted files as well (Through finding them on the drive, not decryption), it still wouldn't really help them break the XOR pad since there's still a layer of AES separating it. Or am I looking at that wrong? Thanks for the answer, as well! –  Thomas F. Jul 17 at 19:32
    
@ThomasF., whether those attacks in particular would apply would depend on how AES would be broken. For example, if the attacker knew how to discern patterns in AES output, that might be analogous to knowing patterns in English. –  otus Jul 17 at 19:32
    
That's true, in which case my previous (second) comment would be rendered moot as they could then use those 100 files to essentially guess between the layer of AES. –  Thomas F. Jul 17 at 19:33

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.

share|improve this answer
    
This is actually closer to the kind of insight I was looking for with it. While it wouldn't be breakable, it would be more difficult in cases where AES was sufficiently weakened. Also in the example AES is applied first. I was merely intending to use this as a pad over AES. I actually came up with a new method for padding the AES which involves 3 keys and a block number. It's essentially a one-time pad for each file, that gives each 192-byte block it's own unique xor key/cipher. I made a rough implementation of it here: pastie.org/private/qjghdungunlbs64qakdgva# (C#) –  Thomas F. Jul 18 at 17:58
    
Also still not sure what is implemented in that link is really a one-time pad. It's unique for the file, and the 192-byte blocks inside of it, but it's not completely random, though the third key changes with each file, and each block gets it's own unique key due to the block number (I can't make it random without storing a -ton- of data) –  Thomas F. Jul 18 at 18:49
    
Uhh that makes it not a pad. –  Joshua Jul 18 at 19:53
    
What would the proper terminology for it be? And how weak would it be? As I said in my main post, I'm not extremely experienced with all of this, I mostly wrote that to experiment with stuff and see what I could do. It's not exactly a pad, no, but I'm not intending to use it as full on encryption either. Also, would you mind commenting on the strength of that implementation? Thanks. –  Thomas F. Jul 18 at 21:18
    
Am I correct in assuming the implementation I linked is closer to a stream cipher? en.wikipedia.org/wiki/Stream_cipher (couldn't edit my last one, was past 5 min :/ ) –  Thomas F. Jul 18 at 21:28

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.