Commit 9563593d authored by David Goulet's avatar David Goulet

Add a habu posts repository for backup

Signed-off-by: default avatarDavid Goulet <>
parent 66e50e51
This diff is collapsed.
Title: Debian OTR team
Slug: debian otr
Date: 2014-04-27 14:15:00
Author: Debian OTR team
Today we launch the Debian OTR team. OTR stands for "Off-the-Record" messaging which provides encryption, authentication, deniability and perfect forward secrecy. The team was started by various maintainers of software that feature "OTR" support. OTR is used for instant messaging. It adds an encryption layer over existing instant messaging protocols like Jabber and IRC and is implemented in several instant messaging clients, which we aim to support and maintain in Debian.
In a post-Snowden age, it is important that Debian provides encryption to those who want to protect their communications. OTR is one of the protocols that is relatively easy to use for end-users. Its end-to-end encryption makes it harder for attackers to decrypt the communication between two parties.
The Debian OTR team is supported by, a community of OTR developers, whose aim it is to work effectively together, peer-review each other's work and encourage people to step in and work together on the OTR ecosystem and OTR upstream.
Now for the burning question, how can you contribute? We welcome any contribution! From bug reporting and triaging, to bugfixing, packaging and backporting. We will help newcomers if needed and are very grateful for your contribution!
You can find the Debian OTR homepage with all the information on how to get involved: [here](
Title: Launch of
Slug: Let the ecosystem bloom off-the-record
Date: 2014-04-27 14:00:00
[]( was started to strengthen the OTR community by providing a hub where developers can find each other, improve their respective projects and contribute to the OTR community.
[Libotr]( is now accessible using a new [bugtracker]( This bugtracker is a new place for contributing to the reference implementation, libotr.
We also want to provide new and/or existing projects with hosting, i.e, giving them access to the bugtracker and git repositories. As of now, along with libotr, the pidgin-otr plugin is also hosted there.
However, is not a replacement for [](, it is merely an addition to the community as a whole and a way to do the project hosting.
There has been increased interest in OTR and [mpOTR]( the past few months. In April 2014, the [Debian OTR team]( has been announced. Furthermore, a group of cryptographers and developers is working on an mpOTR specification, which would allow more than 2 people to chat with each other using end-to-end encryption.
This initiative was brought to you by the [useotr]( folks, who are dedicated to strengthen the OTR ecosystem and bridging gaps between users and developers.
Since Snowden's revelations have been published the need for secure end-to-end communication has become clearer. We aim to help out with providing that. In collaboration with the libotr authors and the various implementation developers.
Last but not least, [get involved](
Title: Debian OTR team featured on LWN
Slug: LWN
Date: 2014-04-27 16:00:00
[Linux Weekly News]( featured the Debian OTR team this week. Check it out.
Title: mpOTR progress report - HOPE X in New York 2014
Slug: hopex mpotr
Date: 2014-07-25 00:00:00
Author: dgoulet, infinity0
- trevp
- infinity0
- DrWhax
- dgoulet
- vmon
This is a progress report on the ongoing mpOTR effort after a meeting at the
HOPE X conference in New York.
First of all, the name of the protocol has not been yet decided thus we'll use
mpOTR in this report so everyone understand what we are talking about.
This initiative was launched by CryptoCat and in early 2014 with the
help of OTF for the funding. You can find an overview of the project here
[mpOTR]( Quite
of work has been put into this new protocol and a second draft of the mpOTR
protocol should be release to the public soon.
Now a quick summary of what we discussed. It is divided into roughly two parts,
the key agreement to establish the session, and mechanisms to ensure transcript
consistency during the session. The key agreement can itself be thought as a
combination of a forward-secure confidentiality key agreement, and a deniable
authentication key agreement.
Unlike OTR which is a bidirectionnal data exchange, a cryptographic agreement
between all parties need to be established before having a group chat secure
channel. There are multiple methods to achieve that, such has having each
participant broadcasting her/his key ("sender keys") or using a common key for
the whole chat session ("group key"). It's also important to consider the
transport protocols that support group chat such as IRC and XMPP; these all
have different semantics for reachability, presence, delivery and so on. In
order for mpOTR to be transport agnostic, we need to assume as little as
possible about the transport, and/or think about how to adapt the semantics we
choose for mpOTR, into the semantics of each transport.
mpOTR will most likely introduce new properties on top of the secure channel
that make sure the transcript between all participants is ordered and
consistent. This is to prevent an insider attacker that decides to send
different information to different people in the group chat - this would be as
disastrous as a non-secure communication channel. I won't go into any more
details but I encourage you all to read infinity0
So back to the HOPE X meeting. The discussion was aimed at trying to get to an
agreement between attendees mostly on two aspects, which key agreement scheme
to use and the transcript consistency property. I'll describe what they are
briefly here but will not go into deep technical details since no decision have
been made.
As mentionned before, there are multiple key agreement scheme that can be used
but there is still a debate on which one to use in mpOTR, sender keys or a
common group key. Each of these have advantages and disadvantages, but details
are being worked out to decide which one the next draft will follow.
For the transcript consistency, the discussion was mostly about the performance
overhead of the scheme described
and whether simpler schemes achieve security guarantees that are strong enough.
Again, I'm not going to go into more details since I feel that this would need
its own blog post/paper and the goal here is to show what's being worked on
right now for mpOTR.
As I said, the second draft will be release soon (hopefully with an official
name) which you, the public, should bring a HUGE amount of scrutiny to it and
we can finally move to an implementation! :)
Title: Release of libotr 4.1.0 and Pidgin-OTR 4.0.1
Slug: libotr 4.1.0 and pidgin-otr 4.0.1 release
Date: 2014-10-21 10:45:00
Author: OTR team
We are pleased to announce the release of pidgin-otr (4.0.1) and libotr
(4.1.0). These are mostly bugfixes as well as some new translations for
### Pidgin-otr updates:
* Fix max message size for Novell Groupwise
* New Czech, Finnish, Brazilian Portuguese, Norwegian Bokmal translations. Updated French, Chinese translations.
* The Windows binary has been linked with updated versions of libotr, libgcrypt, and libgpg-error.
### libotr updates:
* Modernized autoconf build system
* Use constant-time comparisons where needed
* Use gcrypt secure memory allocation
* Correctly reject attempts to fragment a message into too many pieces
* Fix a missing opdata when sending message fragments
* Don't lose the first user message when REQUIRE_ENCRYPTION is set
* Fix some memory leaks
* Correctly check for children contexts' state when forgetting a context
* Add functions' definition for:
* otrl_context_find_recent_instance()
* otrl_context_find_recent_secure_instance()
Thanks to everyone who contributed on this release!
### How to report bugs?
If you found any bugs or want to contribute to the otr project. The best way is
to create an account or login using the anonymous ***cypherpunks*** account
with password **contribute** on [](
You can also post on the OTR mailing list at
[]( for help.
### Where can I find the releases?
#### libotr
* [](
* Signature:[](
#### Pidgin-otr
* [](
* Signature: [](
The OTR team.
Title: OTR meeting notes - Tails hackfest in Paris 2014
Slug: tails otr hackfest meeting
Date: 2014-07-14 12:00:00
- jvoisin
- infinity0
- dgoulet
- drwhax
- vmon
1) Modern cryptography
Migrating current OTR protocol to use modern cryptography. We would like to
replace the DSA signature to "ed25519". The DH exchange should be replaced by
"curve25519". libgcrypt supports ed25519 since version 1.6 (package
libgcrypt20). The curve25519 is unclear if it's merged or a work in progress.
The new key(s) should be derived from the old one so users can keep their
current fingerprint.
For that, we discussed the need to cross sign keys for the transition.
Also, should chacha20 and/or poly1305 should be considered as well? No one had
a strong opinion on that.
A proposal of these changes should be written first before any code starts and
Acked-by maintainers/developers/contributors off the community.
2) Tests suite
You can find here a branch of the test suite started by dgoulet which contains
some basic unit tests now integrated with libtap.
(branch: test-suites)
We agree that an "OTR fuzzer" would be great also to basically hunt bug and
also be able to add this to a continious integration system.
There is a bunch of open bugs/features on that we need to tackle but we all
agree that we should *first* make the test suite with a descent code coverage
so we can actually confirm that what we are fixing/implementing is not breaking
Once we have that, there is some kniffing to do especially on some part of the
internal ABI (for instance, second comments of this Memory allocation used without checks, stuff
like that. Mostly this kniffing would be simply to improve the code to make it
more easily maintainable and robust.
We have a twitter account now to tweet about some stuff that's going on in the
OTR community I guess and news/update... So send anything you think might be
worth tweeting :).
Also, we discussed having more action on the blog (
especially maybe putting a "Call to action" for testing.
A new git repository containing the specifications would be a good idea to
create so we can have people looking at the progress of the modern crypto spec.
for instance.
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