Richard Tookey

There is even more wrong with this code than with your previous code. I can't really follow the overall design logic but it still seems that you are generating both the RSA private key and public key for your client.

In your previous post I said that using toString() on an array did not result in a representation of the content of the array..

You are still working with String when you should be working with byte arrays.

Testing a big amorphous chunk of code within a servlet is very difficult. You need to separate out the various parts of your code into manageable classes. You need a DAO (data access object) for you JDBC code and you need a DES encryption manager object for the DES and an RSA encryption manager object for the RSA. These can all be tested outside of your Servlet so that when you plug them into your Servlet you will be sure they are not giving the problem.

That code is flawed both in concept and implementation but primarily in concept.

Concept - the concept of public key cryptography is that private and public keys are generated by someone who is the owner. The private key is kept very very secret and secure so that it can only be used by the owner. The public key does not need to be kept secret or secure and should passed to anyone who needs it to use it. This means that you are unlikely to need to generate an RSA key pair in a Servlet since you would have access to every private key generated in response to a client request and your client would not have access unless you sent it to him. Now you could send it over HTTPS to make it secure but your client would then be able to plausibly deny anything signed by that key since it could equally well be have been signed by you.

Implementation - in your encrypt method this line of code
return cipherTxt.toString();
return a string representation of a reference to an array and does not in any way represent the content of the array. Also, the cipher text is binary and an only safely be converted to text using some form of encoding such as Base64 or ASSCII or ASCII85.


Before going any further you need to spend a significant time learning the fundamental concepts since your current code can at best result in a security flawed implementation.

Sharad N Srivastava wrote:
Also, instead of firing multiple process from Java, I created a shell script which accepts the file name as input and does all the heavy operation like SORT/SPLIT/Logic execution and returns the result.

You are still using Runtime.exec() so you are still creating a Process object so you still need to handle the Process stdout and stderr streams and you still need to handle the Process exit code. You may get away without doing it properly for a time but at some point it will jump up and bite you.

Interesting. "< 10ms for a file of 500MB size" seems to me to be remarkable! I have never achieved anything like that speed .

P.S. I hope you also examined the Process exit status.

I use as root directory the user's home directory which can be obtained from the "user.home" system property . See https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html .

I don't understand why you are resorting to the use of Runtime.exec() since I see nothing in your code that cannot be done in pure Java.

Having said that, addressing your immediate problem, you are not handling either the stdout or stderr streams associated with the Process objects generated by Runtime.getRuntime().exec(commandSortFileNew1) and you do not seem to be looking at the exit status code of the Process object. I know that you are not expecting anything on the Process stdout stream since you are redirecting the sort to a file but it is as well to purge it anyway.

Now why should you do all this? The stdout and stderr write to internal buffers and when either fills the Process is halted until more space becomes available BUT you are not reading from the stdout and stderr so no more space becomes available and you get a deadlock. If you do not process the Process exit code then you have no idea whether the command succeeded or failed. Now this may not be the cause of your problem but writing out the content to your console will probably give you an idea as to what is wrong.

You need to process stdout and stderr in two different threads. You can use the current execution thread for one stream and then a new thread for the other.

All this and more is explained in http://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html .

The extra code required for this is quite significant and you may want to think about going back to a pure Java solution.

Several points -

1) In its basic form the maximum length that RSA can encrypt at a time is limited to the size of the RSA modulus (or the modulus length - 11 when using PKCS11 padding by using the default padding as you are doing). One can break the input into blocks of less than this modulus and encrypt them individually but then one has to handle the problem problem that in RSA N bytes of cleartext does not necessarily produce N bytes of ciphertext..

When encrypting more than the RSA length one normally creates a hybrid encryption. In this approach one generates a random key for use with a block cipher such as AES and then uses this to encrypt the actual data. The random block cipher key is encrypted with RSA and sent with the AES cipher text. This approach is presented more formally in section 13.6 pf "Practical Cryptography" by Ferguson and Schneier.

2) In my view CipherInputStream and CipherOutputStream are very poor. They swallow all exceptions so when anything goes wrong one never hears of it.

3) Chaining streams as you have done makes it difficult to read the code and if anything goes wrong it is difficult to work out which term in the chain caused the exception. It costs nothing to use something like
InputString fis = new File("C:/Users/sanket jani/Desktop/IMAGES/KRISHNA.jpg"); CipherInputStream cipherIn=new CipherInputStream(fis, cipher);

