Using Netbeans (in Linux)

[Simos Xenitellis]

Hi All,

I have tried getting SMSSalama to run under Netbeans, in Linux x86_64.
The experience is much better than using the plain WTK, and Bouncy
Castle installs just find from the GUI.
It is possible to import the source tree within the GUI, which is very good.
I'll make a write-up once I have all working, and put on the project wiki.

The issue I got into however is the same issue that got me to stop
with the earlier WTK only attempt.
I get an encoding issue, "IOException reading reader invalid first
byte 11111000" (or some other byte number).
This appears to be an issue that is specific to Ubuntu Linux, and I
believe it relates to Java using UTF-16 (same with Windows),
while Linux defaults to UTF-8. This would make sense because the
existing strings (the password) is ASCII.

I am looking into this issue at the moment.

Simos

[Arnold Minde]

Thanks Simos.

As I mentioned in the previous post in the other thread
(http://groups.google.com/group/sms-salama/browse_thread/thread/8d5d86a226037bc5),
I have checked changes to com.smssalama.UserProfile.java .

The password hashing should return a hex encoded string. Please,
update your local copy and see if the problem still persists.

If that doesn't fix the problem, we may still have figure out what
this is. If it fixes it, unfortunately, we will also have to figure
out why UTF8 does not take care of non-UTF characters (unless there is
something about UTF that I am missing).

Arnold.

2008/7/25 Simos Xenitellis <simos...@googlemail.com>:

[Simos Xenitellis]

Hi Arnold,

I managed to compile and run the applet with the new changes.

I think that Windows and Linux have different default file encodinds.
On my system, the program

import java.io.OutputStreamWriter;
import java.io.ByteArrayOutputStream;

public class WhichEncoding {

public static void main(String args[]) {
System.out.println("The system file encoding is : " +
System.getProperty("file.encoding"));

OutputStreamWriter out = new OutputStreamWriter(new
ByteArrayOutputStream());
System.out.println("The Java file encoding is : " + out.getEncoding());
}
}

produces

The system file encoding is : UTF-8
The Java file encoding is : UTF8

I believe on your system, you get cp1252 or something similar.
I suspect that Java implicitly converts from cp1252 (8-bit encoding)
to UTF8 but does not do the same if the source encoding is UTF-8.

Simos

[Arnold Minde]

Hi Simos,

Good to hear that fixed it.

I have seen a problem in my using of new String(byte bytes[]) and
String.getBytes() . These use the platform's default charset for
decoding and encoding respectively. And this could be the source of
the problem.

Here is what was being done before

byte[] digest = Security.digest(password.getBytes());
return new String(digest);

The digest is an output of the digest calculation that is not encoded
in any specific format.
But the constructor String(byte bytes[]) tries to decoded the bytes
using platform's default charset. The constructor will succeed only
when the resulting digest is also a correct result of encoding some
other string using the default charset.

In my case it always appeared to work because the default charset (you
are right it is cp1252 or Windows-1252) was happily decoding the
digest to some random string. In your case, it was failing because UTF
expects the first byte to be in one of the well defined patterns. And
that's how you caught the bug.

If only I could change my default encoding to UTF, I probably could
have reproduced the problem in my system.

The fix I checked in earlier should work because the digest is
converted to a hexadecimal string byte by byte.

Now all may appear to be working correctly. But the problem may come
back when one users sends another user an encrypted messages while the
default charset in their mobile phones is different, and getBytes() is
used to convert the shared password to bytes so that they can be used
during encryption. getBytes() will obviously result different outputs
in the two platforms, and so the receiver wont be able to decrypt the
message because getBytes() will return a different stream of bytes.

A fix here will be that conversions of passwords (String) to bytes[]
should be done with a fixed encoding

I should be able to post a fix by monday. For testing purposes it
should be fine though because messages are not sent between different
platforms.

Have a good weekend.

Arnold.

2008/7/26 Simos Xenitellis <simos...@googlemail.com>: