[Cryptech Tech] fyi: Salty 4.0 released 40 years to the day after Diffie-Hellman algorithm invented

[=JeffH]

pf possible interest, if not please delete :)


Subject: Salty 4.0 released 40 years to the day after Diffie-Hellman algorithm
  invented
From: Carlos Rodriguez <carlos at s8f.org>
Date: Fri, 24 Jun 2016 05:18:08 +0000
To: cypherpunks at cpunks.org, cryptography at metzdowd.com

Salty is a nodejs-powered CLI-based alternative to PGP/GPG using NaCl 
instead of RSA/DSA.

There is a GUI in progress.

Commits and tags in the Salty repo (and this announcement) are signed with 
GPG key 5FBB 2F98 3862 1AFF.

Features

	• NO 3rd parties (peerio), NO p2p network (PRISM-safe, usable on airgapped 
machines), NO browser js (it’s not safe!), NO exotic/compiled deps (goodbye 
openssl vulns), no Comodo SSL (CloudFlare), and NO shady corporations 
(Virgil Sec). PERIOD.
	• general purpose CLI, lightweight library attached
	• audited, bundled dependencies - no install scripts or backdoors
	• supports anonymous-sender or signed/verified messaging
	• sharable pubkey string that can fit in a single tweet
	• does NOT use your ssh keys, pgp keys, or anything RSA
	• encrypt public key is always ephemeral - does NOT leak metadata
	• sender identity is deniable, unless they explicitly commit to sign the 
message
	• file length hidden with padding
	• public signing/verifying with detached signatures
	• binary or “ascii armor” PEM output
	• import/export your wallet folder - PEM encoded and secretboxed with 
Scrypt KDF
	• (new in 3.1) can use anonymous private Github gists to remotely store 
salty messages
	• (new in 3.1) full tar/gz support for encrypting/decrypting directories 
(supports symmetric or asymmetric cipher)
	• MIT-licensed

—

How is this better than PGP?

This is a step-by-step rebuttal to [secushare](http://secushare.org/PGP)'s 
arguments against the PGP model, and how [Salty](https://s8f.org/salty.html) 
tries to make things right again.

### 1. Downgrade Attack: The risk of using it wrong.

Unlike PGP, Salty does not "integrate" into your browser, email client, or 
other sensitive software. Therefore, usability shortcomings of integration 
UIs will not raise security issues. It is up to the user to safeguard the 
connection (i.e. their email account) which Salty can't control, and is not 
interested in controlling. "Doing it wrong" is barely possible since there 
are so few modes of use, and all parameters are hard-coded into the 
software, so no critical choices are necessary on the part of the user.

### 2. The OpenPGP Format: You might aswell run around the city naked.

Salty does not include the sender or recipient's public key in plaintext. By 
default it encrypts using an ephemeral key and nonce, obscures the message 
length with padding, encrypts the real message length, and encrypts the info 
for verifying authenticity and integrity (hmac, public keys, and signature). 
Signature is opt-in.

### 3. Transaction Data: Mallory knows who you are talking to.

Fully anonymized traffic seems like a pipe dream, and (despite the existence 
of the Tor project) will probably not be possible in the near future. 
However, for what it's worth:

In theory, the idea of a "mixing service" from Bitcoin for 
psuedo-anonymizing transactions is possible using Salty files. Since a Salty 
file can only be made sense of by one who posesses the receiver's private 
key, a secure "drop box" could be set up where everyone dumps to the same 
folder, and everyone reads every file, trying to decrypt everything until 
decryptable files are found.

### 4. No Forward Secrecy: It makes sense to collect it all.

Salty solves this problem in two ways:

1. With Salty it's easy to refresh keys: just regenerate your decryption 
key, and tweet the resulting pubkey string. Destroying your encryption key 
effectively renders your previously received messages unreadable and useless 
to collect.
2. Recovering the 32-byte key used to encrypt a message will not allow 
decryption of all Alice<->Bob messages, since each message has a unique key 
as the result of Diffie-Hellman with Alice using an ephemeral key.

### 5. Cryptogeddon: Time to upgrade cryptography itself?

Salty throws out RSA and NIST-approved curves entirely, using the 
independently developed, peer-reviewed, battle tested, public domain NaCl 
crypto suite.

### 6. Federation: Get off the inter-server super-highway.

Salty is not a network protocol, but it's recommended to use the most secure 
channel possible to trade Salty messages. The same goes for any sensitive 
information transferred between two parties.

### 7. Discovery: A Web of Trust you can't trust.

Salty does not prescribe a web-of-trust model. Keyservers are optional and 
if one has a Twitter account, not necessary at all. End of story!

### 8. PGP conflates non-repudiation and authentication.

Salty allows the sender to decide whether to sign the message, revealing to 
the receiver (via HMAC) that they in fact constructed it with their known 
identity. By default, only message integrity is ensured, protecting the 
sender's privacy if they desire it.

### 9. Statistical Analysis: Guessing on the size of messages.

Salty does some random-padding to help obscure the message size.

### 10. Workflow: Group messaging with PGP is impractical.

This is still true. Group messaging is better done by a network protocol.

—

Code on Github: https://github.com/carlos8f/salty

Cheers,
Carlos