On Android, we provide the OpenPGP implementation OpenKeychain that now also supports an impressive list of Security Tokens (https://github.com/open-keychain/open-keychain/wiki/Security...). In our newest release, we also support YubiKey 4 over USB-C, which is a great alternative to NFC (which is only support by YubiKey NEO).

Regarding SSH: We submitted a pull request to ConnectBot. You can try it out if you like: https://github.com/connectbot/connectbot/pull/567

Out of curiosity, can software running in Termux (SSH, gpg, etc) talk to the yubikey?

fantastic, I use password-store on Android, and this would hopefully remove the need for a dedicated pull/push key..

Author of the paper here.

Yup, in regards to Signal our findings are already obsolete :D I think that the new Signal developments are great. It is better to allow only one key verification mechanism for unified usability and also use key continuity. Before, SAS needed to be verified for each call again.

But isn't now with signal that you have to wiretap it once and your are good to go since there are no sas every time?

Sure, but "wiretapping it once" would mean breaking a lot of well studied and until now unbroken crypto.

Author of the paper here.

There is existing work on testing the feasibility of impersonating other person's voice. We discuss them in our related work section at the end of the paper.

I think on the long run, SAS will no longer be a sufficient authentication technique due to advances in speech synthesis. To prolong ZRTP's life we propose usage of sentences instead of words/chars. This is discussed in detail in our best practices section.

This is a fascinating and well elaborated article!

I noticed that UX/UI is important and a guarantee that SAS should increase in length, what are some of the recommendations that you advise to have a good ZRTP implementation ?

Or should we start discussing the fadeoff of ZRTP and a change to something like Matrix protocol or even Signal's one ?

Both Matrix and Signal use WebRTC for VoIP so the content is encrypted by default. Call set up and signaling is also encrypted by default with Signal, and possible with Matrix - it's automatic if the room from which a call is established is already encrypted.

I know Signal attempts to prevent any data leakage by forcing the Opus codec to use a constant bitrate instead of its default VBR -- I'm not sure if Matrix implements anything similar yet.

Yup, we are working on the remaining points, see https://www.openkeychain.org/k-9/

- Dominik

OpenKeychain developer here. If you have any questions about certain fixed vulnerabilities or features, I am happy to answer any questions.

If you are on Android, use OpenKeychain. We don't ask these questions. Instead, we have a simple wizard guiding you through the process of creating a key. We don't ask for the algorithms (RSA, DSA,...). We don't ask for User IDs. We don't mention the words private or public key.

See http://www.openkeychain.org/