CHIXA file crypter documentation by EddyHawk
---
What
---
CHIXA is a file encrypter coded by EddyHawk (me).
It is part of PROTAGON File Crypter (PFC) series done by me.
CHIXA uses XCHICHA cipher, DAZH-128 & DAZH-512 hash functions, and
 EPHS construction, all taken/adapted from WE Pascal sources.

---
What is XCHICHA
---
CHICHA is an supposedly improved version of CHACHA stream cipher
 by D. J. Bernstein [2008], which itself is an improved version of SALSA20
 by the same designer.
But this modification to CHACHA and the naming of CHICHA is actually done
 by me (and not by the designer), so this is an independent modification.
XCHICHA is just CHICHA supporting 192bit IV, using the designer's way to obtain
 XSALSA from SALSA20 (which I already done for CHACHA to obtain XCHACHA) 
My goal is to modify CHACHA to give incompressible keystream after only
 2 rounds (tested against CHAX) WITHOUT performance penalty. That is not easy
 to find, since CHACHA is already significantly improved over SALSA20
 in the same way.
Yet after many trials, I finally managed to do it.

SALSA : incompressible keystream after 4 rounds, near incompressibility on 3
CHACHA: incompressible keystream after 3 rounds, near incompressibility on 2
CHICHA: incompressible keystream after 2 rounds
(note: results are with feed-forward/final-addition applied on the last round)

The difference with CHACHA:
-slightly stronger quarter-round
 back to 'xor rotated sum' like SALSA20
  which I believe is stronger than 'rotates xor-ed sum'
-different rotation constants for quarter-round: 17,11,7,23
-different word ordering for even round
-different rotation direction

CHICHA quarter-round:
a:=a+d; a:=ror32(a,17); b:=b xor a;
c:=c+b; c:=ror32(c,11); d:=d xor c;
a:=a+d; a:=ror32(a, 7); b:=b xor a;
c:=c+b; c:=ror32(c,23); d:=d xor c;

CHICHA odd round (identic w/ CHACHA odd round):
chicha-qr( 0, 4, 8,12);
chicha-qr( 1, 5, 9,13);
chicha-qr( 2, 6,10,14);
chicha-qr( 3, 7,11,15);

CHICHA even round:
chicha-qr( 0, 9, 6,15);
chicha-qr( 1,11, 4,14);
chicha-qr( 2, 8, 7,13);
chicha-qr( 3,10, 5,12);

Why another variant of CHACHA? What about CHICHI?
CHICHI, especially the latest variant, have deviated far from CHACHA in order
to reach best chi-square distribution on 2 rounds (180-378). CHICHA,
on the other hand, returns to CHACHA basic principles as strict as possible
while attaining ideal chi-square distribution on 2 rounds.
Thus the resulting cipher should inspire more confidence to use than CHICHI.

But hey, this is not the same CHICHA. You changed the rotation direction!
Yes, but remember that CHICHA is informal cipher not submitted anywhere,
so changing the algo have virtually no consequence (PFC is not backward
compatible). And the change seems to strengthen it.
Also, I don't want to rename the cipher again.

In Salsax.txt, I complained about the SALSA20 diagonal constants (which are
also used by CHACHA, CHICHI, & CHICHA) But during my 'experiments' here,
I found that they are actually not bad. Changing them with a random letters
& digits ASCII 16-byte string doesn't seem to improve cipher output's
incompressibility nor randomness.

---
What is DAZH-128
---
DAZH-128 is 128bit hash function "designed" by me [2014-2015]. It is MD4 using
2 rounds of Chicha(-like) core & 8 constants as its Transform, and with another
(blank) finalization to fit the theme 'light hashing, heavy finalizing'
(2, 2+2) to achieve very high performance w/o (perhaps) sacrificing safety.
It is not tested for its crypto strength, thus non-crypto.
Implemented in VPascal2.1/BASM32, it reaches:
 ~1.10 Gb/sec on Pentium IV-E 'Cedar Mill' 3.0Ghz (desktop)
 ~0.67 Gb/sec on Celeron 1007U 'Ivy Bridge' 1.5Ghz (mobile)
DAZH-128 is improved version of DAZZ-128:
-real double-finalize
-byte message length, put on the front of 1st finalize
-null bytes padding
-right rotation

---
What is DAZH-512
---
DAZH-512 is 512bit hash function "designed" by me [2015]. It is SHA512 using
4 rounds of Chicha core & 16 constants as its Compress, and with another
(blank) finalization to fit the theme 'light hashing, heavy finalizing'
(2, 2+2) to achieve high performance w/o (perhaps) sacrificing safety.
It is not tested for its crypto strength, thus non-crypto.
Implemented in VPascal2.1, it reaches:
 ~0.21 Gb/sec on Celeron 1007U 'Ivy Bridge' 1.5Ghz (mobile)
Features:
-local wide pipe
-removes big endianess
-real double-finalize
-byte message length, put on the front of 1st finalize
-null bytes padding
-right rotation

---
What is EPHS
---
EPHS is a memory-hard Password Hashing Scheme "designed" by EddyHawk [2015].
It attempts to solve 'problems' with PHC finalists by being a simplest,
 easiest, conceptually fastest, hybrid PHS which is immune to cache-timing
 attacks.
Here it uses DAZH-512 (but actually allows any 512bit hash function)
 & Chicha/2 rounds (but actually allows any Salsa20/r or Chacha/r).
EPHS for CHIXA uses 4Mb mem & 6 iterations.
 It takes ~300 ms on my 7th cpu @0.8Ghz.
Why not wait for PHC winner?
 Q3 2015 is the date. I get bored waiting :-)
 I want to learn about PHS by making my own.

---
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 XCHICHA. XCHICHA stream cipher for CHIXA is thus
adapted by me from that collection [SALSA 18 Jul 2009], then compiled under
Virtual Pascal v2.1b279.

SHA-512 hash function for CHIXA 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 XCHICHA support to WE source of SALSA20, I also apply
user-customizable round number. Thus users of CHIXA 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, CHICHA internals in CHIXA is now also coded in BASM32!
Finally I manage to code it myself.
And since CHICHA requires less instructions than SALSA20, CHIXA 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)

---
CHIXA specific features
---
It accepts 256bit key only & defaults to 14 rounds

192bit IV

Custom round number, from 0-65535

BASM32 core

To improve speed, CHIXA avoids using (& implementing) chichi_encrypt_bytes
& instead using chichi_keystream_bytes. A special buffer is prepared to hold
keystream from chichi_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 CHIXA so it can use single full buffer,
with few expenses such are additional 64byte mem, & more complex calculations
for xor-ing. Thus CHIXA can utilize full buffer for (de)crypt & Fast Verify,
plus (de)crypting the random-sized random-data addition is simplified.

Self-reliance
All important elements in this crypter (except the PRNG) are based on Chicha:
the cipher itself, both hash functions, & KDF.

---
Warning
---
Of course that users specifying non-default value (say 11 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 1. Values < 7 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 14, while if you specify > 65535, it will default to 65535.

---
Notes for certain number of rounds
---
  2: incompressible keystream
  7: 'minimal safe' naively deduced from SALSA20/9 & CHACHA/8
 10: should have similar strength to SALSA20/12 or CHACHA/11
 14: should have similar strength to SALSA20/16 or CHACHA/15
 18: should have similar strength to SALSA20/20 or CHACHA/19

End.