I need help using Bouncy Castle RSA Libraries for a school assignment, but it looks very complicated and I'm trying to learn and need some guidance.
For my assignment I need to just generate a public and private key. Then encrypt a block of message and do timing measurements. Then do the same for decryption.
Could someone point me in the right direction?
The Crypto Library is huge and I'm confused on how to go about this.
Thank you very much.
PS: Basically I need to generate the Key Pairs, Execute the encryption and decryption using different key pairs that are randomly generated.
I would appreaciate any guidance, thanks
Normally with Java you would use the Java Cryptography API's, in the java.security.* and javax.crypto.* packages.
BouncyCastle includes a provider (i.e. an implementation) for this API, but for RSA the one delivered with your JRE should be fine, too. (BouncyCastle additionally also has an own API which does things in other ways.)
You would need the KeyPair and KeyPairGenerator classes for the key generation, and the Cipher class for the actual encryption and decryption operation.
For the timing measurement, repeat the encryption/decryption some thousand times to get reliable data.
Related
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 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 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'm trying to make a decryption of a string in JAVA encrypted in Delphi with DCPcrypt. DCPcrypt uses a Hash algorithms and a custom key for initialization, then an encryption algorithm. Is it possible to decrypt it in JAVA using Java ™ Cryptography Architecture or another JAVA cryptography library? If not have you any idea what libraries combination in JAVA and Delphi allows to have the same results for decryption and encryption of any string ?
Try Chilkat Android and Chilkat Delphi: https://www.chilkatsoft.com
The one thing you have to do to get the Chilkat examples for Delphi and Android to produce the exact same encrypted strings is change the padding scheme to 4. Out of the box, the Android example has a padding scheme of 0, and that results in different trailing bytes. It's worth noting that the Delphi and Java examples have no issues at all.
Now that you've got the answer, and having spent a week on this, I can tell you what doesn't work.
Trying to mix 3DES messages, whether using SHA1 or MD5 on the password, between JCE+JCA and Delphi Encryption Compendium is not going to work. For starters, DEC MD5 is crap. You're better off using the Indy MD5 hash class. It's too bad the version of Indy that comes with XE doesn't include encryption, because their MD5 hash class is flawless and easy to use.
Lockbox didn't want to play nice with Java encryption. In that case it may be that I was so burned out on DEC that I had lost all patience. Again, I spent an entire week, all day and into the night trying to get the various parts to work. I never got to DCP. The next thing I tried was Chilkat.
With Chilkat, I downloaded the trials and installed them, ran the examples, and it all worked straight out of the box. Done.
I've been working on a system that uses asymmetric encryption in a large number of files. I'm currently using RSA with 4096-bit keys to encrypt a 256-bit randomly generated AES key for each file, but performance is somewhat lacking, as one required operation is to scan through all the files (estimated number when the system is in use is around 10,000) and identify which ones can be decrypted using a specific private key. While I don't expect this operation to be instant, it is taking too long at the moment (~2 files processed per second). I considered reducing the key length, but even taking it down to 2048 bits doesn't provide the level of performance I need. 512 bits would just about cut it, but as such keys can now be cracked trivially that is out of the question.
Can anybody point me in the direction of a system that is faster but of similar cryptographic strength? It would need to be implemented via a Java JCA provider (e.g. something like bouncycastle) in order to plug in to my existing application neatly. I know bouncy castle supports El Gamal, but I can't find any details on how strong this algorithm is, or if it is even likely to be any faster than RSA. I also hear about elliptic curve systems that only need relatively short keys (384 bits or the like), but don't know where to find an implementation of one of these.
For your question as asked, try Diffie-Hellman over elliptic curves, also known as "ECDH". Estimating security is a bit difficult once we deal with sizes that cannot be cracked with current technology, since this depends on how we bet on future technological evolutions. Yet one can say that ECDH over the P-256 curve provides "128 bits" of security, a level which is similar to what you would get from 2048-bit RSA. That level is widely sufficient for all current usages, or, more appropriately said, if P-256 is not enough for you then your problem has very special needs and cryptographic strength is likely to be the least of your worries.
On my PC (a 2.4 Ghz Intel Core2, 64-bit mode, running Linux), OpenSSL claims to crunch out about 900 ECDH instances per second, using a single core.
Edit: for estimation of key security, depending on the length, for several algorithms, see this site.
Why don't you calculate a cryptographically strong hash of each key, and then store that in the clear with each filename? Then, given a key that you need to match against all the files, you can simply hash the key and look it up in the table.
I'd go for an approach that requires less RSA operations. SSL/TLS, although they use RSA etc for encrypting AES etc keys, do not use AES for the data simply because it is a computationally expensive operation at sufficiently large key sizes for security to be done on a per-packet, or in your case, per-file basis.
Another public key system is: http://en.wikipedia.org/wiki/ElGamal_encryption. Security-wise I believe it has yet to be broken but would personally put my trust in RSA for now. I do not know if there are any elliptic curve encryption algorithms currently available - that is to say I know they are being researched but understand they may not be ready for production use and I heard there were patent issues.