-5

this forum is way above me and the members here are far, far smarter than I am, so this probaby isn't the place to ask such a simple question, but whatever.

All I wanted to ask is for at rest encryption, like something on your cloud account, I like to encrypt my files. I either use Serpent 256 or AES 256. The program I use is SSE File Encryptor.

As long as you have a very good password, your files should be secure right? And is there a program I should be using rather than SSE File Encryptor? (It's free, hence me using it)

Thanks and I apologize for such a lame question.

Ian

Ievgeni
  • 2,585
  • 1
  • 10
  • 32
Ian
  • 1

1 Answers1

0

I don't really know anything about this particular program. The problem is

encrypt with AES-256

is really under specified. Which mode of operation? Where does the IV/Nonce come from? How do they authenticate the ciphertexts? These are all important questions.

To find out we might try to look at their "specifications". The problem is: They do not answer all of those questions and the answers we get do not inspire a lot of confidence.

S.S.E. File Encryptor - Format Specifications

It starts with the fact that the first step is compression of the data. At least from a theoretical standpoint, that's a big nono. Unless the files are repadded to a fixed length after compression (which would make it pointless) compressing the plaintext before encryption breaks any indististinguishability-based security notion for encryption, such as CPA or CCA security. This is because the size of the resulting ciphertext now leaks information about the file's content rather than just about the size.

It then adds unexplained 32 byte blocks before and after the plaintext before encrypting. This is rather weird, however together with the specification that they use CBC mode, a non-authenticated mode of operation, and do not specify the existence of a MAC anywhere leads me to the conclusion that they were trying to construct some kind of homebrew ad-hoc authentication mechanism. Probably comparing the decrypted first and last block after decryption. This does not offer any kind of real authentication. You can easily change parts of a CBC ciphertext without affecting the first and last block. (I'm sure they're going to argue that everything is fine because decompression might fail if I blindly change parts of the file. In general that's bollocks and there is no formal argument to support this! This means that the ciphertexts are most likely not authenticated at all which means files in storage can be modified without you noticing when you decrypt.

Finally, they do not specify where the IV for the CBC-mode comes from. However this is crucial information, since the IV for CBC mode needs to be unpredictable, otherwise CBC-mode is completely broken. The fact that they do not realize that this would be an important part of the specification does not bode well.

Maeher
  • 6,818
  • 1
  • 33
  • 44
  • 2
    +1, though it seems that since the data is at rest instead of in transit, the compression part may not be such a big deal. Depending on who has access to it and what kind of data it is, it may not be catastrophic (or maybe it is). – Ella Rose Feb 13 '18 at 04:06
  • @EllaRose That's hard to say. It definitely breaks CPA security of CBC-AES-256 which is the basis you would generally want to base the security argument for the whole system on. So, yes it's not an immediate attack, but it's pretty shaky. – Maeher Feb 13 '18 at 04:17
  • Wow... that's one hell of an answer. Most of it went over my head however, the one thing that I did take away from it was that SSE isn't a safe program to use if someone knew what they were doing and wanted to get into my files. How about a program like Advanced Encryption Package 2017? http://www.aeppro.com/products/aep.shtml That's a paid alternative to SSE. I'm not sure if it authenticated encryption or not. However, if it does, then my question to you all is, what program do you all use to encrypt your files that are at rest? Thank you SO much for your all your input. – Ian Feb 13 '18 at 19:03
  • 1
    I don't know, have you tried to read the whole page? – Quark Feb 14 '18 at 13:30
  • the size of the compressed plaintext is almost exactly as useful as the size of the uncompressed plaintext 2) the "unexplained 32 byte blocks" are actually explained in the picture you included in the answer 3) a constant IV doesn't affect security unless chosen plaintext attacks are possible (and the salt mentioned in the picture suggests that they aren't) (unless we assume the salt is constant because they haven't told us how they generate it, as you assumed for the IV)
    • – the default. Jan 21 '21 at 03:40