-1

I want to now can I encrypt and decrypt an XML document using JDK 6 api. I do not want use any third party api like apache Santuario. The whole intention is that if an XML file is encrypted and delivered to a system which has been developed in C#.Net , Python or any other language, the encrypted xml document can be decrypted. If possible public key can be shared with the parties. The object is not to encrypt the whole file. I know, this can be done very easily. I want to encrypt the XML document clearly. It should look like an xml file but the body contents should be encrypted what exactly Apache Santuario does.

Cœur
  • 37,241
  • 25
  • 195
  • 267
user2688934
  • 21
  • 2
    So you want exactly what Apache Santuario does, but don't want to use Apache Santuario? That sounds ... tricky. Also: I don't understand they reasoning *why* Santuario is not an option. – Joachim Sauer Sep 10 '13 at 15:08
  • No I want to use in a generic way what Java provides. Anyway Apache Santuario is a third party API. It will be better if we do so using Java may be standard way so that other language can do it easily. Intention is not to develop our own api like Santuario rather to use already available apis in Java. – user2688934 Sep 10 '13 at 15:13
  • 2
    There is no existing API in Java to do this. You either have to use a third party library or write Santuario again. It's one of the core features of Java to keep the runtime lean (well, yeah, I know ... mostly) and add any extra feature with a library that you can chose. – Aaron Digulla Sep 10 '13 at 15:17
  • 1
    "It will be better if we do so using Java may be standard way" - in Java it is IS the standard to use a 3rd party API, and indeed an open source one to boot. To reject third party APIs is to not grok Java. – Stewart Sep 10 '13 at 15:19
  • Santuario implements official standards, so it doesn't get any more official than that, I really don't understand what you expect. The JDK can't (and shouldn't) provide *all* the functionality out of the box. In 10 years, when (maybe) XML encryption is widely used, it might move into the JDK (or it might not). – Joachim Sauer Sep 10 '13 at 15:27

1 Answers1

-1

The first step is to identify an encryption scheme that all three systems support. I think AES-256 is a good scheme but it's not supported directly by Python (it needs the PyCrypto module).

You should not try to implement your own scheme; cryptography is hard and even harder to get right. Just to give you an example: It took the world's experts on cryptography several years to build AES. So unless you're smarted than the whole world, your algorithm will be flawed.

That also means you might have to resort to an external library when a good scheme isn't supported by all three runtimes since writing a good cryptographic algorithm is also very hard.

After you have identified a schema, encode some test data to make sure each system can properly en- and decode it. These unit tests will make debugging later much easier since you can be sure the problem isn't in the binary data that you can't read.

The last step is them to make everything work with XML. This is relatively simple: Write a filter that keeps elements intact and replaces all text nodes with encrypted code blocks. Use Base64 to convert the binary encrypted data to XML text (make sure you still properly escape the text).

This works pretty well when the most valuable information is in text blocks. But some XML documents also keep important data in the attributes. To fix this, replace all such attributes with new <attr> elements. Original:

 <a foo="Important text">...

Encrypted:

 <a><attr name="foo">...encrypted value of foo....</attr>...

That way, you can convert between the two forms without losing data.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • Well, that is my last option to parse every element and encrypt the contents. But a hacker can easily guess the tag name. Like sdj344&*5%$, it indicates that tag contains the information about the salary. Somebody can play around it. It will be better if I can encrypt from the tag . – user2688934 Sep 10 '13 at 15:21
  • 1
    Sorry, but building your own encryption scheme is *bound to lead to failure*. Writing good encryption (be it protocol, cyphers, or PRNGs) is HARD. And there are *tons* of tricky ways to get it wrong. So **please, please please, don't try to invent your own encryption scheme!*** – Joachim Sauer Sep 10 '13 at 15:28
  • @user2688934: Read up on [Known-plaintext attack](http://en.wikipedia.org/wiki/Known-plaintext_attack). If your encryption can't protect against this, then the whole scheme will only feel safe but it won't be. – Aaron Digulla Sep 10 '13 at 15:34
  • But if you really want to waste more time: Create a list of all XML element names in the document, create a map which translates between the real name to `e0`, `e1`, ... and put that map into a new XML element at the start of the document to the receiver can then decode the shortened names. Might delay them for about 5 seconds. – Aaron Digulla Sep 10 '13 at 15:36
  • I just want to know whether Java 6 provides any API for XML encryption and decryption or not. If it is not possible, I will have to think some other alternative. Please help me in resolving my problem by a specific answer. – user2688934 Sep 10 '13 at 15:43
  • No, Java 6 doesn't have a simple API for XML encryption. If there was one, I'd have mentioned it. AFAIK, Santuario is the best option for this task ATM. But that doesn't solve the "read it with other runtimes", hence my answer. – Aaron Digulla Sep 10 '13 at 15:50
  • Thank you Sir. I was thinking about it. – user2688934 Sep 10 '13 at 15:56