Is there an upper limit to plaintext size in XSalsa20Poly1305? While fiddling with the NaCl implementation in Go, specifically SecretBox, a general crypto question came up after reading the documentation.

Quote:


  Package secretbox encrypts and authenticates small messages. 


I haven't seen this before. Is there a maximum size? What constitutes as a small message? 

I've looked for some paper or documentation explaining that line, and I even went through the source, but I can't find any related information anywhere which explains the noted limit when it comes to the size of the message. 

Practically, I just successfully encrypted hundreds of megabytes of data. So, I am really puzzled as to why the docs say it was specified for small messages only. Currently, I am guessing that there is a cryptographic reason for this which I simply may not be able to find.

So – to recap – what I'm asking is: in Salsa20, is there a limit to the message size that is possible? If there is, can you additionally provide a hint where I can find a related reference/paper for me to look at?

Update:

The issue that I opened has been resolved, and the documentation updated to clarify the limits.
As a comment points out, it’s most probably a mistake/error in the docs.

If you look at “What is the PRG period of stream ciphers such as RC4 or Salsa20?”, you’ll find an answer which explicitly points out the limits of Salsa20 (quote) 


  …Salsa20 used as a stream cipher, it uses a 64-bit block counter and 64-bytes blocks, limiting its capacity to $2^{73}$ bits. After that, the counter would rollover, and thus the output.


That’s a 1180591620717411303424 bytes (around and about 1180591620 Terabyte) maximum size until rollover, which I wouldn’t really call “small”. But that might just be me…

For reference purposes, see the Salsa20 paper (PDF).

EDIT


  Comment by Eclipse:
  SecretBox uses Poly1305 so could it be something about how they work together?


I also don’t see any reason the use of Poly1305 would limit things. If you – for example – look at RFC 7539: ChaCha20 and Poly1305 for IETF Protocols, you’ll read a usefull hint (on page 20) which – from my point of view – practically excludes Poly1305 as the source of any “small message” limits.

Quote:


  …, the ciphertext length field in the construction of the buffer on which Poly1305 runs limits the ciphertext (and hence, the plaintext) size to 2^64 bytes, or sixteen thousand petabytes (18,446,744,073,709,551,616 bytes to be exact).


When you look at page 6 of that RFC, you’ll read that that RFC assumes it’s safe to handle 247,877,906,880 bytes (nearly 256 GB) with Poly1305. So Poly1305 doesn’t really seem to be a limiting factor either which might explain a “small message” comment like that.

All that’s left is a potential limitiation in the implementation itself. If you can’t find “small message” limits in the sourcecode either – which you already checked and confirmed to not exists – an error in the docs is most likely. In the end, the statement …small messages seems to be nothing but a “small” glitch in the docs which causes superfluous confusion where it shouldn’t.