Encryption/Decryption of XML on user machine - java

I have an XML file which I want to store on the users machine. I want this file to be encrypted, so that the user won't use/understand the data. When required, this encrypted file will get decrypted and the front-end will read it and use the data. For front-end and Encryption/Decryption I will be using Java.
I need some suggestion on how to do this. Greenhorn in cryptography.
What can be the best approach?

Encryption is very, very easy to do wrong. Wrong in case of encryption means that making a single mistake can break your whole encryption scheme.
When thinking about employing encryption, it's almost always (except in cases of professional security developers) a good idea to use the solutions the provider of your framework did for you. Java offers the cryptography extensions which you can start with here. There are some good examples for using it here.

You could use a base64 encoder/decoder if you want just to prevent viewing or/and editing your XML files directly.
It's not the best possible solution concerning security, but it would work if you want something easy and quick.

Related

Java Cross-Language Encryption

I am working on a game that has multiplayer support and I want to encrypt the server-client connection. I have done it before using a SecretKey object and an ObjectInput/OutputStream. However, I want to leave the ability open for other languages to connect to the server (if I ever take up another language and want to port my game.) Is there any way I could encrypt all the data without using Java objects so any language can use it?
You can create your own custom object serializer in Java with the Externalizable interface. The custom serializer can write out the state of the Java objects so that another language could read them. I've implemented this is a project where I needed serialization to work even if the objects changed and old state needed to be read back. The painful part of custom serialization is that you have to track the object fields carefully or your deserialize methods will create strange bugs.
Binary object serialization
One action you need to take is to serialize your objects to a binary format. You can do this using the standard serialization API, or you can create your own encoder/decoder. Be sure you describe your own protocol in detail - every bit should be described or you will run into trouble - if not directly then several years after.
There are standardized methods or creating your own protocol with binary encodings such as ASN.1, but if you take that route expect a rather steep learning curve. The general idea of using tag/length/value for values is a good one though, so maybe you can take a look at e.g. BER/DER encoding.
Encryption of your serialized objects
To encrypt, you can create your own cryptographic protocol. Most people on this forum go this route, and most fail. They manage to get their protocol working, but they also leave multiple security holes open.
One of the best ways of securing data in transit is TLS. So if TLS is applicable, by all means go this route. After initial setup, TLS has a relatively low overhead, so there is probably no need to try and implement a competing proprietary protocol.
You can also encrypt at application level instead of transport level. A solution to this is to rely on previous standards for cryptographic constainer formats. Well known formats are CMS (previously known as PKCS#7) or PGP. PGP and CMS formats are implemented in the Bouncy Castle libraries. They both are binary formats with many options present within them.
The way that I did it about six years ago, I serialized the object (so that it was a string) converted the string to a byte array, encrypted the bytes, and sent the data as bytes. The other end then reversed the process. I got this to work for encrypted communications between a Java server and an AS3 client. It won't work for languages that don't support byte arrays though. Do you need more details?

Is there a way to set up random access to encrypted data in Android?

I'm currently trying to provide a transparent encryption/decryption layer to files stored on an Android device. I need random access to each of these files (necessary for search algorithm). The layer needs to provide either a RandomAccessFile or a FileChannel to the rest of the program.
My (very) basic understanding of crypto suggests that certain cipher modes like ECB, CTR, XEX, and XTR could facilitate random access, but I'd rather use somebody else's tool before I reinvent the wheel. Much better to leave crypto to the experts.
An ideal solution would be an encrypted disk image that I could access using a Java library, but I haven't found anything that I could use for Android.
Is there a way for me to provide random access to encrypted files? This feels like something that a lot of people would want in their apps!
Random read access is easy: use CTR, but make sure you have correct key and nonce usage. Random write access could be just as easy, although with CTR you are leaking information in time if you change any block. So if an attacker simply gets a single view of one file then you would be OK, otherwise you directly leak information about the plain text.
You've got a specific usage scenario. If there are any libs that do this for you I haven't seen them yet. Furthermore, the key management is usually application specific too. I am afraid you will have to deal with threat scenarios.
ECB should not be used for related information such as strings or files. XEX (or XTS for that matter) is normally not available in Java crypto libraries (such as the Oracle JCE or Bouncy).

How can you protect/encrypt your Java classes?

Some time ago, in my work I needed to protect some classes against other people to read the code. For that purpose, I created a EncryptedClassLoader, that loaded previously encrypted classes, and can load normal (not encrypted) classes as well.
Working in that way was a little complicated, and testing too (compile, then encrypt, and then decrypt).
Is there any free framework to do what I needed, and is easy to handle? I mean, not only obfuscate, but also encrypt the files, so none can read or debug that part of code. It would also be great that I can change the keys for encryption easily (in my application, it was hardcoded).
Thanks in advance.
Short answer, you can't. Encryption doesn't work. Here's an oldish article about why it's pointless to use an encrypted class loader:
Unfortunately, you would be wrong,
both in thinking that you were the
first to come up with this idea and in
thinking that it actually works. And
the reason has nothing to do with the
strength of your encryption scheme.
You can obfuscate it, but that will only go so far, and in the end I'm a firm believer that your time would be better spend fixing bugs or adding features.
Encryption doesn't add much safety to obfuscation. Anyone that is able to run your program will also be able to dump the decypted bytecode to disk. I assume this is why encrypting the bytecode isn't very common, where signing it is for example.
If you do want to encrypt your bytecode, make sure you also obfuscate it and I think the method you are currently using would work just fine without adding any frameworks or libraries.
We use the JarProtector library to encrypt our jar files. No obfuscation, but only encryption. There is no option to change the encryption key, but defineClass() will never be called.
You can try VLINX Java Protector, it makes a native ClassLoader by modify JVM to encrypt and decrypt the class data, not the ClassLoader written in Java, can effectively protect your java code
The only way you can protect your code is simply to not allow the user to run it. Instead of distributing an application, sell access to an online service. Your code is then sat on a server and the only thing you're exposing is the interface.
The alternative is to protect your code with contracts and lawyers, but unless you wrote something really good then this is going to cost you more than the revenue you'd otherwise have lost.

what is the criteria to choose encryption algorithm for my system

I am working on a system which is going to be applied in the real environment. I need to make high security mechanism for the system, one of them is encryption for user's passwords in my database.
I prefer to use one way encryption method to two way encryption, the problem is I want to choose a good algorithm which has good performance and have reasonable reasons to convince my partners why i choose one algorithm instead of other.
Can you give me some tips for doing that?
Don't just use a simple one-way hash.
Use something like PBKDF2 or bcrypt instead. I'm sure there will be good, free, off-the-shelf implementations available for Java (assuming that they're not already included in the JRE itself).
i don't know what kind of argument you're looking for but :
SHA is a good one-way hash functions.
http://en.wikipedia.org/wiki/Secure_Hash_Algorithm
Edit :
I'm using Bcrypt but maybe you should look at Scrypt (http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html)

