You have already specified some stuff for the module manager, haven't you?
Maybe you could add that to the documentation?

As these words were not really clear in our meeting on monday, here my opinion of their meaning:

• Share: Actually shared directory/number of files which resides on one hand on the client's device and on the other hand on the server.
  Access can have:
  -- only the user who shared it (only his devices)
  -- the user who shared it and contacts defined by him
• Local share: Only the local directory/number of files which are part of a share (local representation of a share on a particular device)
• Upload: A location on a Qabel Storage Server where shares can be stored to (defined by a public token - for read access - , a private token - for write access - , a revoke_token - for deleting it - and the information of the Qabel Storage Server).
  => for every share with another access definition there must be created a new upload, right?

We have to define a way to keep history for drop messages. This is module dependent but we should help modules with this.

This is an issue because we will not use FFsync anymore and hence do not have a sync protocol yet.

Idea: Use Qabel storage to hold a history file for specific modules and provide functionality to ease the history keeping process for module implementations.

NIST recommends not to use SHA-1 since 2006 http://csrc.nist.gov/groups/ST/hash/policy_2006.html
and even Microsoft decided to get rid of SHA-1 (in TLS certificates) https://www.schneier.com/blog/archives/2013/11/microsoft_retir.html

So https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Drop should say that

A digest of the final encrypted message including header, the encrypted AES key, IV,
and the ciphertext is created via the SHA512 hash function."

Since we'll probably use the same crypto setup for all Qabel (core) components, we should create a separate document (wiki page) for the description and reasoning of this crypto setup, briefly mention the essentials in the separate component specs and refer to the dedicated crypto document for further reading.

I would like to create a new wiki page for a threat model.

The page should give detailed information about what information is accessible to the different parties in a Qabel system, e.g. user's client, ISP, drop server, other user's client, ...

Would everybody be OK with having this as part of this wiki, or should I start such a document somewhere else? Or did anybody already start a threat model somewhere else?

Hi everyone,

just got around wondering how to solve that problem about making sure that the client always submits encrypted data.

What if the server encrypted incoming data again using the client's given public key?

This might increase the cpu time needed to store everything but it's absolute ensured that everything cannot be read by server owners or others who don't have the private key.

Or, as a second option, the data could be encrypted via a short randomly generated symmetric key, so the client has to brute-force-crack that key on its own -- and thus has to do some proof of work.

There are multiple points where the pollInterval can be defined:

• DropServer
• LocalSettings

Are those different things?

I vote to remove all pollInterval completely and hardcode them instead.

Is it a good idea, when we add always a version number for every "setting" which using JSON.

An example is here:
https://github.com/Qabel/qabel-contacts-module/wiki/Person-Configuration

Hey @Qabel/internal-write-access,

on Monday we talked about which fields have to be in contact and which fields have to be in person. I can remember that we will have public key, drop urls and email address (and maybe other flieds, too) but I cannot remember where these fields definitely will be (i.e. is email address in contact or in person). Can anyone remember this?

This is important for @malte-z because he has to reference this information in his bachelor thesis.

If a contact has more fields than described in https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Contact-Drop-Messages we have to update this (not time-critical). If email address will be implemented by the person module there has to be a wiki page in the corresponding repository which states this - so @malte-z can reference this page.

Just got that idea about having a certain presence of quality control and thus Unittests all over the modules and libraries.

Crypto tests, serialization tests, IO testing, ensuring that certain predetermined use cases work.
Advantage: Qabel has quite no GUIs, so we don't need to have GUI tests. :-)

Finish the architectural overview page.

Hi!

We want to discuss about the concept of Qabel. @Gottox and I want to create a schedule for this meeting.

Please send us your questions and mind and we will pack it in the schedule.

Please send it until Thursday

Thanks in advance

I think that we need a device id for every device of an user.
The file and sync module need that to syncronise the data. But this id shall be provide this id.

This have to implement in the config and have to be an individual key / id.

• identity: who am I?
• contacts: which people do I know?
• person: describe ths person

