4 ms·

You should have learned this paper last semester, as the paper is from 2015 and is relevant if you study DH. Anyway, for an application developer (as opposed t

You should have learned this paper last semester, as the paper is from 2015 and is relevant if you study DH. Anyway, for an application developer (as opposed to a crypto engineer), just use libsodium when you control both sides. If you need to interop with someone else, use TLS 1.3 if you can, or TLS 1.2 but only with ciphers that support PFS and AEAD, i.e. in practice x25519 and P-256 ECDHE with RSA signatures with AES GCM or ChaCha20Poly1305. Same primitives are available in SSH. If you can, don't use IPSec, use wireguard. Don't use pgp/openpgp/gpg email, use signal. You can use gpg to sign packages and encrypt backups, but the email integration and UX will kill you.

jolmg 8y ago
> Don't use pgp/openpgp/gpg email, use signal. You can use gpg to sign packages and encrypt backups, but the email integration and UX will kill you. Is there any problem with the crypto that gpg uses, or is it just a matter of the UX?
- marcosdumay 8y ago
  Gpg can use a lot of different crypto primitives. Some do have problems, some are kinda broken but still good enough for use, some are too easy to make mistakes so gpg is probably bugged, and some are top of the line. Gpg email also leak some more metadata than signal does. But it leaks to different parties, so this is not clear-cut.
- wolf550e 8y ago
  You can configure it to use crypto that is ok (and then use it to sign software packages or encrypt backups, like I wrote above, especially when interaction with gpg is done by scripts, not manually by humans, and key distribution is out of band and PFS is not needed). For back and forth messages between two or more people, lack of forward secrecy is a problem, integration with the email program is a problem, email metadata is a problem (not just to and from but also the subject line), teaching your confederates to not reply in the clear quoting the entire decrypted message you sent is a problem, etc. Security practitioners basically believe email cannot be saved, it cannot be used securely by regular people and its only use is to bootstrap something else.
  - Boulth 8y ago
    > not just to and from but also the subject line Subject is hidden in newer software e.g. Enigmail and K9 (it's moved to encrypted part and replaced with a placeholder see https://github.com/autocrypt/memoryhole https://github.com/autocrypt/memoryhole).
shandor 8y ago
Is libsodium the de facto standard instead of the original NaCl? If so, what are the reasons? Just enhanced usability, since I recall libsodium using the NaCl crypto primitives almost directly as-is?
- wolf550e 8y ago
  From the readme: > It is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further. > Sodium supports a variety of compilers and operating systems, including Windows (with MingW or Visual Studio, x86 and x64), iOS, Android, as well as Javascript and Webassembly. Look at the release notes on the releases page to see what kind of things they do. https://github.com/jedisct1/libsodium/releases https://github.com/jedisct1/libsodium/releases

jolmg 8y ago

> Don't use pgp/openpgp/gpg email, use signal. You can use gpg to sign packages and encrypt backups, but the email integration and UX will kill you. Is there any problem with the crypto that gpg uses, or is it just a matter of the UX?

marcosdumay 8y ago
Gpg can use a lot of different crypto primitives. Some do have problems, some are kinda broken but still good enough for use, some are too easy to make mistakes so gpg is probably bugged, and some are top of the line. Gpg email also leak some more metadata than signal does. But it leaks to different parties, so this is not clear-cut.
wolf550e 8y ago
You can configure it to use crypto that is ok (and then use it to sign software packages or encrypt backups, like I wrote above, especially when interaction with gpg is done by scripts, not manually by humans, and key distribution is out of band and PFS is not needed). For back and forth messages between two or more people, lack of forward secrecy is a problem, integration with the email program is a problem, email metadata is a problem (not just to and from but also the subject line), teaching your confederates to not reply in the clear quoting the entire decrypted message you sent is a problem, etc. Security practitioners basically believe email cannot be saved, it cannot be used securely by regular people and its only use is to bootstrap something else.
- Boulth 8y ago
  > not just to and from but also the subject line Subject is hidden in newer software e.g. Enigmail and K9 (it's moved to encrypted part and replaced with a placeholder see https://github.com/autocrypt/memoryhole https://github.com/autocrypt/memoryhole).

shandor 8y ago

Is libsodium the de facto standard instead of the original NaCl? If so, what are the reasons? Just enhanced usability, since I recall libsodium using the NaCl crypto primitives almost directly as-is?

wolf550e 8y ago
From the readme: > It is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further. > Sodium supports a variety of compilers and operating systems, including Windows (with MingW or Visual Studio, x86 and x64), iOS, Android, as well as Javascript and Webassembly. Look at the release notes on the releases page to see what kind of things they do. https://github.com/jedisct1/libsodium/releases https://github.com/jedisct1/libsodium/releases