New answers tagged file-encryption
What you need to do is encrypt the file(s) before uploading it to the cloud provider, and decrypt them on download. Assumptions You do not want to cloud provider to by able to read (decrypt) these files. You would like something simple to implement Do This Use a symmetric algorithm to encrypt the files. The most common secure algorthm is AES There ...
AES is available in any crypto library. Use AES. Or better than that, use a blackbox library like NaCl or libsodium with the defaults, which was designed by a top-notch cryptographer, meaning you don't have to worry about screwing up the implementation which you are indeed quite likely to do if you try and implement this yourself.
The one that fulfills your requirements. If you just want to upload and download it, don't encrypt it. If you want to encrypt it because encryption sounds so cool, just XOR it with 01010101b. If you want to encrypt it to be secure, define what secure means for you. Do you want to prevent the cloud provider from automatically analyzing your file? Do you ...
Your need is just for storing the file in the cloud and assuming that the key will always be with you and only you. Here is the list of algorithms that you can use: Triple DES RSA Blowfish Twofish AES You can encrypt with anyone of these and upload them to cloud and for decryption, you will only be having the key.
It depends. It comes down to risk management. By placing the payload into the public domain, you're betting against flaws being discovered in the cipher (and/or implementation), along with technology advancing sufficiently to brute-force the encrypted data. If your data loses value over time, the above risks may be acceptable compared to the convenience ...
Yes, but don't do it. If you are asking if it is possible to come up with a proprietary scheme for encrypting data that only your application "knows," the answer is yes, until someone figures out how to reverse-engineer it (which is usually easier than you realize). This sort of practice is known as security by obscurity and is highly discouraged. Instead,...
Assuming the cryptography is implemented correctly, if any the member's keys are exposed or hacked then your data is vulnerable. The more people you have in this distribution, the greater the risk of information disclosure. Also check out this link, Encryption and the "security time decay" of prior encrypted data
I think one of the biggest risks is that somebody is accidentally going to replace an encrypted file with its unencrypted version. Keeping the files in a private place protects against that. It's part of the concept of multilayered security that others have mentioned: when one layer is bypassed, whether maliciously or accidentally, you still have some ...
If you have confidence in the encryption (which you should), depending on your implementation, you might be leaking some kind of metadata, for example: "user A is using the service", or "user B configuration has not been updated since ...", or "a new user C was recently created", or "80% of users recently moved away from the service".
There is always a risk that any given cipher will be broken at some point and data like this will become truly public. So yes there are some risks but it doesn't mean you aren't making a reasonable security trade-off. A few things you may want to consider: What's your worse case scenario with the data going public and are there implications to this data ...
No it's a pretty accepted practice to do this. Once encrypted, there really isn't any harm in having the encrypted file publicly accessible, assuming you've taken all the standard precautions: Don't store the private keys in the same location Routinely audit who has access and remove accordingly
There are several ways to do this but basically you are describing something of a digital rights management problem. There are some open-source DRM programs like OpenIPMP which may help but there are probably other ways to solve your problem without using DRM. https://sourceforge.net/projects/openipmp/ You didn't provide a lot of information about your ...
There is a program that someone developed that is supposed to be able to crack LUKS passwords by utilizing a GPU, but I don't remember what the name of it was at the moment. I'll try to dig it up. Also, there are a couple of programs/scripts around that can crack LUKS passwords(bruteforce-luks and Grond), Both of which can utilize multiple threads(CPU ...
McNerdHair is correct to require you to use an authenticated mode. There are more options than GCM mode though: GCM mode is fast. It is sometimes called a 1.5 pass authenticated mode because of the fast GMAC calculation. It is standardized by NIST. CCM mode is another NIST certified mode specifically created for packet encryption, i.e. transport mode ...
Top 50 recent answers are included