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.
Related
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.
I have a 3 Disk RAIDz1 Pool, encrypted with AES128 in GEOM_ELI, that I have been using in FreeNAS since version 8.
There have been many zpool upgrades, and over all I am very happy with ZFS.
Lately however I have been growing frustrated with FreeNAS. Largely many bugs that haven't been fixed over the years. But overall its the INSISTING on me using a Flash drive for their os, even though most of it is read only.
It's still a Single point of failure and has always extended boot times by several minutes. Bottom line, I just want to use Vanilla FreeBSD with this pool.
I am looking for more flexibility and a I wish to educate myself with this awesome Operating System.
Doing some more extended research I have found many tutorials on installing FreeBSD naively to a ZFS volume and mounting it as /
It wasn't till I did more research and found an article on mounting a zfs encrypted volume as root. Later I found that FreeBSD 10 does this during installation, which is awesome to say the least.
Tutorial I used
I made a VM With VMWare workstation, with three 2TB Drives, passed through as Physical Disks, and followed every step to a T and everything worked out very well. Now that I had a better grasp on the commands I was doing and why I was doing them, I wanted to do this to an already existing pool, that has a lot of data already on it.
By Default, FreeNAS Creates a 2GB SWAP partition at the front of every data disk. I removed the swap space and made it 1.5GB partition on each drive with 512MB remaining for Swap. I followed through every step, changing things as needed. (I have 3 disks, tutorial speaks of 4, My pool name is foxhole, the tutorial is zroot.) I was successful in decrypting my volume with geom_eli and mounted it successfully.
I did not skip any steps provided. I even copied every command I was given and altered them in a text file so they would suit my case.
Here is my problem now.
After finally restarting to test everything, The kernel begins starting, then I am spat at a mountroot terminal. It seems that geom_eli didn't make an attempt to decrypt my root volume. I have a suspicion why. Correct me if I am wrong.
At the start of the tutorial, I am given commands to create new geoms for the encrypted volume:
geli init -b -B /boot/zfs/bootdir/da0p4.eli -e AES-XTS -K /boot/zfs/bootdir/encryption.key -l 256 -s 4096 /dev/da0p4
geli init -b -B /boot/zfs/bootdir/da1p4.eli -e AES-XTS -K /boot/zfs/bootdir/encryption.key -l 256 -s 4096 /dev/da1p4
geli init -b -B /boot/zfs/bootdir/da2p4.eli -e AES-XTS -K /boot/zfs/bootdir/encryption.key -l 256 -s 4096 /dev/da2p4
Since my volume already exists, I cant perform those commands that would have created "/boot/zfs/bootdir/daXp4.eli" files.
I am really just guessing at this being the cause.
I noticed this when i attempted to perform:
mv bootdir/*.eli bootdir/boot/
Gave me "No Match."
I assumed those would have been created when the pool was decrypted.
I apologize for this post. I am trying to give as much info as I can without giving too much. I have been working on this for the last 18 hours. I would really love someone with a clear head to take a peek at this.
If I missed any useful information, let me know.
Turns out I was correct. The daXp4.eli files are necessary as it's the metadata of each disk. A reference point if you will.
By performing:
geli backup /dev/daXp4 /boot/daXp4.eli
It create the meta files required for geom to attempt a decryption at boot time.
I hope this helps someone else interested in this stuff.
I now have a NAS with 23 Disks. 3 ZFS Volumes, all encrypted with geom_eli
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?
I have an image of an HD which is probably encrypted with PGP with the AES algorithm (256 Bit), I'm not 100% sure though. The image itself is self decrypting and contains a bootloader at the beginning (offset 0) which is not encrypted and a windows system. I don't know how many partitions the image has. I could extract 5 PGP Master Volume AES 256-Bit keys of a memory dump saved of a suspended VM, I've dumped the memory twice after a reboot to verify it's not just randomly detecting memory junk as keys. So now I need to determine where the encrypted partition or partitions begins, because the image has no NTFS header.
I would really appreciate it if somebody can help me with the decryption of the image, I'm even willing to pay.
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.