Salty 4.0 released 40 years to the day after Diffie-Hellman algorithm invented

[Carlos Rodriguez]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20160624/eb388d12/attachment-0002.sig>