If your looking for the reference implementation of the Mumbler Initiative head over to https://github.com/Mumbler/MumblerAPI.
If your looking for the documentation of the MumblerAPI head over to https://docs.mumbler.eu.
Open, secure, simple, authorised-only & web-based communication stack for the web
Table of contents
- Idea / Basic concept
- Technical principal
- Code of conduct
The goal of the Mumbler initiative is to resurrect the german law concept of the “Briefgeheimnis” which translates to secrecy of correspondence and is the basis for privacy of correspondence. For centuries opening and/or reading a correspondence which was intended for someone else was a criminal act, often punished by jail time. The french King Louis XV even declared the death penalty on breaking the "Briefgeheimnis" (with his edict on 25. Sep 1742).
Today it is a well-known fact that all digital correspondence is stored somewhere and is read, analyzed, profiled and last but not least profited off by many parties.
The Mumbler initiative is convinced that it should be of paramount importance to keep the information where it belongs:
Only in the hands of the communication parties themselves.
The Mumbler initiative was created to achieve exactly that. Analog letters have/had the "Briefgeheimnis", digital correspondence have Mumbler.
No third party must be allowed to read, analyze, profile, profit of (etc...) the digital information transferred.
Therefore Mumbler ensures that all the relaying servers and networks must not be able to decipher the information transferred under any circumstances and at any given time or state.
The Mumbler Initiative follows three simple but strict rules:
- keep digital communication simple but secure (everything)
- access only to those who are intended (including revert the access retroactively)
- use existing, open and well-proven techniques
The security and integrity of Mumbler is based on the basic principals of an individual public private key infrastructure. These keys get an additional encryption layer on top which enables the usage of the keys from any internet browser but technically prohibits the use from any other party which includes the Mumbler infrastructure itself.
The client (-browser) initially creates a set of public and private keys to en-/decrypt the various symmetric keys which are used to en-/decrypt the actual data blobs. On top the client encrypts the private key with a strong derivation function only computable with the users secret credentials.
The various steps to create, authenticate, en- & decrypt are described below.
These user-keys are only computed once, when the account is generated. After the computation the keys are stored (additionally encrypted) within the Mumbler infrastructure. Therefore the account (and its keys) can be queried from the infrastructure and be used in any browser world-wide. Except for the SALT generation, all cryptographic procedures are computed within the clients browser ("locally").
The (initial) key generation process is a six-step process:
- Creating an
- Derive a
authorization-keyas a combination of username and password (PBKDF2 with A-SALT + n-iterations)
- Create an
password-keyfrom the users password (PBKDF2 with P-SALT + n-iterations)
- Create asymmetric keys and (symmetrically) encrypt
password-keyfrom previous step
- Register the encrypted asymmetric key set as well as the random IV (from the symmetrical encryption process)
The account authorization token is derived using PBKDF2 with n-iterations and an additional "Account-SALT" (see steps 1 & 2 of Key generation for details). The username + the derived authorization-key is used to authorize a login which alone only identifies the user against the infrastructure.
This derived authorization-key can't be used to access the encrypted data. It is purely for authentication purposes only.
The encryption of a data blob into a mumbler message object is a four-step process:
- Create a random
session-keyas well as a random IV
- Encrypt the data blob using the
- Encrypt the
session-keyusing the users
public-key(see step 5 of Key generation for details)
- Combine encrypted blob data, IV & encrypted
session-keyinto mumbler message object
The decryption of a mumbler message object into its original (unencrypted) data blob is a three-step process:
- Request the users
private-key(see Request private-key for details)
- Decrypt the
- Decrypt the encrypted blob data using the decrypted
session-keyand the IV from the mumbler message object
private-key is the most central and secretive aspect of every mumbler session.
private-key is held encrypted during a session.
If a decryption is requested, the
private-key will be made available for this decryption process and
after that its erased again. For practicality (and speed purposes) the
private-key can be held for a few seconds
after the last request, so multiple subsequent decryption requests can reuse the same
private-key is a four-step process:
- Check if session is valid and (still) active
- Decrypt the encrypted
password-key(see steps 3-5 of Key generation for details)
- Start drop scheduler
- After x seconds erase the decrypted
Additional technical details
For details on the Mumbler session management & message object as well as the technical specifications concerning "JSON Vulnerability Protection", "XSRF Protection", network flow control, perfect forward secrecy, request/response transformations + encodings (etc.) please consider the reference API implementations repository under https://github.com/Mumbler/MumblerAPI or the source code documentation under https://docs.mumbler.eu.
Although the data is handled (en-/decrypted, packaged) solely within the clients browser Mumbler needs an infrastructure to deliver the data blobs to its designated destination(s). We therefore operate currently two independent european-based database clusters (Finland & Germany) which are accessible via Web-API (see https://github.com/Mumbler/MumblerAPI for reference).
Each cluster consists of minimum four independent fully dedicated machines ("nodes"). Every bit of data is mirrored between those two locations and every cluster has (at least one) hot-swap node.
To give as many as possible the chance to create and operate accounts on the infrastructure and the fact, that we currently have no funding for the infrastructure we need to set a limitation on the default account.
These limitations are purely in processing message size and total account size. Both factors are heavy on the infrastructure. No other limitations are in place.
The default limitations are as follows:
- Max total account size: 1GB (1024 * 1024 * 1024 Bytes)
- Max (single) message size: 10 MB (10 * 1024 * 1024 Bytes)
- Max (single) attachment size: 2 MB (2 * 1024 * 1024 Bytes)
As shown above, a message can have a maximum size of 10MB. This is calculated on the basis of the complete message object (which includes all body and attachment payloads). A single attachment can have a maximum size of 2MB and the overall total account size, including all meta data (folders etc.) can't exceed 1GB.
We know this is not very much but please be patient. As soon as we have a solid infrastructure funding we will expand those numbers accordingly.
(We're currently in the progress of setting up a Indiegogo campaign to help found the infrastructure costs. In the meantime it would be great if you could support our efforts).
If you need more now, please contact us directly. We will figure something out together.
Mumbler was born as an idealist idea to apply the principals of the "Briefgeheimnis" to the digital age. We are very low on budget and are currently solely founded through and legally constituted within the austrian-based startup company MagnusIT GmbH.
We're currently in the progress of setting up a Indiegogo campaign to help found the infrastructure costs. In the meantime it would be great if you could support our efforts by donating a couple of euros.
Please support the project with your coding-, design-, brain-time and/or spread the word.
Of course operating the infrastructure is a big issue as well. It would be great if you could support us by donating a couple of euros:
Although the project has its fully implemented reference API (see https://github.com/Mumbler/MumblerAPI) and a fully operational (productive) infrastructure (see Infrastructure for details) it still lacks a good UI-Implementation.
We've developed a test suit but nothing fancy in the field of UI-design. It would be great if you could support use in that area (as well).
Thank you very much and we'll hope you’re as excited as we are on the idea of bringing back the “Briefgeheimnis” to the digital age.
Code of conduct
Lust but not least please read the COC.md file for details on our code of conduct. Contributing to the Mumbler Initiative you agree to our code of conduct.