paulmedic555

Hi all i am trying to make an application in java that achieve confidentiality/authentication. There is any way to encrypt any data with my private Key an then with an other's Public Key and the other decrypt it with his private Key and my publicKey?

lectricpharaoh

Yes, you can do that. Encryption/decryption is essentially applying a transformation to a stream of bytes, which Java (and most any other language) can do. The catch is you need to code the algorithms, and for this, I'd advise looking for an open source implementation that's out there, and seeing how it works. Remember that if you use such code, you may very well have to release your app as open source as well, so another option is finding a specification of how the algorithm works, and using that to write your own implementation of that algorithm from scratch.

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

Arevos

Decrypt it with your public key? Are you talking about encrypting and signing the message?

paulmedic555

I want to find a way such as the sender wants to make sure that ONLY the receiver can read the data and the receiver know that ONLY that sender send the data. I tried this by sequentially encrypt the data with the private key of the sender and then with public key of the receiver. Then the receiver decrypt it wit his private key and then with the senders public key. But during the decryption at the receiver i had a Bad Padding Exception. So i ask if there is another way

Arevos

Then you want to encrypt the message, and then sign it.

In effect the steps you'll take are:

1. Take a hash of the message (such as SHA1, Whirlpool or whatever)
2. Sign the hash, by which I mean "decrypt" it with your private key.
3. Generate a random key (make sure to use cryptographic random functions for this!) for a symmetric encryption algorithm (such as AES or Twofish).
4. Add the hash to your message, and encrypt the whole thing using this random key.
5. Now encrypt the random key using their public key.
6. Send them the fully encrypted message and key.

At their end:

1. They'll decrypt the symmetric key using their private key.
2. They'll decrypt the message and hash using the symmetric key. They can now read the message.
3. They'll then "encrypt" the hash with your public key, returning the hash to its original state.
4. They'll take a hash of the message, and compare it against the hash you sent. If it matches, the message is genuine.

However, with a decent encryption library, a lot of this will happen behind the scenes. What encryption library are you using for this?

ownagesbot

Yeh, also watch out for hash collisions, makes it easier for "crackers" to "crack" your system (i.e. there would be more than 1 possible hash), they also suck solely because it makes your encryption unstable.

Arevos

There have been some prominent attacks on SHA1, where a piece of data that produces an identical hash to the one supplied can be found, given enough computing hardware (I'd have to check this; it might take an infeasibly large amount of hardware, even with the new collision-finding algorithms). However, just finding a random piece of data with the same hash, is very different from finding a specific piece of data with the same hash. In other words, it's possible, barely, to create a set of random data with a valid signature - so long as you have access to a message signed by this signature, and are willing to spend a lot of computing time generating the message that corresponds to the hash. But that's not really going to do you any good - the text is essentially random and thus carries no specific information.

If you're that worried about hash collisions, it would make sense to use a hashing protocol that has no known attacks against it, such as Whirlpool. However, even with SHA1, your cryptographic signature is likely to be secure for quite some time, and certainly no cracker is going to be able to fake it any time soon, even if he or she has access to enough hardware to generate collisions. Also, it's worth noting that vulnerabilities in the hashing algorithm only affect the cryptographic signature, not the encryption itself.