4) I'm never very comfortable with reading and writing just one byte at a time using
while((i=cipherIn.read())!= -1){ fos.write(i);}

I have known this to fail. You would do better to read and write a chunk (say 4K) at a time.

rekha sen wrote:
I have made a change to the method to accept the Exponential values and it is like this,

public static Boolean isNumeric(String str) { return str.matches("[+-]?[0-9]*\\.?[0-9]+([eE][-+]?[0-9]+)?"} }

This method is handling every thing except "1." values.

Please help me in changing the regex to accept numbers like "1." or "100."
.

Using "[0-9]+" to define what can come after the decimal point says that there must always be at least one decimal character. Change the '+' to a '*' and it says any number of decimal characters which includes none at all!

If you are going to use regex in the future you would do well to put in effort to learn about them.

Swastik Dey wrote:Of course in this case it will be true.

It wasn't obvious to me but you are right it does pass though the resulting value is infinity but of course this does not matter to the OP.

Swastik Dey wrote:You may write a function that tries to convert the String into a valid number, if it fails means it might be having alphabets.

public static boolean isNumeric(String str) { try { double d = Double.parseDouble(str); } catch(NumberFormatException nfe) { //we caught an exception, so it's not a valid number i.e. containing alphabets. return false; } return true; }

Using your code what would happen if the number was 1.2345E1000 ?

rekha sen wrote:
Some of the numeric values are like this,

3.04005885553944E-06
1.19449873607102E-05
8.2121788104883E-06
5.22593197031073E-06
4.47937026026634E-06
2.98624684017756E-06
1.
3.73280855022195E-06

I WROTE THIS CODE AND IT IS NOT WORKING FOR THE ABOVE NUMBERS

public static Boolean isNumeric(String str) { return str.matches("[+-]?\\d*(\\.\\d+)?"); }



WHat I need to change to accept the above type of numeric values.

None of those will match your regular expression. Your use of matches() means that the whole line must match and those items with an E cannot match because of the E. The value "1." cannot match because your regular expression insists on having at least one decimal after the decimal point.

To match all your example values you must add to the reges a term to deal with the E and you must allow zero decimals after the decimal point. Simple enough.

Sekhar Nat wrote:Thanks Stephen. This works now.
Pattern mPattern = Pattern.compile("[\\+\\-]?[0-9]{0,8}([,|.][0-9]{0,3})?");

I don't see why the \\ pairs are needed?

Tushar Goel wrote:Yeah thanks Richard. I am able to achieve this but can we transfer decimal output "111217238859577568889117274385450287013" into "3158851493" which
is bignum output.

I understand both are same but in different format but can we changed decimal output to bignum output format.

I despair! We have established that the value "3158851493" is most definitely not the result of "bignum output format". You got that number from the flawed use of printf by printing some part (possibly the first 8 bytes treated as a long) of the bignum. If your technical people have been using this in the generation of format preserving encryption then they need to be shot. Without seeing your format preserving encryption proprietary C code one can say no more.

What I find interesting is that you don't seem able to say which FPE algorithm you are using. OK the code used might be proprietary but the actual algorithm of any encryption technique should never be. Kerckhoffs's principle says that the security is always in the secrecy of key and not the secrecy of the algorithm.

Tushar Goel wrote:Yes it is longer than 32 bit. Decimal value i am getting is "111217238859577568889117274385450287013".

If you allow signed values then
String hexValue = "53ABA93B9131C439D2942C7CBC483FA5"; BigInteger number = new BigInteger(hexValue, 16); System.out.println(number.toString(10));
If you want to force unsigned, as you probably will do for your encryption, then you will need to use
String hexValue = "53ABA93B9131C439D2942C7CBC483FA5"; byte[] byteValue = <some hex decoder>(hexValue); BigInteger number = new BigInteger(1, byteValue); System.out.println(number.toString(10));

I also wanted to ask why it is more than
32 bits? Doesn't understand the logic behind.

32 bits is 8 hex characters. You have 32 hex characters which is 4 times the length of 32 bits!

Tushar Goel wrote:
Can you please tell me if i have to convert Java output to the C output how can i do that? I have to give the output in same format as C output is.

Might be able to if you tell me what the decimal value should be. Note - the resulting decimal value MUST MUST MUST have more than 32 decimal digits. If it hasn't then it is not right.