Possible to decrypt every fragment of an ecrypted file on its own? I have a project where I want to encrypt a file and split it up into several fragments and place these files on different systems. I want to do it on mobile phones as well, so I chose poly-chacha20 as encryption. In my tests it was faster than AES based encryptions. The concern of my tutor is now, that because of the nature of stream ciphers, it would be possible to decrypt each of the several fragments on its own, as long as you have the key, which would be a no go. In my tests I could decrypt the starting fragment, but not the fragments after that, so I'm not sure what is correct now. Is it possible to decrypt every fragment with the given key? Or is it needed that you have all the fragments first before decrypting them?
Unless I'm misunderstanding something this should be fairly easy to do.
The scheme of a stream cipher is the following : 

                    Key
                     |
                     v
               +------------+
               |            |
     IV -----&gt; |  Chacha20  +-----+
               |            |     |
               +------------+     |
                                  |
                                  v
MESSAGE ------------------------&gt; +------&gt;  CIPHER TEXT


Thus you have : 
$$K_{stream} \oplus Message = CipherText$$

If afterward you split your $CipherText$ into blocks of $n$-bits. Then you will notice that the first $n$ bits of the $K_{stream}$ are used to encrypt the first $n$ bits of the $Message$ resulting into the first $n$ bits of the $CipherText$ and so on... 

Therefore, in order to decrypt a $block$ on a separated device, you need to know its position into the full $CipherText$ (how many bits are present before), generate the $K_{stream}$ from the $Key$ and $IV$, drop the first $n$ bits of this $K_{stream}$ where $n$ is the position of the $block$ in the full $CipherText$, and then you can start decrypting your $block$.

Remarks:


you don't need to know the length of the full $CipherText$ but only the number $n$ of preceding bits.
you will need this number anyway when you will want to recombine the blocks on a single device.