neatnik / salty

Portable NaCl-powered encryption

Salty

Portable NaCl-powered encryption

Salty makes it easy to send strongly-encrypted messages with a shared key. It uses NaCl (via Libsodium) for encryption and basE91 for portability.

With Salty, you can encrypt a message as long as 185 characters and the resulting cipher will still fit in a tweet (~277 characters), making it ideal for encrypting tweets or other length-restricted communication. You can use it anywhere, though, with text of any length.

Demo

You can try it out at https://neatnik.net/salty/

Examples

Unencrypted payload: The quick brown fox jumped over the lazy sleeping dog.

Key: hunter2

Resulting Salty cipher:

-- BEGIN SALTY ENCRYPTED MESSAGE --
WZ {/ rf 4a aQ 8f tC WI c? VJ nK UQ 
>T 7W nj W7 rR r~ r& :. zY NJ sm k6 
`@ eq G5 Ty Tl uE %T uR AM D_ J~ "Y 
p+ q2 AM dN 0} ;H #v Ez L_ 9m }! X^ 
Ws `v %) >v ,_ ^] 70 ,+ hv TN
-- END SALTY ENCRYPTED MESSAGE --

(Note that the cipher will change with each encryption.)

The above cipher is identical to this shortened version:

RX.c:L6%xUa,Rhg>w%@]X+rl|a4{uPVRa.)
;&wSOD+_(kJ=bZ?&_|*z+se035=Dw*2Rl?(
H&0c{~5i@CT!V&m5O4&BHNcEL:%c5Tbsd9n
#8++h/*YsGP

Using the key above on either cipher will yield the same plaintext message. Salty’s shortened format is ideal for space-restricted contexts (e.g. Twitter), whereas the longer format works better in emails or other places where text might need to freely wrap.

Spec

Salty’s spec is uncomplicated:

• Take a plaintext message and encrypt it via NaCl’s secret key authenticated encryption scheme “crypto_secretbox”.
• Then take the resulting binary data and encode it in basE91. (Why basE91? It’s the most efficient base conversion around, making the most effective use of available ASCII characters.)
• The resulting encoded cipher can be used as is, or wrapped in the BEGIN header and END footer, and spaces can be added to make the cipher wrap nicely in different places (e.g. email).
• When decrypting a cipher, first remove any spaces or newline characters, as well as the optional BEGIN/END header/footer. The resulting basE91-decoded cipher is ready for decryption via NaCl, using the same key and salt used during encryption.

API

Salty comes with an uncomplicated API. Simply POST an action of either encrypt or decrypt, a payload of plaintext to be encrypted or a Salty cipher to be decrypted, and a key. The response will include an http_status code (200 for success, 400 for failure) and a response consisting of your encrypted/decrypted text (or an error message if the status code is 400).

Further Reading

• NaCl: Networking and Cryptography library
• basE91
• Libsodium

salty's Issues

Errors when trying salty on own php 7.4 server

Hi - I copied salty to my own nginx php 7.4 server to test, and am getting this error:

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/saltyesoliapro/salty.esolia.pro/salty.php on line 60

Deprecated: Array and string offset access syntax with curly braces is deprecated in /home/saltyesoliapro/salty.esolia.pro/salty.php on line 87

Fatal error: Uncaught SodiumException: invalid hex string in /home/saltyesoliapro/salty.esolia.pro/salty.php:37 Stack trace: #0 /home/saltyesoliapro/salty.esolia.pro/salty.php(37): sodium_hex2bin() #1 /home/saltyesoliapro/salty.esolia.pro/index.php(3): include() #2 {main} thrown in /home/saltyesoliapro/salty.esolia.pro/salty.php on line 37

Looks like it's in the base91_decode function and it appears this SO thread sheds some light:

https://stackoverflow.com/questions/59158548/array-and-string-offset-access-syntax-with-curly-braces-is-deprecated

But I'm no php expert so, I'm not sure if that's a help.

As for the third error, it's this line:

define('SALT', sodium_hex2bin('hex representation of 16 bytes of binary goes here'));

I assume I need to set this salt up for the app, somehow. Do you mean us to take a 16 byte decimal integer, convert to binary, then convert to hex?

Question about implementation

This seems like a great way to share passwords with clients. You can email the encrypted short text and tell them the key over the phone.

About implementation, I wonder, could you share how you implemented on salty.fyi? I would like to put it on our own server (we would need the UI to be Japanese), but want to understand how you've got it set up, if you don't mind. For instance, the form action is pointing at /#salty but what does that mean on the server's file system?

<form action="/#salty" method="post">

<label for="payload">Payload</label>
<p><textarea name="payload" id="payload">Quick brown fox</textarea></p>

<label for="key">Key</label>
<p><input type="text" name="key" id="key" value="123"></p>

<input type="submit" value="Go">

</form>

Use of API

Hi, I'd like to pass the api a payload and key, via say URL params, and get back the compressed version of the encrypted string. Is this possible?

Logs

Hi - I was thinking about how storing any kind of credentials in a log inadvertently might be an issue when running Salty, but I cannot find any trace of the payloads or keys I've entered, in my own server logs.

Can you please confirm the security situation with regards to storing whatever people might enter in forms or send via an API on a Sendy site?

Thanks in advance,
Rick

Type alert is incorrect when passing compact salty cipher via payload param

If you pass a url-encoded compact salty cipher "blahblah" to the web UI like ?payload=blahblah, before entering the key and pressing "go", the web UI autodetector indicates it's "plain text", not a salty cipher. Is there a way to indicate this correctly even when passing via url param?

Translation of UI, result on correct page

Hi - I'm trying to have two salty index.php pages, one in English and the other in Japanese.

Japanese would be:

https://mydomain.com/index.php (or of course https://mydomain.com)

English would be:

https://mydomain.com/en/

I am referencing salty.php on /en/index.php at ../salty.php and things seem to be working, but, if I enter a payload and key on /en/index.php, the result comes out at /index.php#salty showing the result on the Japanese page. I'd like this to be piped into the English index.php.

What can I do to make the result display in the right language's page?