[HotNoob]

Vid goes over basics, desc has some release notes to show where the current version is at.

instructions for installing JRE1.7 in linux is also in desc.

with v.06, after sending first message, wait for connection to complete until sending the 2nd messages, v.07 will have a que to remove the need for this.

Overall how it works,

client connects to server, performs 2x rsa handshakes, then continues to perform a dh handshake.

to connect, client sends a request to server, server forwards request to target client. client then returns to server if to connect or not, and provides the port and an accesscode and aes256 key to use to connect. server then forwards back to client. client then connects, sends access code, and encrypts the stream. then the clients perform 2x rsa, and 1x dh.

i have p2p group chats to work, but have not found any one to help me test that functionality. i have tested it between 2 connections, but need help with testing it between 3 or more people, and then also through various relays.

contact lists are stored on the server, but are encrypted by the client, so you have all of the comforts of normal chat systems without any security compromises. The local key used for encrypting the user data does not leave the clients computer, and neither is it saved anywhere on the computer, thus keeping it secure.

v.07 will have an updated ui
v.08 will have support for otp

later on i will be toughening up the security through some methods that i prefer not to disclose until i've programmed it into the client, as the concept could be revolutionary.

[HotNoob]

You have included BouncyCastle, yet you complain about the JCE Unlimited Strength policy files? Were you just stapling together StackOverflow answers for your crypto? You can use BouncyCastle's API directly and skip all of the policy restrictions of Java's Security API.

Code

PaddedBufferedBlockCipher cipher = new PaddedBufferedBlockCipher(new CBCBlockCipher(new AESEngine()));
CipherParameters params = new ParametersWithIV(new KeyParameter(key), iv);
cipher.init(false, params);

From BC website:

Note: with JDK 1.4 and later you will need to have installed the unrestricted policy files to take full advantage of the provider. If you do not install the policy files you are likely to get something like the following:

java.lang.SecurityException: Unsupported keysize or algorithm parameters
at javax.crypto.Cipher.init(DashoA6275)
The policy files can be found at the same place you downloaded the JDK.

https://www.bouncycastle.org/specifications.html

[HotNoob]

Uh seems cool but please explain why Java is terrible in any way. I'd like to know or are you a general Java basher without arguments.

mainly the inconsistencies, and the massive lack of features... and the overall retardation as to how libraries are setup... and sheer stubbornness to add the much needed features.

like seriously... having signed bytes has gotta be one of the most retarded things ever.

[HotNoob]

Every other language in the world EXCEPT!!! for Java uses unsigned bytes...

And pretty much everything else uses unsigned bytes...

IP addresses, Hex, you name it. It's all 0 to 255.
Try doing a very simple check sum in java via adding up the values of the bytes...
You have to first convert the byte to and int, and then convert the int into it's positive value, AND THEN!!! add it to the sum.
vs, simply adding the value of the byte to the sum.

[HotNoob]

The java devs who decided on using signed bytes, publicly stated that it was a huge fucking mistake to do so.

Plz, fan bois, pull your heads out of your asses.

[JavaProfit]

The java devs who decided on using signed bytes, publicly stated that it was a huge fucking mistake to do so.

Plz, fan bois, pull your heads out of your asses.

If all you're going to do is talk about how bad Java is, then just use something else. Honestly the other guys are right: signed bytes aren't that bad. Unsigned bytes make more sense in my opinion; it doesn't really make the language itself bad.