greg stark

Ranch Hand
+ Follow
since Aug 10, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
3
Received in last 30 days
0
Total given
3
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by greg stark

Well, ok, but now I'm out of ideas
11 years ago
That code is pretty hard to read, but from what I can see it use a protocol that doesn't make sense for ciphertext. Ciphertext bytes can be anything, include the value 0. Your code seem to treat 0 specially, by incrementing a variable numNulls and then terminating the loop after 2 are received. I don't see how that can work.
11 years ago
There is nothing wrong with the code shown, which mean the problem is with some code you haven't shown.
11 years ago
Bouncycastle and Flexiprovider are just two. Obviously you are not looking very hard. It sounds like you want to spoon-fed knowledge, code, google results, ..., everything.
12 years ago
If your are encrypting in parts you need to use the Cipher.update() method until the last part. Only for the last part, you use the doFinal() method. Same for decrypting. You should always give the specify the full "algorithm/mode/padding" transformation when calling Cipher.getInstance(). If you want things to work across different platforms and even JVMs do not rely on defaults for *anything*.
12 years ago

kim pham wrote:Hi,
Didn't get the any exception? But it returns a null value.
Any suggestion?
KP


I suggest you read the first 11 words of my 16 word reply.
12 years ago
You seem to be missing the hex decode step on decrypt. Are you getting an exception?
12 years ago
Are you serious? All you have to do is read what I wrote and read the code you posted.
12 years ago
I would bet your problem is that you are using the no-args String.getBytes() method. This is almost always incorrect but it uses the platform's default charset. This default may be different on different platforms. By using the default charset you are risking nonportable behavior.

Always specify an explicit charset. In almost all cases you should always specify the "UTF-8" charset.
12 years ago
You should read your own code. Your are clearly processing the key differently for encryption and decryption. Also, you are using defaults in the getInstance() method in the encryption code but you are fully specifying the mode and padding in that same method in the decryption code? How do you know they'll be the same?
12 years ago
Ah, but "support" means something different here. Java will support new algorithms in the JCE by provider standard names that provider implementers may use to provide actual implementations. The standard names are only half the battle, you must then check and see if there are any JCE providers that implement that algorithm. As you can see here, none of the Oracle providers supports this algorithm.

I believe the bouncycastle provider supports ECIES.
12 years ago

Greg Burdett wrote:I had the same issue with Java 1.5 (on Windows 2008 / 64), "Cannot locate policy and/or framework files ". I got the policy strength files from Oracle, then unzipped them into the C:\Java64\jdk1.5.0_22\jre\lib\security directory. However, the ZIP file had a path of "jce" for the policy JAR files, and so unzipping them placed them at: C:\Java64\jdk1.5.0_22\jre\lib\security\jce. Even though I put that entry in the Path environment variable, they were still not found. I copied them up one level, to C:\Java64\jdk1.5.0_22\jre\lib\security, and then my Java program worked and performed 256 bit encryption / decryption, so it obviously found the files.

Greg Burdett



You're responding to an almost 6 year old question? Really?
12 years ago

Sud Umm wrote:It works fine only on Windows platform, but not on others.



You can't use SecureRandom in the way you are doing it. SecureRandom does NOT only use your seed to initialize itself, it also may seek to use other sources of entropy. This should be made clear in the Javadocs for SecureRandom; unfortunately it is not.

You should use a proper Password-based encryption (PBE) scheme.
12 years ago

Pat Farrell wrote:

What is your problem? In my initial response, I did not say his code was "wrong" or needed "correction"

Go find a fight with someone who cares about what you are ranting about.



Pat,

Peace, buddy. You do a great job providing excellent answers to many questions. This little spat does nothing to lessen my considerable respect for your knowledge and talents.
12 years ago

Pat Farrell wrote:

greg stark wrote:Since the low order bit is ignored, your key is equivalent to James', not better or more correct.


Yes, that was my intent, to show an equivalent set of octets to his as they are interpreted by any compliant DES cipher. For purposes of enciphering or deciphering using DES, James' and my keys are exactly the same.

I presented my version with the comment that it was a nit for a reason.

(Wikipedia: As nitpicking inherently requires fastidious, meticulous attention to detail, the term has become appropriated to describe the practice of meticulously searching for minor, even trivial errors in detail (often referred to as "nits" as well), and then criticising them (see nitpicking (pastime)).)



If you get to nitpick then so do I. James' version contains no errors whatsoever, not even minor ones. At best you expanded on James' explanation, not corrected it.
12 years ago