mrdcvlsc / chacha20-poly1305

A C++ implementation of ChaCha20 & Poly1305 stream cipher described in RFC - 8439.

Hi, I'm Jubal Mordecai Velasco!

Exploring the vast branches of computer science, searching for my place within it, and striving to add a leaf of knowledge to its ever-growing tree.

Welcome to my GitHub profile

I'm still currently a student 🧑‍🎓 taking up a degree in computer science.

At the same time, I'm also growing 🌱 my knowledge 🧠 and mostly learning 📚 new things little-by-little 🐾 on my own during my free time, in the following concepts :

Linear Algebra, BLAS Libraries & Matrix Libraries, x86 & x86-64 Assembly, SIMD Assembly Instructions & Intrinsic, Arbitrary-Precision Arithmetic, Machine Learning, Neural Networks like FFNN, CNN, GAN & transformers models, Full-stack development, Cryptography, Web Security, Compilers, Automata Theory.

• 📫 email : [email protected]

---

Dashboard

---

I Have Experience With the Following Frameworks, Tools, Environments, etc.

chacha20-poly1305's Issues

32 bit mul on uint512/uint320

Currently this repo is taking advantage of the assembly instruction mulq and the rdx:rax registers to get the product of two 64 bit unsigned integers.

This arises to the problem of propagating the carry to the most significant limbs.

If the next limb where the rdx is added using adc %%rdx, %[i] overflows, that would mean we need to add the carry again to the second next limb and then if that second next limb also overflows after adding the carry using adc $0, %[i+1] then we need to add the carry again to the third next limbadc $0, %[i+2], and this can go on until we reach the last limb or the most significant limb.

In short, In order to get the result correctly we need to call the adc sequentially from where we perform the first add operation with the rax, to the adc operation with the rdx, up until to the most significant limb.

Meaning we repeatedly use adc just to propagate the carry until to the most significant limb which I think is expensive?

I wonder if we can avoid this (maybe) expensive(?) carry overflow solution by using only 32 bits of integers in the multiplication operations when getting the product so that the sequential use of adc can be avoided(?).

(or maybe it's not needed because it's just operating on a uint512?, maybe it's only expensive for dynamically big integers?).

implementation of uint320 to replace uint512

currently this repo is using uint512 for the Poly1305 mac/tag generation.

But since the multiplication of (acc+block) and r inside the Poly1305 does not exceed 2^288, a uint320 would be enough, It will use less operations and gain faster performance.

I can't compile this file in MSVC

Hello, when I was searching for chacha20-ploy305 encryption, I saw your code on GitHub and thought it was great, but I couldn't compile this file in my own VS2022 MSVC environment.

known timing attack vulnerabilities

These are known timing attack vulnerabilities in the code that should be addressed/fix in the future.

• uint320 uint320::% - returns the quotient right away if it detects that the dividen is equal to the divisor, or if the dividen is less than the divisor.
• uint320 uint320::compare() - returns the boolean right away if it detects less than or greater than cases early. (due to being the backend function for the operators ==, !=, and <=, they are also adds up to the vulnerability on each use cases).
• There is no constant time comparison function for authenticating the Poly1305 tags.

Buffer encryption & decryption support

A more C++ friendly api

Implementation of a more C++ api

• implement a much easier api like maybe an encryption or decryption that returns a vector<unsigned char> results?

Tutorial Documentation

Create .md tutorials on how to use the different functions of the repo