3
$\begingroup$

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.

Improve this question
$\endgroup$
2
  • $\begingroup$ 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. $\endgroup$
    – fgrieu ♦
    Apr 18, 2013 at 11:26
  • $\begingroup$ @fgrieu: in scenario one it would be from the plain archive data, in scenario two from the encrypted. Edited. $\endgroup$
    – 0xC0000022L
    Apr 18, 2013 at 12:04

2 Answers 2

Reset to default
1
$\begingroup$

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.

Improve this answer
$\endgroup$
5
  • $\begingroup$ 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. $\endgroup$
    – 0xC0000022L
    Apr 18, 2013 at 12:06
  • $\begingroup$ @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. $\endgroup$
    – fgrieu ♦
    Apr 18, 2013 at 13:09
  • $\begingroup$ @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. $\endgroup$
    – 0xC0000022L
    Apr 18, 2013 at 13:27
  • $\begingroup$ @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. $\endgroup$
    – fgrieu ♦
    Apr 18, 2013 at 14:13
  • $\begingroup$ Incidentally, the second (and third) sentence(s) of this answer address(es) $\hspace{2 in}$ why the first candidate method is bad. $\:$ $\endgroup$
    – user991
    Apr 18, 2013 at 17:36
2
$\begingroup$

You could GPG-encrypt both the .7z archive and the PAR2 error-correction data. That will take care of the security issues.

Alternatively, you could compute the PAR2 error-correction data on the results of the GPG encryption, for the reasons Ricky Demer explains. That would be secure too.

Either one works.

Improve this answer
$\endgroup$
3
  • 3
    $\begingroup$ The order: compress; then encrypt; then protect with PAR2 is sound. But I think there might be a problem with the first alternative considered in this answer: compress; then protect with PAR2; then encrypt. Any minor corruption in the archives will prevent their decryption in full (or at least from the point of the error), and PAR2's ability to deal with multiple minor corruptions in the archives will not be used; I fear this makes the system more likely to loose data. Either variant is safe from a confidentiality standpoint. $\endgroup$
    – fgrieu ♦
    Apr 18, 2013 at 11:23
  • $\begingroup$ @D.W.: I agree with fgrieu, from the redundancy standpoint the second option seems safer. $\endgroup$
    – 0xC0000022L
    Apr 18, 2013 at 12:12
  • $\begingroup$ 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. $\:$ $\endgroup$
    – user991
    Apr 18, 2013 at 17:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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