GPG and PAR2 error correction data from the plain archive, will it compromise security?

I have the following scenario:

• Archives compressed with 7z, hundreds of MiB in size
• GPG to encrypt the archives (binary, without ASCII armor)
• PAR2 to create error correction data

Question

1. Encrypted archive + plain archive error correction data

If I encrypt the archive, will it compromise the security of the GPG-encrypted data if the error correction data created before the encryption will be stored along with the encrypted archive?

2. Encrypted archive + encrypted archive error correction data

As an alternative, would it be better to calculate the error correction data from the encrypted data after encryption and would this in any way affect security (common sense tells me no, but you never know).

Why?

Rationale

I need to archive the data in question and want to make sure it can be restored even if it gets damaged in some way. But all of that of course without compromising security.

-
The question should state more clearly if the PAR2 data is created from the GPG-encrypted archives, or from the archives. The order in the question's intro suggests the former, but the text in the question suggest the later, and this answer assumed the later. –  fgrieu Apr 18 '13 at 11:26
@fgrieu: in scenario one it would be from the plain archive data, in scenario two from the encrypted. Edited. –  0xC0000022L Apr 18 '13 at 12:04

Yes, precisely because of what you're using PAR2 for.
Anyone with the PAR2 data and most most of the compressed
archives can easily calculate the rest of the compressed archives.
(In fact, they wouldn't even need the encrypted data!)

Yes, because anyone could calculate the error correction
data from the encrypted data, without the encryption key.

-
so you are saying the encrypted archives along with the error correction data of the plain archives can be used to break the GPG encryption? (1) but the other (2) is secure? How can the error correction data be leveraged in breaking the encryption? Technically it's not plain text. This is why this question seemed intriguing to me. –  0xC0000022L Apr 18 '13 at 12:06
@0xC0000022L: I concur with Ricky Demer that adding an unencrypted PAR2 file computed from the unencrypted archive(s) is bad/unsafe, in that it reveals something about the real data (beside its compressed size). In particular, someone with the PAR2 archive could tell if an alleged unencrypted version of the (compressed) data is genuine, or not, by applying PAR2 to that, and comparing it against the real PAR2. This is somewhat like revealing the unencrypted MD5 of some plaintext leaks info on the plaintext; only much worse. –  fgrieu Apr 18 '13 at 13:09
@fgrieu: that's what the Why? is for, because I am really interested in why it is bad, if it's bad. Neither answer so far addresses that. –  0xC0000022L Apr 18 '13 at 13:27
@0xC0000022L: We do not say that the PAR2 file allows to recover the archive. When modern crypto promise confidentiality, it is meant that NOTHING about the plaintext leaks (except perhaps its size). That an adversary is able to tell if something is the plaintext, or not, is in itself an attack. Why? Joe Hacker might be annoyed if a prosecutor has a much more convincing argument than "size match" that what's been seized on Joe's PC matches some recent movie release. The UNencrypted PAR2 file, SINCE it has a direct relation to the unencrypted data (compressed or not), can become that argument. –  fgrieu Apr 18 '13 at 14:13
Incidentally, the second (and third) sentence(s) of this answer address(es) $\hspace{2 in}$ why the first candidate method is bad. $\:$ –  Ricky Demer Apr 18 '13 at 17:36
The first alternative considered in this answer will work as long as the user makes sure that each file is encrypted separately and that each ciphertext is stored as its own file. $\:$ –  Ricky Demer Apr 18 '13 at 17:46