I am trying to use the EncryptArmor62Seal function to encrypt a message for another party. I am following the example here:

https://pkg.go.dev/github.com/keybase/[email protected]#EncryptArmor62Seal

The issue with the example is that the public key for the receiver is obtained based on the secret key of the receiver. So the conversion process is:

saltpack.BoxSecretKey -> saltpack.BoxPublicKey

However in a real world application you don't have (and shouldn't have) the private key of the recipient. You only have the raw bytes of the public key. But going through the documentation I found that every constructor function or import function presupposes the possession of the private key, which we don't have.

So how can I encrypt a message when all I have is my own private key and the 32 byte array raw public key of the recipient?

I was looking for an encrypted messagepack library and found this project. My goal is to add encryption to a location based app which uses websockets to stream in real time the position of its users. As such, I would expect to send less than 100bytes per user every 5 or 10 seconds at most, which is far away from the readme description of breaking up messages in sizes of 1MB sizes.

Is there anything bad in saltpack for short messages? Will each of them pad to 1MB chunks of gibberish or this is this sentence just aimed at developers willing to implement multimedia communications (sending pictures, audio, video, which weight much more)?

Returns 502 to Cloudflare.

Using go get github.com/keybase/saltpack doesn't generate an executable (at least, not under macOS). How to accomplish this?

https://saltpack.org/signing-format-v2 is giving this error

 Error: Couldn't load /vol/data0/home/keybase/src/keybase/saltpack.org/views/doc_symlink/saltpack_signing_v2.md

Edit: All spec related pages are throwing same errors.

I don't know if anyone monitors this still, but just letting you know that saltpack.org's SSL cert expired yesterday.

Bottom of README, there is a link on "spec" which redirects to /encryption-format but looks like the new one is supposed to be /encryption-format-v2

https://github.com/minio/sio (D.A.R.E. v2) seems very similar to NaCL providing an stream of GCM encrypted chunks + Salsa20 and Poly1305. It looks like this project improves on the "Armor" / display part of things for binary chunks.

With PGP, I can clear-sign, so that the text of my message is available in plaintext, but armored with the signature. That way, if you have PGP, you can paste the whole thing into a verify command and confirm it, and if you don't have PGP, at least you as a human can read what I was trying to say.

Saltpack's detached signature format means it's possible to separate the signature from the plain text, but there's no convenient format to send both the message and the detached signature in a single text block. For example, everyone posting Saltpack signed messages to Mastodon right now to identify themselves is posting a message that humans can't read, even though the messages aren't encrypted. It might be that lacking this functionality is intentional (perhaps to discourage https://xkcd.com/1181/) but that wasn't clear from the docs.

The 3 links under the Go heading on https://saltpack.org/implementations point to the old github.com/keybase/client/tree/master/go/saltpack locations which are gone.

They should point to the new locations including https://godoc.org/github.com/keybase/saltpack#pkg-examples

My friend send me a message on Slack with a BEGIN KEYBASE SALTPACK ENCRYPTED MESSAGE prelude. I typed this phrase into Google, landed on saltpack.org and have been trying to figure out how to decrypt the message.

I've scanned the sidebar, read the intro, read the homepage, read https://saltpack.org/signing-format, read https://saltpack.org/implementations. I ran go get github.com/keybase/saltpack and expected to find a saltpack binary on my $PATH - I could then call saltpack -h and maybe learn about decryption options, but that also failed. I'd rather not write a Go main function to decrypt the message.

I expected to find something like this:

Decrypting messages with Saltpack

To decrypt messages, save the encrypted message to a file, then run keybase decrypt foo.bar or call saltpack decrypt file.name

or whatever other instructions I need.

Or a list item in the sidebar that says "decrypting messages", or something.

I found following post on Stackoverflow. https://stackoverflow.com/questions/23913737/base62-hash-of-a-string

This made me think why saltpack is using base62 and not base64.

I'm trying to learn here about the difference and why it was a better choice for saltpack.

I was wondering if there a reason why we can't get the RawBoxKey out of a SecretKey.
I'm playing around with saltpack and I'm using the keyring to create secret keys, but I can't seem to find a way to get the RawBoxKey from it in order to store it and then load again later.

Am I missing something obvious?

The sample cipher text found at the following website is invalid when used in the latest version of the Keybase client for macOS (Version 5.3.0-20200310172631+4f2689009b (5.3.0-20200310172631+4f2689009b)):

Website:

https://saltpack.org/in-the-wild

Ciphertext Sample

