2

Are there encryption algorithms that are "more suited for" (i.e. provide greater security when) encrypting certain types of content?

For example, if I have a PDF file that I need to encrypt, is the fact that the content to be encrypted is in PDF format (as opposed to plain ASCII text or MSWord or .xlsx) a factor in deciding which encryption algorithm to use?

|improve this question
1

The specific file format is irrelevant in encryption. What matters are factors like the medium on which the file is located, the mechanism of access, and to some extent, the size of the file (which applies more to the difference between a hard drive image and a small document file, not so much to the difference between a PDF and a DOCX). If the file is extremely large, ciphers with a small block size (such as Blowfish, IDEA, and CAST5) begin to become less secure. Encrypting any more than 4 GiB worth of data with these ciphers can be dangerous.

While the cipher itself may be quite strong, the mode of operation can make or break a cryptosystem, and these modes are very context-dependent:

  • ECB - Essentially no mode. Each block is encrypted with the same key. Unless you are encrypting a single block, this mode is dangerous and can give rise to the ECB penguin.
  • CBC - Provides little malleability protection, but is usually good for simple confidentiality. There are many attacks against CBC, but they only apply in specific contexts.
  • CTR - Is highly sensitive to nonce reuse and malleability attacks, but is fast and is good for parallelization. This mode turns a block cipher into a stream cipher. CTR actually uses encryption for both encryption and decryption, so two CTR encryptions with the same key cancel out.
  • GCM - Similar to CTR, but authenticated. This provides integrity on top of confidentiality at the expense of some extra space for each message. This is used in networks.
  • XTS - A "tweakable narrow block mode" which is commonly used for block device encryption. It requires double the key size to function, but provides some minimal malleability resistance.

These are the common ones. Some less common ones are XEX, LRW, PCBC, CFB, OCB, OFB, CTS, EME, EME2, and plenty more. They are either much more limited in purpose (PCBC for example is like CBC, but designed such that a single error in encryption or decryption propagates and mangles all future output), or are patented or otherwise hard to use in a broad context legally (such as EME2 and OCB).

To answer your actual question, I would use CBC for that. If your threat model does not involve someone intentionally messing with the encrypted files, and only with preventing someone from viewing the contents, CBC is fine. It is the most common mode for file encryption.

Do not implement crypto on your own

The specific nuances are very hard to get right, and you can easily end up with a very broken scheme despite using well-established primitives. You should use an existing library or program to encrypt your files, like GnuPG. Even using 7zip's encryption feature would suffice.

|improve this answer
  • How are some cipher modes more suited for encrypting pdfs than docx? (which is the provided question) Note I am talking about types of data, not about how such data is then accessed (eg. sequential vs random access). – Ángel Nov 29 '17 at 3:58
  • Oh! I missed that. It seemed to me like he was asking in general about the medium of storage/transmission, not specifically PDF vs DOCX. You're right, the file format itself does not matter, only the medium on which it lies or is accessed. I'll edit my answer. – forest Nov 29 '17 at 4:01
  • Looks like Baal-zebub changed his/her name to @forest :-) Anyway, regarding the file access mechanism and medium on which it is stored, the context of my question is that the file is to be sent in response to a REST API request over HTTP. Does that narrow down the choices? – Ajoy Bhatia Nov 29 '17 at 18:51
  • Yep, changed my name to what I used to use on my old account. If you're transmitting the data over the network, you probably want an authenticated mode like GCM. You can use the libsodium library to securely transfer files. It uses poly1305, which is similar in purpose to GCM. – forest Nov 29 '17 at 18:53
1

No. All modern algorithms (eg. AES) will provide ciphertext indistinguishability, so -if everything is done properly- it doesn't matter the kind of content that you are storing.

Not specific to any encryption algorithm, as it would happen with all of them, but kinda related to the question:

  • Knowing that it is a PDF (or MSWord, or Excel) would allow some known plaintext for someone attacking the encryption (eg. if I was to bruteforce the encrypted file, I could check if the decrypted content with the candidate key starts like PDFs do).

  • Simply applying an "encryption algorithm" may not hide the length of your data. You may want to add some padding to the file (or at least use a block cipher mode).

  • You must use an iv on the files.

  • Remember that you must verify the contents, not only check if it decrypts to "something". On certain filetypes, a blind attack would be possible where the encrypted file could be modified in order to obtain a different output.

|improve this answer
  • This isn't quite correct (see my answer). For example, not all modes even have an IV. What matters far more than encryption algorithm is the encryption mode itself. – forest Nov 29 '17 at 3:39
  • @Baal-zebub I kinda took for granted that some kind of mode was to be used as part of doing everything properly with the algorithm. I still feel that the question points to the algorithm rather than the mode, a caesar-CBC will hardly be secure ;) – Ángel Nov 29 '17 at 3:53
  • Regarding the iv: as Ajoy seems to be to encrypting individual files, he will need an iv or similar. Otherwise, using the same key on several files that same starting blocks (eg. classic Word documents) will leak that information. – Ángel Nov 29 '17 at 3:55
  • I didn't see it that way, since an encryption algorithm includes the cipher primitive and the block mode. And maybe ceasar-CBC will be insecure, but what about double-rot13-ECB?? – forest Nov 29 '17 at 3:55
  • 1
    In the end, if someone is asking this question, the answer should be "don't implement crypto yourself, use a library or an existing program". Since the OP hasn't reached that point yet, I explained why it is more complicated than it seems when deciding how to set up a cryptosystem. – forest Nov 29 '17 at 3:57

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.