search

ibauersachs / otr4j

Off-the-Record messaging library for Java
Apache License 2.0
65 stars 42 forks source link

Effort to (re)establish/re-enforce collaborative effort and streamline otr4j repos/forks #33

Open cobratbq opened 4 years ago

cobratbq commented 4 years ago

Hi all,

There has been a request (@Neustradamus) to re-establish work on otr4j/otr4j's effort as organization for otr4j and with it the question of which repo's exist, and for what purpose and why so many and what to use. I'd like to see if we can pick up the conversation again.

I was under the impression that there were no issues regarding the existence of otr4j/otr4j. However, recently I have doubts. Please know that there was no bad intention for my continued work on that fork other than wanting to implement under the original license. I am happy to merge the work into jitsi/otr4j, and that includes the license change, for as far as I can grant this. So, if this is a sensitive topic then I would like to discuss it. (Note that I have not offered any changes so far because the work is incomplete.)

Further more there is additional confusion given that https://github.com/redsolution/otr4j is listed by github.com as "the original otr4j repo", with rest being forks of that. However, IIUC jitsi/otr4j is the only one that publishes packages to maven, for example. (I do not know if the release packages at otr4j/otr4j are used by anyone or who created those.)

I have already invited George to the organization. Of course we can change/add invites as needed.

Your thoughts?

cobratbq commented 4 years ago

@ibauersachs in that case, for your request, please do that first. The merge I performed was for changes up to now. Embedding these changes should not be a big issue. I cannot currently do 3. anyways.

As for 1. and 2.:

cobratbq commented 4 years ago

@ibauersachs I'll see if I can tackle the changes you mentioned in the merged repo. We can use those changes as the cross-over moment.

cobratbq commented 4 years ago

@ibauersachs if you already have some of the replacement crypto implemented, can you drop me a line? There is no sense in having the same work done twice.

ibauersachs commented 4 years ago

See the changes in #34

cobratbq commented 4 years ago

Some initial effort, including merging of #34, can be found in branch remove-BC. The changes to the cryptographic code has not been tested yet. It uses JCA for all crypto, so DSA signing/verifying, DH, AES encryption/decryption. As we're looking at some very specific ways of operating the cryptographic primitives, it will need some thorough interop-testing. (I'm not sure when exactly I will get to that.)

cobratbq commented 4 years ago

I've done some cross-implementation testing. Everything seems to be in order. Repeated (15000+ runs) of AES encrypting/decrypting and DSA signing/verifying using random data check out.

Ironically, we cannot yet get rid of Bouncy Castle itself, since we use a utility to serialize BigIntegers. So that's my next target.

@ibauersachs one concern I have is that NONEwithDSAinP1363Format is not available on many Java 8 runtimes, and I specifically have seen very little about Android. This one might be a deal-breaker.

ibauersachs commented 4 years ago

I've done some cross-implementation testing. Everything seems to be in order. Repeated (15000+ runs) of AES encrypting/decrypting and DSA signing/verifying using random data check out.

Thanks! I didn't have time to look at it yet, I hope to find some time tomorrow.

Ironically, we cannot yet get rid of Bouncy Castle itself, since we use a utility to serialize BigIntegers. So that's my next target.

Is that used because of Java's leading 0 signed/unsigned stupidity instead of a built-in function?

@ibauersachs one concern I have is that NONEwithDSAinP1363Format is not available on many Java 8 runtimes, and I specifically have seen very little about Android. This one might be a deal-breaker.

Can that alg be loaded via name? If so, it might be sufficient to optionally depend on BC via Security.addProvider.

cobratbq commented 4 years ago

Thanks! I didn't have time to look at it yet, I hope to find some time tomorrow.

I've moved the BC-specific implementations to testing code. It would be really helpful if you could make some jitsi instances (old + new) set up a session and do some conversing.

Is that used because of Java's leading 0 signed/unsigned stupidity instead of a built-in function?

Yes.

Can that alg be loaded via name? If so, it might be sufficient to optionally depend on BC via Security.addProvider.

It is loaded via that name, so indeed, we should be able to use BC as a provider for JCA. I had not thought of that. That would be great!