> Can someone give some notes about the security of NaCl Secretbox using Poly1305 as authenticator and XSalsa20 for encryption?

(Speaking as an unqualified outsider) Both Poly1305 and Salsa20 are creations of Daniel Bernstein / djb, who seems about as highly respected as you can be in the crypto community. And NaCl, the library they use that implements them (also by djb), is often highly recommended as a 'good' crypto library to use.

That said, it does go against the usual advice not to trust code from people who make their own encryption rather than using existing standards, but maybe this is the exception?

There was an article recently with some good commentary about how uneasy some people feel with how much of modern crypto being used in production is coming from relatively few people, including djb, but I can't seem to find it now...

Older column by Aaron Swartz on djb: http://www.aaronsw.com/weblog/djb

Relevant tptacek comment: https://news.ycombinator.com/item?id=705165 (no idea if this is still valid)

Great summary. The 'don't roll your own crypto' argument is mostly just shorthand to 'defer to the opinion of experts, use ready-made constructs when possible, and if not, then exercise caution when hooking crypto primitives together in unproven ways'. djb is without a doubt a crypto expert and his NaCl library provides sane defaults and good interfaces for implementing crypto in your application.

The other relevant tptacek post is 'Cryptographic Right Answers' [1], which suggests using the NaCl default for encrypting (ie. Secretbox [2][3]), so the rclone author is deferring entirely to NaCl for crypto, as it's recommended.

[1] https://gist.github.com/tqbf/be58d2d39690c3b366ad

[2] https://godoc.org/golang.org/x/crypto/nacl/secretbox

[3] https://nacl.cr.yp.to/secretbox.html

Yes, NaCl is probably the best choice for this.

Ideally you would not allow user-supplied passwords (random password > KDF-ed user password), but it's still solid.