BEGIN KEYBASE SALTPACK ENCRYPTED MESSAGE. ZUHRHckf9VJ6ich bKthcfFYyHcFs9n NI27ndpDFCqUnXj allzG097b3s5NfZ GYqoBPt7GnyCccB i0UhaCcVmbF55ms SYpOCl7tkjUJd40 DO6iR0dJpW60EKj 1K5x2hclL9hZb7V DRObuimxmStmqqs 7yWy26mVOa5Z5RM S7NeocvOyNlgBUp fhsPaNFrYuI3D4H Ku217LIW3V2wniP 7XkayWcyAfH8jWj ETF0WJPn2Aa1aOI Jz5olg5vyxIpofL FIuerimZ6n5qI3p NZr3pfBVjVLbYDO N3VgqUd5r2F85LE vWH3Qg8aK0aFkVw q1ZVVWbOm5ucueX 9RkRpkb2tZOenqu Ik7RAQEbcW5JIlv EFY8c5WjUYMONiM H0DQtdKsdZRjfTm ajt71qa33pffsSE rYDTXFBtGudM9FX SHXAMCGDHVH2sSF yb23QJVJuyGAHuO XpHP06EXRCHj23y GOk77q23cYVd01X 08U6bsPmweu5jvS 7SLTg0OsJpqTsUB NfrZyJ2gSppcPlL bZaTgtoL8U9ZzBV sHKMD5vGiUgb74u llrukVSRcTqk2bO 5wdQ57EmY8IjJSn Lznnv9PhY8xnsTT EVPQcAH0CszKDQN LskpyRGDhsCbuzH 6YSFe2grnjccVAK uvaqEELV4Fnf90s cLxe65hn8918oz6 8BNj30RaMiEJbpq wXfb7vHPfrd1vVe raU4tfG5MZD34s7 xfvLCKSlctVLO7O q1MAgPtT73CGVU8 c4gkvmFWANwUC7g YivwSxNkn5PWiL2 NsaE8UfQDptjGDN hR96GQfuWJ63JTE gGa19OrSzgIErLK IAexacwBNiAXbPb ViAIrl0w6BL4aSa j5p5GZi5PPNlJ2Q OPo67OkcmweyfwE vNGrC7y3PxAemOU GRxeHbQ3FI77C2Y 9OyFG0LT3Qo04iK BVbp0r7xAX0i26O mybjcCqn4eBLKcy 87YiDgQRSa4n2fk c1Q0plK9e2U8rk6 6D0kx3bkxdG8Boy s6kTH9moQzAuKoG yLnoq9cmjCKfrOt 2K4vlJiAqJglyeu rm2lZEHIPW9sELw 06cowGDsmfcGN7h T6j9fbMgNGo9eIs s4YQd5tIKzoWsXl SSPNrVjaNMxtJsI IIjSCrPdjL2oSv6 eHDWXWmPJW6XIBI Ar7ZE8vAFRQSvr8 v9vAB7kALQpHdMv SiRbM1bQ6or7r0l P2QHXfA2lRykA9y 6kX8n0CCWZPO8Qo V4mhJCSF3snj9RK kwZosJw2AyvqDLs OAZ8OPdyYGx3FTg 7PaOijY9fQxcBVM 3omDhcawPWdA7jN 3ZQMvd9FKwIbu7H sF1YJixcN6OLzCp tbCKIi7xwUK0oGw XrO7QaFsHYEXNg9 RbMpaYtGfewhkUj 6LFRs9zfq8K13ni dV8d6V8eApAmgTp 8x3DtGdazE8F0ZG cSAwjiKLJVzYmpj jUiWtx0xcx0J6Hn VeSxuHKKYa7NASA BBzX454HGK3OXvt hPJua8eygXO9Ucp 2nNT12FOfkozrYM M4CkXaBQzYMkYzY sGO1c2plDJaEbV9 9guG5XJg3iJO23K CB7WtsJypxmkMoy eQYuNQMlKk4MU8b NuZhauMnqqQQfNG 1tJLhLyzyHfkBBL rnQo9cstcFLZAd0 md5lpy0X. END KEYBASE SALTPACK ENCRYPTED MESSAGE.

Error Message in macOS client Decrypt tab:

This ciphertext is not in a valid Saltpack format. Please enter Saltpack ciphertext.

It was expected that the client would say the following for a message encrypted to max that I don't have the key for:

Your message couldn't be decrypted, because no suitable key was found.

... or user should not be allowed to generate unparseable messages.

	smsg, err := saltpack.SignArmor62(
		saltpack.CurrentVersion(),
		[]byte("message here"),
		secretKey,
		"TWO PART",
	)
	if err != nil {
		panic(err)
	}

	skey, msg, brand, err := saltpack.Dearmor62Verify(
		saltpack.CheckKnownMajorVersion,
		smsg,
		kr,
	)
	if err != nil {
		panic(err) // will panic here, unable to parse the header
	}

SigningPublicKey interface has Verify method:

Also SigningSecretKey interface has Sign method.

That's very OOP of it... but maybe not ideal.. Maybe the interface name needs the change and the BasePublicKey becomes PublicKey...

I think the interfacer linter reports on this too.

@oconnor663

At one point, the spec for encryption states:

The recipient public key is the recipient's long-term NaCl public encryption key. This field may be null, when the recipients are anonymous.

However, later on it says,

For each recipient, encrypt the payload key using crypto_box with the recipient's public key, the ephemeral private key, and the nonce saltpack_recipsbXXXXXXXX. XXXXXXXX is 8-byte big-endian unsigned recipient index, where the first recipient is index zero. Pair these with the recipients' public keys, or null for anonymous recipients, and collect the pairs into the recipients list.

It's unclear how you're supposed to encrypt the payload key with the recipient's public key if the public key field is null, i.e., if the recipient is anonymous.

In the encryption example, the array order has its final_flag still at the end, contrary to the specification

I publish conference notes (sometimes) in a public GitHub repo

Today I took some notes where the presenter asked me not to make my notes public. To still keep all my notes organized and in one place, I wanted to commit the notes encrypted with my own public key. Since this would look very weird, I wanted to also add an explanatory comment (which I'd do in the PGP Comment: field normally) to explain why the contents are encrypted.

I'm having trouble, however, finding a way to do something like this. Is it even possible, or planned?

Hi, the saltpack.org website appears to be broken in its current state. The homepage and pages listed under the "Basics" menu all work, but the spec details (e.g: Encryption, Signing) display "Error: Couldn't load /home/keybase/src/keybase/saltpack.org/views/doc_symlink/saltpack_signing_v2.md" (or whatever page should be shown).

guys, it's not cool when you develop tools for trust, but your site is devoid of trust =(