1
$\begingroup$

I know restricting access of a file, is a important measure of security.

If we read the Payment Card Industry's Data Security Standard (aka PCI-DSS), we can see a requirement where control access must be applied to mitigate any risk of a sensitive encrypted data be leaked from the system.

Other important requirement define minimum data to be kept encrypted, again mitigating possible leak.

I would like to understand how safe my system is without those mitigations actions. What are the risk on trusting only on Encryption Algorithm.

I would like to know precisely if is considered safe keeping a file encrypted by asymmetric encryption algorithm inside a public & not trusted environment.

How a malicious agent can break file encryption? By brute-force? What are the exactly risks by leaving a encrypted file in a public environment where anyone can read it?

Consider a situation where entropy used to generate the keypair is perfect.

Improve this question
$\endgroup$
5
  • 1
    $\begingroup$ Can you provide a reference for this recommendation ("is not considered safe") that you are asking about? The context would help answer. $\endgroup$
    – bmm6o
    Nov 29, 2022 at 20:11
  • $\begingroup$ Thanks for your feedback, i've edited the post. I've changed it from "is not considered safe" assertment to "is considered safe?" question. $\endgroup$
    – Carl_Dude
    Nov 29, 2022 at 20:22
  • $\begingroup$ You still haven't provided a source for your claim/concern. Are you thinking of an attacker being able to replace encrypted files or something? $\endgroup$
    – samuel-lucas6
    Dec 1, 2022 at 8:23
  • $\begingroup$ I've updated the post, now with a reference. And I was thinking in a situation where public has only read privileges. So I'm not worried by a replace file attack. I'm more worried on the data be submited to a cracking encryption algorithm. $\endgroup$
    – Carl_Dude
    Dec 1, 2022 at 14:02
  • $\begingroup$ Likely no, but the question is not answerable as it stands, for lack of context and security goals. Assuming correct selection and implementation of an encryption algorithm, the confidentiality of data that rests encrypted in a public & not trusted environment depends primarily on the secrecy of the key (of the private key if you use asymmetric encryption), and of the security measures to prevent leak of data when not encrypted. But the integrity of the data is not insured by pure encryption (especially if only public-key encryption is used), and data integrity is typically part of "safe". $\endgroup$
    – fgrieu ♦
    Dec 1, 2022 at 15:07

1 Answer 1

Reset to default
0
$\begingroup$

If you use reputable and open source software to encrypt your files, with a proven and strong encryption algorithm (like AES), and an unguessable secret of at least 256-bit entropy then yes it should be considered safe.

Hackers usually don't break the encryption itself (if conditions above are met). They use the weakest spot. That can be social engineering or installing a backdoor (with keylogger) on the encrypting or decrypting workstation.

There is actually no difference on storing public files or accessing your bank account over https. Both use public channels to exchange private data.

Improve this answer
$\endgroup$
1
  • $\begingroup$ The assertion in the first paragraph is very uncertain given the little context we have. Good encryption (with proper key management and handling of data when not encrypted) gives confidentiality, but (especially, public-key encryption) does not insure integrity, "Safe" typically requires some assurance about data integrity, thus "encrypt your files" is typically not enough. Even authenticated symmetric encryption (e.g. AES-GCM) may not be enough, e.g. it can't prevent rollback to an earlier state. $\endgroup$
    – fgrieu ♦
    Dec 1, 2022 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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