Is it possible that a file signed by GPG https://gpgtools.org/ can be verified using some other tool say BouncyCastle or GnuPG https://www.gnupg.org/? In my opinion it should not be because key providers are different. Am I right? I need some knowledge in this context. Please help.
Is it possible that a file signed by GPG https://gpgtools.org/ can be verified using some other tool say BountyCastle or GnuPG https://www.gnupg.org/?
Yes, of course! Both GnuPG and BouncyCastle implement the common standard OpenPGP. GPGTools just ships GnuPG as binary distribution and adds some tools.
In my opinion it should not be because key providers are different. Am I right?
There is no central trust entity like a certificate authority in OpenPGP, with other words no trusted keys are preconfigured.
To verify signatures, you need to fetch the matching public key. This will tell you, whether the signatures was issued by the matching private key and whether the file was tampered or not. It does not say anything on the validty of the key and signature; you have to verify the key on some other way. This might be by comparing the fingerprints manually, or using the OpenPGP web of trust to find a trust path from a trust anchor like your own key.
I need some knowledge in this context.
It looks you're still very new to those technologies. Covering them in depth is far beyond an answer on Stack Exchange. I'd strongly recommend to read up on the following topics, to get a feeling for the topics:
Public-key cryptography
PGP and OpenPGP
Public key infrastructure, especially the Web of trust in contrast to the Certificate authority system
Related
I have the following way of generating a self signed certificate using the class CertandKeyGen.
CertandKeyGen cert = new CertandKeyGen("RSA", "SHA256withRSA);
cert.generate(size);
..
X509Certificate certificate = cert.getSelfCertificate(name, validity);
Since these are internal APIs from keytool, I am looking at a similar approach using java.security.* APIs.
I want to know if this is possible currently. If yes, what are those APIs? I dug around but I am unable to find anything about it. I am aware of bouncy castle APIs (X509V3CertificateGenerator) but I do not want to use third party APIs.
Thanks.
At present, I do not believe that the generation/signing mechanisms that are used in keytool are part of the public API for Java.
I have implemented a very simple CA/Signing mechanism utilizing BouncyCastle for testing purposes.
I don't think you're going to be able to do this without a 3rd party api or implementing a very significant amount of code on your own.
I have a JKS keystore that keeps several private/public key pairs in my application. That is already protected using the password for the keystore. I'm adding keys used for doing OpenPGP with Bouncy Castle, and I need to generate several keys to use with Bouncy Castle PGP. I know I can store these keys as individual files, but those files would need to be protected individually with passwords creating a headache for the user. I'd like to simply store the PGP keys in the existing Keystore. I've read several responses on Stackoverflow alluding to it being possible, but no definitive answer about how. So can I store the PGP keys in the existing Keystore?
Here is what I'm thinking. Bouncy Castle's classes for PGP do not implement Key or Certificate. It does have JcaPGPKeyPair which can wrap a PrivateKey/PublicKey instance. So I could create keys within JCE, then "import" the JCE keys into the BC PGP infrastructure using JcaPGPKeyPair. Once I'm done I throw away all of the BC PGP instances and recreate when I need them again. Possibly using JcaPGPKeyConverter to do the heavy lifting of converting between JCE keys and PGP keys?
Could I use 2 JCE RSA or DSA keypairs for both signature and encryption keys PGP wants to use? Keep those in the Keystore and simply reconstruct the PGP infrastructure on demand when I want to use those keys?
I'd like to simply store the PGP keys in the existing Keystore. I've read several responses on Stackoverflow alluding to it being possible, but no definitive answer about how. So can I store the PGP keys in the existing Keystore?
The Java key store does not support OpenPGP keys. OpenPGP is another standard incompatible to X.509.
Bouncy Castle's classes for PGP do not implement Key or Certificate. It does have JcaPGPKeyPair which can wrap a PrivateKey/PublicKey instance. So I could create keys within JCE, then "import" the JCE keys into the BC PGP infrastructure using JcaPGPKeyPair. Once I'm done I throw away all of the BC PGP instances and recreate when I need them again. Possibly using JcaPGPKeyConverter to do the heavy lifting of converting between JCE keys and PGP keys?
Could I use 2 JCE RSA or DSA keypairs for both signature and encryption keys PGP wants to use? Keep those in the Keystore and simply reconstruct the PGP infrastructure on demand when I want to use those keys?
You could probably extract the plain numbers forming the public and private keys, but are losing all information on user IDs, timestamps, ..., which you would have to reconstruct every time. I would not go for such a fragile and error-prone path. There is no real mapping of OpenPGP and X.509 key attributes, and it gets worse for certificates (signatures on keys).
I'm creating a web service that stores a list of users with their public keys online, as well as encrypted messages. My end goal was end-to-end encryption.
I initially thought this would be pretty easy -- "Oh, OpenSSL and RSA private/public key asymmetric encryption is great." False. RSA will only encrypt a tiny bit of data, presumably to pass a regular, symmetric key back and forth.
Okay, so I tried to find solutions online. Most of them either ended without a functioning example or pointed at using the command line, all of which seemed excessive and incomplete.
Is there a way to use end-to-end encryption on data with asymmetric keys, or is it all a personal pipe dream? OpenSSL in PHP has a way to do this already, and it's kludgy but it works.
Is there some method I'm missing here?
The common way to encrypt larger amount of data with a asymmetric keys (eg. RSA) is by use of hybrid encryption. In hybrid encryption you mix symmetric and asymmetric encryption. First you generated a random symmetric key, that is used to encrypt the data. Then you encrypt the symmetric key with the asymmetric key. The encrypted data + the encrypted random key are then put together and makes up the full encrypted data.
The openssl_seal() in PHP you refer to, uses hybrid encryption where the symmetric algorithm is RC4. How data is encoded and put together in the encrypted files have been defined by the openssl implementation, and might not necessarily be the way you would want to do it. PGP, as an other example of hybrid encryption, uses it's own way of packing the data.
In any case, hybrid encryption is not something you get out of the box in java, and you typically need to implement each of the encryption + packaging steps yourself, or use one of the libraries that implements there version of this. An example of doing it yourself is this Java code I found that can decrypt messages encrypted with the above mentioned openssl_seal().
An example of using a library for hybrid encryption, could be using the PGP support in Bouncy Castle.
Ebbe's answer is very good, however this question was highly ranked in Google in my attempt to try and find a decent hybrid encryption library (Bouncy Castle's documentation is non-existent and not straight-forward, and GnuPG for Java relies on the OS and is not fully tested). So I thought I'd add on to Ebbe's answer for the weary traveller.
If you can use them, JWTs (JavaScript Web Tokens) could be handy for this. It's also an IETF Standard. There are two different types:
JWS, which is a signed JWT. Plain-text message, but you can verify its authenticity. Which has its own IETF Standard
JWE, which is an encrypted JWT. Which also has its own IETF Standard
Support for JWEs are unfortunately a bit poor at this point in time. However this should hopefully improve. At this point in time (2017-04-11), the only Java JWT library that supports JWEs is BitBucket's Jose4j.
I'm not really sure what you're trying to en- and decrypt, but GnuPG for Java might be a good choice.
It supports public and private keys and can en- and decrypt bigger files and data.
I am currently working on an Android app that talks to a server process on a remote machine. The installation packages for both the Android client and server need to be cryptographically signed; the Android client with a Java Keystore File (JKS) and the server with a PGP key from a keyring file. If possible, I would like to reduce the dependencies by signing both packages with the same key, but neither signing tool supports the opposite file format.
Is it possible to convert a PGP keyring file into a JKS file? Or alternatively, is it possible to convert a JKS file into a PGP keyring file? If so, how?
Edit for clarification: The idea here is to use a single cryptographic key as input for two different signing tools. The tools do not know about each other; it's just some random key to them. I do not want to sign an Android package with PGP, or the server installation package with Android's signing tool, as either would make the output unreadable to the end user.
While it might be theoretically possible there are certainly no tools to do that. If you would want to write one yourself there are a lot of hurdles to overcome. On a low level view there are many different ways to sign data (even if you restrict yourself to RSA, there are still many standards and parameters to choose from). On a high level view such key files and their front end abstractions of certificates or simply "keys" on the pgp side contain a lot meta information like a validity period, ownership information and so on. If you could actually deal with the low crypto problems then you still have to define some translation from one set of meta data to the other.
Also from a cryptographic point of view any key reuse is strongly frowned upon. There are many ways typically sound primitives can break apart if they are used in an unintended way. Certainly the authors and implementers of the algorithms behind the Android tools and the PGP tools did not imagine their tools to be used with such cross generated keys.
I am currently upgrading an application that generates OpenPGP messages to be FIPS 140-2 compliant. Currently I generate PGP messages that use RSA/AES-256 encryption which are both approved algorithms using BouncyCastle and its OpenPGP provider. I am no longer able to use BouncyCastly since it is not FIPS 140-2 validates, so I am looking at the BSAFE library from RSA.
This library doesn't have the high-level abstraction to let you generate an OpenPGP message directly. Does anyone know of a library that can use an existing JCE provider (like my BSAFE library) capable of generating OpenPGP messages? I'd really like to avoid having to implement the OpenPGP spec myself, as that seems like it would be quite time consuming. Alternatively any suggestions for other ways to format my encrypted files?
Thanks in advance for any input!
After much research it seems that there is no way to do this without implementing the OpenPGP format yourself. However the Cryptographic Message Syntax seems to be a suitable replacement.
There are major differences between S/MIME (Cryptographic Message Syntax) and OpenPGP.
http://mozilla-enigmail.org/forum/viewtopic.php?t=67
Mainly, S/MIME exchanges keys in terms of certificates (which must utilize a certificate authority, limited to 1024 bit, and expires after 1 year), while OpenPGP uses PGP keys (can be exchanged peer-to-peer, or utilize a free keyserver, or host your own keyserver).
FIPS 140-2 doesn't apply to protocols like SSL, PGP, S/MIME, or SSH. Those are security protocols that use cryptographic algorithms like RSA and AES. (Commercial crypto vendors aren't likely to point out this distinction, however).
FIPS 140-2 lists approved algorithms. It also specifies testing criteria for "cryptographic modules" that implement these algorithms. But, it doesn't say anything about the application of these algorithms.
So, you can use BouncyCastle's PGP provider. Instead of installing Bouncy Castle as a crypto-provider, install your FIPS 140-2–certified implementation. Bouncy Castle's PGP will use the preferred crypto provider for its underlying cryptographic algorithms. You can use their S/MIME support in the same way.