Currently i am encrypting sensitive files using the following OpenSSL Command:
openssl aes-256-cbc -a -salt -in large_file.zip -out large_file.zip.enc
and to decrypt:
openssl aes-256-cbc -d -a -in large_file.zip.enc -out large_file.zip
This is working fine so far, but being as i don't have much experience with encryption and cryptography i'm looking for some insight into if this is the best way to do things.
Am i encrypting/decrypting the file correctly?
Am i making full use of AES-256 this way?
Am i doing something wrong here that may impact the security of the encrypted file?
Comments/Replies are greatly appreciated.
Daniel.
PS: I'm not quite sure if this belongs in superuser or stackoverflow, please advise.
It can be secure, given the password is secure enough, and given that you only expect confidentiality. It is impossible to say if anything is secure without the use case, threat model and specific system setup though.
The OpenSSL password based key derivation methods are secure, and so is AES-256 in CBC mode. That said, modern crypto often uses some kind of integrity/authentication as in a secure mode of encryption such as GCM or by adding a MAC (using a separate key).
It's more something for http://security.stackexchange.com, although you may get closed/voted down if you don't show enough research etc.
Related
I have a 200GB encrypted file as aes256.
I believe the password is one of 10 however it takes 5+ hours to decrypt currently before it gives an archive failed message in terminal.
my command is:
openssl enc -in ~/path/file.tgz.aes256 -aes-256-cbc -d -k password | tar -zxv -C ~/Desktop/location/
Is there a command I can run to quickly test archive with different passwords to ascertain the right password to use (brute force, essentially, but with a library of 10 passwords).
Decrypt the first part of the file data specifying no padding, it will need to be a multiple of the block size (16-bytes for AES). Then check if the decryption succeeded by looking at the decrypted data. It will either be what looks like random bytes or the correct data.
But your decryption is very slow, I can decrypt 200MB/s on an iPhone so 200GB would only take about 15 minutes plus the time to read the 200GB from disk. You may need to find another implementation that takes advantage of the Intel AES instructions (AES-NI). Software only decryption can be up to 1000 times slower.
On a unix system, I encrypt a file file1 using OpenSSL AES-256-CBC: openssl aes-256-cbc -a -salt -in file1 -out file1.enc -k secret
The decryption is done via openssl aes-256-cbc -d -a -in file1.enc -out file1.dec -k secret
Is there a way to verify that, before actually starting the decryption process, the secret is correct?
My research has not shown any helpful results so far.
If all you have is the encrypted data it is impossible to determine if the key is correct prior to decryption. It is also impossible to determine if the key was correct after decryption other than by examining that the data make sense, is what you expect.
You would have to add some other method to determine if the key is the correct one.
What you are asking for is a check for integrity and/or authenticity. AES in CBC mode does not provide these features, only plain encryption/decryption.
If you need it you should switch from CBC to GCM mode. It provides authenticity and integrity check while decrypting. Therefore if the decryption succeeds you are sure that the decryption result is correct.
If this is your entire system, then no, OpenSSL does not have any mechanism to check the password prior to decryption (or in many cases even after decryption). You can build such a system, however, and can even build it out of OpenSSL if you're restricted to that.
If we were building it out of OpenSSL, then the absolute simplest way to solve it is to just encrypt some know piece of data with the same password. Glue the encrypted known-plaintext and the encrypted actual-plaintext together. You can glue them together many ways; the simplest in commandline form would be to stick them in separate files and then tar them together.
When you're ready to decrypt, tear them back apart, and try to decrypt the known-plaintext. If it decrypts correctly, then you're golden and you can decrypt your real data.
OpenSSL does not have a particularly strong KDF, so this approach can make brute-force password cracking a bit easier (though no easier than if your file has some known header).
This doesn't ensure that the ciphertext is unchanged, however. An attacker could still have modified it and OpenSSL won't always know. There are ways to fix that problem by modifying the format further, but again openssl doesn't provide any direct way that I'm aware of. The best approach here would depend on your exact constraints.
what is difference between symantec command line pgp encryption and other pgp encryption tool like iGolder,GnuPG etc.
Is it possible that a file pgp encrypted by symantec command line that can be decrypt by other tool like iGolder,GnuPG, bouncy castle etc.
In general, compatibility between various OpenPGP applications and libraries is achieved by using the algorithms defined in the RFC 4880. This means that if Symantec PGP follows OpenPGP standard and doesn't use proprietary patented extensions (they do exist), the resulting file would be handled by other applications.
The other thing to check is that the algorithm used by the originating application is supported by the software that decrypts the file later. For modern versions this is not an issue, but some companies use the dated versions of PGP software, which doesn't handle some of the newer algorithms. In this case you can have an issue.
I've got a situation where the source system has PGP installed, and they can only encrypt the file with PGP tool, and Target System has GPG installed, and we can decrypt only using GPG. is is possible to accomplish this functionality ?
The thing with encrypting is the encryption algorithm you're using. These algorithms are published and documented - and that means anyone can write code to implement it.
PGP is a piece of software written to implement a crypto algorithm. GPG is the Gnu implementation of the same.
So there's no reason to think this wouldn't work - as long as you use an algorithm that both products support. I believe GPG has more options than PGP.
From:
http://en.wikipedia.org/wiki/GNU_Privacy_Guard
As of versions 2.0.26 and 1.4.18, GnuPG supports the following algorithms:
Pubkey: RSA, ElGamal, DSA
Cipher: IDEA (from 1.4.13/2.0.20), 3DES, CAST5, Blowfish, AES-128, AES-192,
AES-256, Twofish, Camellia-128, Camellia-192, Camellia-256 (from 1.4.10/2.0.12)
So as long as your encrypting application uses one of these it should work fine. (RSA is probably a pretty good bet.)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am writing a package in R and would like to protect/crypt the code. Basically, when looking into my package code, it should be crypted and not readable. I have read that someone has crypted his code(1), however I haven't found any more information about that. I know I could just write the code in C/C++ and compile it, however I would like to let it in R and just "protect" it there.
My question is: Is this possible, how is this possible?
I appreciate your answer!
Reference:
(1) link
Did you try following that thread?
https://stat.ethz.ch/pipermail/r-help/2011-July/282717.html
At some point the R code has to be processed by the R interpreter. If you give someone encrypted code, you have to give them the decryption key so R can run it. Maybe you can hide the key somewhere and hope they don't find it. But they must have access to it in order to generate the plain text R code somehow.
This is true for all programs or files that you run or view on your computer. Encrypted PDF files? No, they are just obfuscated, and once you find the decryption keys you can decrypt them. Even code written in C or C++ distributed as a binary can be reverse engineered with enough time, tools, and clever enough hackers.
You want it protected, you keep it on your servers, and only allow access via a network API.
I recently had to do something similar to this and it wasn't easy. But i managed to get it done. Obfuscating and/or encrypting scripts is possible. The question is, do you have the time to devote to it? You'll need to make sure whichever "obfuscation/encryption" method you use is very difficult and time consuming to crack, and that it doesn't slow down the execution time of the script.
If you wish to encrypt a Rscript code fast, you can do so using this site.
I tested the following rcode using the aforementioned site and it produced a very intimidating output, which somehow worked:
#!/usr/bin/env Rscript
for (i in 1:100){
if (i%%3==0) if (i%%5==0) print("fizzbuzz") else print("fizz") else
if (i%%5==0) print("buzz") else
print(i)
}
If you do have some time on your hands and you wish to encrypt your script on your own, using your own improvised method, you'll want to use the openssl command. Why? Because it appears to be the one encryption tool that is available across most, if not all Unix systems. I've verified it exists on Linux (ubuntu, centos, redhat, mac), and AIX.
The simplest way to use Openssl to encrypt a file or script is:
1. cat <your-script> | openssl aes-128-cbc -a -salt -k "specify-a-password" > yourscript.enc
OR
2. openssl aes-128-cbc -a -salt -in <path-to-your-script> -k "yourpassword"
To decrypt a script using Openssl (notice the '-d'):
1. cat yourscript.enc | openssl aes-128-cbc -a -d -salt -k "specify-a-password" > yourscript.dec
OR
2. openssl aes-128-cbc -a -d -salt -in <path-to-your-script> -k "yourpassword" > yourscript.dec
The trick here would be to automate the supply of password so your users need not specify a password each time they wanted to run the script. Or maybe that's what you want?