Win a copy of Java EE 8 High Performance this week in the Java/Jakarta EE forum!

Richard Tookey

+ Follow
since Aug 27, 2012
Richard likes ...
Java Linux Netbeans IDE
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by 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.

2 years ago
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 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.

2 years ago

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.
2 years ago
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.
2 years ago
I use as root directory the user's home directory which can be obtained from the "user.home" system property . See .
2 years ago
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 .

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

2 years ago
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

4) I'm never very comfortable with reading and writing just one byte at a time using

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

2 years ago

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

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.
2 years ago

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.
2 years ago

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.

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

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



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.
2 years ago

Sekhar Nat wrote:Thanks Stephen. This works now.

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

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.
2 years ago

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

If you allow signed values then

If you want to force unsigned, as you probably will do for your encryption, then you will need to use

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!

2 years ago

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.
2 years ago