 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / April 2006Client-Side Encryption and Studio Creator
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 >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  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. 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 >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 [quoted text clipped - 3 lines] >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 SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > 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 >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. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. "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 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 >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 SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. "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 > [...] 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 "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 > "Don't even /think/ about inventing your own encryption unless you are, > or aim [quoted text clipped - 10 lines] > 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 > My impression is that most encryption algorithm development is being > done as academic research. For finding out the current state, I suggest [quoted text clipped - 3 lines] > > 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 [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" ;-) 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 > 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 > As an aside: if your project is sponsored by your university, then they > certainly have a moral responsibility to ensure that they are using [quoted text clipped - 3 lines] > 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 > 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 > Oh dear. I hope I haven't discouraged you. > [quoted text clipped - 9 lines] > > -- chris No, you haven't discouraged me at all. I am glad to find out that much less has been done in this regard and whatever constructive I do will add to building something new. Just another addition to the lists of tasks, and one which has lower priority for the moment. Thanks! 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.