ChaChaEngine fails after 128 bytes

[bcgit]

ChaChaEngine fails after 128 bytes

[peterdettman]

@wzoet Thanks for the report. We originally implemented a much earlier version of the draft (actually it might have been a slightly different draft even), so it's not surprising that we're no longer compatible, but we certainly mean to address this.

[timw]

As @peterdettman notes, this will probably be due to bc-csharp not implementing the 96bit nonce/32 bit counter split in draft-nir-cfrg-chacha20-poly1305 (now draft-irtf-cfrg-chacha20-poly1305). I've implemented this for bc-java in bcgit/bc-java#108, so if/when that gets pulled I'll migrate the fu to bc-csharp.

This report is a little odd/concerning though - it'd be good to see a minimal test case demonstrating the problem to be sure - since ChaChaEngine can't actually execute the quoted test vector: it enforces a 64bit nonce (the test vector uses a 96 bit nonce) and the test vector requires the first block of output to be skipped (the Initial Block Counter = 1 bit, which requires skip support (this is already in bc-java, but also needs porting to bc-csharp).

[wzoet]

I found out I already subclassed the Salsa engine and updated it for 96bit nonce support and changed the block-assignment of it. I also added a property to set the initial blockcounter value. I guess I didn't look thorough enough when updating this code. I should have mentioned that.

The real problem is in processBytes And getKeyStream though.
ProcessBytes initializes a 128 byte array and uses it upon the plaintext.
I made that size dependent of the input length and added some extra bytes so it is now a multiplication of 64. After that this array can be 1-1 xorred with the plaintext.

The generateKeyStream method has to create enough blocks to fill the entire output array and not just two blocks as it does now.

I could post my customChaChaEngine class here together with my tests if you like, the tests are from the document I pointed out in my first post.

[peterdettman]

@wzoet Apologies for the long delay on this. We did spend some time bringing ChaCha (and Salsa) up-to-date recently, including compatibility with test vectors from the latest draft descended from the one you mention (draft-ietf-tls-chacha20-poly1305-04). If you could quickly review the current state of things and see if you still see a problem here, it would be much appreciated.

[wzoet]

Hi,

Thanks for your reply and the effort to check into this.
I will check this in a few weeks when I have some more time. I will post back here.

Mvg,
Wim Zoet

Op 3 feb. 2016 om 17:49 heeft Peter Dettman <[email protected]mailto:[email protected]> het volgende geschreven:

@wzoethttps://github.com/wzoet Apologies for the long delay on this. We did spend some time bringing ChaCha (and Salsa) up-to-date recently, including compatibility with test vectors from the latest draft descended from the one you mention (draft-ietf-tls-chacha20-poly1305-04). If you could quickly review the current state of things and see if you still see a problem here, it would be much appreciated.

Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-179340373.

[wzoet]

Unfortunately, I am not yet able to use Tls.ChaCha20Poly1305 in my code.
This is because of lack of some example code to use this class. I need a TlsContext which I don't know how to create.

I did test the Chacha7539 engine. This produces the same chacha result as my code, but does not give me the opportunity to extract the poly1305 key in the process.

I included my own code. To use this code, I had to set the accessmodifier for engineState of SalsaEngine to protected and some methods in the Pack class had to be made public.

Do you have any exmples for this, perhaps based on the example code included?

ChaCha20Poly1305.zip

[wzoet]

Getting back to this github issue after a busy period. I see you asked me to test the TLS version of the algorithm. My code is a conversion to a AEAD version: https://tools.ietf.org/html/rfc7539

[jimsch]

@wzoet I needed to get a version of this running, but was not ready to get it up to snuff for BC. However here is a pointer to my version https://github.com/cose-wg/cose-implementations/blob/master/csharp/COSE/ChaCha20Poly1305.cs

Note that there are a couple of different things, one of which is a reset of the key schedule that occurs after the first 128 bits are generated and an increment of the counter before starting encrypting the data. This might be your problem.

I also had to totally re-write poly1305 as the version did not match what is in the CFRG specification at all.

[wzoet]

@jimsch Thx for the input. i have it working in my code already, using an inherited salsa engine. Therefore I have no current need for solutions. Just wanted to point out that this part of the library was not producing right results for me and that an AEAD cipher is not present.
I rather use proven libraries in my projects than custom solutions which are hard to maintain.

[peterdettman]

I'm assuming this issue is obsolete. Release 1.8.2 already brought Poly1305 into line with RFC 7539, and I don't think there were any problems with ChaCha20 itself.