openssl enc -e -bf -in X:\a.jpg -out X:\a -kfile Y:\password.txt
or
openssl enc -e -bf -in X:\a.jpg -out X:\a -k password
I get:
### is some number always different
###:error20074002:BIO routines:FILE_CTRL:system lib:.\crypto\bio\bss_file.C:400:
It would seem it does not like writing to Drives. It use too work till I updated even then it was sort of iffy.
I have tried every Windows admin rights I think of http://www.mydigitallife.info/how-to-open-elevated-command-prompt-with-administrator-privileges-in-windows-vista/
Related
Trying to encrypt a file & make executable using openssl. Found an interesting link that was suitable to my problem with one issue. which is "I had to pass the password used for encryption in openssl command" which is resulting error.
Create Write your script (script-base.sh)
#!/bin/sh
echo "Hello World"
Encrypt your script (give a password): foobar is my password
openssl enc -e -aes-256-cbc -a -in script-base.sh > script-enc
Write de Wrapper (script-final.sh):
#!/bin/sh
openssl enc -d -aes-256-cbc -a -in script-enc | sh -passin pass:foobar
Running "script-final.sh" I see following error in console
enter aes-256-cbc decryption password: bad password read
Though the following code works but its deprecated
openssl enc -d -aes-256-cbc -a -in script-enc -k foobar | sh -
when used the following error is thrown
*** WARNING : deprecated key derivation used.
Using -iter or -pbkdf2 would be better.
bad decrypt
... works but [] deprecated: openssl enc -d -aes-256-cbc -a -in script-enc -k foobar | sh -
In that case you give -k foobar as an option to the openssl enc -d command, so it is used as the password to decrypt, which succeeds since you did in fact encrypt using foobar as the password (and the same cipher and default KDF). See below about deprecation.
openssl enc -d -aes-256-cbc -a -in script-enc | sh -passin pass:foobar [gives]
enter aes-256-cbc decryption password: bad password read
Here you didn't give -passin pass:foobar as an option to openssl, you gave it as an option to the shell that is the second component of the pipeline. Since you didn't give the password as an argument to openssl and it is needed, openssl prompted you to input it, but you didn't give valid input (perhaps entering control-D or similar) so it failed. If you did instead
openssl enc -d -aes-256-cbc -a -in script-enc -passin pass:foobar | sh
it would work exactly the same as the -k version, except for taking more space in your script.
It is indeed true that the key-derivation long used (and still default) by openssl enc is very poor and weak and has been widely criticized for decades; OpenSSL 1.1.1 (released 2018, after the date of the answer you link to) and up finally offers a better method with -pbkdf2 and warns about using the old one. However, you should pay attention to this warning on the encrypt side rather than decrypt; once you've encrypted with the poor method, you must use it to decrypt (and suffer the warning). Also note, as I commented at that link, OpenSSL 1.1.x (and 3.0) are incompatible with earlier versions, so if any system(s) you or anyone (like your users if any) want this to work on are running older software it will fail.
Alternatively, consider using something that was properly designed in the first place, such as GPG which was recommended in the answer by Gilles on that same question (well over a year earlier). Although GPG, depending on the version, makes it less convenient to provide the password on the commandline because that usually allows it to be compromised -- but in your case you are already compromising it yourself, so GPG's attempt to give you security is wasted.
I have to create a shell-script that can decrypt a RSA key file that is encrypted with a specific .pem file. And then to decrypt zip file with the AES key which I get from the RSA file once it is decrypted in a file named keyaes (or whatever you want).
Here are the two commands I have to use
openssl rsautl -decrypt -in AES_KEY -inkey CERTIFICATE.pem -out keyaes
openssl enc -d -aes-256-cbc -in zipfile.zip -out extraction.zip -nosalt -p -K RSA_KEY_from_key_aes_output -iv 0
The commands work perfectly, the problem is in my script I don't know how to make it automatically and to get the key from the keyaes output and put it into the next command properly.
How can I do it ?
you could just use bash command substitution in the second command, using backticks
openssl enc -d -aes-256-cbc -in zipfile.zip -out extraction.zip -nosalt -p -K `cat output_filename_with_aes_key` -iv 0
I'm using fastlane and sh command to decrypt some credentials but seems ruby prints the output in logs. How do I hide the sensitive information from logs?
cmd_decrypt = "openssl enc -aes-256-cbc -d -a -k \"#{ENV["MATCH_PASSWORD"]}\" -in #{enc_file} -out #{dec_file[0]}"
sh(cmd_decrypt)
output:
[09:38:15]: --------------------------------------------------------------------
[09:38:15]: Step: openssl enc -aes-256-cbc -d -a -k "PASSWORD_SHOWN!" -in /var/folders/7g/yy/T/d20190925-1304-1qv6cj1/vault/zz-out /var/folders/7g/yy/T/d20190925-1304-1qv6cj1/vault/xx
[09:38:15]: --------------------------------------------------------------------
[09:38:15]: $ openssl enc -aes-256-cbc -d -a -k "PASSWORD_SHOWN!" -in /var/folders/7g/yy/T/d20190925-1304-1qv6cj1/vault/zz -out /var/folders/7g/yy/T/d20190925-1304-1qv6cj1/vault/xx
You can pass sh extra parameters. In this case, you would call it like this:
sh(cmd_decrypt, log: false)
The documentation for sh is here: https://docs.fastlane.tools/actions/sh/
You get can get the docs for other built-in actions here:
https://docs.fastlane.tools/actions/
And the docs for other plugin's actions here: https://docs.fastlane.tools/plugins/available-plugins/
Since you have an environment variable, why not just run with that?
cmd_decrypt = "openssl enc -aes-256-cbc -d -a -k \"$MATCH_PASSWORD\" -in #{enc_file} -out #{dec_file[0]}"
sh(cmd_decrypt)
From there shell interpolation should take over and make it work. One thing to note is your -in parameter doesn't have shell escaping, which it usually must have, done using shellescape.
You really should be specifying these as separate arguments, though, whenever possible to avoid injection issues. The problem is you lose shell interpolation at that point.
The good news is you can always write a wrapper script to provide safety and ease of use, something like:
#!/bin/sh
# descrypt.sh
openssl enc -aes-256-cbc -d -a -k "$MATCH_PASSWORD" -in $1 -out $2
So then you can call it like this:
sh('descrypt.sh', enc_file, dec_file[0])
Now it logs something a lot quieter as well as a bonus. You can pick which arguments to pass through, or even throw them all through with $*.
I would like to sign a file using a dsa key and openssl. The DGST(1) man page says the following:
file...
file or files to digest. If no files are specified then
standard input is used.
For me this means that the following two terminal commands should give the same results, which they do not. I piped the output through od because the result is binary.
specify the file on command line
openssl dgst -dss1 -sign private_key.pem test_archive.zip | od -x
0000000 2c30 1402 e30d 9073 0059 0de7 f03e 8fd2
0000020 874b 5252 b025 8f44 1402 ed26 2f55 7fa4
0000040 f474 0426 1d44 787c ecd6 5059 921b
0000056
piping the file into the openssl command
openssl dgst -dss1 -sign private_key.pem < test_archive.zip | od -x
0000000 2c30 1402 2444 c3a5 f498 7bb8 3dfe 715d
0000020 e179 c5ad c0a5 2b16 1402 173b 692b 9d71
0000040 3970 c497 9994 9cbc 4cfd d642 62df
0000056
As you can see both outputs are not the same, although the file which should be signed is the same in both cases.
Why is this the case? Am I missing something obvious here?
Edit
I am using OpenSSL version 0.9.8y 5 Feb 2013 on FreeBSD and version 0.9.8r 8 Feb 2011 on Mac OS X 10.7.5 and observing the effect on both.
Edit 2 - How to generate a key for testing
small shell script for generating appropriate keys
#!/bin/bash
openssl=/usr/bin/openssl
${openssl} dsaparam 1024 < /dev/urandom > dsaparam.pem
${openssl} gendsa dsaparam.pem -out private_key.pem
${openssl} dsa -in private_key.pem -pubout -out public_key.pem
rm dsaparam.pem
I also ran a test on a CentOS 6 Linux system using OpenSSL version 1.0.0-fips which shows the same strange behavior.
Edit 3 - More Versions Tested
Also the freshly compiled OpenSSL version 1.0.1e 11 Feb 2013 shows this behavior.
I'm not able to reproduce this (OpenSSL 1.0.1 14 Mar 2012) . (I was using an RSA key) I think there are three possibilities:
OpenSSL bug [or different default option] You may have a different version that has a bug. For example:
http://rt.openssl.org/Ticket/Display.html?id=2965
(I don't necessarily think it's this particular bug, but it is similar.)
The key changed.
The zipfile changed
Try adding -binary to your commands. Looking at #1, it could be that my version is doing --binary by default, which excludes the digest type.
openssl dgst -sha1 </dev/null
(stdin)= da39a3ee5e6b4b0d3255bfef95601890afd80709
openssl dgst -sha1 /dev/null
SHA1(/dev/null)= da39a3ee5e6b4b0d3255bfef95601890afd80709
With the dsa key, I am able to reproduce this in multiple versions of openssl (1.0.1 and 0.9.8y)
Using the -hex option, I was also able to confirm that the prefix is changing.
(1.0.1)
openssl dgst -hex -dss1 -sign private_key.pem config
DSA-DSA(config)= 302e021500ca417b14be6e1c08426d4f4cdb3beb51181e6055021500e6a768689cfe9c6f7538e9ec2f952c9465fea80b
openssl dgst -hex -dss1 -sign private_key.pem <config
(stdin)= 302c02142a59682765ae10e37fe114ca63a21cdf4127ff5302141c8b3ac5caf538a23dc43b20cc9c01b1278c0d8e
(0.9.8y)
apps/openssl dgst -hex -dss1 -sign private_key.pem config
DSA(config)= 302e0215008aef560f547425fb4360e24be343fa6db2dc4551021500eb594cea70455400838dc0a14dae7b86614c5218
apps/openssl dgst -hex -dss1 -sign private_key.pem <config 302c02146aa92d6cf2cc9a6fb1d340fed21c29d05f936fc002141fd9e781def4897cfc306b7a68a92b90e6861cb9
Note: all 4 commands have different binary output. Given that the hex hash is the same but the prefix is different, it seems reasonable to infer that the differences in the prefixes are causing the changes in the outputs.
The behavior of OpenSSL is not a bug. The created signature is different if the file is piped in via stdin or specified on the command line, but both outputs are a valid signature if tested with
openssl dgst -dss1 -verify public_key.pem -signature file_with_archive_signature.sig test_archive.zip
Therefore I think that without looking at the algorithm there is more than one valid signature for each file, but a signature is only valid for one file (neglecting collisions).
How can I trick the -in argument of the OpenSSL command line tool in order to get data from string instead a file?
Normally, I could use echo command to do it:
echo 'test string 1' | openssl enc -aes-256-cbc -a -salt -pass pass:mypassword
Is there a way I can do it without echo and pipe? Similar to the -pass pass: argument?
Thanks in advance!
If your shell is bash and your OS supports it, you can use process substitution:
openssl enc -in <(echo 'test string 1') -aes-256-cbc -a -salt -pass pass:mypassword
I found a way to go around this! Instead of passing everything before and since openssl has an interactive mode, it's possible to run the command without input:
openssl enc -aes-256-cbc -a -salt -pass pass:mypassword
And OpenSSL will be waiting for data to encrypt. This can be also useful for streams!
Then type in the string or data you want to encrypt and send a EOT (End of Transmission) in Terminal is usual ^D Control+D it it will output to stdout the encrypted string!
Hope this may help someone some day!