I would like to ask a question about ioncube encryption. I have successfully encrypted a *.conf file.
When I run it, it doesn't seems to be running properly.
How can I encrypt a non-php file? Can you give a step by step process?
All steps taken from the latest ionCube Encoder User Guide for Version 9 and the GUI documentation.
Encrypt files
In the command line encoder, you can create encrypted files with the command
--encrypt "fileselector"
You can chain these together to select multiple files, and use Wilcards as selectors. For example:
ioncube_encoder --encrypt "*.conf" --encrypt "*.xml"
In the GUI you can enter these selectors in the 'Source Tab' in your Project settings, under the 'Non-PHP encryption extensions' label:
Loading encrypted files
Once the files are encrypted, you can read their content by calling the function:
mixed ioncube_read_file(string path [,bool &was_encrypted [,string passphrase] ] ] )
For example, if you encrypted the file foo.conf without passphrase, you can get the content back by calling:
$file_content = ioncube_read_file("foo.conf");
Note: This only works from already encoded files, otherwise the encryption would be useless. Furthermore, encrypted files can only be decrypted by files encoded with the same ionCube Encoder, i.e. if you encrypt your files on Machine 1 and try to decrypt them with files encoded on Machine 2, you won't be able to decrypt the file.
Related
I Have Some P7M And P7S Files got from My Client.
I want o Extract Attachments from the Corresponding Files
I am able to decrypt P7M And Extracted Attachments from that eml Files using OpenSSL
but when it come to the case of P7S the decryption method is not working
Is there any one can help to the correct way of decryption format of Openssl
I would like to do full file encryption of an org mode file. I would like just to have a password to open it - I believe its called symmetric encryption - no keyrings, public keys, etc because I know nothing about that.
So far I have learned that all I have to do is save an org mode file ending in .gpg or .org.gpg, and when I save, I get:
Select recipients for encryption.
If no one is selected, symmetric encryption will be performed.
- ‘m’ to mark a key on the line
- ‘u’ to unmark a key on the line
[Cancel][OK]
I just click OK and I am prompted for the password. Wonderful.
When I close Emacs and view the file in another text editor, I can see the file is encrypted. Wonderful.
The problem comes in when I open the encrypted file - Emacs does not prompt me for the password. Emacs does report it decrypted the file and then it opens it.
I would like to be prompted for the password.
I have tried many different commands in both .emacs and in the file itself and nothing works. Eg:
(setq epa-file-cache-passphrase-for-symmetric-encryption nil)
I find that most articles seem to be old or for different versions of gpg or different types of encryption and so the commands suggested are not suitable.
What is the minimum amount of commands and what are those commands that I need to use to make sure encryption/decryption functions properly and securely and i will be prompted for the password each time I open the file?
I am using:
gpg (GnuPG) 2.2.20
libgcrypt 1.8.5
See this question on the Emacs SE site. It's a matter of configuring the default-cache-ttl setting in ~/.gnupg/gpg-agent.conf. The default is 300 seconds (5 mins), so the password is cached in gpg-agent for that long. Setting it to 0 makes sure that it is not cached.
While using GPG for encryption is it safe to rename the file after it is encrypted or depending on the algorithm used for encryption the file uses the name also for verifying the contents.
You can rename the file without issues. The original filename is safely encrypted inside the file. The filename is never used for decryption in any way.
I have been tasked with duplicating the functionality of SecureZip; namely encrypting and digitally signing a file and then sending via SFTP.
I've been able to put together a java program based on the bouncycastle examples, and have been able to encrypt and decrypt files (with a locally generated PGP key) using this program. However, now I'm trying to implement the digital signature and want to capture the keys used for signing on the AIX system that is running the SecureZip commands.
So when I run the command
pkzipc -listcertificates
I get a response that indicates there are two OpenPGP certificates available for signing. Referring to them using
pkzipc -archivetype=pgp -add -recipient=<PUBLIC KEY RECIPIENT> -certificate=<CERT NAME> -sign=files file.out file.in
allows me to create the encrypted files using this CERT NAME cert. My question is, where? Where are these certificates located? Does AIX have a central OpenPGP certificate location or are these somehow imported into some SecureZip storage location?
Using SecureZip Server Version 14 for AIX
Using AIX 7100-03
I found the certificate location. Evidently there are three locations in UNIX that PKZIPC looks (according to the manual I finally got my hands on):
For public keys:
$PK_OPENGPG_PUBLIC_RING
$HOME/.pgp/pubring.pkr
For private keys:
$PK_OPENPGP_SECRET_RING
$HOME/.pgp/secring.skr
$HOME/.gnupg/secring.gpg
I'm using gpg to decrypt files sent to me by a vendor. Everything works fine accept for when the content of the encrypted file is empty (the vendor has told me that there is no content in the files in question).
If I try and decrypt one of these files I get:
gpg: can't handle this ambiguous
signature data
Is there any way to check that the file has no content accept for the header, so that I can set it up to fail more elegantly?
According to this mailing-list post, the official PGP tool has a bug that sometimes causes it to produce malformed messages. You can verify whether this is the case for your particular file by running gpg --list-packets path/to/encrypted/file.pgp and looking at the output. If you see a :onepass_sig packet: followed immediately by a :signature packet: then that's probably what's going on.
In my (limited) experience, this occurs if the sender has tried to encrypt an empty file. Unfortunately, since encryption is designed to make it difficult to see what's inside, it's hard to tell if that's actually the case before you try to decrypt it. gpg's --list-packets output will give you some information, but I've noticed that the :literal data packet: output will usually say "raw data: 0 bytes" even if the message contains a non-empty file.
You can make gpg ignore all signature data in the encrypted file with the --skip-verify option, but then of course you can't tell whether the file you're decrypting comes from a trusted source.
Assuming you are using a unix shell script, you could first do a '[ -s /the/file ]' before attempting the GPG decrypt.