Basically a first implementation of the chacha20 Poly1305 algorithm #90
Conversation
Still not working.
* Fixed bugs to get stream functions working - not yet tested * shrinking base classes to get the extended aead functions working (ccm, gcm, poly1305) - not yet tested
Minor: removed debug idx variable.
|
Added code to implement XChaCha20 as well |
|
I need to find the time to look at this over the next few weeks. Please be a bit patient! I value your contribution. Thanks for the warning about the changes in the base class. Yes, they need to be evaluated carefully. Does your code contain unit tests? |
|
Yes.. at least the two vectors from the original RFC. I found a bunch of test vectors here: This commit would also tackle the problems with the encodings - I changed the base class so it could be used in such a way. The chacha and GCM modules are already converted. Let me know what you think of that. |
|
We should try to have unit tests for as many areas of the library as possible. |
|
Refering to this one: "do you think it is a good idea to implement them here?" |
|
They actually include the RFC test in their test suit. It is even the first test.... |
|
I try to find original test vectors. Ok, when I took the library over there was some "crude" automatic test program which worked on a text file which contained the test vectors. And there were about a dozend unit tests for some newer date helper functions (from DECUtil). I started to implement unit tests for those test vectors in the text file, without questioning where they came from. Later on somebody reported a few flaws and fixes for them and that made me start to look for original test vectors for all the hash algorithms. After all those years I couldn't find them for all the hash algorithms but for those where I found them I added them. For KDF it was like this: the original author had implemented KDF2. At least that's what he had claimed. I found there were no tests yet and found the KDF specification and the test vectors for KDF2 didn't match the results produced by DEC. So I started to investigate and found out, that the original author had implemented KDF1 and KDF2 and 3 are only small deviations from that. The only difference is the order of 2-3 lines of code in their main method. So I implemented these two as well and added tests from that specification. => I try to find the original specification of the algorithm, be it some PDF, an RFC whatever and check if that contains test vectors. Also NIST is sometimes a source for test vectors or other standard bodies. Does this answer your question? |
|
I see... thanks for the info. |
Removed dll reference Fixed a crucial bug in the poly1305 generation - the ConstTimeCarray32 had wrong brackets applied.
|
These two last commits include the found test vector - about 300 tests. |
…d also AES HW support).
* extended additional buffer size in AES to allow alignment * Moved align code to DECUtil.pas * Fixed an old assembler routine for 64 bit byte swapping * Fixed include file - it only worked for 32bits environments but not for 64 bits * Updated chacha defines so they work with the DEC internal defines (removed my original ifdefs) * Fixed bug appearing in the gcm testcases -> wrong blocksize should throw an exception
|
Just a few updates here:
And... There are now new routines that utilizes the Intel AES instructions + a class variable that allows to fall back to the purepascal implementation (the original). |
|
Any thoughts about the update? |
* Added tests
|
Just checking ;) any news if that implementation is useful? There is now also some AVX assembler code for the Poly1305 implementation which does some decent speed increase I guess... |
|
Thanks for reaching out and sorry that I still haven't found the time to look at it! I can also tell you that I only should have time for this starting in summer, as I'm still in the middle of my preparations for a lecture at the local university (my first one) which will start in March and that's not the only time bound thing at the moment. I do hope that after the international Pascal Congress, where I'm a speaker (yes, I still need to prepare that one as well), see here: https://pascalcongress.com/talks.html things should get a bit calmer and I do hope to find then a bit of time for DEC again. Can we agree on moving this development to its own branch? Is this ok for you? |
…1305 - the current available CPU is queried and the best mode is selected
|
I actually was working on the development branch (a fork of it) - I created a pull request which seems to commit to the master branch though - I hope that is ok... Congrats by the way to the IPC talk and your course in the university :) I hope these will rock 👍 I don't know if it is actually necessary to have a separate branch to work on - I can still use my fork and create pull requests right? (I'm not so fluent with git and try my best ;) |
|
I'm not so fluent with git either and I'd really like you to not work on the master branch. For this I ccreated a new branch for you from the current state of the development branch: |
mikerabat
changed the base branch from
master
to
development_chacha20poly1305
|
Oh great :) thanks for that - I was able to change the branch target |
|
Great that you managed this! |
|
I guess all that is left is that you merge these then... And to keep in mind that the AES test cases that depend on chunks or streams are now all failing (since the underlying test case is flawed). As far as I can see there is another pull request that fixes these right? |
2 participants
Hope this works as intendent....
Basically I implemented the base chacha20 algorithm and a poly1305 mode following the GCM mode implementation.
I need to say I did quite some rewriting on the base class (don't be mad...) to have a more leaner interface in the
cipher classes.
In addtion I rewrote the GCM part such that it works on streams too - multiple encode/decode calls are now allowed.
This was a rewrite of bug #87 based on the new base authenticator class.
I did not rewrite teh CCM stuff - simply I didn't knew how...
There are also SSE, AVX version of the chacha algorithm so I hope I managed to put it correctly in there - unfortunately I was not
successfull with a SSE/AVX version of the Poly1305 algorithm, this one is way more complicated that chacha...
Let me know what you think of the code...