[JDEV] encryption
Duane Maxwell
dmaxwell at entrypoint.com
Fri Apr 28 13:23:22 CDT 2000
You have a couple of problems here, both related to the fact that XML is
really a text-based scheme, with very specific rules for the encoding of
data.
What this means is that you have to take special care when you're sending
non-text data. In other protocols that sometimes need to carry binary
data, such as mail, the usual answer is to map the raw binary data to a
legal textual representation, typically, Base64. The basic idea is that
you take three raw 8-bit bytes, which together represent 24 bits, and split
them up into four 6-bit bytes (64 possible values), and encode them using
upper and lower case letters (52 values), digits (10 values), and two other
common ASCII characters, + and / (2 values). What this means is that your
data size increases by one-third, but it's valid text and can be safely
sent within XML with no other special handling. Another simpler, but more
inefficient, answer is to dump the raw data as hex digits.
So the other issue is the encoding of characters with the high-bit set.
The meaning of characters from 0x80 through 0xFF is very platform
dependent. XML by default uses a character encoding scheme called 'UTF-8',
which interprets the high bit as a method for extending the character set
in a very specific way that precludes you from just including arbitrary
extended ASCII characters and having them work as you expect.
What you should do, if you plan on embedding such characters in your text,
is to escape them using a method similar to the one you must use to embed
things like '>' and '<' (you _are_ doing this, aren't you?). To encode the
character at 0x89, for instance, you'd replace it by '‰'. Keep in
mind, again, that your characters has no consistent cross-platform meaning.
You should also encode other non-printable characters in the 7-bit ASCII
range the same way.
Somebody brought up the idea of using CDATA sections. This really just
keeps the parser from interpreting the text as XML, but really doesn't
solve the extended ASCII problem - also, you still have to be careful that
the CDATA terminator is not in the text. I've found them to be of marginal
value.
Regards -
-- Duane
chandan writes:
> Hi all,
> I am working in a Internet based project where we are using Instant
>Messaging
> service using Jabber Server. ( Using Win32 COM Object. )
> We are implementing security featrure in Jabber IM service at
>client side.
> While sending message, we first encrypt it, send message to
>server, store it at
> server in encrypted form and then decrypt it at client side when
>he receives
> message. But we are facing following problem.
>
> 1. When we send a message to another client, It goes thr jabber
>server.
> At that time, message is in encrypted form. When jabber
>server receives
> encrypted message, it gives error "Invalid XML received" .
>
> 2. If we remove encryption, and send message which contains characters
> like ¦ ( ascii value = 199) or other characters like that ,
>then jabber server
> responds with same error that "Invalid XML received" .
>
> So message is not forwarded to other client.
> Doesn't jabber server support these characters in message body?
> If it doesn't support, then how can we encrypt it since while
>encryption,
> these characters will come in message body.
> How can we handle this issue of security?
> Can you provide some solution to this or alternative to this ?
>
> Thanking in advance,
>
> chandan .
>
>
>
>
>
>
More information about the JDev
mailing list