I just ran the tests on my Macbook and two crypto tests (CryptoUtilsTest.encryptDecryptSymmetricTest() and CryptoUtilsTest.encryptHybridTest()) exited with an error and one (CryptoUtilsTest.encryptSymmetricTest()) failed. Beforehand in every test of CryptoUtilsTest (except in sha512Test()) a "InvalidKeyException: Illegal key size" is thrown.

Mac OS X version: 10.9.3
Java version: 1.7.0_67 (Travis CI runs with 1.7.0_60)

@L-Henke, maybe you have any idea why that happens?
Does someone else use Java version 1.7.0_67?

I'll start with the RSA encryption since this is needed for the primary/subkey structure.

Implement basic crypto functionality to get used by the drop component or - to be more specific - so that basic Qabel contacts and identities can have crypto keys.

Build the needed directories and packages.

I guess we'll need secure random bytes in many different classes. Should there be a singleton class with a secure initialized random number generator? Maybe this could be part of a general cryptography related utility class.

When this repository is public, add travis ci with Pull-Request testing.
Also add Status images to the readme :)

This has to be changed ASAP.

You @jan-schreib need to touch at least classes Drop and DropHTTP. Talk to @jasinai for the details.

Just thought about this question concerning possible race conditions for the sync component.

When uploading stuff into a QSV, will the server ensure that noone else/no other client etc can neither read nor write into the same QSV?
Perhaps it should be possible that a QSV may be readable while being written - but then the read procedure takes as long as the data is loaded up OR it just dumps an old version of the QSV's contents.

Currently, private keys in the identity are just represented as a string. An own class would be better, because is would allow private key related operations like getting the public key from a private key.

and find out if this is enough (i.e. if no further license headers are needed).

This might reduce the time/bandwidth needed to encrypt or send all the data - but will obviously take some time to actually compress the strings + drop queries probably have a very small mem footprint anyway, so the zip's dictionary would only create overhead then.

Might be good to have some benchmarks or a rough estimation whether this is actually needed concerning the quota between encryption time vs. compression time.

I found a strange structure in the config (SyncedSettings & SyncedModuleSettings):

• SyncedSettings contains:
  A member SyncedModuleSettings syncedModuleSettings and a Set syncedModuleSettings1.
• SyncedModuleSettings contains:
  A member SyncedSettings syncedSettings1 and a Set< SyncedSettings> syncedSettings.

I know that the members syncedModuleSettings and syncedSettings are references of the containing classes. But for what reason does SyncedModuleSettings contain a Set of SyncedSettings?

Implement the drop listener interface between modules and the drop component.

We use the term server for a single server and sometimes for more than one server. We also use the term servers for more than one server.

I suggest:

• server for one server.
• servers for e.g. a set of server(s) :)

I'll do the AES encryption.

As seen in @jasinai issue and pullreq #10 she changed String URLs to Java object URLs.
I think its a good idea. If everybody is fine with it I would open an issue to change the rest of the strings.

edit: typo

We should check if it is really recommended to use JCA's KeyGenerator concept to generate AES keys instead of simply pulling the keys out of the random bytes source.

Here is a discussion on stackoverflow, which suggests the using of KeyGenerator as best practice.
Advantages of using KeyGenerator:

• leave the randomness-related decisions to the provider

Topic: basic crypto #29

• Deleted

During the decryption of drop messages, the routine currently iterates over all possible senders (contacts) and checks if the drop message signature has been created by the respective contact.

        for (Contact c : contacts.getContacts()) {
            plainJson = decryptDrop(cipherMessage.getBytes(),
                    c.getContactOwner().getPrimaryKeyPair(),
                    c.getSignaturePublicKey()
            );
            if (plainJson == null) {
                continue;
            } else {
                plainMessages.add(deserialize(plainJson));
                break;
            }
        }

This algorithm is prone to timing attacks, because the contact list is allways iterated in the same order and a passive attacker (capable of monitoring e.g. CPU utilization) could learn from the decryption time, that two drop messages have been written by the same contact.

To mitigate this problem, one could instead iterate the contact list in a randomized fashion.

OS: VoidLinux
Java: oracle jdk1.7.0_65

./gradlew --info check 2>&1 | gist
https://gist.github.com/deb4cd13c5f4451e2047

https://gist.github.com/deb4cd13c5f4451e2047

• One with public methods only
• One with package private methods and fields

Reviewing the settings concept, I noticed, that the *ModuleSettings classes contain no information as to which module they belong to.
This is currently missing, isn't it?

