Unable to get same output for UTF encoding in .NET and java

Question

1.00/5 (2 votes)

See more:

Hi We have encryption logic where we are encoding using UTF8 but when using in Java we are using the same methodology to encode but the output byte stream is different.

Please let us know how to resolve the issue if we need to get the same output from both C# .Net and Java

following is the C# code that we have used for encoding

byte[] baPwd = Encoding.UTF8.GetBytes(password);

value for

baPwd

is different when encrypted using Java.

Please let us know what can be done

What I have tried:

We have tried to get the logs for both C# code & java code but the byte code is different.

Posted 3-Oct-24 20:14pm

SNI

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Answer 1 · 2024-10-03T20:21:00

Encoding.UTF8 Property (System.Text) | Microsoft Learn[^] is not an encryption operation: it's a text conversion format. It takes a UTF16 string, and returns an UTF8 version of it.

Whatever you are doing with the Java code that we can't see, we can't tell - but if encryption is your intent then this is not going to work at all!

Richard Deeming · Answer 2 · 2024-10-03T21:20:00

Solution 2

As Griff said, encoding is not the same as encryption.

And when it comes to storing passwords, encryption is almost always the wrong thing to do. Unless you're writing a "password manager" app, or need to pass the original passwords to some third-party system, you should be hashing the passwords:

Secure Password Authentication Explained Simply[^]
Salted Password Hashing - Doing it Right[^]

As to why the bytes are different, perhaps it's something to do with endian-ness?
Little-Endian and Big-Endian in Java[^]

Posted 3-Oct-24 21:20pm

Richard Deeming

Comments

OriginalGriff 4-Oct-24 8:17am

Coming soon from the same poster: "How do I reverse the hashing so I can compare passwords?" :D

Rob Philpott 4-Oct-24 11:45am

I did actually spend an afternoon trying to do that once. Didn't work.

OriginalGriff 5-Oct-24 2:50am

See here: Decrypting MD5 and SHA: Why You Can't Do It[^]

Rob Philpott 4-Oct-24 11:46am

Actually, I think I need to expand on that and say that I wasn't expecting to get back to the original password, just something which would hash to the same value.

OriginalGriff 5-Oct-24 3:14am

I know you know this, but for those who don't: Unless you brute force it (i.e. keep trying passwords until you get a match) then when you find a way to do that the hashing algorithm is considered broken - which is why MD5 is not recommended for new projects - a way to find a "matching" password was found in 2008. Similarly, SHA-1 was discontinued in 2013, and is due to be phased out by 2030.

Rob Philpott 4-Oct-24 11:44am

"encryption is almost always the wrong thing to do." Yeah, that's what I thought, salted hashes used to be the preferred thing but when I was forced to change my password at work recently, which happens way too frequently, it detected for the first time that my new password was too similar to the old one - got to change more than one digit. Can't see anyway you could possibly do that with hashes, so maybe encryption is at work here. Or maybe they take different hashes of different parts of it and compare those - that might work. Hmm....

Richard Deeming 7-Oct-24 3:17am

One possible approach would be to generate minor variations of the new password, hash them with the old salt, and see if the result matches the stored value for the old password.