I am looking for a way (lib) to encrypt data sent over internet.
The endgoal is to have a server/client to server/client sharing program, so that two users (peers) can send eachothers files in a secure way.
Currently I am able to do it in a non-secured version (meaning raw bytes are sent and received)
As @kornel said, TLS is the way forward. You mentioned securing files, so an alternative to AES-GCM-SIV, if you can't have TLS, is the secretstream from libsodium, that makes splitting larger files into chunks relatively easy.
I see that TLS, the crate you recommend, uses TcpStream, but I started to implement my program as udp packets. Also I would like to use the least amount of libraries possible, so I am more looking into a homemade solution where I encrypt data myself (using aes 256 for example).
Keep in mind that the UDP packets can silently be dropped, reordered and duplicated on the wire. If you tries to reimplement just reliable byte stream transport on top of the UDP you'll get the another TCP at best but not recognized/optimized by the internet router boxes.
Is there any particular reason you want or must use UDP?
If you use UDP to transfer large files you will need to take care of: Lost packets, out of order packets, timeouts, retries, generally reconstructing your file from fragments , and so on. This is all done by TCP already so why reinvent the wheel and do a lot of work doing it yourself?
One of the first pieces of advice one gets from anyone concerned about such security is "Don't try and implement a crypto system yourself". It's complicated to get right and unless you know what you are doing and take great care easy to make mistakes and build something insecure. Better to use ready made solutions made by experts that has been extensively used, reviewed and battle tested.
Of course if all this is just a learning exercise then go ahead.
Typically "amateurs" make their mistakes and create a broken crypto system in all the rest of the system. Using insecure random salts, insecure key distribution, transmitting messages with the same key, and so on and so on.
This was famously demonstrated by the cracking of the German Enima in WWII. Made a lot easier when a German wireless operator resent a modified message using the same key.
Even in my very limited real work on crypto communications, many years ago, I found a flaw in a NATO standard crypto device we were supposed to be compatible with. They had failed to encrypt the zero padding bytes in blocks at the end of messages.
I have the same recommendation as @ZiCog. As long as it's just for learning-purposes, go nuts. I'd still consider taking a look at the documentation and implementation of the aforementioned, just to see what kind of threats exist and how they are mitigated with secretstream.
If you still just want the raw "encryption" part, then look into AEADs (authenticated encryption). The XChaCha20-Poly1305 AEAD is good (in addition to the suggested AES-GCM-SIV). Both libraries I linked earlier support XChaCha20-Poly1305 as well.
I depends on what you mean by same length. Encryption is done with XChaCha20, which is a stream cipher. This means that the ciphertext is the same length as the original plaintext, since there is no padding. In reality, you won't get the exact same length for a stream. Each stream message is individually authenticated in secretstream, which means each message has additional data appended to the ciphertext. The length of this data is what is called ABYTES in secretstream (I don't know if sodiumoxide documents this, but I know Orion has it listed).
I don't think that's possible with modern AEAD based crypto. Also it would leak the information.
Leaking the original length of the plaintext happens with (X)ChaCha20-Poly1305. This usually isn't an issue, but if it is, I'd just add some amount of extra bytes to simulate some padding I want, and then split it off during decryption.