Commit cab1edb6 authored by Matthew Hodgson's avatar Matthew Hodgson

Merge branch 'markdown' into 'master'

Convert docs from RST to Markdown

See merge request !2
parents 214908ac b6cd1690
Contributing code to libolm
===========================
# Contributing code to libolm
To contribute code to this library, the preferred way is to clone the git
repository, create a git patch series (for example via ``git
......@@ -8,18 +7,16 @@ format-patch --stdout origin/master``), and send this by email to
Naturally, you must be willing to license your contributions under the same
license as the project itself - in this case, Apache Software License v2 (see
`<LICENSE>`_).
[LICENSE](LICENSE)).
Sign off
--------
## Sign off
In order to have a concrete record that your contribution is intentional and
you agree to license it under the same terms as the project's license, we've
adopted the same lightweight approach that the
`Linux Kernel <https://www.kernel.org/doc/Documentation/SubmittingPatches>`_,
`Docker <https://github.com/docker/docker/blob/master/CONTRIBUTING.md>`_,
and many other projects use: the DCO
(`Developer Certificate of Origin <http://developercertificate.org/>`_).
[Linux Kernel](https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin),
[Docker](https://github.com/docker/docker/blob/master/CONTRIBUTING.md),
and many other projects use: the DCO ([Developer Certificate of Origin](http://developercertificate.org/)).
This is a simple declaration that you wrote the contribution or otherwise have
the right to contribute it to Matrix::
......
Olm
===
# Olm
An implementation of the Double Ratchet cryptographic ratchet described by
https://whispersystems.org/docs/specifications/doubleratchet/, written in C and
C++11 and exposed as a C API.
The specification of the Olm ratchet can be found in `<docs/olm.rst>`_.
The specification of the Olm ratchet can be found in [docs/olm.md](docs/olm.md).
This library also includes an implementation of the Megolm cryptographic
ratchet, as specified in `<docs/megolm.rst>`_.
ratchet, as specified in [docs/megolm.md](docs/megolm.md).
Building
--------
## Building
To build olm as a shared library run either:
.. code:: bash
cmake . -Bbuild
cmake --build build
```bash
cmake . -Bbuild
cmake --build build
```
or:
.. code:: bash
make
```bash
make
```
Using cmake is the preferred method for building the shared library; the
Makefile may be removed in the future.
To run the tests when using cmake, run:
.. code:: bash
cd build/tests
ctest .
```bash
cd build/tests
ctest .
```
To run the tests when using make, run:
.. code:: bash
make test
```bash
make test
```
To build the JavaScript bindings, install emscripten from http://kripken.github.io/emscripten-site/ and then run:
.. code:: bash
make js
```bash
make js
```
Note that if you run emscripten in a docker container, you need to pass through
the EMCC_CLOSURE_ARGS environment variable.
To build the android project for Android bindings, run:
.. code:: bash
cd android
./gradlew clean assembleRelease
```bash
cd android
./gradlew clean assembleRelease
```
To build the Xcode workspace for Objective-C bindings, run:
.. code:: bash
cd xcode
pod install
open OLMKit.xcworkspace
```bash
cd xcode
pod install
open OLMKit.xcworkspace
```
To build the Python bindings, first build olm as a shared library as above, and
then run:
.. code:: bash
cd python
make
```bash
cd python
make
```
to make both the Python 2 and Python 3 bindings. To make only one version, use
``make olm-python2`` or ``make olm-python3`` instead of just ``make``.
......@@ -80,27 +77,25 @@ to make both the Python 2 and Python 3 bindings. To make only one version, use
To build olm as a static library (which still needs libstdc++ dynamically) run
either:
.. code:: bash
cmake . -Bbuild -DBUILD_SHARED_LIBS=NO
cmake --build build
```bash
cmake . -Bbuild -DBUILD_SHARED_LIBS=NO
cmake --build build
```
or
.. code:: bash
make static
```bash
make static
```
The library can also be used as a dependency with CMake using:
.. code:: cmake
find_package(Olm::Olm REQUIRED)
target_link_libraries(my_exe Olm::Olm)
```cmake
find_package(Olm::Olm REQUIRED)
target_link_libraries(my_exe Olm::Olm)
```
Release process
---------------
## Release process
First: bump version numbers in ``common.mk``, ``CMakeLists.txt``,
``javascript/package.json``, ``python/olm/__version__.py``, ``OLMKit.podspec``,
......@@ -113,34 +108,32 @@ git.
It's probably sensible to do the above on a release branch (``release-vx.y.z``
by convention), and merge back to master once the release is complete.
.. code:: bash
```bash
make clean
make clean
# build and test C library
make test
# build and test C library
make test
# build and test JS wrapper
make js
(cd javascript && npm run test)
npm pack javascript
# build and test JS wrapper
make js
(cd javascript && npm run test)
npm pack javascript
VERSION=x.y.z
scp olm-$VERSION.tgz [email protected]:packages/npm/olm/
git tag $VERSION -s
git push --tags
VERSION=x.y.z
scp olm-$VERSION.tgz [email protected]:packages/npm/olm/
git tag $VERSION -s
git push --tags
# OLMKit CocoaPod release
# Make sure the version OLMKit.podspec is the same as the git tag
# (this must be checked before git tagging)
pod spec lint OLMKit.podspec --use-libraries --allow-warnings
pod trunk push OLMKit.podspec --use-libraries --allow-warnings
# Check the pod has been successully published with:
pod search OLMKit
```
# OLMKit CocoaPod release
# Make sure the version OLMKit.podspec is the same as the git tag
# (this must be checked before git tagging)
pod spec lint OLMKit.podspec --use-libraries --allow-warnings
pod trunk push OLMKit.podspec --use-libraries --allow-warnings
# Check the pod has been successully published with:
pod search OLMKit
Design
------
## Design
Olm is designed to be easy port to different platforms and to be easy
to write bindings for.
......@@ -150,46 +143,40 @@ API. As development has progressed, it has become clear that C++ gives little
advantage, and new functionality is being added in C, with C++ parts being
rewritten as the need ariases.
Error Handling
~~~~~~~~~~~~~~
### Error Handling
All C functions in the API for olm return ``olm_error()`` on error.
This makes it easy to check for error conditions within the language bindings.
Random Numbers
~~~~~~~~~~~~~~
### Random Numbers
Olm doesn't generate random numbers itself. Instead the caller must
provide the random data. This makes it easier to port the library to different
platforms since the caller can use whatever cryptographic random number
generator their platform provides.
Memory
~~~~~~
### Memory
Olm avoids calling malloc or allocating memory on the heap itself.
Instead the library calculates how much memory will be needed to hold the
output and the caller supplies a buffer of the appropriate size.
Output Encoding
~~~~~~~~~~~~~~~
### Output Encoding
Binary output is encoded as base64 so that languages that prefer unicode
strings will find it easier to handle the output.
Dependencies
~~~~~~~~~~~~
### Dependencies
Olm uses pure C implementations of the cryptographic primitives used by
the ratchet. While this decreases the performance it makes it much easier
to compile the library for different architectures.
Contributing
------------
Please see `<CONTRIBUTING.rst>`_ when making contributions to the library.
## Contributing
Security assessment
-------------------
Please see [CONTRIBUTING.md](CONTRIBUTING.md) when making contributions to the library.
## Security assessment
Olm 1.3.0 was independently assessed by NCC Group's Cryptography Services
Practive in September 2016 to check for security issues: you can read all
......@@ -197,18 +184,16 @@ about it at
https://www.nccgroup.trust/us/our-research/matrix-olm-cryptographic-review/
and https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-encryption-security-assessment-released-and-implemented-cross-platform-on-riot-at-last/
Bug reports
-----------
## Bug reports
Please file bug reports at https://github.com/matrix-org/olm/issues
What's an olm?
--------------
## What's an olm?
It's a really cool species of European troglodytic salamander.
http://www.postojnska-jama.eu/en/come-and-visit-us/vivarium-proteus/
Legal Notice
------------
## Legal Notice
The software may be subject to the U.S. export control laws and regulations
and by downloading the software the user certifies that he/she/it is
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
.. Copyright 2016 OpenMarket Ltd
..
.. Licensed under the Apache License, Version 2.0 (the "License");
.. you may not use this file except in compliance with the License.
.. You may obtain a copy of the License at
..
.. http://www.apache.org/licenses/LICENSE-2.0
..
.. Unless required by applicable law or agreed to in writing, software
.. distributed under the License is distributed on an "AS IS" BASIS,
.. WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
.. See the License for the specific language governing permissions and
.. limitations under the License.
Signature keys and user identity in libolm
==========================================
# Signature keys and user identity in libolm
The use of any public-key based cryptography system such as Olm presents the
need for our users Alice and Bob to verify that they are in fact communicating
......@@ -23,13 +7,13 @@ out-of-band process in which Alice and Bob verify that they have the correct
public keys for each other. For example, this might be done via physical
presence or via a voice call.
In the basic `Olm <olm.html>`_ protocol, it is sufficient to compare the public
In the basic [Olm][] protocol, it is sufficient to compare the public
Curve25519 identity keys. As a naive example, Alice would meet Bob and ensure
that the identity key she downloaded from the key server matched that shown by
his device. This prevents the eavesdropper Eve from decrypting any messages
sent from Alice to Bob, or from masquerading as Bob to send messages to Alice:
she has neither Alice's nor Bob's private identity key, so cannot successfully
complete the triple-DH calculation to compute the shared secret, :math:`S`,
complete the triple-DH calculation to compute the shared secret, $`S`$,
which in turn prevents her decrypting intercepted messages, or from creating
new messages with valid MACs. Obviously, for protection to be complete, Bob
must similarly verify Alice's key.
......@@ -41,7 +25,7 @@ one-time keys. Curve25519 keys are intended for use in DH calculations, and
their use to calculate signatures is non-trivial.
The solution adopted in this library is to generate a signing key for each
user. This is an `Ed25519`_ keypair, which is used to calculate a signature on
user. This is an [Ed25519][] keypair, which is used to calculate a signature on
an object including both the public Ed25519 signing key and the public
Curve25519 identity key. It is then the **public Ed25519 signing key** which is
used as the device fingerprint which Alice and Bob verify with each other.
......@@ -50,8 +34,7 @@ By verifying the signatures on the key object, Alice and Bob then get the same
level of assurance about the ownership of the Curve25519 identity keys as if
they had compared those directly.
Signing one-time keys
---------------------
## Signing one-time keys
The Olm protocol requires users to publish a set of one-time keys to a key
server. To establish an Olm session, the originator downloads a key for the
......@@ -60,19 +43,20 @@ is left to the application. There are both advantages and disadvantages to
doing so.
Consider the scenario where one-time keys are unsigned. Alice wants to initiate
an Olm session with Bob. Bob uploads his one-time keys, :math:`E_B`, but Eve
replaces them with ones she controls, :math:`E_E`. Alice downloads one of the
compromised keys, and sends a pre-key message using a shared secret :math:`S`,
an Olm session with Bob. Bob uploads his one-time keys, $`E_B`$, but Eve
replaces them with ones she controls, $`E_E`$. Alice downloads one of the
compromised keys, and sends a pre-key message using a shared secret $`S`$,
where:
.. math::
S = ECDH\left(I_A,\,E_E\right)\;\parallel\;ECDH\left(E_A,\,I_B\right)\;
\parallel\;ECDH\left(E_A,\,E_E\right)
```math
S = ECDH\left(I_A,\,E_E\right)\;\parallel\;ECDH\left(E_A,\,I_B\right)\;
\parallel\;ECDH\left(E_A,\,E_E\right)
```
Eve cannot decrypt the message because she does not have the private parts of
either :math:`E_A` nor :math:`I_B`, so cannot calculate
:math:`ECDH\left(E_A,\,I_B\right)`. However, suppose she later compromises
Bob's identity key :math:`I_B`. This would give her the ability to decrypt any
either $`E_A`$ nor $`I_B`$, so cannot calculate
$`ECDH\left(E_A,\,I_B\right)`$. However, suppose she later compromises
Bob's identity key $`I_B`$. This would give her the ability to decrypt any
pre-key messages sent to Bob using the compromised one-time keys, and is thus a
problematic loss of forward secrecy. If Bob signs his keys with his Ed25519
signing key (and Alice verifies the signature before using them), this problem
......@@ -81,38 +65,38 @@ is avoided.
On the other hand, signing the one-time keys leads to a reduction in
deniability. Recall that the shared secret is calculated as follows:
.. math::
S = ECDH\left(I_A,\,E_B\right)\;\parallel\;ECDH\left(E_A,\,I_B\right)\;
\parallel\;ECDH\left(E_A,\,E_B\right)
```math
S = ECDH\left(I_A,\,E_B\right)\;\parallel\;ECDH\left(E_A,\,I_B\right)\;
\parallel\;ECDH\left(E_A,\,E_B\right)
```
If keys are unsigned, a forger can make up values of :math:`E_A` and
:math:`E_B`, and construct a transcript of a conversation which looks like it
If keys are unsigned, a forger can make up values of $`E_A`$ and
$`E_B`$, and construct a transcript of a conversation which looks like it
was between Alice and Bob. Alice and Bob can therefore plausibly deny their
partition in any conversation even if they are both forced to divulge their
private identity keys, since it is impossible to prove that the transcript was
a conversation between the two of them, rather than constructed by a forger.
If :math:`E_B` is signed, it is no longer possible to construct arbitrary
If $`E_B`$ is signed, it is no longer possible to construct arbitrary
transcripts. Given a transcript and Alice and Bob's identity keys, we can now
show that at least one of Alice or Bob was involved in the conversation,
because the ability to calculate :math:`ECDH\left(I_A,\,E_B\right)` requires
knowledge of the private parts of either :math:`I_A` (proving Alice's
involvement) or :math:`E_B` (proving Bob's involvement, via the
because the ability to calculate $`ECDH\left(I_A,\,E_B\right)`$ requires
knowledge of the private parts of either $`I_A`$ (proving Alice's
involvement) or $`E_B`$ (proving Bob's involvement, via the
signature). Note that it remains impossible to show that *both* Alice and Bob
were involved.
In conclusion, applications should consider whether to sign one-time keys based
on the trade-off between forward secrecy and deniability.
License
-------
## License
This document is licensed under the `Apache License, Version 2.0
<http://www.apache.org/licenses/LICENSE-2.0>`_.
This document is licensed under the Apache License, Version 2.0
http://www.apache.org/licenses/LICENSE-2.0.
Feedback
--------
## Feedback
Questions and feedback can be sent to olm at matrix.org.
.. _`Ed25519`: http://ed25519.cr.yp.to/
[Ed25519]: http://ed25519.cr.yp.to/
[Olm]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/olm.md
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment