I need encrypt data using exactly the PKCS#1 V2.0 encryption method (defined in item 7.2.1 of the PKCS#1V2 specification).
Is it already implemented for Java?
I'm thinking in something like just pass a parameter to javax.crypto.Cipher specifying "PKCS#1V2", I wonder if there is something like this?
PKCS#1 v2.0 encryption is usually called OAEP encryption. So:
Cipher.getInstance("RSA/ECB/OAEPWithSHA1AndMGF1Padding");
The place to look is the Java Cryptography Architecture documents: Standard Algorithm Name Documentation or Sun Providers Documentation.
As you can see the SunJCE provider supports the following variations of OAEP:
OAEPWITHMD5ANDMGF1PADDING
OAEPWITHSHA1ANDMGF1PADDING
(OAEPWITHSHA-1ANDMGF1PADDING)
OAEPWITHSHA-256ANDMGF1PADDING
OAEPWITHSHA-384ANDMGF1PADDING
OAEPWITHSHA-512ANDMGF1PADDING
Related
Is there any way to make XAdES signature using Google Cloud KMS? I cannot find any info about it.
Wow, XAdES is a maze of twisty standards documents, it's tough to find what is supported. From what I can tell, XMLDSIG originally supported DSA and RSA-SHA1 which are now pretty dated and neither is supported by Cloud KMS's algorithms.
In 2013 XML Signature Syntax and Processing Version 1.1 which specified some more algorithms, including an RSA algorithm with SHA-256 which should be compatible with Cloud KMS's RSA_SIGN_PKCS1_2048_SHA256, RSA_SIGN_PKCS1_3072_SHA256 and RSA_SIGN_PKCS1_4096_SHA256. and I believe its ECDSAwithSHA384 should be compatible with Cloud KMS's EC_SIGN_P384_SHA384.
There may have been further developments since then with other supported algorithms. I suspect that particular XAdES implementations or interoperability groups may only support a selection of algorithms, so you may need to check with those for interoperable algorithms.
All that said, Cloud KMS does not provide the tooling to encode the documents for signing nor encode the signatures in a way compatible with XAdES, so while I believe, if you had algorithmic compatibility, you could implement signing with keys stored in Cloud KMS, but it would take a chunk of work to do the various format conversions.
Thanks for using GCP and Cloud KMS. If you have more info on what you wish it could do, I'd be happy to get the request.
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 trying to decrypt the data using RSA Algorithm. While doing the decryption, I am getting an exception.That is,
java.security.NoSuchAlgorithmException: Cannot find any provider supporting RSA/ECB/PKCS5Padding
at javax.crypto.Cipher.getInstance(DashoA13*..)
How to solve this exception? Currently, I am using java version "1.6.0_26".
It's a typo. The correct name for RSA with PKCS #1 v1.5 padding is "RSA/ECB/PKCS1Padding".
Generally, it is a good idea to compare with a list of available algorithms.
E.g. this question contains some ways to print such a list.
(And of course using OAEP instead of v1.5 padding would be preferable, especially if your
main field is not cryptography).
The error means that the library you use cna't decrypt the data because there isn't an algorithm in the Lib which decrypts RSA.
You can use a library like Bouncy Calste or GNU Crypto to decrypt data using RSA. There are plenty of samples how to do this on the web.
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.
I need an java RC5 encryption and decryption algorithm.
The JCE includes support for RC5 but Sun has not implemented RC5 in any of their providers. The Bouncycastle provider, on the other hand, does include RC5. So if you just add the bouncycastle provider you should be able to use RC5 through the JCE (e.g. Cipher c = Cipher.getInstance("RC5/CBC/PKCS5Padding");)
However, just because you can get it for free does not mean you can legally use it for free. For example, in the U.S. you would need to obtain a license from the RC5 patent holder.
EDIT: The RC5 patent has expired in the United States.
The JDK comes with a JCE provider supporting RC5. See http://download.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html and look for the explanations on the Cipher class to get you started.
Also look at the RC5ParameterSpec class.