How to exchange the public key to the client place. i have encrypted a document(text file) using RSA algorithm by using private key and then stored the public key as an java.security.Key object in a file using serialization.I want to know about the integrity of the serialized public key object whether it is safe option to do or any other option available.
A public key is usually just exchanged as a piece of text. It is then imported into a keystore. The exact method of doing is depends on the implementation (I've always used PGP).
I wouldn't expose the key as a serialized form of java.security.Key because it's not really standard. The key in it's simple form is the standard form of interchange.
On exposing the key as a download: it's public, so there's nothing an intruder could do by downloading your key. The only thing that could go wrong is that someone could fake your server and host a different key. Then sign with that key's private key and claim to be you. Of course you could have the same issue if you mailed it to somebody. But then at least you would know who you mailed it to.
The safest approach is to spread the key out-of-bound. Like on a usb stick.
Depending on your cause, I think you can live with the risk.
Joeri has answered on the security aspects - I have nothing to add about that.
The main problem you might have is the serialized representation changing between library versions, which is a potential issue with any use of Java serialization.
Of course there are other ways to do it. The RSA public key should have an industry-standard encoding which you can access using the getEncoded() method. This gives you an array of bytes which you can write to a FileOutputStream. So it's really easy.
Related
I'm university student and have got a task to do the secure under the requirement "Don't store the whole secret on the server but still able to validate". My scheme is making an RSA key pair on the client, store the public key on the server and throw away the private key. When authentication needed, Server will encrypt some string with stored private key, let the Client make a same key again and decrypt it with the key and send back to server.
(Maybe) Explained as follow
Some data ----Processing----> RSA-1024(or better) PrivateKey + PublicKey
Private key have to be generated and was the same every time
Public key have to be stored on the server and compatible with given private key
The problem is the processing, I want to let the Client generate the same key for every time I want (could use hashed of some data as an input) but I don't know how to config this. Both Private and Public key is still need to compatible with each other.
Strong private key in the device make the application can't be used if user change the device.
I tried to research all along but most says that I have to save the key on the device otherwise generate a new key every time which is not my aiming.
I have already talk to my Project Teacher and this scheme is passed. but I still need more comments if this scheme has any error or if there are any suggestion from you. I'm still wondering if this scheme is better than storing hashed data and keep it for validation or not.
My scheme have to works on Android Client and PHP Server.
Highly thank you for reading and sorry If there is any error in this thread. I'm quite new here but this time I'm quite sure that this thread isn't duplicated.
I've read about the Adobe CryptoSupport that is now in CQ5.5+, which is meant to provide a utility for encrypting and decrypting data, for example, to store API keys in the JCR more securely.
The JavaDocs or the general Adobe documentation give no details on its implementation, just stating that:
Note that this method and the decrypt(byte[]) method provide full
round trip support:
decrypt(encrypt(plainText)).equals(plainText) == true
Please note,
that calling this method twice on the same plainText does not return
the same cipher text:
encrypt(plainText).equals(encrypt(plainText)) == false
This is reasonably useful, but what it doesn't tell me is how these ciphers are enncrypted to begin with. I've tried encrypting on one CQ instance & decrypting on another, but this doesn't seem to work.
To use this feature with confidence, I'd like to know on what CQ bases its encrypted.
There are two main concerns I have:
How do I know that the service is salted (think that's the correct term) based on something secure? Or if it needs to be configured, how do I do that? (i.e. does it use the equivalent level of security OOTB as a log-in of 'admin/admin'!)
If the encryption is environment specific, does this mean that I cannot encrypt data & then transfer across between servers?
Bundle description in the Felix console states that
The Crypto Support bundle provides a CryptoSupport services which
allows applications to encrypt and decrypt binary and String data.
Encryption is based on the symmetric AES/CBC/PKCS5Padding (AES
algorithm, CBC mode with PKCS5 padding) from the RSA JSafe libary.
Key is randomly generated during the first start of the Adobe Granite Crypto Support bundle and then saved as /etc/key/master property. It is per-instance by design and I don't think it's a good idea to move this key between CQ installations. Actually, Adobe says it's a good idea to move key between author and publish instances.
Answering your questions:
you don't need to worry about configuring the service as it's done automatically during the first bundle activation,
you can move encrypted data from one instance to another as long as you also move the key.
In my application I want to use Private key which will encrypt password once and decrypt as many times the tool will be run.
Application will run like:
User will encrypt the password using the tool.
Then user will paste that password in properties file.
When next time tool will run it will read that password and decrypt it to login.
Here I am facing problem like, when I encrypt the password I am doing it using another tool just for encryption perpose. So when I try to decrypt it the key is different than key generated. How can I share private key between these two tools..
Thanks..
I think you are confusing symetric and asymetric encryption. When doing symetric encryption you can use the same key. In asymetric encryption you have two keys. A public key with which you can encrypt your passwords, but you can't decrypt them with this key. This is only possible with the private key.
Therefore you don't need to share a key between those tools. Like the name suggests the private key should never leave you system.
You mixed up different things...
When you use a private key to encrypt something you will need the corresponding public key to decrypt.
If you really want to do this then you can put the path to the public key into the properties file also.
What you have described is some symmetric cipher which uses only one key.
Also, as dasblinkenlight noted, make a password decryptable yields some security issues so test if you can design your application different...
Thanks to all of you for your replies,
I am very new in data encryption. Trying it for the first time..
I am working on a tool which is basically run using script. The code will be kept on secured server where very few people have access. Just the concern was the Users do not want to keep password in properties file without encrypting it. So if any one else try to configure properties file they should not be able to figure out the password. As there are there will be three different loging credential will be there for three differnt sources. And respective admins will configure them from the same file.
I found one solution over it.
http://www.code2learn.com/2011/06/encryption-and-decryption-of-data-using.html
Which is best suited solution for my problem...
:)
I think your main concern is sharing the key between applications.
In my opinion, the best way to do this would be to use a Public-Private Keypair. You could distribute the public key and keep your private key safe.
If several apps are used to generate passwords, then use the public key to encrypt.
If one app generates the password and several apps use it then you could encrypt with private key and all your other apps can use their bundled public key to decrypt the password.
Point is, once you have figured out your keypair distribution, you could you either public or private to encrypt or decrypt depending on how the application is designed.
Please refer Beginning Crypto examples for more details on how to create keypair and encrypt/decrypt data.
Android's security manual says that it is not safe to keep public key (used for Android market) just as a string and it should be hidden/encoded somehow.
Can somebody please provide me with example how it can be done?
(I don't have separate server, so it can not be stored there)
Upd. Believe, this is quite common task related not to Android, but to other apps also.
The relevant text from the page you linked to is this:
Important: To keep your public key safe from malicious users and
hackers, do not embed your public key as an entire literal string.
Instead, construct the string at runtime from pieces or use bit
manipulation (for example, XOR with some other string) to hide the
actual key. The key itself is not secret information, but you do not
want to make it easy for a hacker or malicious user to replace the
public key with another key.
That's pretty much all you need to know. There's no harm in people knowing your public key, the potential harm here is that someone replaces the public key in your program with their own in an effort to divert in-app purchases to their own account.
They're suggesting that you make it more difficult for that attacker by storing the key in separate pieces or XORing the key with some other string. Now, instead of just pasting their key over yours, they have to figure out what transforms you're doing to the string and make their own key fit that pattern. This is more work and might deter casual attackers, but won't prevent someone who is really determined.
If you use the Keytool utility this is all done for you. You'll get a .keystore file on your local computer containing your private key(s) that is encrypted with a password; keep that file and the password secret and you're secure.
http://developer.android.com/guide/publishing/app-signing.html
In fact I believe the Android plugin for Eclipse even does all of this for you automatically.
On the public key, you can hash it and save it as a hash value. Better yet would be to salt the hash value with something you would know when you need to get the hashed value back. May be something like user name, or ESN. Look at android.telephony.TelephonyManager.getDeviceId()
I'm looking for a low-level encryption to write questions/answers for a test/exam application in Java. Both the questions and exam are objects. Basically, I need a way to serialize a object, write it to a file, whilst encrypting everything so no one can read the question/answers without my program.
I've heard of Protocol Buffers (http://code.google.com/apis/protocolbuffers/docs/javatutorial.html), but not sure if there is something newer/better out there or if it is the next best thing.
Cheers
-Tanner
You need two steps - serialization/deserialization, which converts an object to a representation which can be stored on disk; and encryption/decryption, which enciphers the on-disk representation.
In Java you can use an ObjectOutputStream to perform the serialization, and a CipherOutputStream to perform the encryption. First obtain a FileOutputStream, then pass that to the constructor of a CipherOutputStream, then pass that to the constructor of an ObjectOutputStream. Then you can just hand your Serializable object(s) to the ObjectOutputStream, and they'll end up serialized, encrypted and written to a file. (You will of course need to perform additional setup on at least the CipherOutputStream object, but that's the basic idea).
However, there is a rather large caveat to all of this. The encryption you're doing is no more than obfuscation - if you give someone the encrypted data and a program that can decrypt it, that person has all the information they need to decrypt the data themselves. There's no way to get around this - if your program can decrypt it, then your program can be pulled apart and its secrets found.
Judging from your description of the application, performance is not a concern. So a solution that serializes to XML (e.g. using XStream) and then encrypts the XML would be satisfy your requirements.
However, I should warn you that there is a significant risk that student with sufficient incentive could hack your encryption. I can think of only ways you can guard against this:
don't store the encrypted data on the user's machine at all, or
use an asymmetric cipher and don't ever do any decryption on the user's machine.
If you cannot do one or the other, your application is vulnerable. Hacking it is not quite as simple as reading the files with a text editor, but it is not all that hard either ... even if you feed the application through an JAR file obfuscator.