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.
Related
We have some Java library performing AES and RSA encryptions (using javax.crypto.Cipher).
A new requirement came in to make the code FIPS 140-2 compliant. Reading some articles what I understood is that I have to change the followings in the java.security file in JDK/JRE and recompile the code. Will that make my library FIPS 140-2 compliant?
#Use these three providers for FIPS compliant
security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=com.rsa.jsse.JsseProvider
security.provider.3=sun.security.provider.Sun
#Disable the below providers for FIPS compliant
#security.provider.1=sun.security.provider.Sun
#security.provider.2=sun.security.rsa.SunRsaSign
#security.provider.3=sun.security.ec.SunEC
#security.provider.4=com.sun.net.ssl.internal.ssl.Provider
#security.provider.5=com.sun.crypto.provider.SunJCE
#security.provider.6=sun.security.jgss.SunProvider
#security.provider.7=com.sun.security.sasl.Provider
#security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
#security.provider.9=sun.security.smartcardio.SunPCSC
#security.provider.10=sun.security.mscapi.SunMSCAPI
Is there any other changes I need to perform, like using any special jar, compiling with any argument, etc.?
To be FIPS 140-2 compliant:
You have to use a FIPS 140-2 approved cryptographic modules. It will provides the approved cryptographic implementations. See: https://csrc.nist.rip/groups/STM/cmvp/documents/140-1/140val-all.htm. Read the description and/or the certificate to know the version to use.
For each cryptographic operations (signature, encryption, key establishment, hashing ...) you also have to use approved security algorithms and parameters. Read: https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402annexa.pdf. The document provides also a lot of references about the configuration of the security functions (key size, elliptic curve, ...).
For your case:
AES128, AES192 or AES256 for encryption, with operation mode GCM, CCM, CTR, CBC, CFB, OFB (Or XTS for storage).
RSA for Key Establishment or Signature with key size of 2048 bits minimum.
I have a case where I need to encrypt some files using OpenPGP. I am using Bouncy Castle to do so.
As I understand it Bouncy Castle encryption can be used in java in two ways:
I add Bouncy Castle as a provider and continue to use the standard Java libraries.
I use the classes specified in the Bouncy Castle library directly.
I wanted to know the pros and cons of both the ways and which method is recommended.
Also if I am using the second approach then why do I still have to add Bouncy Castle as a security provider. If I do not do so then I get a "No Such Provider" exception when I execute the following line:
PGPEncryptedDataGenerator encGen =
new PGPEncryptedDataGenerator(
new JcePGPDataEncryptorBuilder(PGPEncryptedData.CAST5).setWithIntegrityPacket(withIntegrityCheck).setSecureRandom(
new SecureRandom())
.setProvider("BC"));
As I understand it Bouncy Castle encryption can be used in java in two ways:
I add Bouncy Castle as a provider and continue to use the standard Java libraries.
I use the classes specified in the Bouncy Castle library directly.
I wanted to know the pros and cons of both the ways and which method is recommended.
The Java JCA is a better designed and certainly better documented API. It has better defined exception handling, more up to date parameter handling (ByteBuffer).
Furthermore, through the use of the provider abstraction, it can be enhanced not just with software based providers such as Bouncy Castle, but also with platform functionality and hardware providers. So if you program against the JCA you'll be rewarded with a more flexible runtime.
On the other hand the lightweight crypto API is a relatively low level API that provides a lot more functionality in a relatively well structured fashion. If you use it you're basically choosing Bouncy Castle as your sole provider of functionality. Bouncy Castle contains specific implementations in Java code only, which means that you won't get (much) hardware support.
Bouncy Castle's lightweight API doesn't have jurisdictional restrictions (such as 128 bit AES keys). So you can use it for your own protocol if you want to work around those restrictions (don't get me started on the reason why these restrictions are there in the first place if you can download an equivalent library without issue).
Also if I am using the second approach then why do I still have to add Bouncy Castle as a security provider. If I do not do so then I get a "No Such Provider" exception (...) ?
The Bouncy Castle PGP functionality is actually build upon the JCA; it's that simple. If it wasn't you could not use Java keys or other (platform or hardware) cryptographic functionality.
A lot of other software components also assume the JCA to be used. You cannot simply plug the lightweight API into an existing protocol implementation.
My application has to publish a file to several clients over a common channel. I have been doing below process to encrypt it
Generating a symmetric key to encrypt the data.
then encrypting this key with RSA public key and publish it.
Considering all the clients of this application have application's RSA public key, is there any standard format to encrypt a file before publishing it?
Apparently, there are several standard formats for encryption. One of the most popular standard format is Cryptographic Message Syntax (CMS). Also refer to specs for CMS at Internet Standard. This format is widely used for for S/MIME mail message security.
Bouncy Castle APIs provides a wonderful support for this. BC's bcmail-jdkNN-MMM.jar is the Bouncy Castle SMIME/CMS library which is of your use. It is a package for processing RFC 3852 Cryptographic Message Syntax (CMS) objects - also referred to as PKCS#7 (formerly RFC 2630, 3369), and also dealing with S/MIME objects (RFC 3851).
Another popular standard format, XML Encryption format. end-to-end security for applications that require secure exchange of structured data. XML itself is the most popular technology for structuring data, and therefore XML-based encryption is the natural way to handle complex requirements for security in data interchange applications.
I have just watched a crypto 101 talk which said if you are typing the letters "AES" into your code, you're doing it wrong! The solution was to "just use GPG".
If you are storing your data on the cloud, all readers and writers need to know the key. If the key is a public private key, that's just a slow key but not a more secure key than just having a good password?
What standard alternatives are there to GPG that properly encrypt data at rest but use a shared secret instead of public keys?
I use Java, and would like to use a library, but want interchange with other platforms.
The solution is wrong in terms - you don't use "GPG" but OpenPGP.
Indeed for encryption using shared secrets (passphrases and alike) OpenPGP is optimal, as it supports multiple methods at the same time and includes compression.
The alternative would be to use CMS encryption with keypairs derived (in some predetermined way) from the shared secret. However such scheme is not standard.
I can remember also XML encryption that supports encryption with symmetric keys, but it has certain security flaws.
So OpenPGP is probably the best way to go.
Regarding compatibility - OpenPGP-compliant library should create packets that can be later processed by any other OpenPGP-compliant library or application. Unfortunately OpenPGP implementation in popular BouncyCastle library sometimes produces not compliant packets - we came across its issues several times when packets created with BouncyCastle could not be processed by GnuPG or our SecureBlackbox due to issues in the packet created.
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.