@Gottox Can you explain your idea behind the module settings handling?

Shouldn't there be a module identifier member in the AbstractModuleSettings class or something like this?

Implement basic Qabel contacts and identity so that the drop component can be used.

Implement module-manager to initialize modules.

The number of drops in the Identity class has to be changed according to Qabel/qabel.github.io#63

This class should be used between the Drop and the Crypto component. It allows the Crypto component to be agnostic about the Drop message format.

• Implemnt API to send and receive drop messages
  • Implement interface for modules to do that (optional)

...to prevent all kinds of unforeseen NRE (null ref exceptions)

Just saw places like these which will likely cause unnecessary trouble because of returned null-objects.
Imo, we should stick to .Empty default objects, just like DropMessage<ModelObject>.Empty or so.

Qabel is still somewhat small, so converting all the things won't be that time-consuming for now.

Hi!

@Gottox wrote a mail which the result of its test.

Can you clearify in which language we write it now. I am not in on Monday.

The build.gradle file sets sourceCompatibility = 1.6.
@thechauffeur said we will use Java 7 for development.
Wouldn't that mean the file should set it to sourceCompatibility = 1.7?

Output of java -version:

java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.1) (7u65-2.5.1-4ubuntu1~0.14.04.2)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

@Gottox does it need to stay on 1.6 for Android?

Just saw a PR (pullrequest) featuring changed Core API.
Since we've got only 2 UMLLab licenses (and because it's likely that most people are too lazy to update their diagrams immediately as well), we need to have an update policy concerning the diagram definition and exported diagram charts, imho.

In #10 I suggested that once a week, those Java => Uml conversions will happen in order to keep the documentation halfway updated. Does this sound reasonable? @Gottox @k-c13

See https://help.github.com/articles/setting-guidelines-for-repository-contributors

We need a tool to auto format the source code according to our style guide.

The functionality to add a new instance of a class to a container class should be encapsulated in an add() method (e.g. one would use identities.add(Identity identity) instead of identities.getIdentity().add(Identity identity). Thereby this functionality would be independent of the implementation of the collection in these container classes.

The class diagram (core.png) in the repository looks kind of confusing and it is not clear which class diagram is the actual (the one in qabel-core or in qabel-doc repo).

https://github.com/Qabel/qabel-doc/wiki/Qabel-Client-Contact-Drop-Messages

Afaik, private keys are used to sign and decrypt stuff, public keys are used to encrypt stuff.
So, as a primary optimization proposal, I'd give an identity just a QblKeyPair which then does everything.

Were there other intentions concerning having a 'public' key for signature?

As described in the documentation issue Qabel/qabel.github.io#62 we have to change the setUrl() method of the DropServer class to accept URLs pointing just to the drop service and not containing a drop id.

As stated in the aftermath of #52, we need HMACs and signatures in the symmetric resp. hybrid encryption schemes.

Relevant documentation:

• Drop message specific documentation with details about the hybrid encryption + signatures https://github.com/Qabel/qabel-doc/wiki/Qabel-Client-Drop
• Generic documentation about the symmetric encryption https://github.com/Qabel/qabel-doc/wiki/Components-Crypto

This might include:

HTTP(Drop)Connection

• DropRetrieve
• DropSend

The HTTP(Drop)Connection should open a connection to a server, implement the required REST methods and handle the HTTP response codes.

Besides the documentation and the Qabel protocols - whether they may use the network or not - the code also needs versioning. We will use semver and we need to talk about the implications of doing so.

Since we will have some kind of a release in the near future (see attached milestone) this issue is here as a reminder.

Implement basic Qabel identity so that the drop component can be used.

We need a way to persist object on Android and PC without Android specific code. Maybe @Gottox know more about the persistence possibilities on Android and how this can be done platform independent.

@L-Henke started with #1 to reformat the code (variables on top, accessors and mutators below). We need to continue this work to have a consistend style in our code.

To prevent code injections, prior to dynamical instatiations of Model Classes, Modules must register the Model Classes they use.

this may be done in the init method of a module.

The classes in the config package are not up-to-date. Update them.

We need a platform independent logging toolkit which will also work with Android.

Since most of our communication is done asynchronous, only limited parts of the code should be vulnerable to timing attacks. These has to be identified.

• Re-requests of corrupted communications might be critical
• Drop messages which trigger a further action. (e.g. drop message that notifies about a modified file on the storage system)