I am working with jcls on mainframe with the program pkzip and pkunzip for creating and reading zip files.
I need some information about the AES encryption of creating password protected zip files. I want to know what is the default / standard AES encryption type (128 / 192/ 256 bits) of pkzip?
I know you can set the Parameter in the jcl file but if you won't set it, what will be the default value?
I didn't find any Information in the documentation.
https://www.pkware.com/documents/manuals/PKMU-V5R5000.pdf
Thank you
Seems to me you can specify what pkzip uses: -AES128 | -AES192 | -AES256 are clearly indicated in the document you point to, and CBC mode is specified. And the decryption will detect which one was used from the archive - again as documented.
Related
I Have a parameter file which I am using in mapping. This file contains credentials and other sensitive information stored as follows:
$$username=myusername
$$password=mypassword
$$secret_key=xxxnnccmmmmmz
$$Client_id=ccmmmmlksjsjkl
These $$username etc. parameters are defined in the mapping level and used. Ths parameter file is stored on the unix path which can be accessed by everyone. I need to secure this information in the file, I have heard about AES Encrypt and Decrypt but not have used it . Anyone can explain how this can be achieved and encryption can be done? or can this file be read only for owner, currently it has 775 permissions.
So I created encrypted key using ansible-vault create my.key.
Then I use it as var:
my_key: "{{ lookup('file','{{ inventory_dir }}/group_vars/my.key') }}"
And then when running my playbook, like this:
- name: Create My Private Key
ansible.builtin.copy:
content: "{{ secrets.my_key }}"
dest: "{{ secrets_key }}"
no_log: true
It does properly create key on remote host and it is then unencrypted. But I'm thinking if this is the right way to do it? Does it unencrypt at the right time and I am not exposing sensitive data where it should not be?
I thought encrypted variables must also have !vault keyword specified. But if I do this for my my_key, I get this error:
fatal: [v14-test]: FAILED! => {"msg": "input is not vault encrypted data. "}
So this got me worried, that file is unencrypted at the wrong time or maybe message is misleading or something.
Is this the right way to do it? Or I should do it differently?
Firstly, a definitive answer as to whether this approach is appropriate, is directly linked to what you want to achieve from encryption. Therefore all the answers here can do is talk about how Vault works and then you can decide if it is right for your requirements.
Fundamentally what you are doing is a 'correct' usage of Ansible Vault, although I have not previously seen it used in quite this workflow (typically I have seen create used for encrypting YAML files of vars).
Using your method, your secret is turned into ciphertext and stored in my.key (which can be confirmed by using basic text tools such as cat, less or more). You will see the first line of the file, contains a bunch of metadata that allows Ansible to understand the file contents and decrypt on demand.
At runtime, Ansible will then use the password/key for the encrypted file (accessed through a number of methods) to decrypt the file contents into plain text and then store it in the variable my_key for use during the play.
A non-exhaustive list of things to consider when determining if Ansible Vault is the right approach for you:
Ansible Vault encryption is purely designed to protect secrets at rest (i.e. when they are stored on your hard disk)
At run time, the secrets are converted into plain text and treated like any other variable/string data, however the file on disk still contains ciphertext so the plaintext is only accessible within the running Ansible process (i.e. on a multi-user system, at no point can anybody view the plaintext simply by looking inside the my.key file. However, depending on their level of access, skills and what your Ansible tasks are doing, they may be able to access the plaintext from the running process.)
Given inside the process the data is just plain text, it is vulnerable to leakage (for example by writing the contents out into a log file - checkout the Ansible no_log option)
At run time, Ansible needs some way to access the key necessary to decrypt the ciphertext. It provides a variety of methods, including prompting the user, accessing it from a file stored on disk, accessing it from an Env var, using scripts/integrations to pull it from another secrets mgmt tool. Careful thought needs to be given about which option is chosen, relative to what you are looking to achieve from the encryption (e.g. if your goal is to protect your data in the event that your laptop gets stolen, then storing the key in a file on the same system, renders the whole operation pointless). Quite often, with more sophisticated methods, you can still end up in a 'chicken and egg' situation, once more relative to what your goal from using encryption is
I might be talking complete cobblers or be a nefarious individual trying to sow disinformation, so read the docs thoroughly if the value of the secrets if significant to you :)
Unfortunately there is no getting away from generally good security is harder to achieve than the illusion of good security :|
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.
I am working on an embedded Linux project that can run on multiple
platforms. One uses e.MMC for storage and another NAND flash. I want
to encrypt all the filesystems (mainly to protect against someone
unsoldering the flash chips and putting them in a reader). I want to
try and maintain a common approach across both hardware types as far
as possible. One big difference between the two is the wear levelling
is in the hardware for the e,MMC whereas for NAND I'll be using UBI.
For the root filesystem I am thinking of using squashfs which is
protected using dm-crypt. For the NAND device I have tried this out
and I can layer dm-crypt on top of ubiblock then use the device mapper
to load the squashfs. This maps nicely to the e.MMC world with the
only difference being that the device mapper is on a gpt partition
rather than a ubiblock device.
My challenge is for other read/ write filesystems. I want to mount an
overlay filesystem on top of the read-only root and a data partition.
I want both of these to also be encrypted. I have been investigating
how fscrypt can help me. (I believe dm-crypt won't work with ubifs).
For filesystems on the e.MMC I will be using ext4 and for NAND
ubifs. The documentation says both of these support fscrypt. I've struggled
a bit to find detailed documentation about how to use this with ubifs
(there is a lot more for the ext4) but I think that there are some
differences between how this has been implemented on each and I'd like
those who know more to confirm this.
On the NAND side I have only been able to get it to work by using the
fscryptctl tool (https://github.com/google/fscryptctl
) as opposed to the fuller featured fscrypt tool
(https://github.com/google/fscrypt). This was following instructions I
found in a patch to add fscrypt support to mkfs.ubifs here:
https://patchwork.ozlabs.org/project/linux-mtd/cover/20181018143718.26298-1-richard#nod.at/
This appears to encrypt all the files on the partition using the
supplied key. When I look at fscrypt on ext4 it seems here that you
can't do this. The root directory cannot itself be encrypted, only
sub-directories. Reading here:
https://www.kernel.org/doc/html/v4.17/filesystems/fscrypt.html it
says:
"Note that the ext4 filesystem does not allow the root directory to be
encrypted, even if it is empty. Users who want to encrypt an entire
filesystem with one key should consider using dm-crypt instead."
So this is different. It also seems that with ubifs I can't apply
encryption to the subdirectories like I could in ext4. The README.md
here https://github.com/google/fscryptctl gives an example using ext4.
This encrypts a subdirectory called test. I don't see how to do the
same thing using ubifs. Could someone help me?
I've been using the NANDSIM kernel module for testing. At the end of
this post is a script for building an encrypted overlay ubifs
filesystem. As you can see the mkfs.ubifs is taking the key directly
and it appears to apply it to all the files on the partition. You
can't then apply policies to any sub-directories as they are already
encrypted.
I would like to use some of the other features that the userspace
fscrypt tool provides e.g. protectors (so I don't need to use the
master key directly). I can't however see any way to get the userspace fscrypt
tool to setup encryption on a ubifs. The userspace fscrypt command
creates a .fscrypt directory in the root of the
partition to store information about policies and protectors. This
seems to fit more with the ext4 implementation where the root itself isn't encrypted.
When I try to set-up an unencrypted ubifs with "fscrypt setup" I run
into trouble as making a standard ubifs seems to create a v4 ubifs format
version rather than the required v5. This means the "fscrypt encrypt"
command fails. (Errors like this are seen in the dmesg output
[12022.576268] UBIFS error (ubi0:7 pid 6006): ubifs_enable_encryption
[ubifs]: on-flash format version 5 is needed for encryption).
Is there some way to get mkfs.ubifs to create an unencrypted v5 formatted
filesystem? Or does v5 mean encrypted?
Here is my script to create an encrypted ubifs using the fscryptctl tool:
#!/bin/bash
MTD_UTILS_ROOT=../../mtd-utils
FSCRYPTCTL=../../fscryptctl/fscryptctl
MOUNTPOINT=./mnt
dd if=/dev/urandom of=overlay.keyfile count=64 bs=1 # XTS needs a 512bit key
descriptor=`$FSCRYPTCTL get_descriptor < overlay.keyfile`
$MTD_UTILS_ROOT/mkfs.ubifs --cipher AES-256-XTS --key overlay.keyfile
-m 2048 -e 129024 -c 32 -r ./overlay -o overlay.enc.img
$MTD_UTILS_ROOT/ubiupdatevol /dev/ubi0_6 overlay.enc.img
# Try it out
$FSCRYPTCTL insert_key < overlay.keyfile
key=`keyctl show | grep $descriptor | awk '{print $1}'`
mount -t ubifs /dev/ubi0_6 $MOUNTPOINT
ls $MOUNTPOINT
umount $MOUNTPOINT
keyctl unlink $key
NB I've been working with mtd-utils v2.1.2 on a 5.4 kernel.
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.