Encryption of IP address

I need to encrypt an IP address, save it to file, and then be able to retrieve it later. I was wondering if anyone could suggest a good way to do this. Just the name of some encryption algorithms would be fine or links to resources.
Ive done my research and have come up with a few solutions. Just wanted to make sure there wasnt something I missed. If it helps at all, the application is written in java. We do use JNI for some native functions, but would prefer to stay away from JNI.
Thanks
EDIT:
Its a client/server model. The server will send the encrypted ip address to the client. The client will decrypt it, and then connect to that address.The data will be just a string. Its IPv4.
As other answers have already indicated, AES is your best bet for this problem. However, as is always the case with encryption, the real problem is not which algorithm to choose; it is how to keep your key a secret. If it is simply a string in your source code, it would take very little work for someone to figure that key out and use it to decrypt your file.
Assuming that you want arbitrary encryption on the client then you have a serious key management problem. It is pretty trivial to reverse engineer client code to obtain an embedded encryption key. And you need to consider what you'd do if that key is compromised and splattered all over the internet. Once it's embedded in your code then it's out of your hands (see CSS and deCSS for more fun reading on that subject).
So, a better solution is to have the server do the encryption and decryption and the client to just send up a bunch of bytes that it's stored locally.
Now, what's a good way of encrypting stuff on the server in an easy to maintain manner? I'm talking about key management; ease of use; strength of encryption; easy Ant/Maven targets/goals to manage the generation of said server side keys and so on. One framework that works really well for me is KeyCzar by Google. Simple API and external management is a piece of cake. Take a look.
I can answer to your straight question about encryption algorithm: AES
Java has classes for that!
But I still have my doubts about the robustness of you solution
I'd personally use AES.
Some more resources:
http://java.sun.com/developer/technicalArticles/Security/AES/AES_v1.html
Java 256-bit AES Password-Based Encryption
http://www.aescrypt.com/java_aes_crypt.html
I strongly recommend using the BouncyCastle library for Java. It's a lot cleaner than the built-in crypto stuff in Java and significantly easier to understand. Instead of mucking around with passing names of algorithms to methods and seeing if you actually get a cipher back you can just use new. Much easier.
You mentioned you have a few solutions, why not mention them.
Also, this is a very general question, are you looking for a symmetric algorithm or prefer public/private key, or something that uses both?
If you are looking at keeping the key on the server, since IP addresses are small (is this for IPv6, http://en.wikipedia.org/wiki/IPv6) then RSA would be a good choice, as you can then keep the public key on the server but no one can create a new key without the private key.
How will you be using the data? If you are going to decrypt all of them then just keep them in one file, zip it, then encrypt the entire file.
More details would help to narrow this down, as there are a large number of solutions.
But for libraries, in Java, I like BouncyCastle (http://bouncycastle.org/) as they give a large selection and works well if you need to exchange keys with .NET.
UPDATE:
Based on the latest update to the question the biggest concern is how to exchange the encryption key.
Since this is being sent to a client, your best bet may be to use something like RSA to help with this. The client would have a private key, and the server would have the public key of each client, so that if one is compromised the entire system isn't. Then, the server generates a symmetric key (AES is fine, I like IDEA), and encrypts that key. Then, you transmit both pieces to the client, the client then decrypts the symmetric key and then the IP address.
This idea was made popular by PGP.
You may want to use BouncyCastle, as I mentioned, so that if your client is written in .NET or Java you can still do the key exchange, since it has APIs for both platforms.
How you get the key to the server, from the client, or vice versa, depends on many factors, but that will be the weak link in this whole system, and so that part needs to be designed carefully.
As commented elsewhere, it is pointless. The information is available by other means so encrypting it via this channel is a compete waste of time. Netstat is yet another way the address can be detected.
Is there no way to route the TCP traffic through a proxy IP and "obfuscate" the IP that way?
I don't see the issue there unless the said provider of the proxy blocks the required ports according to projects needs. It's too bad Cloudflare wont allow anything except HTTP/S requests through their service unless you get on Enterprise, otherwise there is your solution in a blink.

Categories