Client-Side Encryption and Studio Creator

[Dev]

Hi all!

Profile: I am new to web technologies and am using the J2EE 1.4
tutorial (June 2005) release to get acquainted with the technologies -
JSP, Servlets and Beans. I've a decent experience in programming in
Turbo C++. I intend to develop a web application which heavily uses
databases and also manages personal information of its users.

Reason to be here:
1) As I've said that the app has to deal with personal info, I need to
implement client-side encryption (the client sends and receives data in
encrypted form) so that anyone cannot 'hook' the transmission lines and
steal the info... as a german hacking group did to steal Windows
Activation codes (I happen to like reversing too, but unfortunately
can't do it myself). Is there any way to do this using java? I know
java has methods for implementing encryption... I had made a small
application that encrypts and decrypts using DESede. An intro to SSL
cerificates in this regard would also be nice.

2) Sun Java Studio Creator: To make my learning a bit easier, I am
using this tool (VS .NET equivalent for JSF). Unfortunately, it
develops JSP in XML syntax if I use its drag-and-drop feature. Is there
any tool that gives me the code in HTML/standard form and also provides
drag-and-drop functionality? Is there any way to do this in Studio
Creator?

All responses would be appreciated,
Dev

 

[Roedy Green]

As I've said that the app has to deal with personal info, I need to
implement client-side encryption (the client sends and receives data in
encrypted form) so that anyone cannot 'hook' the transmission lines and
steal the info... as a german hacking group did to steal Windows
Activation codes (I happen to like reversing too, but unfortunately
can't do it myself). Is there any way to do this using java?

See http://mindprod.com/jgloss/jce.html

for a lightweight version that does not require JCE, see
http://mindprod.com/products1.html#TRANSPORTER

 

[Dev]

Thanks Mr. Green, for the resource you had shared. I still have to go
thru it satisfactorily, but I believe this will help me in solving my
problem.
Another Query: Do I have to make an applet (an invisible one) and
transport all the data thru it? I also need to change keys every
session because as long as the encryption is static, otherwise the
purpose will not be solved. How can this be done?

SVG: What plugin/component do I need to install to make it visible in
IE?

Followup:
Regarding JSC, I have shifted to WebLogic. It writes JSPs in HTML form
and also has drag-and-drop. Also, IT IS MUCH FASTER THAN JSC.

Regards,
Dev

 

[Dev]

Thanks Mr. Green, for the resource you had shared. I still have to go
thru it satisfactorily, but I believe this will help me in solving my
problem.
Another Query: Do I have to make an applet (an invisible one) and
transport all the data thru it? I also need to change keys every
session because as long as the encryption is static, otherwise the
purpose will not be solved. How can this be done?

SVG: What plugin/component do I need to install to make it visible in
IE?

Followup:
Regarding JSC, I have shifted to WebLogic. It writes JSPs in HTML form
and also has drag-and-drop. Also, IT IS MUCH FASTER THAN JSC.

Regards,
Dev

 

[Roedy Green]

Another Query: Do I have to make an applet (an invisible one) and
transport all the data thru it? I also need to change keys every
session because as long as the encryption is static, otherwise the
purpose will not be solved. How can this be done?

SVG: What plugin/component do I need to install to make it visible in
IE?

I need to know more about what you are doing to make specific
recommendations.

If you are going to do encryption with an Applet, you would normally
use SSL which does not need the Applet to have a permanent private
key. The Applet and Server negotiate one dynamically. All the Applet
needs is access to a list of certificate authorities (people who issue
SSL certs).

See http://mindprod.com/jgloss/ssl.html

If you want to use some other form of encryption e.g. RSA (see
http://mindprod.com/products1.html#TRANSPORTER
You might go for one-way encryption. The Applet can send encrypted
messages to the server but not vice versa. In that case the Applet
only need the PUBLIC key of the server.

If you want 2-way encryption, then the Applet at some point has to
generate a private key and store it permanently. It then can send its
public key to the server to use in encrypting message to it.. (This
is for low volume, e.g. a credit card transaction).

Each Applet could do its own socket/encryption or one mother applet
could, and pass cleartext messages to the other applets. All the
applets are running in the same JVM, so it primarily for your
convenience how you do it.

A simple DES connection requires each end know the other's secret key,
and you want to change that key often. That is probably the most
difficult to manage. You somehow have to exchange keys securely, say
by secure courier. If you are going to all that fuss you might as
well use a one-time pad and get theoretical uncrackability.
see http://mindprod.com/products3.html#ENCODE

 

[Dev]

If you want 2-way encryption, then the Applet at some point has to

generate a private key and store it permanently. It then can send its
public key to the server to use in encrypting message to it.. (This
is for low volume, e.g. a credit card transaction).

This was what I was actually thinking of. I want to generate this
key-pair for every session, i.e. a new pair is generated everytime the
user logs in.

You being a expert in this field, I wanted to know about the
feasibility of an idea I had. I can make more than 2 sockets (let say
n, where n is such that n! <= 2^(8*x), where x is an int. Acc to me,
x>1 will not be useful, lets see how) between the client and server,
break my data into n(+ x byte(s)) equal parts and assign these n
portions to each of the n sockets in any random fashion. The random
order in which the data is being sent will be specified by that/those
extra x byte(s). These x-bytes will specify the order only in one of
the n sockets, while in the rest, they will act as padding. The
position in the message where they will appear can be pre-decided or
arbitarated by the communicating machines.

Logic behind n! <=2^(8*x): n parts can be arranged in n! ways. To
specify these n! arrangements using x byte(s), I'll need 2^(8*x) bit
arrangements, each bit pattern pointing to a particular arrangement in
those n! arrangements.
Justification of x=1: 2^8 = 256. This implies to satisfy the above
relation, n=5. This means we will have 5 sockets per client
communicating to the server. On the server side, there will be only one
thread for one client handling the communication. As I am living in a
country where 256Kbps is awesome, 5 sockets per client will virtually
leech the bandwith at clients' end.

I wanted to know this idea's performance overheads and its actual
ability to protect under a threat. To make things a bit faster, we can
use an encyption method which involves fewer bits, lets say 64 or 128.

I need to know more about what you are doing to make specific
recommendations.

Am an engineering student in third year of my degree, learning J2EE and
side-by-side making project in it for automating the workflow of my
college. I want to make it as secure as possible because the project
has to be deployed in a college, with thousands of students
scrutinizing it.

Because I am a student, I currently dont how to use the SSL thing. I
have too much to learn right now (J2EE, AJAX), and also dont want to
add another topic to the list. I hope I am not being rude here.

I hope my profile of a learner doesn't stop you from answering my
queries.

Regards,
Dev

 

[Roedy Green]

n parts can be arranged in n! ways.

There are so many ways to slip up, that you are probably best off
using a time tested algorithm. Lots of people have had a crack at
breaking it, and you can be pretty sure there is no easy way to do it.

 

[Dev]

"There are so many ways to slip up...".
This may be because of inexperience, but may I know how this may cause
a slip while encryting/decrypting? If these slip-ups may occur while
reversing, I believe encryption is meant to do this. Guess then this
makes it a compliment!

"...that you are probably best off using a time tested algorithm..."
What about their (time tested alogs) overheads? I'll need 1024 bit RSA
encryption which will consume a lot of CPU. Cant do that.

" Lots of people have had a crack at breaking it, and you can be pretty
sure there is no easy way to do it."
Sir, as far as I know, the worst thing a developer can do is to work on
assumptions. This is something that I cannot digest. I have to be sure
that no one can have a successful go at reversing it in near future.

Please dont take these as personal attacks. Last time around, someone
did. Please criticize me and comment on it so that I can come up with
something useful.

Also http://mindprod.com/jgloss/ssl.html states:
"SSL chews up huge amounts of the server's CPU time. One solution is an
SSL hardware box that acts as a proxy server." I also have some
hardware restrictions. We cannot run a dedicated SSL server. Also
obtaining SSL cert may cost something, which I am unwilling, and also
would be unable, to pay.

Therefore I need a new solution. As far as my findings reveal, I'll
need to use scriptlets in a .jsp page. Now I have to confirm whether or
not the client can reach the source. An alternative here could be to
use Custom XML tags. Comments?

Regards,
Dev

 

[Dev]

Addendum to why use other technology than applets...
I have *source code* of all the files in your jdisplay.jar archive.
This is the archive in which you have class files for your applets. I
had started from http://mindprod.com/jgloss/ssl.html. If I could
reverse this in matter of 5 minutes, then using applets for encryption
will not be a good idea at all. I have to do some experiments using the
jsp pages... see if I am able to reach their source.

Regards,
Dev

 

[Roedy Green]

Addendum to why use other technology than applets...
I have *source code* of all the files in your jdisplay.jar archive.
This is the archive in which you have class files for your applets. I
had started from http://mindprod.com/jgloss/ssl.html.

If you wanted the source, you could just ask for it. You would get the
comments too. You don't have all the backend stuff since it is not in
applet form. JDisplay itself is just the tip of the iceberg. The
touch part is in the various parsers. All JDisplay does in render
preparsed programs.

But you are correct an Applet is very easy to disassemble. You can
make it tougher with an obfuscator or much tougher still with native
compilation.

see http://mindprod.com/jgloss/obfuscator.html
http://mindprod.com/jgloss/aot.html

 

[Chris Uppal]

[...] I wanted to know about the
feasibility of an idea I had.

Don't even /think/ about inventing your own encryption unless you are, or aim
to become, a cryptographer.

Because I am a student, I currently dont how to use the SSL thing. I
have too much to learn right now (J2EE, AJAX), and also dont want to
add another topic to the list.

I agree that it's one more think to learn, but if you're doing web
applications, then it's almost certainly something you will /have/ to know
about, so you may as well add it to your skill-set now while you have the
chance. Believe me, it'll look a lot more convincing to potential employers
than "I invented my own encryption instead of using SSL".

-- chris

 

[Dev]

"Don't even /think/ about inventing your own encryption unless you are,
or aim
to become, a cryptographer. "

I had followed job advertisements regularly for quite some time last
year. It seems that no one needs a cryptographer. So by that, there's
just no use doing this thing of encryption!

"Believe me, it'll look a lot more convincing to potential employers
than "I invented my own encryption instead of using SSL". "

Point noted. But still, I'd like to develop a new mechanism, though
I'll surely go through SSL now. Any resources that you may like to
suggest?

Thanx,
Dev

 

[Dev]

"http://mindprod.com/jgloss/obfuscator.html "

I had a complete thesis of a Ph.D student in Australia on this subject.
It seems that I have misplaced it. But I will surely find it...

"http://mindprod.com/jgloss/aot.html"

AOT have costs associated with them.

Please comment on usage of Custom tags in JSP for this purpose. I have
no leads on this front yet. Anyone out there who can help me on this??

Regards,
Dev

 

[Patricia Shanahan]

"Don't even /think/ about inventing your own encryption unless you are,
or aim
to become, a cryptographer. "

I had followed job advertisements regularly for quite some time last
year. It seems that no one needs a cryptographer. So by that, there's
just no use doing this thing of encryption!

"Believe me, it'll look a lot more convincing to potential employers
than "I invented my own encryption instead of using SSL". "

Point noted. But still, I'd like to develop a new mechanism, though
I'll surely go through SSL now. Any resources that you may like to
suggest?

My impression is that most encryption algorithm development is being
done as academic research. For finding out the current state, I suggest
going to Citeseer, http://citeseer.ist.psu.edu/. It tends to get
overloaded. Currently, the MIT mirror seems to be more reliable:
http://citeseer.csail.mit.edu/

Patricia

 

[Chris Uppal]

Dev wrote:

[re: crypto]

Point noted. But still, I'd like to develop a new mechanism, though
I'll surely go through SSL now. Any resources that you may like to
suggest?

[I'm assuming you mean crypto resources, rather than SSL tutorials.]

If you find that kind of thing interesting, then you may already have a copy of
Bruce Schneier's book (Applied Cryptography, or perhaps Practical
Cryptography), if not then one or the other (I've read[*] the first but not the
second) would be worth a look.

Another prong of attack would be to stuff some of the more distinctive
algorithm names (such as "Rijndael" or "Twofish") into your favourite search
engine and see who is talking about such things. Rummage outwards from there.

-- chris

[*] For "read" read "skimmed" ;-)

 

[Dev]

My impression is that most encryption algorithm development is being
done as academic research. For finding out the current state, I suggest
going to Citeseer, http://citeseer.ist.psu.edu/. It tends to get
overloaded. Currently, the MIT mirror seems to be more reliable:
http://citeseer.csail.mit.edu/

Patricia

Thanks Patricia for sharing this immense repository of infomation. This
will surely help me in pursuing my interests better and critically
analyze ideas that I come up with from time to time.

Regards,
Dev

 

[Dev]

The (softcopy of) book looks worth a read. Hmmm... Guess it will help
me do my homework before I jump into a discussion on this topic. Thanx!

My introduction to this topic started from Blowfish and DES. I had used
Java Cryptography by O' Reilly for implementing the latter. Believe me
its a very practical guide for using encryption without the need to
convert algorithms to source codes. Though the copy I have is a bit
old... coz it talks in terms of Java 1.2, its still a great starter
material!

Also, as I have seen in most of the other groups' posts, we seem to be
veering away from the topic. So back to the ol' thing- what do I do,
using Java technology and free of costs, to make the communication
between client and server secure? Applets (easy disassembly) and SSL
(costs and complexities requiring new hardware) have been ruled out.

Regards,
Dev

 

[Chris Uppal]

what do I do,
using Java technology and free of costs, to make the communication
between client and server secure? Applets (easy disassembly) and SSL
(costs and complexities requiring new hardware) have been ruled out.

If you don't use client side Java (applets or JWS) then you are limited to
HTML, a normal enough scenario.

I think you are overestimating the performance costs of SSL. The initial
handshake is computationally intensive, but the encryption used for the bulk
transmission (as opposed to agreeing keys) is pretty cheap. If you have a high
load then the SSL will add to that load, but if you are attempting to support a
high load on a zero budget then you are hosed anyway...

The certificate itself will cost, of course, but it may be that your university
has some way of providing you with one (I don't know enough about the subject
to say what technical options there may be here).

As an aside: if your project is sponsored by your university, then they
certainly have a moral responsibility to ensure that they are using
best-practise security for student's personal details. Depending on where you
are, they may also have a legal responsibility too. I think that besides
whatever information you get here, you should have a serious talk with someone
in authority at your university about the security and data-protection
implications of whatever ideas you come up with.

-- chris

 

[Dev]

As an aside: if your project is sponsored by your university, then they
certainly have a moral responsibility to ensure that they are using
best-practise security for student's personal details. Depending on where you
are, they may also have a legal responsibility too. I think that besides
whatever information you get here, you should have a serious talk with someone
in authority at your university about the security and data-protection
implications of whatever ideas you come up with.

SSL is a very widely accepted security mechanism. I wouldn't have
thought twice had there been no costs associated with it. The problem
is, the project is my initiative and a mean to show that I have some
mettle. A sort of challenge... Adding this level of security is also
what I have thought of. I don't think anyone would like to go behind
the scenes as long as the system is functioning properly. But as I've
said in one of my earlier posts, I am pretty serious about reverse
engineering too. I dont want a motivated newbie to just play around
with the system.

Guess I'd have to think on it from scratch. And the best de-moralising
factor is: Its been only a month since I've been introduced to web
technologies.

Thanks for taking out all the time for giving constructive comments.

Regards,
Dev

 

[Chris Uppal]

Guess I'd have to think on it from scratch. And the best de-moralising
factor is: Its been only a month since I've been introduced to web
technologies.

Oh dear. I hope I haven't discouraged you.

Maybe you could put this together as a sort of proof-of-concept. You'd be able
to say "it all works, but before we can deploy it for real, we have to arrange
for proper security with a real SSL certificate and a properly secured and
administered database". So your version would either not use SSL at all (but
have the hooks to put it in easily) or would use SSL with a free, self-signed,
certificate. Similarly, you would not need a "real" secure database (in secure
environment, with physically and logically restricted access, etc), but your
code would "talk" to your DB in just the same way as it would if the DB were
properly secured.

-- chris