i am new to PGP and want to implement encryption/decryption in one requirement. i googled it and decided to use Boynce Castle algo. But when i am trying to understand it, i confused at how i will get the .pkr and .skr files. i just downloaded required jars and program and when tried to run it shows me file not found. i was not aware so by myself i created .pkr and .skr files (converting from .txt) but i think it should be in some format and that should generated by some mechanism. can some explain me about this? How i can proceed.. ?
If you have PGP Desktop installed on the same Windows computer as the PGP Command Line, and you installed PGP Desktop to the default directory, then PGP Command Line will automatically locate and use your existing keyrings. If you are not using PGP Keyrings from a PGP Desktop product, you will need to create blank keyring files. To do so open a command prompt and type the following command:
pgp --create-keyrings
This will create a pubring.pkr (public keyring) and secring.skr (private keyring) file in the default keyring location. For Windows this is in the My Documents>PGP folder. This article will use [ ] to identify information that you will need to enter that is specific to your individual keys.
After that, you will need to create a key pair. To create a key pair using PGP Command Line follow these steps:
On the command line, enter:
pgp --gen-key [user ID] --key-type [key type] --bits [bits #] --passphrase [passphrase]
NOTE: Any information that contains spaces must be contained inside quotation marks.
Example: The following example will show you how to create a 2048 Bit RSA key for Joe User, an employee of ACME Corp, with the passphrase "my passphrase".
pgp --gen-key "Joe User" --key-type RSA --bits 2048 --passphrase "my passphrase"
PGP Command line will now generate your keypair. You should see your Key ID (i.e. 0X12345678), and a message that the key was successfully generated.
NOTE: To display your new keypair enter the following command:
pgp --list-keys
This will display all the keys that are found on your keyring.
After the key pair is generated and identified, it is important to export the public portion (public key) of the key pair so others can import your public key and encrypt to you. NOTES: Once you have exported your public key to a file, it is easy to distribute. You can attach it to an email, paste the public key block text into the body of an email message (open with Notepad), or copy to a CD, for example. To export your public key you will need to have information about the key in order to identify it, which will be referred to in this document as (input). You can use the key ID (i.e. 0x12345678), user ID (i.e. "Joe User"), or a portion of the user ID, (i.e. Joe). To export the key, do the following:
pgp --export (input)
PGP Command Line responds by exporting keys as ASCII armor (.asc) files into the directory currently active on the command line.
The following examples will show you how to export your public key using your key ID and user ID.
pgp --export 0x12345678
pgp --export "Joe User"
You may import a public key from an ASCII Armor file (.asc) or from a text file, the process is the same for both. The file containing the key(s) to be imported must be in the current directory. As with exporting a key, this will be referred to as (input) in the examples. Both public and private keys will be imported if they exist in the file. If a key being imported already exists in the local keyring, the keys are merged. Import Key From File:
pgp --import (input)
PGP Command Line responds as follows: Joe User.asc:import key {0:key imported as 0x12345678 Joe User}
The following examples will show you how to import a key from an ASCII Armor file (.asc) and from a text file containing the PGP key block.
pgp --import "Joe User.asc"
pgp --import "PGP Joe.txt"
Those files are public and private (secret in OpenPGP terminology) keyrings respectively. They contain collections of public and private keys. You usually generate a keypair (a pair of public and private key) or several keypairs for your own use, and other people do the same. Then they can give you their public keys and you create a public keyring from those keys. Public keyring is then used to encrypt data for recipients or to verify other people's daa signatures.
Private keyring is composed from your private keys which you generate. You use private keyring for signing your data, and you can give corresponding public keys to other people so that they could encrypt data for you (which you then decrypt using your private keys).
I believe BouncyCastle has key generation functions, or you can use GnuPG application or PGP Desktop to generate keys.
You can check the examples for OpenPGP key generation that ship with the BouncyCastle library.
They are located at :
[bouncy castle sources]\src\org\bouncycastle\openpgp\examples\RSAKeyPairGenerator.java
[bouncy castle sources]\src\org\bouncycastle\openpgp\examples\DSAElGamalKeyRingGenerator.java
Example code that uses the keys can be found at:
[bouncy castle sources]\src\org\bouncycastle\openpgp\examples\KeyBasedFileProcessor.java
Related
For verifying builds of Renderdoc using the publisher's public key, verifying the Linux binary tarball works as expected; I run gpg --import ./baldurk-pubkey.asc and then gpg --verify renderdoc_1.18.tar.gz.sig renderdoc_1.18.tar.gz and then I receive the following output:
gpg: Signature made Tue Jan 25 07:25:56 2022 MST
gpg: using RSA key 1B039DB9A4718A2D699DE031AC612C3120C34695
gpg: Good signature from "Baldur Karlsson <baldurk#baldurk.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 1B03 9DB9 A471 8A2D 699D E031 AC61 2C31 20C3 4695
However, when I try to do the same process for the Windows 64-bit portable zip, i.e. gpg --verify RenderDoc_1.18_64.zip.sig RenderDoc_1.18_64.zip I receive the following output instead:
gpg: Signature made Tue Jan 25 08:01:06 2022 MST
gpg: using RSA key EC0F4688931695D3BCF0D10FB93B9B66E68BA2E9
gpg: Can't check signature: No public key
I receive similar output if I attempt to pass in the extracted qrenderdoc.exe as the second argument instead of the .zip itself.
I understand that the Windows executables have their own digital signatures; if I right-click qrenderdoc.exe, go to "Properties", and then go to the "Digital Signatures" tab, there is a signature by the same publisher. But I am confused as to what purpose the Windows .sig files serve or how to use them. I'm assuming there must be a correct way to do this, or else the sig files would not be provided, but I do not know what that way would be.
OK, I can sort of understand the downvote to my question. Clearly, as the output to the command for the .zip.sig says, it was signed with a different RSA key. I assumed that, since the Renderdoc website makes no mention of another key and nobody else online mentioned any issues with the Renderdoc signatures, then clearly there was an obvious way to find/add said key that I was missing. But after asking the developer, it turns out they changed build systems at some point and a different key was being used, and I guess I was just the first one to notice or report the problem. I can see now that this probably should have been my first assumption; apologies for the unnecessary question.
In the miniscule chance another Renderdoc user stumbles across this: According to the developer, subsequent builds (so anything above the current v1.18) will be signed with the correct key.
Suppose you want to distribute a file foo along with its detached signature foo.sig and your public key public.key.
Suppose further you want to make signature verification as easy as possible, i.e. in the minimum number of steps: just one command. Ideally something like
gpg2 [magic option combo here involving foo, foo.sig, public.key]
I've read the gpg2 man page up and down a few times, but it seems the receiver needs to first import the public key to his key ring.
Is there a way to avoid importing the public key and specify it explicitly? I would like to avoid the receiver being spammed with a newly created $HOME/.gnupg directory and its contents.
Or am I trying something stupid from a security point of view?
Use gpgv instead, which you can pass a keyring file (a single exported key also accounts as a keyring). If no slash is contained in the keyring path, gpgv will search in the GnuPG home directory, so either pass an absolute path or at least include ./ to denote the current working directory if no slash would be involved otherwise:
# Create and sign file
echo foo >foo.txt
gpg --local-user a4ff2279 --sign foo.txt
# Create "keyring" / export key
gpg --export a4ff2279 >a4ff2279.gpg
# Verify using gpgv
gpgv --keyring ./a4ff2279.gpg foo.txt.gpg
Finally, the only difference between importing and not importing the key is whether how the key is verified. There is no verification through the web of trust, certifications and local trust if you don't import the key, if the only way to verify the key is "downloading it from a trusted source", not importing it is totally fine. If you just fetch file, signature and key from an untrusted web server without encrypted connection and certificate, the OpenPGP signature is degraded to a simple checksum to realize transmission errors, not attacks providing faked files, signatures and keys.
On Linux, I have access to PGP. However, I do not have PGP SDK service running on a particular box to which I have access to.
Normally, I use "pgp --verify --passphrase " to verify the .pgp files.
Is it possible to verify a file (I only need to check if the file is encrypted or not) using pgp but not where PGP SDK service is required?
RHEL already brings GnuPG, which is a fully compliant implementation of OpenPGP. Using gpg --list-only --list-packets you can dump the contents of an OpenPGP file (either sending the contents into STDIN or providing an additional option containing a file name).
An example output for my own key:
$ echo foo | gpg --recipient a4ff2279 --encrypt | gpg2 --list-only --list-packets
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid CC73B287A4388025
data: [4096 bits]
# off=527 ctb=d2 tag=18 hlen=2 plen=63 new-ctb
:encrypted data packet:
length: 63
mdc_method: 2
If you want to test for encrypted information, look for the :pubkey enc packet line if you only want to match public-private-key cryptography, the :encrypted data packet will be available in both public-private-key cryptography and with symmetric encryption.
PGP probably provides similar interfaces, but I have few experience with it and currently no setup around to play with it. Anyway, if using PGP make sure you're not using one of the very old, outdated versions suffering from some flaws and limited compatibility with newer releases of the standard.
I am Exporting only the private key(s) from a .pfx file to a .pem (.key) file:
I am using the command as below.....I executed the command twice to generate the private key twice (It asks me for a import password and a PEM pass phrase each time) in two different physical files
openssl pkcs12 -nocerts -in DigitalCertificateExport.pfx -out
OnlyKey_SameParaPhrase_1.key openssl pkcs12 -nocerts -in
DigitalCertificateExport.pfx -out OnlyKey_SameParaPhrase_2.key
However, the resulting key file has different private key each time. Should it not be the same always? I was expecting it to be the same each time.
Worth mentioning that I provide exactly the same pass phrase each time.
According to this OpenSSL doc, at least some encryption methods for .pem files use a random salt. When using your command to convert a .pfx file I get a file with the following line:
-DEK-Info: DES-EDE3-CBC,6AC8DB439F2BDE03
This cointains a random salt used for encryption and / or validation.
I have generated a private key with a pass pass phrase using PuTTygen on my windows machine. I know need to import that private key to a linux machine but unsure how to go about using the private key that is pass phrase protected. On a windows machine I would just open the private key with Putty Pageant which will ask me for the pass phrase, whats the equivalent on linux?
Beskee
I think that what you need is to copy the public part of the key: to achieve this you can just copy the corresponding file. You can also copy the private key (even if I think it makes no sense), you don't need the password to copy it, but you will need it to use it.