It was not specified in with mode AES should be used. @cburkert and I decided to use CTR mode with a random IV as nonce. Reusing the nonce shouldn't be a problem as we don't have any long living AES keys.

Is this fine for everybody?

One small question (for clarification)

Shall every module use the local and synced configuration to save its configuration or have to save it their?

I think that is important to fix it to start with the configuration stuff in the module and especially for the person and sync module

https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Configuration#upload

https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Configuration#block-server

These two fields have overlapping functionality. I vote for joining the into one class. This keeps the class diagram a little simpler. (gosh, it'll be huge anyway :P )

See https://github.com/Qabel/intern-doc/wiki/Architectural-Overview

We need to find out how one can implement our bridgehead concept on Android systems.

Issues to consider: We need to keep a TCP socket open, but we don't want to drain the battery.

Orbot, the Java implementation of the Tor client, https://gitweb.torproject.org/orbot.git might be a good reference to look at.

@Gottox and I reviewed and simplified https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Contact-Messages. We only define what we need in order to make communication between Qabel clients possible. Everything else is module specific (and we accounted for that, too).

I think we should add unencrypted version information (and maybe also utilized encryption/hash algorithms) to the encrypted drop messages or we will end with an unchangeable drop message format.

Since the size of the encrypted AES key depends on the size of the RSA key used to encrypt the original AES key, the encrypted message format would change in an incompatible way when using RSA keys with a different size. Also the digest size varies with the utilized hash function. When we just concatenate all these values without a delimiter, a client could never identify a changed message format.

Assignee is everyone with some time to spare.

Hi @Gottox and @thechauffeur! And also the rest!

Can you review this document. Is that a solution we can live with it
https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Drop

CU
k-c13

I just looked at
https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Contact
and noticed that all the non-technical items in the contact transmission schema should've been put into the modules/person section - am I right concerning this thought?

I'd like to clean this up then.

https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Configuration#synced-settings

Here the term "block_server" is used. This is not documented anywhere. I suspect it means the storage server, which is wrong either. It should be address one storage volume ON a server, not the server itself.

This field should link to a Qabel Storage Volume (or internally called "Storage Volume") so I suggest the name "storage_volume".

Any thoughts?

Should we remove the documentation about the Qabel servers from this documentation?

• Pro: The servers will have / already have their own repositories and this would be consistent to modules.
• Con: We might want to have some of these things documented in the core documentation of Qabel.
  • I think we account for that with documenting the protocols in our core documentation (which we are currently doing)

The general stuff which is not technical nor is about what this documentation is about should be written there. It will stuff most developers don't want - definitely don't need - to read.

We have to define which module and function is important in the beta and have to develop and what is fancy stuff

I reviewed the config page and detailed some parameters.
Please check especially the following points:

• I changed the storage server config to use a URL instead of separate keys for host, port, service prefix (as in the drop config). Reason: protocol key was missing (and for sake of unification)
• The private key is stored in the identity, but I miss the public key. Shouldn't it be stored there, too?
• what exactly is the meaning of the provider/user/auth fields in an account structure?

How will the client choose the drop id?
And how do we ensure that the drops of qabel users will overlap in order to obfuscate meta data?

Because of a milestone scheduled for tomorrow (finishing layout of documentation) I have to remove some pages from the TOC https://github.com/Qabel/intern-doc/wiki/Table%20of%20contents. These pages are not gone, they are just not linked in the TOC anymore.
This is because I think the information in these pages heavily belongs into modules like https://github.com/Qabel/qabel-file-module and https://github.com/Qabel/qabel-contacts-module (which is now called "person module").
The pages I'll remove from the TOC are the following.

• https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Contact
• https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Shares
• https://github.com/Qabel/intern-doc/wiki/Qabel-Client-AccessLists
• https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Blocks
• https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Blocks-Notes

@k-c13 if you agree that some of these pages belong into the wiki of a specific module can you please migrate them?

First off: Shall we use git submodules for efficient dependency management between components?

If so, part of the implementation will be to have all proper submodules referenced in each sub repo.

Are there standards for directory names (like 'ext' for storing all kinds of submodules in there) to have?

Best practice for encrypted data which is transported over a network is to append a MAC. (The preferred way is encrypt-then-MAC). This ensures the integrity of an encrypted message before the message itself has to be decrypted. Special crafted malicious packs might use security flaws in the decryption progress if a message is decrypted without prior integrity checks. I can't imagine a legitimate reason to not use a MAC on an encrypted message.

Section "Aufbau der Packs" in https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Blocks list "decrypting the pack" as the first step, which leads to the assumption that no MAC is utilized.

How should be call the sub-parts of a Storage Volume?
In the wiki they are sometimes referred to as chunks or blobs.

We kind of started this discussion in #31 but didn't come to any conclusion.
Let's make it clear. What do you think?

I favour chunk.

Hi Christian!

Can we discuss about the contact details. Because we have a small conflict.

CU
Michael

We have to discuss some inconsistencies in the architecture and thus in the wiki structure:

• will there be a separate storage component in the core or is it a part of bridgehead?
• same thing with drop
• currently the two Components-* pages for drop and storage describe fundamental principals of the Client-Server-Architecture but are sometimes referenced as server pages (Overview, and somewhere else I think...)
• If Components-[Drop|Server] should describe the client-side protocol implementation as parts of the core, what does the Qabel-Client-* pages describe?

I would suggest a bit of refactoring.

• Rename Components-[Drop|Storage] to Introduction-*
• Rename Qabel-Client-Drop to something else that reflects its content
  • Drop-Message
  • or this can be the new Components-Drop

In any case we have to do something about it. I think the naming is totally confusing.

https://github.com/Qabel/intern-doc/wiki/Components-API

Doesn't a generic explanation of an API belong to the glossary?
Why is this a dedicated component that is required to be explained in a non-technical way?

Or is this page indeed just about explaining the interface/"link" between the core and its dependers (here: Modules/Clients)?

Assignee is everyone with some time to spare.

https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Configuration

Local_Settings contains two values: an object of modules and the preferences itself. There's no reason why LocalSettings should encapsulate the preferences in an extra field instead of containing the preference values directly.

So instead of this I propose the following:

    Local_Settings  = "{"
                    'poll_interval' : NUM,
                    'poll_interval_wlan' : NUM,
                    'poll_interval_mobile' : NUM,
                    'last_update' : STR,
                    'modules' : { KEY : { ... }, ... }
                    "}"

This keeps the Class diagram simpler as we do not need an empty class just to encapsulate the settings

Any thoughts?

https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Configuration#common-settings

We have to discuss which fields we really need for the sync of the settings. The common settings added because of usage of FFsync that Qabel can compare it.

To have the structure of the documentation ready I have to decide if I shall remove https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Sync from the TOC.

I may remember correctly if Qabel Sync will be module in the future. If so, the link to https://github.com/Qabel/intern-doc/wiki/Qabel-Protocol-Sync should also be removed from the TOC.

Do you @Qabel/internal-write-access think it is correct to remove this from the TOC? I think yes and will remove this by tomorrow if no one argues against it.

Create a class diagram.

The introduction should make clear what this documentation is about what not. Maybe also where to find the stuff which this documentation is not about.

@Gottox Is it required to define exceptions for now? I just thought about Java's urge to have 'throws' in methods' declarations aka class diagram.

Stuff like CouldntSendDropException, NoContactFoundException, DropEmptyException or whatsoever.. I know that it might be a bit complicated to have them thought out by now, but just in case that the class diagram should somehow be 'fix' once the documentation is finished -- although I just can't imagine this :-D

Document wording (e.g. "user", "account", "component", "module") for example in the wiki glossary.

Please review the storage documentation.

• https://github.com/Qabel/intern-doc/wiki/Components-Storage
• https://github.com/Qabel/intern-doc/wiki/Qabel-Protocol-Storage