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.
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've encrypted a file using Bouncy Castle API. I've successfully decrypted that file using the same API.
However I cannot decrypt the file using PGP command line
No error messages are shown but the decrypted file is not being generated:
C:\pgp-cli>pgp arquivo-cripto-cast5-bin.pgp
Pretty Good Privacy(tm) Version 6.5.8
(c) 1999 Network Associates Inc.
Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
Export of this software may be restricted by the U.S. government.
File is encrypted. Secret key is required to read it.
Key for user ID: contine
2048-bit RSA key, Key ID 0x150AAE5B, created 2015/03/26
Key can sign.
Could it be a compatibility issue?
PGP 6.5.8 is horribly outdated, a lot changed in cryptography since then. There is a bunch of ways to introduce incompatibilities with this old PGP version, and it's hard to tell what exactly is the problem. Since that old version, new ciphers (both symmetric and assymetric), hashing and I think even compression algorithms have been introduced.
If you do not want to buy a newer version, consider using GnuPG which is free and mostly even compatible with PGP's arguments (and probably has much broader usage than the good old PGP, which is owned by Symantec at the moment). A readily built GnuPG package for Windows is available on GPG4Win.
I am trying to use encryption algorithms from GNU-CRYPTO.
But whenever I try I get an: java.lang.SecurityException: JCE cannot authenticate the provider GNU-CRYPTO'
What is weird is the fact the I can use all hash functions from this package normally, but when I try to use ciphers I got those, for AES, DES, DESede...
Based on that I think the installation went fine. Also, when I use my code with other providers (BC,SUN), it works normally.
Could anyone help me with that.
algorithm="DES";
provider="GNU-CRYPTO";
generator = KeyGenerator.getInstance(algorithm); <-works
generator.init(randGenerator);
SecretKey key = generator.generateKey();
cipherEncryption = Cipher.getInstance(algorithm, provider); <- stops here
This is likely due to the fact that that project was integrated into GNU classpath. That means that the last signed provider was for 1.4. Up to 1.5 you had to create signed versions of your libraries for each Java version, so one for 1.4 is probably not compatible with 1.5 and higher (check for instance the bouncy class library, which has separate downloads for each version of Java up to 1.5). Furthermore, the certificate may have expired.
Please use cryptographic libraries that are actually maintained. There should be no need for GNU crypto in the first place.
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 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