CHAX file crypter documentation by EddyHawk
---
What
---
CHAX is a file encrypter coded by EddyHawk (me).
It is part of PROTAGON File Crypter (PFC) series done by me.
CHAX uses XCHACHA cipher, MD4 & SHA-512 hash functions, and HMAC & PbKDF2
 constructions, all adapted/taken from WE Pascal sources.

---
What is XCHACHA
---
CHACHA is a stream cipher designed by Daniel J. Bernstein (DJB) [2008].
It is a synchronous stream cipher having variable rounds, claiming 256bit
security, & (even at 20 rounds) consistently faster than AES having 128bit key.
It's a variant or extension of SALSA20 stream cipher by the same designer
in which SALSA20 with 12 rounds managed to be included in ECRYPT eSTREAM
portfolio.
It aims for faster diffusion at equal performance with SALSA20.

CHACHA is relatively easy to be implemented.
CHACHA outputs 64 byte (512bit) at a time.

CHACHA restriction: 2^70 bytes per pair of key/passphrase & nonce.

Best known attack to CHACHA:
 256bit Chacha/7:
  CCD attack requiring 2^246.5 operations [Shi et al. 2012] 
  attack requiring 2^242.82 operations [Maitra 2015] 
while SALSA20 best known attack is on 8 rounds, thus partially validate that
CHACHA is slightly stronger at equal speed than, or slightly faster
at equal strength with, SALSA20.

Unbroken status: as 2015, 7 years.

In the same way that DJB turns SALSA20 into XSALSA, I turn CHACHA into XCHACHA.
Thus mind that DJB never specifies XCHACHA. Thus, this is unofficial extension
to CHACHA.

---
What is WE Pascal source
---
Wolfgang Ehrhardt (WE) creates a collection of crypt Pascal sources which is
freely available in Internet, supporting Borland Pascal 7, all flavors of
Borland Delphi, Free Pascal Compiler, & Virtual Pascal, in single source.

However, WE doesn't implement XCHACHA. XCHACHA stream cipher for CHAX is thus
adapted by me from that collection [SALSA 18 Jul 2009], then compiled under
Virtual Pascal v2.1b279.

MD4 & SHA-512 hash functions and HMAC & PbKDF2 constructions for CHAX are also
taken from that collection [CRC_Hash 25 Aug 2014], also compiled under
Virtual Pascal v2.1b279.

---
My Changes to WE Source
---
Besides adding XCHACHA support to WE source of SALSA20, I also apply
user-customizable round number. Thus users of CHAX can choose:
-default round number, which is balance between speed & confidence
-lower round number for faster speed (less confidence)
-higher round number for higher confidence (slower speed)
-even lower round number for curiosity/testing/experiment
-even higher round number for curiosity/paranoidicity
Odd number of round is also supported in the same way SALSAX supports it

And just like SALSAX, CHACHA internals in CHAX is now also coded in BASM32!
Finally I manage to code it myself.
And since CHACHA requires less instructions than SALSA20, CHAX may perform
slightly faster than SALSAX at the same round number! 

Perhaps 21 rounds or more are already 'paranoid' enough and custom values
should be up-limited to say 40, but unless there's good reason to do that
(such as program hangs) I don't want to prevent users who wish to gain even
more confidence and willing to wait even longer ('paranoid' users). Very short
files (say less than 100kb) with extremely high round number (say 100) will
still be (en/de)crypted very fast and grants extreme confidence to the users.
Yet users should remember that relying on higher round number alone (and say
neglecting your passphrase strength) isn't sufficient because attacker(s)
always attack the weakest part.
Also remember that very high round number is beyond designer's recommendation
& imagination and may produce unexpected effect (say, short cycle)

---
CHAX specific features
---
It accepts 256bit key only & defaults to 16 rounds

192bit IV

Custom round number, from 0-65535

BASM32 core

To improve speed, CHAX avoids using chacha_encrypt_bytes & instead using
chacha_keystream_bytes. A special buffer is prepared to hold keystream from
chacha_keystream_bytes, and the buffer is 32bit-xor-ed with plain/cipher -text
(file) buffer using my 'xorbuf'.
But due to this, plain/cipher -text buffer becomes only half of other PFCs'
because the other half is used by the special buffer, while I want all PFCs
to have same sized buffer (so they can be fairly benchmarked).
Another problem is that Fast Verify also operates on half buffer (thus slower
than other PFcs).
I tackle the last problem by declare another buffer which occupy those
2 buffers (using Pascal 'absolute') when performing Fast Verify, so Fast Verify
get full buffer just like other PFCs.
Then I managed to rewrite 'xorbuf' for CHAX so it can use single full buffer,
with few expenses such are additional 64byte mem, & more complex calculations
for xor-ing. Thus CHAX can utilize full buffer for (de)crypt & Fast Verify,
& (de)crypting the random-sized random-data addition is simplified.

---
Caution
---
No test vector available, thus I can't check the correctness of my
implementation

Of course that users specifying non-default value (say 15 rounds) for
encryption for a plaintext must also specifying the same value under decryption
for the resulting ciphertext, if they want to get their ciphertext correctly
decrypted

Remember that too low round numbers are too weak for 'security', the obvious
such values are 0 to 2. Values < 8 are only for meant for experiments.
Maximum value is only limited by program parameter size (longint) & cipher
internal parameter size (word), so max is 65535. That should be
way way way more than enough :-) If you specify minus value, it will default
to 16, while if you specify > 65535, it will default to 65535.

---
Notes for certain number of rounds
---
  2: compressible keystream
  3: incompressible keystream
  7: best attack on ChaCha is 2^242.82, 'slightly risky'
  8: 'minimal safe'
 12: normal following SALSA20/12
 16: default in CHAX
 20: conservative following SALSA20
>20: paranoid
>24: ultra paranoid

End.