CODEWITHSUNDEEP
javaobfuscation
Axel Carré
Axel Carré

Reputation: 83

Obfuscation to hide some algorithm

I am working on a java client/server application. Every user must be able to create and modify files (containing some sensitive data) through the client application (marking them with a digital signature) or manually (marking them with a 99.99999% chance wrong signature). The signature does not use client identity, only the content of the file, which mean two distant clients creating the exact same file would end up with two files with the exact same signature).

After doing pros and cons, I ended up thinking about using obfuscation to protect from malicious users than would use reverse-engineering to find the algorithm delivering digital signature for a given file.

But if I've understood it correctly, obfuscation makes code harder to read for human, harder to understand, but my goal is more about hiding the algorithm behind digital signature. Any idea on how to make it:

At the moment my idea are:

Also I'm not sure to understand how compiling and reverse engineering work.

When a code is compiled, I ever thought variables were nicknamed in the "method area", and that a reverse engineering would give us back a code with variables named a, b, c... etc. But it appears not to be the case and it makes sense now that I think about it, since reflection is possible in java, am I right on that last part?

To conclude, I'm not sure to understand how this would prevent user to reverse my code (except for variable names' part).

Upvotes: 0

Views: 330

Answers (2)

GhostCat
GhostCat

Reputation: 140427

Let's clarify your misconceptions about obfuscation:

  • You don't do it on your source code. In the java world, if at all you obfuscate the binary delivery, in other words: your class files. Or to be precise: it is mostly about class file obfuscation, there are commercial tools for source code obfuscation.
  • Obfuscation is still used within the Android realm, but "pure" java shops, it is rarely used these days

And most importantly: "security by obscurity" rarely works.

If you are really serious about running your code at the client side (where you have no control over it), it might be better to do that part in native code, and to deliver machine compiled binaries for that part.

Upvotes: 0

Stephen C
Stephen C

Reputation: 718758

I ended up thinking about using obfuscation to protect from malicious users than would use reverse-engineering to find the algorithm delivering digital signature for a given file.

I think this is misguided for the following reasons.

  1. There are a few well-known cryptographic hashing functions that are understood to be sufficiently secure against reverse engineering, given the current "state of the art" in cryptography. You can read about some of the common ones here:

    You can combine a cryptographic hash function with public key encryption to provide digital signatures that are (should be) secure enough for your use-case. For example:

    There are solid implementations of these technologies available for Java. There is no need to implement your own.

  2. Designing and implementing your own digital signature algorithm is unwise. Unless you are an expert in the mathematics of cryptography, your algorithm is likely to have weaknesses that you are unaware of. And you are an expert, you will fully understand the difficulty in creating a strong system.

  3. Obfuscation is not an adequate protection against reverse engineering to extract secrets (such as an algorithm) from code. Indeed, in the case of Java it is little more than a "speed bump" for a skilled hacker.

OK, I'm just struggling to understand how my app will be able to determine that the signature of "a" is equals to some word while a user can't find the same algorithm on the internet to do exactly the same and find the same signature.

You have a point. If the "text" that you are creating a hash for is known to be very short and/or easy to "guess", then it will be feasible to brute-force its hash, assuming that the algorithm is known. (For example, Gravatar's approach of using hashes of email addresses for privacy is flawed, because it is not hard to assemble a list of known email addresses, generate their hashes and store them in a database that can be queried.)

However, once you have gotten beyond a few tens of random bytes of data, or a few tens words of text, brute-force (and rainbow table) attacks become impractical. So, you can can start with your document, add an "envelop" with a timestamp, other identifying information, and (if necessary) some random junk to pad out the source text. Then hash the lot. The other end merely needs to repeat the process and see if they get the same hash.

(There is more stuff you need to do to create a full digital signature ... but read the link above.)

Upvotes: 1

Related Questions