I retrieved the PGP key from the public key server ,Now need help in getting a python method for encryption which can accept this PGP public key .
As i know PGP/Gnupg.py module do not allow me to use encryption/decryption function separately without generating the key.
It seems to me that the easiest approach is use GPGME, which is basically GnuPG wrapped up in a convenient library form (thus the name, GPGME = GnuPG Made Easy). There is a Python wrapper for GPGME named Pyme which will let you do things like import keys, encrypt messages using them, etc, all using the standard PGP formats. There is some basic Pyme documentation online, along with the promise of more complicated examples being included in the source distribution.
Related
I am playing around with some encryption / blockchain ideas right now that require the use of a public / private key pair. I looked at some of the existing packages and could not find one. https://gitlab.com/braneproject/ECC.jl provides much of the desired functionality but lacks the ability to create a public key.
Any idea how I would go about doing this? In Python, I would use from ecdsa import SigningKey to get this functionality. I also looked at https://github.com/JuliaCrypto/OpenSSH.jl but it seems focused on documenter.
The library you mention depends on OpenSSH being installed on your system, and if it is, you can do the following in the REPL. Hit the ';' key and you can enter ssh-keygen at the prompt, as in:
shell> ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (users/yourname/.ssh/id_rsa):
I have some Lua scripts embedded in nginx. In one of those scripts I connect to my Redis cache and do it like so:
local redis_host = "127.0.0.1"
local redis_port = 6379
...
local ok, err = red:connect(redis_host, redis_port);
I do not like this, because, I have to hard code host and port. Should I instead use something like .ini file, parse it in Lua and get configuration information from this file? How do they solve this problem in real world practice?
Besides, I my scripts I use RSA decryption and encryption. For example, I do it like so now:
local public_key = [[ -----BEGIN PUBLIC KEY----- MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAL7udJ++o3T6lgbFwWfaD/9xUMEZMtbm GvbI35gEgzjrRcZs4X3Sikm7QboxMJMrfzjQxISPLtsy9+vhbITQNVkCAwEAAQ== -----END PUBLIC KEY----- ]]
...
local jwt_obj = jwt:verify(public_key, token)
Once again what I do not like about this, is that I have to hard code public key. Do they use it in production like so or use some other techniques to store secrets (like storing them in environment variable)?
I'm sure some people do it this way in production. It is all a matter of what you're comfortable with and what your standards are. Some things that should determine your approach here -
What is the sensitivity of the data and risk if it were to be available publicly?
What is your deployment process? If you use an infrastructure as code approach or some type of config management then you surely don't want these items sitting embedded within code.
To solve the first item around sensitivity of the data, you'd need to consider many different scenarios of the best way to secure the secrets. Standard secret stores like AWS Parameter Store and CredStash are built just for this purpose and you'd need to pull the secrets at runtime to load them to memory.
For the second item, you could use a config file that is replaced per deployment.
To get the best of both worlds, you'd need to combine both a secure mechanism for storing secrets and a configuration approach for deployments/updates.
Like was mentioned in the comments, there are books written on both of these topics so the chances of getting enough detail in a SO answer is unlikely.
I have relatively less idea about encryption but i have done research on encryption in spring boot in application.properties file but i have not found any material based on multiple password encryption.If someone could provide some material or some direction as to how i would proceed will be helpful
Basically you got to do 3 things.
1. Encrypt your password using jasypt.This can be done using command line tool as indicated here or using a simple java program as indicated here. You need a password along with the string you need to encrypt. password is something like a secret key(or salt) which is used to encrypt the string you want to encrypt.
2. Add this to your application properties or yml jasypt.encryptor.password=password_used_in_the_previous_step
3. And add the encrypted password you got from step 1 like this ENC(Your_Encrypted_Password)
Add the necessary dependencies.
Here is a good example.
https://github.com/ulisesbocchio/jasypt-spring-boot.
Is it possible to "retarget" keys generated via the ncipher JCE API to pkcs11? I know that you can retarget via the generatekey command but I don't see how to do it to an existing JCE key. The first prompt is for the "source application" and the options don't seem to include JCE. Does it support other options beyond the ones listed there or should I be looking at a different way of retargeting?
The ultimate goal here is to export a couple keys (asymmetric and symmetric) that were generated via nCipher's JCE API (yes, I know that an HSM's job is to secure the keys and exporting is usually not a good idea but it is a requirement here). We are able to export keys that were generated via the PKCS11 interface but not ones that were generated via the JCE so our thinking is that if we can retarget it from JCE to PKCS11 we might be able to export these keys as well. If there is another way to do this we are open to that as well.
Lastly, the JCE keys show up as "recovery enabled" when executing the nfkminfo on them. Does that mean that they are exportable or does recovery here mean something else?
Disclaimer: I work for Thales e-Security but do not speak for the company.
Yes you can retarget a jcecsp key to pkcs11. If you have any jcecsp keys in your kmdata/local, /opt/nfast/bin/generatekey will offer jcecsp as a source option. If you have no keys of that ilk, it will quietly omit that option from the source list. However, this retarget process may not do what you think it does. All retargeting does is change the application type and potentially the associated metadata: it doesn't change the fundamental capabilities of the key as those were baked into the protected key blob at generation time and cannot be changed.
The Security World uses nShield key ACLs to limit the key's capabilities (Sign, Verify, Encrypt, Decrypt, Wrap, Be Wrapped, etc.). PKCS#11 pulls its parameters (CKA_SIGN, etc.) directly from the key ACLs, and when generating keys through the API, the ACLs saved in the key blob are derived directly from the parameters in the key template. If you set CKA_SENSITIVE to FALSE, and your Security World allows it, you can generate and save an exportable key. JCE is not that sophisticated: it has no concept of key capabilities at all, so the Provider has to guess at the user's intent with the key and it defaults to a fairly generous set. However, since as you point out the whole idea of HSMs is to protect key bits and not let you have them, Export is not one of the defaults. And what's not baked into the key file when you create it, you don't get by retargeting the key.
One thing you could do if you want to use JCE is to generate the key using a different Provider and then store it in an nCipher.sworld KeyStore using the nCipherKM Provider: this will import the key into the Security World (if your World allows that) and save it as a key_jcecsp_* file. However this has nothing to do with key security so from an HSM perspective it's not recommended. Another thing you could do is to drop down to the native nCore API, generate the key with the ACL entries you require, and then polymorph it to a JCE Key Object and save it in the HSM-backed KeyStore. You can shoot yourself in the foot as many times as you want with the ACLs on the key you create. The polymorphing is very poorly documented: ask Thales Support and they can guide you.
Finally, the Recovery capability means that in addition to the Working Key blob which may be protected by an Operator Card Set, the key file has a Recovery Blob. This is in case that Operator Card Set is lost: the Recovery Blob can be opened up by the Administrator Card Set of the Security World using the rocs utility (Replace Operator Card Set), which will write a new key file under a new OCS. No, this does not mean the key is exportable. It just means that you are protected against losing the OCS. Of course losing the ACS is a non-starter as that is your Root of Trust.
I have two clear components, generated by command 000A30303030413230303255 (it's a 000A0000A2002U in HEX mode. This is "GC" - Translate a ZPK from LMK to ZMK Encryption command from 1270A513 Issue 3 manual) using Java code
Now I need to generate an Encrypted key from those components. The console command for it: "FK" command (1270A513 Issue 3, page 5-14).
I couldn't find any commands for doing it by Java code. I used Host Command Reference manual (1270A351 Issue 6) and found only A4- Form a Key from Encrypted Components command, but this command for generating key from Encrypted components.
Is there way to generate encrypted key using clear components?
There is no way to do this and for good reason. If you were to send this via your java code it is open to attack as the clear components are being sent through the network unencrypted. Any person intercepting these components can generate the key themselves. The GC and FK commands are meant to be used with the console and not remotely which is why it is possible using those commands.
If you already have the components you can only form them at the HSM console. If you can possibly generate new keys use the A0 command from your java code.
I don't recommend using this in production. I would take following steps if i really need to do that.
Generate A ZMK(clear and encrypted) on HSM console using 'GC' and 'FK' command.(Need to do only once and reuse key).
use clear ZMK to encrypt all of your keys using TripleDES-ECB-NOPADDING in your application.
Use command 'A6'. Import all ZMK encrypted keys to LMK.
Use 'A4' command to form key using LMK encrypted Components.